Testen von EF Core-Anwendungen

Das Testen ist ein wichtiges Anliegen für fast alle Anwendungstypen – sie ermöglicht es Ihnen, sicherzustellen, dass Ihre Anwendung ordnungsgemäß funktioniert, und macht sie sofort bekannt, wenn das Verhalten in Zukunft zurückgeht. Da tests sich auf die Architektur Ihres Codes auswirken können, empfiehlt es sich dringend, frühzeitige Tests zu planen und eine gute Abdeckung sicherzustellen, wenn sich Ihre Anwendung weiterentwickelt. Dieser einführungsabschnitt bietet einen schnellen Überblick über verschiedene Teststrategien für Anwendungen mit EF Core.

Einbeziehung der Datenbank (oder nicht)

Beim Schreiben von Tests für Ihre EF Core-Anwendung muss eine grundlegende Entscheidung getroffen werden, ob Ihre Tests ihr Produktionsdatenbanksystem umfassen werden – genau wie Ihre Anwendung – oder ob Ihre Tests gegen ein Testdoppel ausgeführt werden, das Ihr Produktionsdatenbanksystem ersetzt. Zwei prominente Beispiele für Testdoubles im EF Core-Kontext sind SQLite im Speichermodus und der In-Memory-Provider.

Eine eingehende Vergleichs- und Analyse der verschiedenen Ansätze finden Sie unter Auswählen einer Teststrategie. Nachfolgend finden Sie eine kurze, Punkt-für-Punkt-Zusammenfassung, die Ihnen dabei hilft, sich mit den verschiedenen Optionen vertraut zu machen.

• Entwickler vermeiden häufig Tests mit ihrem Produktionsdatenbanksystem, da sie glauben, dass dies schwierig oder langsam ist. Dies ist in unserer Erfahrung nicht immer der Fall, und wir empfehlen, diesem Ansatz eine Chance zu geben: Tests mit Ihrem Produktionsdatenbanksystem bieten Techniken für eine zuverlässige und effiziente Ausführung. Das Schreiben von mindestens einigen Tests für Ihre Datenbank ist in jedem Fall erforderlich – um sicherzustellen, dass ihre Anwendung tatsächlich mit Ihrer Produktionsdatenbank funktioniert - und Tests, die nicht mit der Datenbank verbunden sind, können eingeschränkt sein, was Sie testen können (siehe unten).
• Der In-Memory-Anbieter verhält sich nicht wie Ihre echte Datenbank auf viele wichtige Weise. Einige Features können überhaupt nicht mit ihr getestet werden (z. B. Transaktionen, rohes SQL), während sich andere Features vielleicht anders verhalten als in der Produktionsdatenbank (z. B. Groß-/Kleinschreibung in Abfragen). Während der Arbeitsspeicher für einfache, eingeschränkte Abfrageszenarien funktionieren kann, ist sie stark eingeschränkt und wir raten davon ab.
  • Das Mocken DbSet für Abfragen ist komplex und schwierig und leidet unter den gleichen Nachteilen wie der Ansatz im Hauptspeicher; wir raten auch davon ab.
• Der SQLite-In-Memory-Modus bietet eine bessere Kompatibilität mit relationalen Produktionsdatenbanken, da SQLite selbst eine vollwertige relationale Datenbank ist. Es gibt jedoch noch einige wichtige Diskrepanzen zwischen SQLite und Ihrer Produktionsdatenbank, und einige Features können überhaupt nicht getestet werden (z. B. anbieterspezifische Methoden auf EF. Funktionen).
• Für einen Testansatz, mit dem Sie einen zuverlässigen Test für alle Funktionen Ihres Produktionsdatenbanksystems verwenden können, ist es möglich, eine Repositoryebene in Ihrer Anwendung einzuführen. Auf diese Weise können Sie EF Core vollständig vom Testen ausschließen und das Repository vollständig modellieren. Dies ändert jedoch die Architektur Ihrer Anwendung auf eine Weise, die erheblich sein könnte, und erfordert mehr Implementierungs- und Wartungskosten.

Weiterführende Lektüre

Ausführlichere Informationen finden Sie unter Auswählen einer Teststrategie. Implementierungsrichtlinien und Codebeispiele finden Sie unter Testen gegen Ihr Produktionsdatenbanksystem und Testen ohne Ihr Produktionsdatenbanksystem.