Testowanie aplikacji EF Core

Testowanie jest ważnym problemem dla prawie wszystkich typów aplikacji — pozwala upewnić się, że aplikacja działa poprawnie i sprawia, że natychmiast wiadomo, czy jej zachowanie ulega regresji 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 platformy EF Core.

Dotyczenie bazy danych (lub nie)

Podczas pisania testów dla aplikacji EF Core należy podjąć jedną z podstawowych decyzji, czy testy będą obejmować produkcyjny system bazy danych — podobnie jak w przypadku aplikacji — lub czy testy będą uruchamiane względem testu dwukrotnego, co zastępuje produkcyjny system bazy danych. Dwa znaczące przykłady podwojeń testowych w kontekście platformy EF Core to 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 pomoże Ci zorientować się w różnych opcjach.

• Deweloperzy często unikają testowania pod kątem produkcyjnego systemu bazy danych, ponieważ uważają, że jest to trudne lub powolne. Według naszego doświadczenia, nie zawsze tak jest, i sugerujemy wypróbowanie takiego podejścia: Testowanie w systemie bazy danych produkcyjnej zapewnia techniki niezawodnego i wydajnego wykonywania tej czynności. Pisanie co najmniej niektórych testów względem bazy danych jest zwykle konieczne w każdym przypadku — aby upewnić się, że aplikacja rzeczywiście działa w odniesieniu do produkcyjnej bazy danych — i testy, które nie obejmują bazy danych, mogą być ograniczone do tego, co umożliwiają testowanie (patrz poniżej).
• Dostawca magazynujący dane w pamięci nie będzie zachowywał się jak prawdziwa baza danych pod wieloma ważnymi względami. Niektórych funkcji nie można w ogóle przetestować (np. transakcji, nieprzetworzonych danych SQL). Inne funkcje mogą zachowywać się inaczej niż produkcyjna baza danych (np. wielkość liter w zapytaniach). Chociaż przetwarzanie w pamięci może działać w przypadku prostych, ograniczonych scenariuszy zapytań, ma ono duże ograniczenia i odradzamy jego używanie.
  • ** Mockowanie DbSet do zapytań jest skomplikowane i trudne oraz cierpi na te same wady, co podejście in-memory. Zniechęcamy również do tego.
• Funkcja SQLite w trybie pamięci zapewnia lepszą zgodność z produkcyjnymi relacyjnymi bazami danych, ponieważ sqLite jest pełną, relacyjną bazą danych. Jednak nadal będą występować pewne istotne rozbieżności między bazą danych SQLite i produkcyjną bazą danych, a niektóre funkcje nie mogą być w ogóle testowane (np. metody specyficzne dla dostawcy w programie EF. Funkcje).
• W przypadku podejścia testowego, które umożliwia użycie niezawodnego testu dwukrotnego dla wszystkich funkcji produkcyjnego systemu bazy danych, można wprowadzić warstwę repozytorium w aplikacji. Dzięki temu można całkowicie wykluczyć EF Core z testowania i w pełni zamockować repozytorium; To jednak prowadzi do zmiany architektury aplikacji w sposób, który może być znaczący, i obejmuje wyższe koszty implementacji i utrzymania.

Dalsze informacje

Aby uzyskać bardziej szczegółowe informacje, zobacz Wybieranie strategii testowania. Aby uzyskać wskazówki dotyczące implementacji i przykłady kodu, zobacz Testowanie pod kątem produkcyjnego systemu bazy danych i Testowanie bez produkcyjnego systemu bazy danych.