Pod koniec ubiegłego miesiąca zacząłem mówić o pisaniu testów jednostkowych w PHPUnit dla kodu opartego na WordPressie. Dotyczyło to przede wszystkim pomysłu skonfigurowania PHPUnit, funkcji setUp i pisania podstawowych testów.
Nie omówiłem jednak tego, co wiem o funkcji tearDown, która wciąż jest ważną cechą pisania przy użyciu testów. Co więcej, są też dwa sposoby rozważenia pisania testów dla projektów WordPress.
Mianowicie:
- pisanie testów specjalnie dla wtyczek i funkcjonalności warstwy aplikacji,
- przeprowadzanie testów jednostkowych aplikacji WordPress.
Zanim jednak przejdę dalej z tym konkretnym postem, radzę nadrobić zaległości o tym, co omówiłem do tej pory. Obejmuje to następujące posty:
- Środowisko programistyczne WordPress (przy użyciu menedżera pakietów)
- IDE do programowania WordPress
- Praca z ustawieniami użytkownika w Visual Studio Code
- Pisanie testów jednostkowych za pomocą PHPUnit, część 1: Konfiguracja
Gdy to zrobisz, wróć do tego postu i kontynuujmy omawianie funkcji tearDown i tego, jak faktycznie wyglądają testy jednostkowe w kontekście WordPressa.
Testy jednostkowe z PHPUnit, część 2: The Tear Down
Zanim przejdziemy dalej, pamiętaj, że programiści często traktują funkcję setup jak konstruktor, a funkcję tearDown jak destruktor; pamiętaj jednak, że to drugie nie zawsze jest potrzebne.
Oto dobra praktyczna zasada do zapamiętania:
- Wszystko, czego potrzebuje funkcja testowa, wywoła funkcję setUp, aby potrzebne były klasy.
- Funkcja tearDown nie zawsze jest potrzebna, ponieważ funkcja setUp może ponownie zainicjować klasę.
Co to oznacza dla funkcji tearDown, jeśli nie resetuje ona danych utworzonych podczas funkcji konfiguracji?
1 Funkcja odrywania
Najlepszą radą, jaką mogę udzielić w związku z funkcją tearDown, jest to, że należy jej użyć, jeśli podczas jednego z testów zostanie coś ustawione.
Może to być coś zapisanego w bazie danych, coś zapisanego w dzienniku lub, bardziej ogólnie, coś zapisanego na dysku twardym.
Tak więc, jeśli test zapisze rekord lub plik, metoda rozdzielania zostanie uruchomiona po teście i powinna usunąć wszystkie testy zapisane na dysku, które nie są częścią testu, ale nie są na stałe potrzebne w następnym teście lub które należy po sobie posprzątać.
W pewnym sensie to jest jak destruktor, ale jeśli nigdy nie używałeś języka, który ma destruktor, to nazewnictwo albo wydaje się nieistotne, albo nie ma sensu.
Destruktor to specjalna funkcja członkowska, która jest wywoływana po zakończeniu okresu istnienia obiektu. Celem destruktora jest uwolnienie zasobów, które obiekt mógł nabyć podczas swojego życia.
Dlatego może lepiej jest po prostu myśleć o funkcji jako o sposobie sprzątania po teście (a nie w sensie ustawiania zmiennej równej null, ponieważ funkcja setUp może to zrobić).
2 testy jednostkowe dla projektów WordPress
Pisząc testy jednostkowe dla projektów WordPress, musimy upewnić się, że mamy jasność co do rodzaju testów jednostkowych, o których mówimy.
Na przykład to, co będę nazywał klasycznymi lub standardowymi testami jednostkowymi, przebiega zgodnie z metodologią „test-driven development", o której za chwilę opowiem. Z drugiej strony WordPress ma własny zestaw testów jednostkowych dla motywów i tym podobnych, o których również opowiem nieco później w tym poście.
Ale w tej sekcji pomyślałem, że pomocne może być omówienie tego pierwszego, a nie drugiego, aby zobaczyć, jak to może działać.
W poniższym przykładzie piszę testy z wtyczką odpowiedzialną za komunikację z zewnętrznym API. Ta konkretna wtyczka wymaga nazwy użytkownika i hasła lub interfejsu API, a my chcemy się upewnić, że na potrzeby tego postu poprawnie pobiera błąd za każdym razem, gdy uruchamiany jest test.
Zauważ, że czytając ten kod, zobaczysz, jak mówię trochę o refleksji. Niedługo napiszę cały post na temat PHP Reflection, więc rzucę na to trochę światła.
W przypadku poniższego kodu załóżmy jednak, że jest to sposób, w jaki możemy uzyskać dostęp do właściwości, które w inny sposób są oznaczone jako prywatne.
Przypomnijmy z ostatniego posta z tej serii, mieliśmy wstępny test, który wyglądał tak:
Zauważ jednak, że w tym teście nie ma funkcji tearDown, która ma sens, prawda? W końcu nic nie jest zapisywane w bazie danych ani w pliku.
Ale powiedzmy, że chcemy wprowadzić przypadek testowy, który będzie miał nazwę pliku, zawartość i zapisze zawartość do pliku. W tym przypadku będą to dane statyczne, ale technicznie może to być wszystko, co zostało zapisane na dysku.
1 Konfiguracja testu
Najpierw chcemy skonfigurować test, definiując nazwę pliku, zawartość pliku i przygotowując właściwości.
Wystarczająco łatwe, prawda?
2 Zapis i odczyt danych
Następnie chcemy zapisać dane, odczytać dane i stwierdzić, że zawartość jest taka sama.
W tym momencie, jeśli uruchomisz test (którego jeszcze technicznie nie omówiłem), zauważysz, że testFile.txt nadal znajduje się w twoim systemie.
3 Korzystanie z funkcji odrywania
Na koniec musimy popracować z metodą tearDown, aby upewnić się, że plik zostanie usunięty po zakończeniu testu jednostkowego. Oto, jak może wyglądać, jeśli zaimplementowałeś kod w sposób podobny do tego, który widzisz powyżej.
Zauważ, że w metodzie tearDown najpierw sprawdzam, czy plik_istnieje. Dzieje się tak dlatego, że jeśli po prostu spróbujesz odłączyć plik, który nie jest obecny, otrzymasz błąd podczas uruchamiania testów, ponieważ jeśli występuje funkcja tearDown, spróbuje usunąć coś po każdej funkcji testowej. A jeśli plik nie istnieje, to nie ma nic do usunięcia, a co za tym idzie, spowoduje to problem.
Więc próbując pisać kod w sposób defensywny, uważam, że jest on odpowiedzialny za sprawdzenie, czy plik istnieje, zanim faktycznie spróbuje go usunąć.
3 Kolejność Operacji
Jeśli chodzi o czyste testy jednostkowe, zwykle czytasz to w kontekście programowania opartego na testach. To duży temat sam w sobie; jednak warto tutaj wspomnieć, jeśli zdecydujesz się na dalsze badania, a nawet wdrożenie go w swoich wysiłkach rozwojowych.
Ogólna idea tego podejścia jest często określana jako „czerwono-zielono-powtórka”. I nie zaprzeczam, jest coś w tym podejściu. Mianowicie, pozwala tobie, jako programiście, pisać kod tak, jak oczekujesz, że będzie działał przed faktycznym napisaniem kodu.
Za tym stoi psychologia: jeśli wiesz, jak działa kod, masz większe szanse na pisanie testów, które zdają; mając na uwadze, że jeśli piszesz testy, jak kod powinien działać, powinieneś napisać lepszy kod.
Niestety nie zawsze możemy sobie pozwolić na ten luksus. Ale to nie znaczy, że powinniśmy wylać przysłowiowe dziecko z wodą. Zamiast tego jestem nastawiony na to, że powinieneś pisać testy, kiedy możesz, a kod pisać później; w przeciwnym razie napisz testy po kodzie.
Ostatecznie przeprowadzanie testów niezależnie od tego będzie lepsze niż ich brak.
4 Testowanie z WordPress
Jeśli chodzi o testowanie jednostkowe w WordPress, jest kilka rzeczy, na które prawdopodobnie natknąłeś się. Czasami treść jest myląca lub może nawet wprowadzać w błąd, jeśli chodzi o „testy jednostkowe w WordPressie”.
Na przykład warto zwrócić uwagę na dwie rzeczy:
- Test jednostkowy tematu. Ten konkretny zestaw treści ma na celu pomóc twórcom motywów przetestować wszystkie główne i mniejsze przypadki dla ich motywów. Nie ma na przykład zautomatyzowanych narzędzi, których można używać w sposób opisany powyżej.
- Testowanie automatyczne. WordPress jest dostarczany z własnym zestawem testów jednostkowych, dzięki czemu nie musimy pisać testów dla większości funkcji WordPressa (np. czy funkcje API działają zgodnie z oczekiwaniami). To pozwala nam skupić się na pisaniu testów jednostkowych dla naszej własnej logiki domeny.
- Testy jednostkowe wtyczek. Jeśli korzystałeś z WP-CLI (lub jesteś nim zainteresowany), prawdopodobnie przeczytałeś tę stronę lub nawet użyłeś tego narzędzia. Jest to przydatne, ale dotyczy również konkretnych aspektów testowania wtyczek WordPress.
Wszystkie powyższe informacje są użyteczną informacją i nie twierdzę, że należy je zignorować. Zamiast tego powinien być połączony z resztą informacji wykorzystanych w tym poście.
Przeprowadzanie testów jednostkowych
W następnym poście przeprowadzę Cię przez wszystko, co musisz wiedzieć, aby skonfigurować plik XML, który poinformuje PHPUnit, gdzie znajdują się testy i jak je uruchomić.
Na razie jednak przejrzyj kod zawarty w tym poście i przygotuj się do zbudowania go w następnym poście z tej serii.