Testowanie jednostek wtyczki WordPress z PHPUnit

Kiedy pracujesz nad wtyczkami i zaczynasz wprowadzać nowe funkcje, dobrą praktyką jest upewnienie się, że istniejąca logika nie jest zepsuta. Bez odpowiedniego testowania, szanse są wysokie, że proste poprawki mogą Śnieżką w koszmar kodowania spaghetti.

W dzisiejszym artykule pokażę Ci, jak skorzystać z testów jednostkowych dla wtyczek WordPress. Chociaż istnieje wiele frameworków testowych, pozostaniemy przy PHPUnit, ponieważ jest to oficjalny framework z wyboru dla WordPress.

Testy jednostkowe WordPress przy użyciu PHPUnit są zazwyczaj ukierunkowane na wtyczki, ale mogą się zdarzyć, że będziesz chciał ich użyć do motywów. Jednak, co do zasady, Twój motyw nie powinien oferować funkcji podobnych do wtyczek.

Krótko przyjrzymy się konfiguracji, charakterystyce testów jednostkowych w WordPress i wreszcie przetestujemy prostą wtyczkę.

Uwaga: Ten artykuł jest przeznaczony dla zaawansowanych programistów WordPress. Jeśli jednak jesteś początkującym lub średniozaawansowanym użytkownikiem, koncepcje omówione tutaj mogą pomóc ci zrozumieć, co dzieje się za kulisami podczas tworzenia aplikacji WordPress.

Będziesz potrzebował praktycznej wiedzy na temat WordPress, PHP i PHPUnit przed nurkowaniem w tym poście. Jeśli nie jesteś pewien lub chcesz odświeżyć, polecam zapoznanie się z poniższymi:

• Rozwój WordPress dla początkujących: pierwsze kroki
• Rozwój WordPress dla początkujących: Nauka PHP
• Rozwój WordPress dla początkujących: tworzenie motywów
• Rozwój WordPress dla początkujących: widżety i menu
• Rozwój WordPress dla początkujących: budowanie wtyczek
• Pierwsze kroki z PHPUnit

Testy jednostkowe: czy jesteśmy po tej samej stronie?

Przede wszystkim testowanie jednostkowe polega na poprawie jakości oprogramowania. Celem jest redukcja błędów przy użyciu systematycznego podejścia. Oszczędzasz czas i wysiłek, uruchamiając Pakiety testowe dla różnych obszarów aplikacji i możesz mieć pewność co do zmian.

Z technicznego punktu widzenia chodzi o pisanie dodatkowego kodu, aby przetestować swoje funkcje lub moduły w izolacji. Polega na przekazywaniu danych wejściowych dla różnych scenariuszy, warunków brzegowych i zapewnieniu, że dane wyjściowe lub zwracane są zawsze zgodnie z oczekiwaniami. Testowana funkcja jest odcięta od reszty systemu. Różni się od testu integracji, w którym testujemy, jak komponenty lub funkcje współpracują ze sobą. Kiedy wprowadzasz nowe zmiany, musisz tylko uruchomić poprzednie testy. To, co działało wcześniej, powinno nadal działać, a natychmiast dowiesz się, czy nie zadziałało.

Jak to pomaga deweloperowi

Sekretem udanych testów jednostkowych jest pisanie mniejszych, mniej złożonych funkcji lub modułów w głównej aplikacji. Umożliwia to testowanie poszczególnych komponentów w izolacji. Każda funkcja powinna wykonać jedno zadanie i wykonać je dobrze. W ten sposób nie przebijesz się przez kilka instrukcji warunkowych ani nie skończysz z kodem spaghetti. Na pewno kończy się pisanie więcej kodu, ale kod, który jest bardziej czytelny i wyższej jakości. I jest to zgodne z suchą (nie powtarzaj się) zasadą kodowania:

„Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie.”

Skoro jesteśmy po tej samej stronie, zaczynajmy.

Wymagania wstępne

