Jak rozpocząć testowanie kodu WordPress za pomocą Pest PHP Testing Framework

Wszyscy możemy się zgodzić, że WordPress przeszedł długą drogę od samego początku i że stał się czymś znacznie więcej niż oprogramowanie do blogowania.

Zasadniczo jest to nadal system zarządzania treścią (CMS), ale dzięki ponad 59 000 wtyczek w katalogu wordpress.org możesz go dostosować, aby był znacznie więcej.

Powodem jego popularności jest niska bariera wejścia zarówno dla twórców treści, jak i deweloperów. Czasami wiąże się to z kosztami. Nie jest tajemnicą, że WordPress ma złą reputację, jeśli chodzi o rozwój. Ma wiele przestarzałych bagaży i twardych zasad, które zapobiegają jakimkolwiek zmianom naruszającym wsteczną kompatybilność, jeśli chodzi o kod PHP (Gutenberg to kolejna historia, w którą nie będę się zagłębiać).

Ten przestarzały kod PHP jest często używany przez programistów, którzy zaczynają wkraczać w świat programowania, a problem polega na tym, że mogą nauczyć się kilku złych wzorców programowania. To z kolei oznacza, że ​​będą ponownie wykorzystywać źle napisany kod, zwiększając ilość złego kodu na świecie.

W tym miejscu WordPress zyskuje złą reputację w społeczności programistów.

Przełamanie cyklu

Jak więc możemy przerwać ten cykl złego kodu? Ucząc nowych programistów, jak powinni pisać dobry kod. Jednym z przykładów uczenia nowych programistów (ale także tych starych, którzy wciąż trzymają się sposobu działania „WordPress”) jest pisanie samouczków.

Innym sposobem jest zachęcenie ich do korzystania z narzędzi, które pomogą im napisać lepszy kod.

Obecnie jestem zaangażowany w prace, które mają na celu wydanie nowej wersji WordPress Coding Standards, zbioru reguł wykorzystywanych w narzędziu PHP_CodeSniffer, który poinformuje Cię, czy Twój kod ma jakieś potencjalne problemy (bezpieczeństwo, najlepsze praktyki, styl kodu ).

Innym narzędziem, które ostatnio opracowałem, jest pakiet, który pomoże programistom skonfigurować testy integracyjne WordPress z wykorzystaniem frameworka testowego Pest.

Ok, więc po co nam to nowe narzędzie?

Główną motywacją stojącą za stworzeniem tego pakietu jest zachęcenie większej liczby osób do pisania testów swojego kodu, zwłaszcza twórców wtyczek.

Wielu programistów w społeczności WordPressa podąża za mantrą: widzę, że to działa, ponieważ wypróbowałem to w mojej przeglądarce. W porządku, ale są z tym problemy.

Po pierwsze, jest to czasochłonne. Za każdym razem, gdy dokonujesz jakiejś zmiany, musisz upewnić się, że to działa, ale także, że niczego nie zepsułeś.

Po drugie, ludzie popełniają błędy. Nie jesteśmy niezawodni, a kod może zostać nadużyty w sposób, o którym nigdy nie myślałeś, że jest to możliwe. Zdziwiłbyś się, jak kreatywni potrafią być ludzie podczas pisania kodu.

Testy automatyczne są szybkie i mogą pomóc w testowaniu różnych przypadków, które pojawią się podczas wykonywania kodu.

Testujesz pod kątem zamierzonego zachowania (szczęśliwa ścieżka) i w szybki sposób możesz dodać przykłady, w jaki sposób Twój kod może być używany w sposób, w jaki nie zamierzałeś go używać (nieszczęśliwa ścieżka).

Chroni również Twój kod przed regresją. Regresja kodu polega na niezamierzonym złamaniu jednej części kodu przez dodanie nowego kodu.

Problem z założonymi do tej pory testami

Testowanie w WordPressie nie jest niczym nowym. I to nie tak, że nie mogłeś wcześniej skonfigurować testów dla swojego kodu. Istnieją niesamowite biblioteki, które pomogą Ci skonfigurować wszystko jak przeglądarka wp.

Problem polega jednak na tym, że procedura konfiguracji jest często niezgrabna.

