Unit Tests bieten zahlreiche Vorteile. Sie schaffen Sicherheit für uns Entwickler, weil wir sie jederzeit schnell ausführen können und sofort sehen, ob wir etwas kaputt gemacht haben, wenn wir Details einer Implementierung ändern.

Aber Moment: wieso brechen in bestimmten Fällen ständig unsere Tests, obwohl wir nur Implementierungsdetails geändert haben, nicht jedoch das öffentliche Verhalten einer Methode? Insbesondere dann, wenn eine Methode viele Methoden anderer Klassen aufruft, und man in Unit Tests den Aufruf dieser Methoden mit Mocks testet, entsteht schnell dieses Problem. Die Unit Tests bieten nun keine Sicherheit mehr und haben wenig Nutzen, da sie Implementierungsdetails testen und damit genau das tun, wofür sie nicht gedacht und nicht geeignet sind. Eigentlich wollen wir doch Änderungen vornehmen können, ohne dass die Tests brechen, wenn sich die öffentliche Schnittstelle nicht ändert.

Als Alternative zu Unit Tests kommen in solchen Fällen Integration Tests infrage. Die haben den Ruf, dass sie langsam und fehleranfällig sind, weil sie meistens eine echte Datenbank verwenden.

Aber das muss nicht sein. Im .NET Umfeld bietet Entity Framework Core eine interessante Möglichkeit, Integration Tests umzusetzen, die fast genau so schnell laufen wie Unit Tests. Damit erreichen wir, dass wir in dem oben beschriebenen Szenario Sicherheit zurückgewinnen, ohne dass wir Abstriche bei der Ausführungsgeschwindigkeit machen müssen.

In diesem Vortrag wird zunächst das beschriebene Problem anhand eines Code Beispiels erläutert. Anschließend wird im Live Coding demonstriert, wie sich schnelle Integration Tests konkret mit .NET, C# und Entity Framework Core umsetzen lassen.