Na początku tego miesiąca zaczęliśmy przyglądać się instalacji PHPUnit w Visual Studio Code, a ostatecznym celem jest nauczenie się pisania testów jednostkowych dla naszych projektów opartych na WordPressie.
W tym celu ten post zakłada, że przeczytałeś następujące posty i zakłada, że nadrobiłeś kilka poprzednich postów:
- Środowisko programistyczne WordPress (przy użyciu menedżera pakietów)
- IDE do programowania WordPress
- Praca z ustawieniami użytkownika w Visual Studio Code
I oczywiście zainstalowanie PHPUnit w Visual Studio Code, jak link powyżej. Gdy to zrobisz, będziemy gotowi do kontynuowania. Należy jednak pamiętać, że będzie to tradycyjny lub kompleksowy kurs pisania testów jednostkowych.
Zamiast tego chodzi o pisanie testów jednostkowych dla projektów WordPress.
Testy jednostkowe z PHPUnit, część 1: Konfiguracja
Zanim zagłębię się w to zbyt głęboko, chcę wyjaśnić, że nie jest to post poświęcony programowaniu opartemu na testach, ale post, który kładzie podwaliny pod zrozumienie pisania testów jednostkowych. A potem, ostatecznie, będziemy pracować nad pisaniem testów jednostkowych dla naszego kodu.
Dla tych z was, którzy wcześniej czytali testy jednostkowe, wiedzą, że pisanie testów jednostkowych to temat, na który jest dużo informacji, a ten post nie będzie próbował tego wszystkiego omówić. Zamiast tego przyjmie bardziej pragmatyczne podejście do pisania testów jednostkowych dla wtyczek opartych na WordPressie, aplikacji internetowych i tym podobnych.
1 Pisanie testów jednostkowych
Za każdym razem, gdy po raz pierwszy zaczniesz pisać testy jednostkowe, zobaczysz zarówno ideę metody setup, jak i metody tearDown. Jest to powszechne w PHPUnit (podobnie jak w innych frameworkach testowych). Jest kilka rzeczy dotyczących tych dwóch konkretnych metod, które często powodują problemy.
Krótko mówiąc, ludzie traktują funkcje w następujący sposób:
- setUp jest jak konstruktor, w którym tworzysz instancję swojej klasy, a następnie przygotowujesz wszystko, czego potrzebujesz do testu, w tym testowany obiekt, potrzebne dane i tak dalej.
- tearDown to destruktor, w którym resetujesz wszystko, a następnie usuwasz swoje obiekty. Jest to zwykle bardziej powszechne w językach kompilowanych, ale nie można tego pominąć również w PHPUnit.
I chociaż całkowicie to rozumiem, nie zawsze tak jest. Mówię tu też z doświadczenia. Zamiast tego, stąd pochodzi faktyczne testowanie jednostek fraz. Chodzi o testowanie kodu jednostek i robienie tego w przejrzysty, zwięzły sposób.
Po co więc te metody? Może to być szczególnie trudny do złamania nawyk, a nawet model koncepcyjny do zerwania, gdy po raz pierwszy wchodzisz w proces. W tym celu chcę zbadać cel każdej metody, a następnie jak podejść do tego podczas pracy z projektami opartymi na WordPressie.
I jak zwykle postaram się, aby było to jak najprostsze i pragmatyczne. Znacznie mniej interesuje mnie teoria kryjąca się za pewnymi rzeczami, niż to, jak może ona dobrze służyć zarówno mojej firmie, jak i moim projektom. (Oczywiście nie chodzi o pominięcie teorii, ale nie ma na to czasu, a ten blog nie jest tym.)
2 Funkcja konfiguracji
Chociaż zaczynam od krótkiego omówienia metody konfiguracji, ważne jest, aby pamiętać, że jej siostrzana funkcja (jak uważają niektórzy) nie zawsze jest potrzebna.
Na przykład, jeśli piszesz kod, w którym wszystko, co robisz, to tworzenie wystąpienia obiektu lub zestawu obiektów, metoda tearDown może nie być potrzebna. Omówię to bardziej szczegółowo w następnej sekcji.
Powiedziawszy to, załóżmy, że masz klasę, która jest odpowiedzialna za wykonanie trochę logiki domeny. Pamiętaj, że na potrzeby tego posta nie zajmujemy się kodem, który będzie robił rzeczy, które WordPress robi naturalnie i który ma już własny zestaw testów.
Rozumiem przez to, że zajmujemy się kodem, który działa konkretnie w problematycznej domenie. Na przykład, być może zajmujemy się pisaniem klasy, która buforuje dane w bazie danych. Jedną z informacji odpowiedzialnych za buforowanie informacji jest to, jak długo dane powinny być buforowane. Tak więc kandydat do testu jednostkowego mógłby za pomocą tego, że jesteśmy w stanie ustawić i zmienić ilość czasu, prawda?
To prawda, że być może te dane są zakodowane na sztywno, ale dla celów przykładu załóżmy, że jest inaczej. Oznacza to, co następuje:
- Mamy klasę, która służy jako nasza pamięć podręczna,
- Klasa przechowuje fragment danych instancji, jak długo powinien być ustawiony cache,
- Czas pamięci podręcznej można ustawić z zajęć innych firm,
- Czas pamięci podręcznej można odczytać z zajęć innych firm.
Oznacza to, że test jednostkowy obejmowałby:
- Założenie klasy,
- Definiowanie wartości,
- Stwierdzenie, że zdefiniowana wartość jest zgodna z oczekiwaniami,
- Zmiana wartości,
- Zaktualizowano wartość, która została zmieniona.
Tak więc podstawowa klasa może wyglądać mniej więcej tak (cała dokumentacja jest pominięta poza klasą w celu zachowania możliwie zwięzłego kodu):
Zauważ, że domyślnie mamy ustawiony czas pamięci podręcznej na 12 godzin (w sekundach). Zajęcia wspierają również umiejętność zmiany i odczytywania czasu trwania.
Oznacza to, że możemy pisać testy, które testują:
- jeśli wartość początkowa jest taka, jak oczekiwano,
- czy nowa wartość jest zgodna z oczekiwaniami (i czy zastępuje wartość początkową)
Jedną z rzeczy, na które chciałbym zwrócić uwagę w powyższym kodzie, jest to, że możesz przeczytać, że każdy test powinien mieć pojedynczą asercję, podczas gdy testNewDuration ma wyraźnie dwie asercje.
Zwykle przyjmuję ideę jednego stwierdzenia na test jako praktyczną regułę. Na przykład w tym przypadku chcę zapewnić, że wartość początkowa jest nadpisywana lub nie jest nigdzie przechowywana, a nowa wartość jest przechowywana.
Jednak nie zawsze tak jest, więc może być konieczne ostrożne traktowanie tego rodzaju sytuacji.
Jak widać, nie ma to nic wspólnego z WordPress; ma to jednak związek z logiką testowania związaną konkretnie z daną domeną. Mianowicie czas trwania pamięci podręcznej. I na tym właśnie polega sedno testowania jednostkowego: testowanie logicznego zachowania jednostek kodu, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami.
I w zależności od tego, kiedy piszesz ten kod, możesz mieć nieudane testy. Może to ostatecznie pomóc w projektowaniu klas, ale to inny temat, a nie ten, który jest częścią tego postu.
Przeprowadzanie testów
Gdy testy zostaną napisane, ważne jest, aby móc je wykonać, aby sprawdzić, czy zdają, czy nie, co się sprawdza, a co nie. Ale jeszcze nie skończyliśmy. Chcę przedstawić kompleksowe spojrzenie na testy jednostkowe w kontekście WordPress, a to dotyczy omówienia tego, co zapewnia WordPress, a czego nie, niektórych błędnych przekonań i jak uruchomić te testy w terminalu lub w Visual Studio Code.
W następnym poście z tej serii przyjrzymy się funkcji tearDown i jak (i kiedy) jej używać, kiedy jest potrzebna, a kiedy nie, a następnie przyjrzymy się bliżej jednostce ogólnie testowanie w WordPressie.
Ostatecznie pracujemy nad uzyskaniem pełnego obrazu tego, jak to zrobić i jak zrobić to dobrze. Ale ważne jest, aby położyć pod tym podstawę, a zrobienie tego na kilku słupkach jest łatwiejsze niż w przypadku jednego słupka monolitycznego.
Tak więc zbadanie tearDown(), jego zastosowania i sposobu wykonywania testów z wiersza poleceń będzie tematem następnego wpisu z tej serii.