Testen von EF Core-Anwendungen

Das Testen ist für nahezu alle Anwendungstypen eine wichtige Angelegenheit. Dadurch können Sie sicherstellen, dass Ihre Anwendung ordnungsgemäß funktioniert und sofort bekannt wird, ob ihr Verhalten in Zukunft Rückschritte macht. Da sich Tests auf die Architektur Ihres Codes auswirken können, wird dringend empfohlen, frühzeitig einen Test zu planen und eine gute Abdeckung sicherzustellen, wenn sich Ihre Anwendung weiterentwickelt. Dieser Einführungsabschnitt bietet eine kurze Übersicht über verschiedene Teststrategien für Anwendungen, die EF Core verwenden.

Einbeziehen der Datenbank (oder nicht)

Wenn Sie Tests für Ihre EF Core-Anwendung schreiben, müssen Sie eine grundlegende Entscheidung treffen, ob Ihre Tests das Produktionsdatenbanksystem einbeziehen (so wie Ihre Anwendung) oder ob die Tests mit einem Testdouble ausgeführt werden, wodurch Ihr Produktionsdatenbanksystem ersetzt wird. Zwei wichtige Beispiele für Testdoppel im EF Core-Kontext sind der SQLite-In-Memory-Modus und der In-Memory-Anbieter.

Einen ausführlichen Vergleich und eine Analyse der verschiedenen Ansätze finden Sie unter Auswählen einer Teststrategie. Im Folgenden finden Sie eine kurze punktuelle Zusammenfassung, die Ihnen dabei hilft, mit den verschiedenen Optionen zu starten:

• Entwickler*innen vermeiden häufig Tests mit ihrem Produktionsdatenbanksystem, da sie der Meinung sind, dass dies schwierig oder langsam ist. Das muss nicht immer der Fall sein, daher wird empfohlen, dem folgenden Ansatz eine Chance zu geben. Unter Testen für Ihr Produktions-Datenbanksystem finden Techniken für eine zuverlässige und effiziente Durchführung. Es ist normalerweise erforderlich, zumindest einige Tests für Ihre Datenbank zu schreiben, um sicherzustellen, dass Ihre Anwendung tatsächlich für Ihre Produktionsdatenbank funktioniert, und Tests, die die Datenbank nicht betreffen, können hinsichtlich ihrer Möglichkeiten eingeschränkt werden (siehe unten).
• Der In-Memory-Anbieter verhält sich in vielerlei Hinsicht nicht wie Ihre echte Datenbank. Einige Features können nicht damit getestet werden (z. B. Transaktionen oder unformatierte SQL), während andere Features sich möglicherweise anders verhalten als Ihre Produktionsdatenbank (z. B. Unterscheidung von Groß- und Kleinschreibung in Abfragen). Auch wenn der In-Memory-Anbieter für einfache, eingeschränkte Abfrageszenarios verwendet werden kann, ist er jedoch stark eingeschränkt und wird daher nicht empfohlen.
  • Die Simulation von DbSet für die Abfrage ist komplex und schwierig und weist dieselben Nachteile wie der In-Memory-Ansatz auf. Deshalb wird von dieser Option ebenfalls abgeraten.
• Der SQLite-In-Memory-Modus bietet eine bessere Kompatibilität mit relationalen Produktionsdatenbanken, da SQLite selbst eine vollständige relationale Datenbank ist. Es gibt jedoch weiterhin einige wichtige Abweichungen zwischen SQLite und Ihrer Produktionsdatenbank, und einige Features können überhaupt nicht getestet werden (z. B. anbieterspezifische Methoden für EF.Functions).
• Für einen Testansatz, bei dem Sie ein zuverlässiges Testdouble für alle Funktionen Ihres Produktionsdatenbanksystems verwenden können, ist es möglich, eine Repositoryebene in Ihrer Anwendung einzuführen. So können Sie EF Core vollständig von Tests ausschließen und für das Repository eine vollständige Simulation erstellen. Dadurch wird die Architektur Ihrer Anwendung jedoch auf erhebliche Weise verändert, und es fallen höhere Kosten für die Implementierung und Wartung an.

Weitere Informationen

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