Scrivere Unit Test con PHPUnit, Parte 2: The Tear Down

Alla fine del mese scorso, ho iniziato a parlare di scrivere unit test in PHPUnit per codice basato su WordPress. Ciò includeva principalmente l’idea di impostare PHPUnit, la funzione setUp e la scrittura di test di base.

Questo, tuttavia, non ha discusso di ciò che so sulla funzione tearDown, che è ancora una caratteristica importante della scrittura utilizzando i test. Inoltre, ci sono anche due modi per considerare la scrittura di test per i progetti WordPress.

Vale a dire:

1. scrivere test specifici per plug-in e funzionalità a livello di applicazione,
2. eseguire unit test sull’applicazione WordPress.

Prima di andare avanti con questo particolare post, però, ti consiglio di recuperare ciò che ho trattato finora. Ciò include i seguenti post:

1. Un ambiente di sviluppo WordPress (utilizzando un gestore di pacchetti)
2. Un IDE per lo sviluppo di WordPress
3. Utilizzo delle impostazioni utente in Visual Studio Code
4. Scrivere Unit Test con PHPUnit, Parte 1: Il Set Up

Dopo averlo fatto, torna a questo post e continuiamo a discutere della funzione tearDown e dell’aspetto effettivo degli unit test nel contesto di WordPress.

Unit test con PHPUnit, parte 2: The Tear Down

Prima di andare avanti, ricorda che gli sviluppatori spesso trattano la funzione setUp come il costruttore e la funzione tearDown come un distruttore; tuttavia, ricorda che quest’ultimo non è sempre necessario.

Ecco una buona regola pratica da ricordare:

• Tutto ciò di cui una funzione di test ha bisogno chiamerà la funzione setUp in modo che siano necessarie le classi necessarie.
• La funzione tearDown non è sempre necessaria poiché la funzione setUp può reinizializzare una classe.

Quindi cosa significa per la funzione tearDown se non sta ripristinando i dati creati durante la funzione di configurazione?

1 La funzione di smontaggio

Il miglior consiglio che posso dare sulla funzione tearDown è che dovrebbe essere usata se qualcosa viene impostato durante uno dei test che viene lasciato indietro.

Potrebbe trattarsi di qualcosa che viene scritto su un database, qualcosa che viene scritto su un registro o, più in generale, qualcosa che viene scritto sul disco rigido.

Pertanto, se un test scrive un record o un file, il metodo tearDown verrà eseguito dopo un test e dovrebbe rimuovere qualsiasi test registrato sull’unità che non fa parte del test ma non è permanentemente necessario per il test successivo o quello dovrebbe essere pulito dopo se stesso.

Quindi, in un certo senso, è come un distruttore, ma se non hai mai usato un linguaggio che ha un distruttore quella nomenclatura o sembra irrilevante o non ha senso.

Un distruttore è una funzione membro speciale che viene chiamata al termine della durata di un oggetto. Lo scopo del distruttore è di liberare le risorse che l’oggetto potrebbe aver acquisito durante la sua vita.

Quindi, forse è meglio pensare semplicemente alla funzione come a un modo per ripulire dopo un test (e non nel senso di impostare una variabile uguale a null poiché la funzione setUp può farlo).

2 test unitari per progetti WordPress

Quando scriviamo unit test per progetti WordPress, dobbiamo assicurarci di essere chiari sul tipo di unit test di cui stiamo parlando.

Ad esempio, quelli che chiamerò unit test classici o standard seguono la metodologia dello “sviluppo test-driven" di cui parlerò tra poco. D’altra parte, WordPress ha una propria serie di unit test per temi e simili di cui parlerò anche un po’ più avanti in questo post.

Ma per questa sezione, ho pensato che potesse essere utile parlare un po’ del primo piuttosto che del secondo in modo da poter vedere come potrebbe funzionare.

Nell’esempio seguente, sto scrivendo test su un plug-in responsabile della comunicazione con un’API di terze parti. Questo particolare plugin richiede un nome utente e una password o un’API e vogliamo assicurarci che, ai fini di questo post, recuperi correttamente un errore ogni volta che viene eseguito il test.

Nota che durante la lettura di questo codice, mi vedrai parlare un po’ di riflessione. Presto scriverò un intero post su PHP Reflection, quindi si farà un po’ di luce su questo.

Per il codice seguente, tuttavia, supponiamo che sia un modo per poter accedere a proprietà altrimenti contrassegnate come private.

Ricordiamo dall’ultimo post di questa serie, abbiamo fatto un test iniziale simile a questo:

