Celem zadania jest wykonanie unit testów przy użyciu PHPUnit dla modułów PHP w datasource/src/include/modules
Organizacja testów¶
- Testy dzielą się na unit i functional
- Functional testy wymagają do działania bazy danych i działającego Doctrine'a (EntityManagera), korzystają z tego powodu z klasy ExtendedTestCase
- Unit testy nie korzystają z bazy danych, nie potrzebują żadnych dodatkowych konfiguracji więc korzystają z podstawowej klasy PHPUnit'a TestCase
- Testy znajdują się w ds/src/tests
- Unit testy w folderze unit
- Functional testy w folderze functional
- Folder core zawiera logikę ExtendedTestCase oraz fixtures
- Ścieżki w folderach z testami powinny być takie jakby zaczynały się od ds/src Przykład
- Oba foldery (functional i unit) powinny mieć taką samą strukturę, jeżeli któreś foldery będą z tego powodu puste można dostawić do nich plik .gitkeep aby Git je dodał do commita Przykład
- Pliki unit testów nazywamy po prostu test.php
- Pliki functional testów nazywamy nazwaFunkcjiWCamelCase_test.php (jest od tego wyjątek o którym napisałem więcej niżej) Przykład
- Testy uruchamiamy przechodząc na develu do ds/src i wpisując
vendor/bin/phpunit
ale spowoduje to uruchomienie wszystkich testów a to nie jest najlepszy pomysł - Każdy test ma zawsze metodę setUp i tearDown o których można coś przeczytaj w dokumentacji
- setUp jest wykonywana gdy test się rozpoczyna (inicjalizacja testu)
- tearDown jest wykonywana po zakończeniu testu
- Staramy się aby nazwa testu mówiła jak najwięcej o nim, stosujemy zasadę że nazwy mają następujący format testNazwaFunkcji_opisCoZwracaTestWJakimPrzypadkuTestujeFunkcję_opcjonalnieDodajemyWytłumaczenieDlaczegoTakSięDziejeJeśliWynikJestNiejasny Przykłady
Dodatkowe uwagi do tworzenia testów dla modułów PHP¶
- Klasy testów nazywają się w formacie ModuleNazwaFunctionalLubUnitNazwaFunkcjiTest Przykłady
- Tworząc testy dla modułów które są strukturalne
- Zmieniamy aby był obiektowy, czyli był klasą która dziedziczy po Module Przykład jak zmienił się moduł ze strukturalnego na obiektowy
- Korzystamy z ModuleUtils do sprawdzania danych, dzięki temu moduły będą zwracać znane wyjątki, w modułach strukturalnych często moduły nie zwracały wyjątków gdy coś poszło nie tak (podano złe dane, nie podano czegoś)
- Można również zwracać samemu wyjątki w kodzie jeśli jest taka potrzeba bez używania ModuleUtils Przykład
O unit testach¶
Unit testy wykonują się bardzo szybko, ale też jest ich bardzo mało. Jako że jest ich mało nie ma potrzeby dzielenia testów na pliki po nazwach funkcji, wewnątrz unit testów można dzielić kod na fragmenty komentarzami
Przykład
O functional testach i fixture¶
Functional testy wykorzystują do działania bazę danych. Fixture uzupełniają bazę danych danymi, co każdy functional test każda tabela w bazie jest czyszczona (TRUNCATE) i uzupełniana od nowa dzięki czemu każdy test na pewno działa na tych samych danach a testy są powtarzalne.Główną wadą tego jest wysoki czas potrzebny na wykonanie takich testów dlatego jeśli chcemy sprawdzić jeden konkretny test lepiej uruchomić tylko go (jak zostało to opisane w Organizacja testów).
Functional testy mogą również na potrzebę testu załadować inne dane, domyślnie ładowane są Fixture które nie mają w nazwie żadnego dodatkowego parametru (Taki zostanie załadowany domyślnie a taki nie zostanie)
- Aby jeden konkretny test w danym pliku używał innych danych należy użyć
loadCustomFixture, Przykład w którym używam Fixture do wyczyszczenia tabeli - Aby wszystkie testy w danym pliku używały innych danych należy w setUp użyć
loadCustomFixtureOnSetUpPrzykład w którym ładuje więcej access pointów - Aby nie ładować w danym teście jakiś domyślnych Fixture należy użyć
disableLoadStandardFixturePrzykład w którym podczas ładowania większej ilości access pointów nie ładuje tych w domyślnych Fixture
Co testować¶
Testy powinny sprawdzać- Czy testowana funkcja działa i zwraca odpowiednie dane - dane porównać przy pomocy assertEquals
- W przypadku gdy funkcja działa na bazie danych a nie zwraca danych można pobrać dane które powinny się zmienić przy pomocy Doctrine'a i sprawdzić czy rzeczywiście działa Przykład
- Jeśli funkcja używa danych z bazy danych sprawdzić jak działa gdy tych danych nie ma - dane można usunąć na potrzeby testu używając
loadCustomFixture, Przykład w którym używam Fixture do wyczyszczenia tabeli - Sprawdzić jakie wyjątki może zwrócić i dla każdego wyjątku napisać jeden test - aby sprawdzić czy wyjątek na pewno jest zwracany, wyjątki można sprawdzać przy pomocy exceptException
- Jeśli funkcja przyjmuje argumenty
- Jeśli argumenty są opcjonalne przetestować kod z nimi/bez nich
- Jeśli argumenty to rozbudowane tablice/obiekty (np. duży obiekt z wieloma możliwościami sortowania danych) przetestować każdą taką możliwość Przykład
Pomysły na wykorzystanie testów¶
To akurat tylko kilka moich pomysłów- Uruchamiać testy po aktualizacji na produkcji - szybko można wtedy wykryć że coś jednak nie działa
- Uruchamiać automatycznie wszystkie testy
- Gdy dodany zostanie nowy commit na mastera - jest chyba skrypt który mógłby to robić, aktualnie wysyła maile gdy dodany zostanie commit
- O danej godzinie, może to być np. o północy tak jak wgrywana wtedy jest kopia bazy danych na develu
Gdy po sprawdzeniu testów okaże się że któryś nie przeszedł można wysyłać do autora maila/tworzyć jakiegoś automatycznego ticketa.
Nie powinno być też problemów z tym aby odpowiednio czytać wyniki testów, PHPUnit pozwala na własne klasy do logowania wyników testów i można to łatwo wykorzystać na nasze potrzeby
Dodatkowo należy¶
- Poprawić skrypt mkmod.py który tworzy nowy moduł tak aby dodawał automatycznie odpowiednie foldery w testach i tworzony moduł był obiektowy
- Poprawić ws_stateful.php aby działał z obiektowymi modułami
- Dodać do config.json.php dane do bazy danych z której korzystają functional testy
- Poprawić skrypt reconf.py aby można było podać dane do połączenia dla bazy danych functional testów