Aby rozpocząć, potrzebujesz trzech rzeczy:

• PHPUnit-biblioteka do testowania kodu PHP
• WP-CLI-interfejs wiersza poleceń WordPress do integracji testów z instalacją WordPress
• Konfiguracja WordPress.

Polecam korzystanie ze środowiska programistycznego, takiego jak VVV, ponieważ skonfigurowanie powyższego zajmie trochę czasu i nie chcesz nadmuchać codziennego środowiska pracy. Sprawdź nasz post Konfigurowanie VVV dla rozwoju WordPress, aby uzyskać szczegółowe informacje na temat korzystania z VVV.

Uwaga dla użytkowników Windows:

Nie ma problemu z instalacją Vagrant i VVV na Windows. A jeśli jesteś na Microsoft Windows 10 można kopać go wycięcie-Microsoft wydał Podsystem Windows dla Linuksa (WSL), więc można teraz mieć Ubuntu BASH na Windows. Umożliwi to uruchamianie (prawie) wszystkich natywnych poleceń Linuksa w systemie Windows, a także interakcję z plikami w systemie Windows. Użytkownicy komputerów MAC i Linux zawsze mieli zintegrowaną powłokę.

Będę używał WSL tylko po to, aby udowodnić, że naprawdę działa i nie musisz już instalować oddzielnej maszyny Wirtualnej, aby uzyskać powłokę. Oto jak można skonfigurować WSL.

Przepływ Pracy Programistycznej

Używam NetBeans z Vagrant i VVV w podsystemie Windows dla Linuksa. Daje mi to świetny przepływ pracy, w którym mogę rozwijać i debugować za pomocą NetBeans na moim systemie hosta oraz uruchamiać testy i serwery przy użyciu środowiska wirtualnego VVV.

Wszystko jest automatycznie synchronizowane między systemem hosta a systemem gościa. Tak więc wszelkie testy, które piszę za pomocą NetBeans lub dowolnego edytora na moim hoście, są również synchronizowane z maszyną wirtualną.

Trzymam również moje wtyczki i motywy poza konfiguracjami WordPress i ładuję je w docelowej instancji VVV WordPress za pomocą konfiguracji CustomFile w Vagrant.

To pozwala mi korzystać z Git (Kontrola wersji) bez konieczności synchronizacji niepotrzebnych plików WordPress core.

Oto jak wygląda moja konfiguracja:

Wtyczki i motywy znajdują się w folderze poza WordPress (na hoście) i są ładowane w docelowej instalacji WordPress w maszynie wirtualnej za pomocą następujących CustomFile konfiguracja:

Będę pracować z prostym plugin, PHPUnit-demo-plugin, I instancji WordPress ” test.dev ” stworzony przy użyciu VV create do wykonywania testów jednostkowych.

Ponadto, aby załadować test.projekt dev w NetBeans wraz z wtyczką poza WordPress, stworzyłem link symboliczny do folderu wtyczek, jak poniżej:

Uwaga: Musisz utworzyć dowiązania symboliczne z poziomu komputera hosta:

• Do użytku w systemie Linux / MAC ln-s target link_name
• W systemie Windows użyj wiersza poleceń do uruchomienia mklink / d link_name target

Konfigurowanie PHPUnit dla wtyczki WordPress

Z VVV mamy wszystkie niezbędne narzędzia: PHP, PHPUnit, WP-CLI itp. WP-CLI instaluje również podstawową konfigurację dla ramy testowej, która jest przydatna do uruchamiania testów na plikach podstawowych WordPress.

Rozszerzenie tego dla wtyczek wymaga kilku dodatkowych kroków. Sprowadza się do trzech komend:

• > $cd / srv / www / WordPress-instalacja
• > wtyczka $ wp scaffold-testuje your_plugin
• > $sh wp-content/plugins/your_plugin/bin/install-wp-tests.sh < db_args>

