Come iniziare a testare il tuo codice WordPress con Pest PHP Testing Framework

Siamo tutti d'accordo sul fatto che WordPress ha fatto molta strada dal suo inizio e che è diventato qualcosa di molto più di un semplice software di blogging.

Al suo interno, è ancora un sistema di gestione dei contenuti (CMS), ma con oltre 59.000 plugin nella directory wordpress.org, puoi personalizzarlo per essere molto di più.

Il motivo della sua popolarità è la sua bassa barriera all'ingresso sia per i creatori di contenuti che per gli sviluppatori. A volte questo ha un costo. Non è un segreto che WordPress abbia una cattiva reputazione quando si tratta di sviluppo. Ha un sacco di bagaglio legacy e regole dure a morire che impediscono qualsiasi modifica della compatibilità con le versioni precedenti quando si tratta di codice PHP (Gutenberg è un'altra storia in cui non entrerò).

Quel codice PHP legacy viene spesso utilizzato dagli sviluppatori che stanno iniziando a entrare nel mondo della programmazione e il problema è che possono imparare alcuni schemi di programmazione sbagliati. Ciò a sua volta significa che riutilizzeranno il codice scritto male, aumentando la quantità di codice errato nel mondo.

È qui che WordPress ottiene la sua cattiva reputazione nella comunità degli sviluppatori.

Rompere il ciclo

Quindi, come possiamo interrompere questo ciclo di codice errato? Insegnando ai nuovi sviluppatori come dovrebbero scrivere un buon codice. Un esempio di insegnamento ai nuovi sviluppatori (ma anche a quelli vecchi che sono ancora aggrappati al modo di fare le cose "WordPress") è la scrittura di tutorial.

Un altro modo è incoraggiarli a utilizzare strumenti che possano aiutarli a scrivere codice migliore.

Attualmente sono coinvolto nel lavoro che mira a rilasciare la nuova versione di WordPress Coding Standards, un insieme di regole utilizzate per lo strumento PHP_CodeSniffer che ti farà sapere se il tuo codice ha dei potenziali problemi (sicurezza, best practices, stile del codice ).

Un altro strumento che ho sviluppato di recente è un pacchetto che aiuterà gli sviluppatori a impostare test di integrazione di WordPress che utilizzano il framework di test Pest.

Ok, allora perché abbiamo bisogno di questo nuovo strumento?

La motivazione principale alla base della creazione di questo pacchetto è incoraggiare più persone a scrivere test per il loro codice, in particolare gli sviluppatori di plugin.

Molti sviluppatori nella comunità di WordPress seguono il mantra: posso vedere che funziona perché l'ho provato nel mio browser. Va bene, ma ci sono problemi con quello.

In primo luogo, è dispendioso in termini di tempo. Ogni volta che apporti qualche modifica, devi assicurarti che funzioni, ma anche che non hai rotto nulla.

In secondo luogo, le persone commettono errori. Non siamo infallibili e il codice potrebbe essere utilizzato in modo improprio in modi che non avresti mai pensato possibile. Rimarrai stupito di quanto possano essere creative le persone quando scrivono codice.

I test automatici sono rapidi e possono aiutarti a testare vari casi che si verificheranno durante l'esecuzione del codice.

Si verifica il comportamento previsto (percorso felice) e, in modo rapido, è possibile aggiungere esempi di come il codice può essere utilizzato in un modo in cui non si intende utilizzarlo (percorso infelice).

Protegge anche il tuo codice dalle regressioni. Una regressione del codice si verifica quando si interrompe involontariamente una parte del codice aggiungendo nuovo codice.

Il problema con i test impostati finora

I test su WordPress non sono una novità. E non è che non potevi impostare test per il tuo codice prima. Ci sono incredibili librerie là fuori che ti aiuteranno a configurare tutto come wp-browser.

Ma il problema è che la procedura di installazione è spesso goffa.

È necessario configurare un database separato per i test ed è necessario eseguire determinati script, quindi modificare i file per far funzionare tutto.

Ammettiamolo, non è una cosa semplice da fare e gli sviluppatori sono per natura creature pigre (ecco perché scriviamo codice per fare le cose per noi).

Lo scopo della configurazione del test di integrazione wp-pest è eliminare tutto quel lavoro extra.

Come configurarlo

Per configurarlo, il tuo progetto deve utilizzare Composer. È un modo standard di fatto per aggiungere pacchetti al codice.

Nel tuo tipo di terminale

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

Dopo aver scaricato il pacchetto e le sue dipendenze, puoi impostare i test del tema digitando

 vendor/bin/wp-pest setup theme

Oppure, nel caso in cui desideri impostare dei test per il tuo plugin, puoi scrivere

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

Facoltativamente, puoi fornire un parametro --wp-version , per specificare su quale versione di WordPress desideri testare il tuo codice.

In background, verrà scaricata un'istanza di WordPress e verrà impostato un database in memoria, insieme a due esempi di test che puoi eseguire.

Quindi, correndo

 vendor/bin/pest --group=unit

o

 vendor/bin/pest --group=integration

eseguirà le prove.

Il bello di Pest è che la sua sintassi è adatta agli sviluppatori. Ha una documentazione straordinaria e un'ottima sintassi. Diamo un'occhiata a un semplice esempio. Supponiamo che tu stia registrando un tipo di post personalizzato chiamato "Libri":

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

Dopo aver eseguito il comando di installazione che aggiunge un esempio, un test chiamato BooksCptTest.php sarebbe simile a questo:

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

L'esecuzione di vendor/bin/pest --group=integration ci fornisce il seguente output:

 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

Conclusione

E proprio così, hai la possibilità di eseguire test di integrazione di WordPress nel tuo tema o plug-in. I test sono sorprendenti perché non solo ci salvaguardano dagli errori, ma ci obbligano anche a scrivere codice pulito e verificabile. Ciò è particolarmente vero per i plug-in che hanno una logica complicata o comunicano con API di terze parti.

Scrivere test per una tale base di codice ti costringerà a pensare all'aspetto della tua architettura di codice in modo da poter scrivere facilmente test automatici, per non parlare del tempo e del denaro che risparmierai non dovendo testare tutto manualmente.

Se pensi che questo sia qualcosa di cui potresti trarre vantaggio, sentiti libero di usarlo e aggiungi il repository su GitHub.

Si spera che questo incoraggerà più sviluppatori WordPress a utilizzare strumenti che miglioreranno le loro capacità di programmazione.