Scrivere Unit Test con PHPUnit, Parte 1: Il Set Up

Last updated Nov 26, 2022

Contenuto

Unit test con PHPUnit, Parte 1: La configurazione

All’inizio di questo mese, abbiamo iniziato a esaminare l’installazione di PHPUnit in Visual Studio Code con l’obiettivo finale di imparare a scrivere unit test per i nostri progetti basati su WordPress.

A tal fine, questo post presuppone che tu abbia letto i seguenti post e presuppone che tu abbia raggiunto una manciata di post precedenti:

E, naturalmente, l’installazione di PHPUnit in Visual Studio Code come collegato sopra. Una volta fatto, saremo pronti per procedere. Ma una cosa da tenere a mente è che questo sarà un corso tradizionale o completo per la scrittura di unit test.

Invece, si tratta di scrivere unit test per progetti WordPress.

Unit test con PHPUnit, Parte 1: La configurazione

Prima di approfondire questo aspetto, voglio essere chiaro che questo non è tanto un post nello sviluppo basato su test, ma un post che pone le basi per comprendere la scrittura di unit test. E poi, alla fine, lavoreremo per scrivere unit test per il nostro codice.

Per quelli di voi che hanno letto in precedenza i test unitari, allora sapete che la scrittura di test unitari è un argomento per il quale ci sono molte informazioni e questo post non tenterà di coprire tutto ciò. Invece, adotterà un approccio più pragmatico alla scrittura di unit test su plug-in, applicazioni Web e simili basati su WordPress.

1 Test unitari di scrittura

Ogni volta che inizierai a scrivere unit test, ti verrà presentata sia l’idea del setUp che dei metodi tearDown. Questo è comune in PHPUnit (come con altri framework di test). Ci sono alcune cose su questi due metodi particolari che spesso causano problemi.

In breve, le persone trattano le funzioni in questo modo:

setUp è come il costruttore in cui istanzia la tua classe e poi prepari tutto ciò di cui hai bisogno per il tuo test incluso l’oggetto da testare, i dati necessari e così via.
tearDown è il distruttore in cui resetti tutto e poi smaltisci i tuoi oggetti. Questo di solito è più comune nei linguaggi compilati, ma non è nemmeno da perdere all’interno di PHPUnit.

E anche se posso capirlo completamente, non è sempre così. Parlo per esperienza anche qui. Invece, è da qui che viene la vera e propria frase unit test. Si tratta di testare il codice delle unità e di farlo in modo pulito e conciso.

Quindi a cosa servono questi metodi, comunque? Questa può essere un’abitudine particolarmente difficile da rompere o persino un modello concettuale da rompere quando ci si avvicina per la prima volta al processo. A tal fine, voglio esaminare lo scopo di ciascun metodo e quindi come affrontarlo quando si lavora con progetti basati su WordPress.

E, come al solito, mirerò a mantenerlo il più semplice e pragmatico possibile. Sono molto meno interessato alla teoria dietro certe cose che a come può servire bene sia la mia attività che i miei progetti. (Questo non è per scartare la teoria, ovviamente, ma c’è un tempo non un posto per quello e questo blog non lo è.)

2 La funzione di configurazione

Anche se sto iniziando con una breve discussione sul metodo setUp, è importante tenere a mente che la sua funzione sorella (come alcuni la considerano) non è sempre necessaria.

Ad esempio, se stai scrivendo codice in cui tutto ciò che stai facendo è creare un’istanza di un oggetto o di un insieme di oggetti, il metodo tearDown potrebbe non essere necessario. Entrerò in maggiori dettagli su questo nella prossima sezione.

Detto questo, supponiamo che tu abbia una classe responsabile dell’esecuzione di un po’ di logica di dominio. Ricorda, ai fini di questo post, non ci interessa il codice che farà cose che WordPress fa naturalmente e che ha già una propria serie di test.

Con ciò, intendo dire che ci occupiamo di codice che funziona specificamente all’interno di un dominio problematico. Ad esempio, forse siamo interessati a scrivere una classe che memorizza nella cache i dati nel database. Una delle informazioni responsabili della memorizzazione nella cache delle informazioni è la durata della cache dei dati. Quindi, un candidato per il test unitario farebbe usando che siamo in grado di impostare e modificare la quantità di tempo, giusto?

Certo, forse questi dati sono codificati, ma ai fini dell’esempio, supponiamo il contrario. Ciò implica quanto segue:

Abbiamo una classe che funge da cache,
La classe conserva un pezzo di dati di istanza per quanto tempo deve essere impostata la cache,
Il tempo della cache può essere impostato da classi di terze parti,
Il tempo della cache può essere letto da classi di terze parti.

Ciò significa che un test unitario includerebbe:

Allestimento della classe,
Definire un valore,
Affermando che il valore che è stato definito è quello atteso,,
Modificando il valore,
L’affermazione del valore che è stato modificato è stata aggiornata.

Quindi la classe base potrebbe assomigliare a questa (tutta la documentazione viene esclusa dalla classe allo scopo di mantenere il codice il più conciso possibile):

Si noti che, per impostazione predefinita, il tempo della cache è impostato su 12 ore (in secondi). La classe supporta anche la capacità di modificare e leggere la durata.

Ciò significa che possiamo scrivere test che verificano:

se il valore iniziale è quello previsto,
se il nuovo valore è quello previsto (e che sovrascrive il valore iniziale)

Una delle cose che vorrei sottolineare nel codice sopra è che potresti leggere che ogni test dovrebbe avere una singola asserzione mentre per testNewDuration ha chiaramente due asserzioni.

Tendo a prendere l’idea di un’affermazione per test come regola pratica. Ad esempio, in questo caso, voglio affermare che il valore iniziale viene sovrascritto o non memorizzato da nessuna parte e il nuovo valore viene memorizzato.

Questo potrebbe non essere sempre il caso, quindi potrebbe essere necessario trattare questi tipi di situazioni con cura.

Come puoi vedere, questo non ha nulla a che fare con WordPress; tuttavia, ha a che fare con la logica di test relativa specificamente al dominio in questione. Vale a dire, la durata della cache. E questo è il fulcro del test unitario: testare il comportamento logico delle unità di codice per assicurarci che le cose funzionino come previsto.

E a seconda di quando scrivi questo codice, potresti avere test falliti. Questo alla fine può aiutare con la progettazione della classe, ma questo è un altro argomento e non uno che fa parte di questo post.

Esecuzione dei test

Una volta scritti i test, è importante essere in grado di eseguirli per vedere se superano, se falliscono, cosa passa e cosa no. Ma non abbiamo ancora finito. Voglio fornire uno sguardo completo agli unit test nel contesto di WordPress e questo arriva alla discussione di ciò che WordPress fornisce, cosa non offre, alcune idee sbagliate e come eseguire questi test nel terminale o all’interno di Visual Studio Code.

Nel prossimo post di questa serie, esamineremo la funzione tearDown e come (e quando) usarla, quando è necessaria, quando non lo è, e poi esamineremo un po’ l’unità test in WordPress in generale.

In definitiva, stiamo lavorando per ottenere un quadro completo di come farlo e come farlo nel modo giusto. Ma è importante gettare le basi per questo e farlo nell’arco di pochi post è più facile che in un post monolitico.

Quindi esaminare tearDown(), il suo utilizzo e come eseguire i test dalla riga di comando sarà l’argomento del prossimo post di questa serie.

Fonte di registrazione: tommcfarlin.com