PHPUnit nadpisze bazę danych WordPress, więc najlepiej użyć świeżej instalacji lub utworzyć kopię zapasową istniejącej. Nie trzeba dodawać, że nie uruchamiaj go w swoim środowisku produkcyjnym.

Będę odnosić się do folderów jako katalogów podczas pracy w Linux VM.

Omówmy to szczegółowo. Możesz również zapoznać się z podręcznikiem WP-CLI.

Krok # 1

Aby skonfigurować PHPUnit za pomocą wtyczki WordPress, Uruchom instancję Vagrant za pomocą vagrant up a potem SSH do niego z vagrant ssh. Po wejściu przejdź do katalogu głównego instalacji WordPress.

W moim przypadku pracuję z instalacją WordPress test.dev

> $cd / srv / www / test / htdocs/

Krok # 2

Twoja wtyczka (z komputera hosta) powinna być już dostępna w katalogu wp-contents. Aby skonfigurować testy jednostkowe dla wtyczki, musimy użyć polecenia scaffold WP-CLI, jak poniżej:

wp scaffold plugin-testuje your_plugin

> $wp scaffold plugin-testuje phpunit-demo-plugin

To właśnie się stało.:

Jeśli teraz sprawdzisz katalog wtyczki, zauważysz kilka dodatkowych plików, z których najważniejszy znajduje się w podkatalogu test. PHPUnit automatycznie uruchomi wszystkie testy (pliki z prefiksem test-) znajduje się w katalogu tests. Automatyczne wykrywanie odbywa się poprzez phpunit.xml, który jest głównym plikiem manifestu, który mówi PHPUnit, gdzie znaleźć testy i jak rzeczy są konfigurowane.

Krok # 3

Teraz musimy tylko skonfigurować testową kopię bazy danych dla naszej wtyczki. Po uruchomieniu testów PHPUnit użyje tego do naszego środowiska testowego. Jeśli chcesz użyć działającej instancji bazy danych, pamiętaj, aby wykonać jej kopię zapasową.

Musimy wykonać install-wp-tests.sh skrypt znajdujący się pod „bin/”, który został również stworzony przez polecenie WP scaffold:

bash plugin_dir/bin/install-wp-tests.sh db_name db_user db_password db_host version

• db_name jest nazwą testowej bazy danych (wszystkie dane zostaną usunięte!)
• db_user czy nazwa użytkownika MySQL
• db_pass  czy hasło użytkownika MySQL
• db_host jest hostem serwera MySQL
• Wersja to wersja WordPress

> $bash bin/install-wp-tests.sh wordpress_test root root localhost najnowsze

Krok # 4

Aby sprawdzić, czy wszystko jest poprawnie zainstalowane, wystarczy uruchomić polecenie phpunit. Przykładowy plik testowy próbka.php który został utworzony wcześniej zostanie wykonany.

> $phpunit

Pisanie testów jednostkowych dla WordPressa

Jeśli spojrzysz na zawarte próbka.php w testach zauważysz, że Klasa SampleTest rozszerza Wp_unitestcase i nie PHPUnit_Framework_TestCase. Dzieje się tak dlatego, że WordPress jest dostarczany z własną biblioteką testową, która oferuje specyficzną funkcjonalność WordPress i jest zbudowana na bazie PHPUnit_Framework_TestCase.

Z WP_UnitTestCase, każda metoda, która zaczyna się od test zostanie uruchomiony automatycznie.

Kiedy biegliśmy phpunit powyżej, test_sample() został wykonany, ponieważ został poprzedzony test_ i zapewnił, że Prawda to prawda.

Oto jak możemy wykorzystać Wp_unitestcase do własnych testów:

Wp_unitestcase dostarcza nam fabryki obiektów, metody użytkowe i konkretne twierdzenia WordPress oprócz twierdzeń dostarczanych przez PHPUnit,

Testy WordPress

• Twierdzenia o błędach
  • $this - > assertWPError ($actual, $message)
  • $this - > assertNotWPError ($actual, $message)
  • $this - > assertIXRError ($actual, $message)
  • $this - > assertNotIXRError ($actual, $message)

