Public

Celem zadania jest wykonanie unit testów przy użyciu PHPUnit dla modułów PHP w datasource/src/include/modules

1. 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ładPrzykład

     tests/functional/include/modules/module-agreements w testach i include/modules/module-agreements w ds/src

   • 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ładPrzykład

     Ten moduł nie ma unit testów ale ma functional testy

   • 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ładPrzykład

     Testowana funkcja to read_single_data więc plik nazywa się readSingleData_test.php

   • 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ł
     • Aby uruchomić tylko testy z jednego pliku wpisujemy vendor/bin/phpunit ścieżka/do/testu.php PrzykładPrzykład

       vendor/bin/phpunit tests/functional/include/modules/module-agreements/addData_test.php

     • Aby uruchomić tylko jeden test z jednego pliku wpisujemy vendor/bin/phpunit ścieżka/do/testu.php --filter nazwaTestu PrzykładPrzykład

       vendor/bin/phpunit tests/functional/include/modules/module-agreements/addData_test.php --filter testAddData_returnTrueWhenTemplateCreated

   • 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ładyPrzykłady
     • Przykład najprostszego functional testu - testReadSingleData_returnArrayWithTemplateData
     • Przykład gdy w nazwie testu podano jaki wyjątek powinien zostać wyłapany ponieważ test sprawdza odpowiedni wyjątek - testSelectAgreementsByValue_throwModuleIsNullExceptionWhenTableValueIsNull
     • Przykład gdy w nazwie testu dodano wytłumaczenie wyniku - testAddData_doesntThrowAnyExceptionWhenContentDataValueIsEmpty_BecauseContentIsOptional
2. Dodatkowe uwagi do tworzenia testów dla modułów PHP
   • Klasy testów nazywają się w formacie ModuleNazwaFunctionalLubUnitNazwaFunkcjiTest PrzykładyPrzykłady
     • ModuleAgreementsFunctionalAddDataTest - Functional testy funkcji add_data module-agreements
     • ModuleAutosuggestUnitTest - Unit testy module-autosuggest
   • 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
3. 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
4. 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ć loadCustomFixtureOnSetUp Przykł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ć disableLoadStandardFixture Przykład w którym podczas ładowania większej ilości access pointów nie ładuje tych w domyślnych Fixture
5. Co testować PokażPokaż
   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
6. Pomysły na wykorzystanie testów
   To akurat tylko kilka moich pomysłów Pokaż pomysłyPokaż pomysły
   • 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*
7. 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