Krótka odpowiedź to Przeczytaj wpis The Fine Manual na temat testowania baz danych w podręczniku PHPUnit .
A teraz długa odpowiedź...
Pierwszą rzeczą do zapamiętania o testowaniu jednostkowym jest to, że należy je wykonywać w izolacji ze wszystkich innych komponentów. Często ten cel jest upraszczany za pomocą technik odwrócenia kontroli (IoC), takich jak wstrzykiwanie zależności . Kiedy twoje klasy wyraźnie pytają o ich zależności w metodach konstruktora, jest to prosta operacja imitacja te zależności, abyś mógł przetestować pozostały kod w izolacji.
Testowanie kodu, który współdziała z modelami, jest jednak nieco inne. Zazwyczaj wstrzykiwanie modeli do klasy, w której chcesz uzyskać do nich dostęp, nie jest praktyczne ani wskazane. Twoje modele są zazwyczaj „głupie” strukturami danych, które ujawniają ograniczone lub żadne możliwości. W rezultacie ogólnie akceptowalne jest (pod względem testowalności) tworzenie instancji modeli w locie wewnątrz wstrzykiwanych w inny sposób klas. Niestety, utrudnia to testowanie kodu bazy danych, ponieważ, jak zauważa dokumentacja PHPUnit:
Jak więc izolować i testować kod, który współdziała z bazą danych, jeśli modele nie są bezpośrednio wstrzykiwane? Najprostszym sposobem na to jest użycie urządzeń testowych .
Ponieważ na pewno już używasz PDO lub biblioteka ORM oparta na PDO (prawda?), konfigurowanie urządzeń jest tak proste, jak zaszczepienie podstawowej bazy danych SQLite lub pliku XML danymi, aby pomieścić twoje przypadki testowe i użycie tego specjalnego połączenia z bazą danych podczas testowania kodu, który współdziała z bazą danych. Możesz określić to połączenie w pliku startowym PHPUnit, ale prawdopodobnie bardziej semantycznie właściwe jest skonfigurowanie Przypadek testowy bazy danych PHPUnit
.
Ogólnie przyjęte najlepsze praktyki dotyczące testowania kodu DB (są również powtórzone w dokumentacji PHPUnit na temat testowania DB):
- Skonfiguruj urządzenie
- Testowany system ćwiczeń
- Zweryfikuj wynik
- Zburzenie
Podsumowując, wszystko, co musisz zrobić, to stworzyć „fikcyjną” bazę danych i sprawić, by Twój kod wchodził w interakcję z tymi znanymi danymi zamiast z rzeczywistą bazą danych, której używałbyś w produkcji. Ta metoda pozwala skutecznie wyizolować testowany kod, ponieważ zajmuje się znanymi danymi, a to oznacza, że możesz tworzyć określone/testowalne twierdzenia dotyczące wyników operacji na bazie danych.
AKTUALIZUJ
Tylko dlatego, że jest to niezwykle przydatny przewodnik po tym, co nie do zrobienia w kodzie, jeśli chcesz promować testowalność, dodaję link do Jak napisać 3v1L, nietestowalny kod . Nie jest związany w szczególności z testowaniem baz danych, ale mimo to jest pomocny. Miłego testowania!
AKTUALIZACJA 2
Chciałem odpowiedzieć na komentarz dotyczący odkładania testowania modelu, ponieważ istniejąca baza kodu nie implementuje PDO dostęp do bazy danych:
Twoje modele nie muszą używać PDO do implementacji rozszerzenia DbUnit PHPUnit.
Ułatwi ci to trochę życie, jeśli użyjesz PDO, ale nie musisz tego robić. Załóżmy na przykład, że zbudowałeś swoją aplikację za pomocą wbudowanego w PHP pg_* Funkcje PostgreSQL. PHPUnit nadal pozwala na określenie urządzeń i nadal może je odbudować dla każdego testu - wystarczyłoby wskazać połączenie podczas wykonywania testów do tego samego zasobu, którego rozszerzenie DbUnit używa dla swojego urządzenia.
