Nei primi due articoli di questa serie, abbiamo esaminato in modo approfondito quale test dell'unità è e come applicarlo nel contesto dello sviluppo di plugin. Certo, c'è di più in WordPress che scrivere plug-in, non è vero? Una parte significativa di un lavoro di sviluppatori WordPress - per alcuni è il maggior parte parte significativa - è lo sviluppo del tema.
Quindi, in questo articolo, daremo un'occhiata a come sviluppare temi testabili. Nello specifico, daremo un'occhiata a come i temi sono diversi dai plug-in e poi scriveremo un tema estremamente semplice che verrà utilizzato per dimostrare i principi del testing unitario e che può essere applicato nello sviluppo futuro.
Prima di iniziare a creare un tema o rivedere qualsiasi codice, è importante capire la differenza nello sviluppo di temi e plug-in. Innanzitutto, i plugin possono essere scritti in due modi:
Entrambi i metodi fanno la stessa cosa: cioè, usano una collezione di funzioni e filtri per introdurre nuove funzionalità in WordPress. La differenza principale è come le funzioni sono incapsulate.
Ma quando si tratta di sviluppo di temi, c'è davvero un solo modo per sviluppare un tema e cioè utilizzando una serie di funzioni definite in functions.php. Questo presenta le seguenti due sfide per la scrittura di unit test per temi:
Poiché i buoni temi utilizzano una raccolta di filtri e azioni, creeremo un tema che segue quelle best practice e poiché l'enfasi di questo particolare articolo risiede nei temi dei test unitari, verrà posta maggiore enfasi sulla scrittura dei test piuttosto che su creando un tema bello e altamente funzionale.
Prima di iniziare la codifica, inizializziamo la directory del nostro progetto. Abbiamo bisogno di impostare lo scheletro del tema così, nella tua directory dei temi di WordPress, creare una nuova directory per il tema. Il mio è chiamato Basic-Theme. Aggiungi i seguenti file (li compileremo in seguito):
Andiamo avanti e cancelliamo il foglio di stile in modo che WordPress riconosca il tema e ci consenta di attivarlo dall'interno del Dashboard. Per fare ciò, aggiungi il seguente codice:
/ * Nome tema: URI tema tema di base: TODO Versione: 1.0 Descrizione: Un tema di base utilizzato per dimostrare come scrivere test unitari per temi. Autore: Tom McFarlin Autore URI: http://tommcfarlin.com Licenza: GNU General Public License v2.0 Licenza URI: http://www.gnu.org/licenses/gpl-2.0.html * /
Per essere completo, vai avanti e aggiungi i tag PHP di apertura e chiusura all'inizio e alla fine del tuo file di funzioni. Ciò assicurerà che abbiamo gettato le basi quando iniziamo a scrivere le funzioni dei temi più avanti in questo articolo.
E aggiungi una nuova directory chiamata test. Qui, dovremo inserire i test di WordPress.
In precedenza in questa serie, ho fornito un collegamento ai test di WordPress situati su GitHub. Sebbene questi test siano validi, i più recenti test di WordPress gestiti da Automattic si trovano in questo repository di Subversion.
Se sei uno sviluppatore avanzato, ti consiglio di controllare quei test; tuttavia, se hai appena iniziato con i test delle unità - nessun problema! Fornisco tutto il codice sorgente, compresi i test di WordPress, in un repository GitHub che potrai scaricare, consultare e utilizzare per i tuoi progetti.
Una volta che i test sono stati installati, la directory del tuo tema dovrebbe apparire così:
Poiché PHPUnit deve essere eseguito dalla riga di comando, è necessario aprire una sessione terminale (o un prompt dei comandi), passare al test directory e dovresti essere in grado di eseguirli usando il seguente comando (ad esempio):
phpunit test / test_user_capabilities.php
Il tuo terminale dovrebbe quindi mostrare qualcosa di simile a questo:
Dritta: Se non sei in grado di eseguire i test, fai riferimento al primo articolo della serie per verificare la tua configurazione. Inoltre, il tuo chilometraggio può variare in base al tuo sistema operativo, server web e configurazione della macchina locale. Se si finisce per dover fare qualcosa di diverso, si prega di condividere le note nei commenti per aiutare gli altri.A questo punto, procediamo con l'attivazione del tema in Dashboard. Il tema dovrebbe attivarsi (in caso contrario, assicurarsi di non avere caratteri vaganti nei file del modello). Se si tenta di visualizzare il tema, visualizzerà naturalmente una schermata bianca.
Prima di scrivere qualsiasi test, andiamo avanti e compiliamo i nostri file modello con un po 'di contenuto solo per consentirci di farlo qualcosa comparire sul frontend.
Nel header.php, aggiungi il seguente codice:
> Questa è l'intestazione.
Nel index.php, aggiungi il seguente codice:
Questo è il contenuto.
E in footer.php, aggiungi il seguente codice:
Questo è il piè di pagina.
Semplice, lo so, ma questo ci darà quanto basta per lavorare ogni volta che iniziamo a scrivere test. Salva il tuo lavoro, rivedi il tema nel browser e dovresti vedere questo:
Nel tuo test directory, creare un file chiamato test_basic_theme.php e stub il file per assomigliare a questo:
// Include le funzioni per il tema include_once ('... /functions.php'); class Test_Basic_Theme estende WP_UnitTestCase // end class
In alto, stiamo definendo una classe che verrà utilizzata per completare tutti i test unitari del nostro tema.
Per prima cosa, definiamo il impostare
metodo. Il impostare
Il metodo è una funzione fornita dal framework di WordPress Test e possiamo utilizzarlo per attivare determinate funzioni prima dell'esecuzione dei test. Ad esempio, quando i test di WordPress vengono eseguiti, vengono eseguiti rispetto al tema predefinito, ovvero, Twenty Eleven. Nel nostro caso, vogliamo eseguire i test sul nostro tema.
Per fare ciò, dobbiamo dire a WordPress di cambiare i temi prima di eseguire il resto dei nostri test. Poiché questo deve accadere prima dell'esecuzione dei test, deve essere definito nel impostare
metodo. Ha senso?
Quindi scriviamo il nostro impostare
metodo:
function setUp () parent :: setUp (); switch_theme ('Tema di base', 'Tema di base'); // fine configurazione
Ancora una volta, eseguiamo i nostri test. Possiamo farlo eseguendo lo stesso comando di quando abbiamo inizialmente configurato il test:
test phpunit / test_basic_theme.php
Se hai eseguito correttamente tutto, dovresti vedere un errore durante l'esecuzione del test:
Il messaggio di errore è chiaro, però: "Nessun test trovato nella classe "Test_Basic_Theme"
"Quindi attenuiamo il problema e scriviamo il primo test per il tema. Può essere qualcosa di straordinariamente semplice, ma ricorda dal post precedente che non vogliamo testare appena il percorso ottimale, ma anche il percorso di errore.
In quanto tale, è necessario testare che il tema di base sia attivo e che Twenty Eleven non sia attivo. Per fare questo, utilizzeremo il metodo assertTrue e il metodo assertFalse e lo faremo nel contesto di due funzioni. Dai un'occhiata al codice qui sotto e aggiorna il file di prova di conseguenza:
function testActiveTheme () $ this-> assertTrue ('Tema di base' == get_current_theme ()); // end testThemeInitialization function testInactiveTheme () $ this-> assertFalse ('Twenty Eleven' == get_current_theme ()); // end testInactiveTheme
Ancora una volta, esegui i test e dovresti vederli diventare verdi. Bello, giusto?
Questa è una funzionalità relativamente semplice, quindi prendiamo in considerazione alcune funzioni avanzate che il nostro tema potrebbe avere.
Fuori dalla scatola, il tema di base non include jQuery, quindi lo includeremo con il nostro tema. Se ti ricordi dai post precedenti, la metodologia di test dell'unità corretta è la seguente:
Quindi, facciamo esattamente questo per jQuery.
Per prima cosa, dobbiamo scrivere un test per determinare se jQuery è caricato. Useremo la funzione WordPress wp_script_is. Poiché il tema sta attraversando il normale ciclo di vita della pagina in un browser, dobbiamo dire manualmente a WordPress di caricare jQuery usando la funzione do_action.
function testjQueryIsLoaded () $ this-> assertFalse (wp_script_is ('jquery')); do_action ('wp_enqueue_scripts'); $ this-> assertTrue (wp_script_is ('jquery')); // end testjQueryIsLoaded
Prima di andare avanti, c'è qualcosa di importante da notare qui: non mi piace mettere più asserzioni in una singola funzione perché penso che ogni funzione dovrebbe servire per testare un singolo scopo; tuttavia, ci sono delle eccezioni. Qui, dobbiamo assicurarci che jQuery non è caricato prima di chiamare do_action
.
Ad ogni modo, esegui il test e fallirà. Quindi dobbiamo aggiungere il codice a functions.php ciò assicurerà che jQuery venga aggiunto al nostro tema. Per fare ciò, includere la seguente funzione nel file delle funzioni:
function basic_add_jquery () wp_enqueue_script ('jquery'); // end basic_remove_jquery add_action ('wp_enqueue_scripts', 'basic_add_jquery');
Infine, esegui il test e dovrebbe essere verde. Abbastanza facile, no??
Diciamo che vogliamo includere una meta description predefinita sulla homepage. Nel caso più semplice, non sarà nient'altro che la descrizione del blog. Quindi, seguendo la nostra metodologia illustrata sopra, introduciamo una funzione per verificare che la stringa meta description aggiunta all'elemento head corrisponda a quanto ci aspettiamo:
function testBasicMetaDescription () $ meta_description = ''; $ this-> expectOutputString ($ meta_description, basic_meta_description ()); // end testBasicMetaDescription
Eseguilo: fallirà. Nota che non sto usando lo standard assertTrue
, assertFalse
funzioni - ci saranno maggiori dettagli su questo in un attimo. Ora, introduciamo la seguente funzione in functions.php:
function basic_meta_description () echo ''; // end basic_meta_description add_action ('wp_head', 'basic_meta_description');
Si noti che questa funzione si aggancia al wp_head
azione. Per scrivere la descrizione meta nell'elemento principale, dobbiamo eco la stringa piuttosto che ritorno la stringa.
Ora, nota che nel test sopra stiamo usando expectOutputString
. Questo è utile quando abbiamo bisogno di valutare una funzione Echo una stringa (piuttosto che ritorna una stringa). Dal momento che il wp_head
l'azione restituirà una quantità significativa di dati (ovvero l'intero elemento principale), abbiamo solo bisogno di valutare la meta descrizione che viene restituita. Ed è per questo che piuttosto che chiamare do_action ('wp_head')
, Sto semplicemente chiamando la funzione stessa e valutando l'output rispetto a quello che mi aspetto che abbia.
Ancora una volta, esegui PHPUnit e tutti i tuoi test dovrebbero passare.
Chiaramente, abbiamo solo scalfito la superficie di ciò che i test unitari possono fare per lo sviluppo del nostro tema. C'è ancora molto che può essere testato - non abbiamo nemmeno dato un'occhiata al test di The Loop, a vari modi per valutare i formati dei post, o anche come esaminare i commenti.
Ricorda questo è una guida per principianti e i tre articoli coprono molto terreno.
Indipendentemente da ciò, i principi sono gli stessi: si tratta di fare in modo che si attivi a livello di programmazione la funzione o l'azione appropriata e valutare il suo output in entrambi i casi previsti e inaspettati.
Infine, puoi trovare l'intero progetto insieme a funzioni documentate in questo repository GitHub.
Ecco un riepilogo delle risorse utilizzate in questo articolo:
assertTrue
assertFalse
wp_script_is
do_action
wp_head
expectOutputString