• Asercje do testowania WP_Query dla znaczników warunkowych
  • $this - > assertQueryTrue ($args)

Np. $this->assertQueryTrue ('is_single', 'is_feed') środki is_single() oraz is_feed() to musi być prawda.

WordPress Fabryka Obiektów

Fabryki bardzo ułatwiają tworzenie postów, taksonomii, użytkowników itp. Używają następujących trzech metod do tworzenia obiektów:

• create() – zwraca ID obiektu wytworzonego obiektu
• create_and_get() – wytworzy i zwróci cały obiekt
• create_many ($count) – tworzy wiele postów na podstawie $ count

Aby utworzyć użytkownika i uzyskać jego identyfikator użytkownika, możemy po prostu zrobić –

$user_id = $this - > factory - > user - > create();

Lub stworzyć użytkownika z określoną rolą WordPress

$user_id = $this->factory->user->create( array( 'role' => 'author' ) );

Inne typy fabryczne to post, załącznik, komentarz, użytkownik, termin, Kategoria, tag, blog, sieć.

Przykłady wykorzystania fabryk

Możesz znaleźć więcej szczegółów na temat każdej fabryki na Trac WordPress

DodatkowesetUp() oraz tearDown()

Wp_unitestcase zapewnia również własne setUp() oraz tearDown() metody, które mogą być używane z PHPUnit setUp() oraz tearDown(). Z tearDown, Wp_unitestcase zresetuje stan WordPress, który mógł ulec zmianie za pomocą metody testowej. I z konfiguracja zajmie się czyszczeniem pamięci podręcznych i resetowaniem zmiennych globalnych. Aby z nich korzystać, wystarczy zadzwonić z parent:: setUp() lub parent:: tearDown()

Na przykład:

Testy WordPress działają na stronie głównej Twojej witryny. Aby uruchomić testy na innej stronie, musisz ją poinstruować, aby to zrobić.

Na przykład, aby uruchomić testy na ekranie administracyjnym Edytuj posty:

Jeśli chcesz przetestować, przechodząc do określonego adresu url, możesz skorzystać z $this - > go_to ($url), a następnie przetestuj z assertQueryTrue

Na przykład:

Testowanie Naszego Pluginu (W Końcu!)

Użyjmy tych informacji i napiszmy kilka testów dla naszej wtyczki demo. Oto link do wtyczki PHPUnit-demo, która dodaje dodatkowy element meta użytkownika, gdy nowy użytkownik typu „Editor” jest tworzony. Wyświetla również meta użytkownika na ekranach profilu, aby administratorzy i użytkownik mogli je zmodyfikować.

Zacznij od usunięcia próbka.php z katalogu tests i utwórz nowy plik, test-PHPUnit-demo-plugin.php.

Uwaga: będę pisać testy w NetBeans na moim hoście i uruchamiać je z PHPUnit na instancji VVV. Wszystkie zmiany zostaną automatycznie zsynchronizowane między dwoma systemami. W ten sposób mogę skorzystać z automatycznego uzupełniania, odwołania do kodu i debugowania za pomocą Xdebug z NetBeans.

Teraz napiszmy kilka testów dla naszej wtyczki. Tutaj tworzymy użytkownika z rolą „autora” i sprawdzamy, czy klucz meta nie został utworzony.

Po uruchomieniu testu za pomocą phpunit (używam phpunit --debug dla szczegółowego wyjścia) powinno przejść:

Teraz stwórzmy nieudany test, tworząc użytkownika z rolą „edytora”, a następnie porównajmy wartość meta użytkownika dla preferred_browser z pustym ciągiem.

Po uruchomieniu phpunit test nie powiedzie się.

Uwaga: gdy twierdzenie się nie powiedzie, nie są uruchamiane żadne inne testy. Można modyfikować to zachowanie w phpunit.xml.

