Testowanie aplikacji korzystających z rozwiązania EF Core

Testowanie jest ważnym problemem dla prawie wszystkich typów aplikacji — pozwala zapewnić poprawne działanie aplikacji oraz natychmiast wykrywać regresję zachowania aplikacji w przyszłości. Ponieważ testowanie może mieć wpływ na sposób tworzenia architektury kodu, zdecydowanie zaleca się zaplanowanie wczesnego testowania i zapewnienie dobrego pokrycia w miarę rozwoju aplikacji. Ta sekcja wprowadzająca zawiera krótkie omówienie różnych strategii testowania aplikacji korzystających z rozwiązania EF Core.

Czy należy uwzględnić bazę danych

Jedna z podstawowych decyzji podczas pisania testów dla aplikacji korzystających z rozwiązania EF Core polega na tym, czy testy będą obejmować produkcyjny system baz danych — tak jak robi to aplikacja — lub czy testy będą uruchamiane względem duplikatu testowego, który zastępuje produkcyjny system baz danych. Dwa istotne przykłady duplikatów testowych w kontekście rozwiązania EF Core to baza danych SQLite w trybie pamięci i dostawca w pamięci.

Aby uzyskać szczegółowe porównanie i analizę różnych podejść, zobacz Wybieranie strategii testowania. Poniżej znajduje się krótkie podsumowanie punkt po punkcie, które ułatwi rozpoczęcie pracy z różnymi opcjami:

• Deweloperzy często unikają testowania względem produkcyjnego systemu baz danych, ponieważ uważają, że jest to trudne lub powolne. Z naszych doświadczeń wynika, że nie zawsze jest to prawdą, więc sugerujemy, aby wypróbować takie podejście: testowanie względem produkcyjnego systemu baz danych zapewnia techniki niezawodnego i wydajnego testowania. Pisanie co najmniej niektórych testów względem bazy danych jest zazwyczaj konieczne w każdym przypadku, aby upewnić się, że aplikacja rzeczywiście działa przy użyciu produkcyjnej bazy danych. Poza tym testy, które nie obejmują bazy danych, mogą mieć ograniczone możliwości (zobacz poniżej).
• Istnieje wiele istotnych różnic między zachowaniem dostawcy w pamięci a prawdziwą bazą danych. Niektórych funkcji nie można w ogóle testować (np. transakcji, nieprzetworzonego kodu SQL), a inne funkcje mogą zachowywać się inaczej niż produkcyjna baza danych (np. uwzględnianie wielkości liter w zapytaniach). Korzystanie z pamięci może sprawdzać się w prostych, ograniczonych scenariuszach zapytań, ale ta metoda jest istotnie ograniczona i odradzamy jej stosowanie.
  • Pozorowanie obiektu DbSet do uruchamiania zapytań jest złożone i trudne oraz ma takie same wady jak podejście z użyciem pamięci, dlatego odradzamy również tę metodę.
• Oprogramowanie SQLite w trybie pamięci zapewnia lepszą zgodność z produkcyjnymi relacyjnymi bazami danych, ponieważ oprogramowanie SQLite jest relacyjną bazą danych o pełnej funkcjonalności. Jednak nadal będą występować istotne rozbieżności między oprogramowaniem SQLite i produkcyjną bazą danych, a niektórych funkcji nie można w ogóle testować (np. metod specyficznych dla dostawcy we właściwości EF.Functions).
• W przypadku podejścia do testowania, które umożliwia użycie niezawodnego duplikatu testowego dla wszystkich funkcji produkcyjnego systemu baz danych, można wprowadzić warstwę repozytorium w aplikacji. W ten sposób można całkowicie wykluczyć rozwiązanie EF Core z testowania oraz w pełni pozorować repozytorium, ale takie podejście zwiększa koszty implementacji i konserwacji oraz może istotnie zmienić architekturę aplikacji.

Dalsze informacje

Aby uzyskać więcej szczegółowych informacji, zobacz Wybieranie strategii testowania. Aby uzyskać wskazówki dotyczące implementacji i przykłady kodu, zobacz Testowanie względem produkcyjnego systemu baz danych i Testowanie bez produkcyjnego systemu baz danych.