Musisz skonfigurować oddzielną bazę danych do testów i musisz uruchomić określone skrypty, a następnie zmienić pliki, aby wszystko działało.

Spójrzmy prawdzie w oczy, nie jest to proste, a programiści są z natury leniwymi stworzeniami (dlatego piszemy kod, który robi coś za nas).

Celem konfiguracji testu integracyjnego wp-pest jest wyeliminowanie całej tej dodatkowej pracy.

Jak to skonfigurować

Aby to skonfigurować, Twój projekt musi korzystać z Composera. Jest to de facto standardowy sposób dodawania pakietów do kodu.

W twoim terminalu typ

 composer require dingo-d/wp-pest-integration-test-setup --dev

Po pobraniu pakietu i jego zależności możesz skonfigurować testy motywu, wpisując

 vendor/bin/wp-pest setup theme

Lub, jeśli chcesz skonfigurować testy dla swojej wtyczki, możesz napisać

 vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slug

Opcjonalnie możesz podać parametr --wp-version , aby określić wersję WordPress, na której chcesz przetestować swój kod.

W tle zostanie pobrana instancja WordPress i utworzona zostanie baza danych w pamięci wraz z dwoma przykładami testów, które można uruchomić.

Następnie biegnij albo

 vendor/bin/pest --group=unit

lub

 vendor/bin/pest --group=integration

przeprowadzi testy.

Piękno Pest polega na tym, że jego składnia jest przyjazna dla programistów. Ma niesamowitą dokumentację i świetną składnię. Spójrzmy na prosty przykład. Załóżmy, że rejestrujesz niestandardowy typ wpisu o nazwie „Książki”:

 <?php /** * Plugin Name: Test plugin * Desctiption: Test plugin * Version: 1.0.0 * License: MIT */ function test_plugin_register_books_cpt() { $args = array( 'label' => esc_html__( 'Books', 'test-plugin' ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => true, 'rewrite' => array( 'slug' => 'book' ), 'capability_type' => 'post', 'has_archive' => true, 'hierarchical' => false, 'menu_position' => null, 'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ), ); register_post_type( 'book', $args ); } add_action( 'init', 'test_plugin_register_books_cpt' );

Po uruchomieniu polecenia setup, które dodaje przykład, test o nazwie BooksCptTest.php będzie wyglądał tak:

 <?php namespace Tests\Integration; beforeEach(function () { parent::setUp(); }); afterEach(function () { parent::tearDown(); }); test('Books custom post type is registered', function () { // We can use assertions from PHP_Unit. $this->assertNotFalse(has_action('init', 'test_plugin_register_books_cpt')); $registeredPostTypes = \get_post_types(); // Or we can use expectations API from Pest. expect($registeredPostTypes) ->toBeArray() ->toHaveKey('book'); });

Uruchomienie vendor/bin/pest --group=integration daje następujące dane wyjściowe:

 Installing... Running as single site... To run multisite, use -c tests/phpunit/multisite.xml Not running ajax tests. To execute these, use --group ajax. Not running ms-files tests. To execute these, use --group ms-files. Not running external-http tests. To execute these, use --group external-http. PASS Tests\\Integration\\BooksCptTest ✓ Books custom post type is registered Tests: 1 passed Time: 0.14s

Wniosek

I tak po prostu masz możliwość uruchamiania testów integracji WordPress w swoim motywie lub wtyczce. Testy są niesamowite, ponieważ nie tylko chronią nas przed błędami, ale także zmuszają nas do pisania czystego i testowalnego kodu. Dotyczy to zwłaszcza wtyczek, które mają skomplikowaną logikę lub komunikują się z zewnętrznymi interfejsami API.

Pisanie testów dla takiej bazy kodu zmusi Cię do zastanowienia się nad tym, jak wygląda Twoja architektura kodu, dzięki czemu możesz łatwo pisać testy automatyczne – nie wspominając o czasie i pieniądzach, które zaoszczędzisz, nie musząc wszystkiego ręcznie testować.

Jeśli uważasz, że jest to coś, z czego możesz skorzystać, możesz z niego skorzystać i uruchomić repozytorium na GitHub.

Mamy nadzieję, że zachęci to więcej programistów WordPressa do korzystania z narzędzi, które poprawią ich umiejętności kodowania.