Si noti, tuttavia, che in questo test non esiste una funzione di tearDown che abbia senso, giusto? Dopotutto, non viene scritto nulla su un database o su un file.

Ma supponiamo di voler introdurre un test case che avrà un nome file, un contenuto e scriverà il contenuto nel file. In questo caso, saranno dati statici, ma tecnicamente potrebbe essere qualsiasi cosa scritta su disco.

1 Impostazione del test

Innanzitutto, vogliamo impostare il test definendo il nome del file, il contenuto del file e preparando le proprietà.

Abbastanza facile, giusto?

2 Scrivere e leggere i dati

Successivamente, vogliamo scrivere i dati, leggere i dati e affermare che i contenuti sono gli stessi.

A questo punto, se esegui il test (che non ho ancora spiegato tecnicamente su come fare), noterai che testFile.txt risiede ancora sul tuo sistema.

3 Utilizzo dello smontaggio

Infine, dobbiamo lavorare con il metodo tearDown per assicurarci che il file venga eliminato al termine dello unit test. Ecco come potrebbe apparire se hai implementato il tuo codice come quello che vedi sopra.

Si noti che nel metodo tearDown, prima controllo per vedere se un file_exists. Questo perché se tenti semplicemente di scollegare un file che non è presente, riceverai un errore durante l’esecuzione dei test perché se è presente tearDown, proverà a eliminare qualcosa dopo ogni singola funzione di test. E se il file non esiste, non c’è nulla da eliminare e quindi risulterà un problema.

Quindi, nel tentativo di scrivere codice in modo difensivo, credo che sia responsabile del controllo se il file esiste prima di provare effettivamente a eliminarlo.

3 Ordine delle operazioni

Quando si tratta di puro unit test, normalmente lo si legge in termini di sviluppo basato su test. Questo è un grande argomento in sé e per sé; tuttavia, vale la pena menzionarlo qui se dovessi scegliere di ricercarlo ulteriormente e persino implementarlo nei tuoi sforzi di sviluppo.

L’idea generale alla base di questo approccio viene spesso definita "ripetizione rosso-verde". E non lo nego, c’è qualcosa in questo approccio. Vale a dire, ti consente, come sviluppatore, di scrivere il codice come ti aspetti che funzioni prima di scrivere effettivamente il codice.

La psicologia dietro è questa: se sai come funziona il codice, è più probabile che tu scriva test che passano; mentre, se scrivi test su come dovrebbe funzionare il codice, dovresti scrivere un codice migliore.

Sfortunatamente, non sempre ci viene concesso quel lusso. Ma questo non significa che dovremmo buttare fuori il proverbiale bambino con l’acqua. Invece, sono della mentalità che dovresti scrivere test quando puoi e scrivere il codice in seguito; in caso contrario, scrivi i tuoi test dopo il tuo codice.

In definitiva, avere i test in atto a prescindere sarà meglio che nessun test.

4 Test con WordPress

Quando si tratta di unit test in WordPress, ci sono alcune cose in cui probabilmente ti sei imbattuto. A volte, il contenuto è un termine improprio o può persino essere fuorviante in termini di "test unitario in WordPress".

Ad esempio, ci sono due cose degne di nota:

1. Il test dell’unità tematica. Questo particolare insieme di contenuti ha lo scopo di aiutare gli sviluppatori di temi a testare tutti i casi principali e minori per i loro temi. Non ci sono strumenti automatizzati, ad esempio, che useresti come in quello che abbiamo discusso sopra.
2. Test automatizzati. WordPress viene fornito con il proprio set di unit test in modo da non dover scrivere test sulla maggior parte delle funzionalità di WordPress (ad esempio se le funzioni API funzionano o meno come previsto). Questo ci permette di concentrarci sulla scrittura di unit test per la nostra logica di dominio.
3. Test unità plug-in. Se hai utilizzato WP-CLI (o ti interessa), probabilmente hai letto questa pagina o addirittura utilizzato questi strumenti. È utile, ma mira anche ad aspetti specifici del test dei plugin di WordPress.

Tutto quanto sopra è un’informazione utile e non sto dicendo che dovrebbe essere ignorata. Invece, dovrebbe essere accoppiato con il resto delle informazioni utilizzate in questo post.

Esecuzione di test unitari

Nel prossimo post, ti guiderò attraverso tutto ciò che devi sapere per configurare un file XML che informerà PHPUnit di dove risiedono i test e come eseguirli.

Per ora, però, rivedi il codice che si trova in questo post e preparati a costruirlo nel prossimo post di questa serie.