Aby to naprawić, możemy albo sprawdzić, czy wartość meta nie była pusta, albo przeprowadzić porównanie ciągów znaków dla „chrome”. Ponadto podzielimy testy na dwie funkcje – aby testować użytkowników z rolą „Edytora” i bez niej. W ten sposób, rozdzielając twierdzenia, mamy dobry model do znajdowania błędów w miarę ich pojawiania się.

Testowanie wywołania zwrotnego lub jego priorytetu

W naszej wtyczce dodaliśmy wywołanie zwrotne dla Hooka akcji user_register z wartością priorytetową inną niż domyślna z 10. Tutaj możemy skorzystać z has_action funkcja, która zwraca priorytet wywołania zwrotnego na określonym hooku.

Nieudany test jako priorytet musi być większy niż 10

Zaliczenie testu z kontrolą priorytetu większą niż 10

Testowanie składania formularzy

Aby sprawdzić, czy preferred_browser pole jest poprawnie zaktualizowane z profilu użytkownika, będziemy musieli sfałszować zmienną POST, a następnie wywołać metodę, która aktualizuje meta użytkownika. To jest testowanie w izolacji. Martwimy się tylko o funkcję naszej wtyczki, która aktualizuje metę, a nie o resztę systemu, na przykład jeśli formularz profilu został przesłany poprawnie, czy nie.

Nieudany test po aktualizacji wartości meta

Zdany test porównując, że preferred_browser został zaktualizowany do Opera

Oto kompletny kod do testów w tym poście:

Przykłady testów jednostkowych w WordPress

Oto kilka testów, które napisałem dla prostego narzędzia admin plugin, które wykorzystuje konstrukcje obiektowe.

Uwaga: Aby skorzystać z PHPUnit TestDoubles w pluginie bez klasy, musisz użyć przestrzeni nazw i PHP 5.3 lub nowszego.

Dla niektórych zaawansowanych przykładów testowych sprawdź:

• Testy dla rdzenia WordPress
• Testy Jednostkowe WooCommerce
• Testy dla żądań ajax
• WordPress API Framework

Testowanie motywu WordPress

Prostym sposobem na przetestowanie motywu WordPress jest użycie danych testowych jednostki motywu. Mamy świetny artykuł, który wyjaśnia, jak go skonfigurować.

Jeśli twój motyw zapewnia funkcjonalność podobną do wtyczek lub chcesz skorzystać z PHPUnit, możesz rzucić okiem na podstawowe testy motywów Toma Mcfarlina. Sposób skonfigurowania będzie zależał od struktury motywu.

Test Driven Development (TDD)

TDD to paradygmat projektowania oprogramowania, w którym najpierw są pisane testy jednostkowe, a następnie kod jest pisany, aby przejść testy. Chodzi o to, aby napisać nieudane testy jednostkowe, a następnie napisać kod, aby przejść te testy. Cykl trwa do momentu dodania wszystkich brakujących funkcji. Przy każdej iteracji kod jest refakturowany bez zmiany zachowania. Niezależnie od tego, czy używasz TDD, czy nie piszesz testów w miarę rozwoju, kluczem jest tutaj.

Dalsze Testy Jednostek Wtyczek

Mam nadzieję, że ten artykuł pomoże Ci rozpocząć testy PHPUnit w WordPress. Można również przyjrzeć się automatyzacji testów za pomocą biegacza zadań, takich jak gulp lub grunt. Wreszcie, można śledzić WordPress Trac, który pomoże Ci napisać testy przy użyciu najlepszych praktyk dla WordPress.

Dodatkowe Zasoby

• https://make.wordpress.org/cli/2013/02/19/plugin-unit-tests/
• http://wordpress.tv/?s=unit + test
• https://carlalexander.ca/introduction-wordpress-unit-testing/
• https://jtreminio.com/2013/03/unit-testing-tutorial-part-5-mock-methods-and-overriding-constructors/

Tagi:

• środowisko testowe