Cum să începeți să testați codul WordPress cu cadrul de testare PHP Pest

Putem fi cu toții de acord că WordPress a parcurs un drum lung de la început și că a devenit ceva cu mult mai mult decât un software de blogging.

În esență, este încă un sistem de management al conținutului (CMS), dar cu peste 59.000 de plugin-uri în directorul wordpress.org, îl puteți personaliza pentru a fi mult mai mult.

Motivul popularității sale este bariera redusă de intrare atât pentru creatorii de conținut, cât și pentru dezvoltatori. Uneori, acest lucru vine cu un cost. Nu este un secret pentru nimeni că WordPress are o reputație proastă când vine vorba de dezvoltare. Are o mulțime de bagaje moștenite și reguli dure care împiedică orice modificare a rupturii de compatibilitate cu înapoi când vine vorba de codul PHP (Gutenberg este o altă poveste în care nu voi intra).

Acest cod PHP moștenit este adesea folosit de dezvoltatorii care încep să intre în lumea programării, iar problema este că aceștia pot învăța câteva modele de programare proaste. Asta înseamnă că vor reutiliza codul prost scris, crescând cantitatea de cod rău din lume.

Acesta este locul în care WordPress își obține reputația proastă în comunitatea de dezvoltatori.

Ruperea ciclului

Deci, cum putem întrerupe acest ciclu de cod prost? Învățând noii dezvoltatori cum ar trebui să scrie cod bun. Un exemplu de predare a noilor dezvoltatori (dar și a celor vechi care încă se agață de modul „WordPress” de a face lucrurile) este prin scrierea de tutoriale.

O altă modalitate este de a-i încuraja să folosească instrumente care îi pot ajuta să scrie un cod mai bun.

În prezent sunt implicat în munca care urmărește lansarea noii versiuni a standardelor de codare WordPress, un set de reguli utilizate pentru instrumentul PHP_CodeSniffer care vă va anunța dacă codul dvs. are unele probleme potențiale (securitate, bune practici, stilul codului). ).

Un alt instrument pe care l-am dezvoltat recent este un pachet care îi va ajuta pe dezvoltatori să configureze teste de integrare WordPress care utilizează cadrul de testare Pest.

Ok, de ce avem nevoie de acest nou instrument?

Principala motivație din spatele creării acestui pachet este de a încuraja mai mulți oameni să scrie teste pentru codul lor, în special dezvoltatorii de pluginuri.

Mulți dezvoltatori din comunitatea WordPress merg cu mantra: văd că funcționează pentru că l-am încercat în browserul meu. E în regulă, dar există probleme cu asta.

În primul rând, consumă mult timp. De fiecare dată când faci o schimbare, trebuie să te asiguri că funcționează, dar și că nu ai rupt nimic.

În al doilea rând, oamenii fac greșeli. Nu suntem siguri, iar codul poate fi folosit greșit în moduri pe care nu le-ați crezut niciodată posibil. Ai fi uimit de cât de creativi pot fi oamenii când scriu cod.

Testele automate sunt rapide și vă pot ajuta să testați diferite cazuri care se vor întâmpla atunci când executați codul.

Testați comportamentul dorit (calea fericită) și, într-un mod rapid, puteți adăuga exemple despre cum poate fi folosit codul dvs. într-un mod în care nu ați intenționat să fie folosit (calea nefericită).

De asemenea, vă protejează codul de regresii. O regresie de cod este atunci când spargeți neintenționat o parte a codului dvs. adăugând cod nou.

Problema cu testele puse până acum

Testarea în WordPress nu este un lucru nou. Și nu este ca și cum nu ați putea configura teste pentru codul dvs. înainte. Există biblioteci uimitoare care vă vor ajuta să configurați totul ca wp-browser.

Dar problema este că procedura de configurare este adesea greoaie.

Trebuie să configurați o bază de date separată pentru teste și trebuie să rulați anumite scripturi, apoi să schimbați fișierele pentru ca totul să funcționeze.

Să recunoaștem, nu este un lucru simplu de făcut, iar dezvoltatorii sunt prin natură creaturi leneșe (de aceea scriem cod pentru a face lucruri pentru noi).

Scopul setării testului de integrare wp-pest este de a elimina toată munca suplimentară.

Cum să-l configurezi

Pentru a-l configura, proiectul trebuie să folosească Composer. Este o modalitate standard de facto de a adăuga pachete la codul tău.

În tipul dvs. de terminal

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

După ce ați descărcat pachetul și dependențele acestuia, puteți configura testele temei tastând

 vendor/bin/wp-pest setup theme

Sau, în cazul în care doriți să configurați teste pentru pluginul dvs., puteți scrie

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

Opțional, puteți furniza un parametru --wp-version , pentru a specifica versiunea WordPress pe care doriți să testați codul.

În fundal, va fi descărcată o instanță WordPress și va fi configurată o bază de date în memorie, împreună cu două exemple de teste pe care le puteți rula.

Apoi, fie alergând

 vendor/bin/pest --group=unit

sau

 vendor/bin/pest --group=integration

va rula testele.

Frumusețea lui Pest este că sintaxa sa este prietenoasă pentru dezvoltatori. Are o documentație uimitoare și o sintaxă excelentă. Să ne uităm la un exemplu simplu. Să presupunem că înregistrați un tip de postare personalizat numit „Cărți”:

 <?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' );

După rularea comenzii de configurare care adaugă un exemplu, un test numit BooksCptTest.php ar arăta astfel:

 <?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'); });

Rularea vendor/bin/pest --group=integration ne oferă următorul rezultat:

 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

Concluzie

Și chiar așa, aveți posibilitatea de a rula teste de integrare WordPress în tema sau pluginul dvs. Testele sunt uimitoare pentru că nu numai că ne protejează de greșeli, dar ne forțează și să scriem cod curat și testabil. Acest lucru este valabil mai ales pentru pluginurile care au o logică complicată sau care comunică cu API-uri terțe.

Scrierea de teste pentru o astfel de bază de cod vă va forța să vă gândiți la cum arată arhitectura dvs. de cod, astfel încât să puteți scrie cu ușurință teste automate - ca să nu mai vorbim de timpul și banii pe care îi veți economisi dacă nu trebuie să testați manual totul.

Dacă credeți că acesta este ceva de care ați putea beneficia, nu ezitați să îl utilizați și să vedeți depozitul pe GitHub.

Sperăm că acest lucru va încuraja mai mulți dezvoltatori WordPress să folosească instrumente care le vor îmbunătăți abilitățile de codare.