Share
Abbiamo esaminato i test unitari per lo sviluppo di WordPress. Attraverso l'uso di esempi pratici, abbiamo esaminato i test unitari sia per i plug-in che per i temi; tuttavia, non abbiamo davvero parlato della teoria alla base dei test unitari.
Ciò vuol dire che non abbiamo preso in considerazione ciò che è di alto livello, perché è vantaggioso e come possiamo incorporarlo nel nostro flusso di lavoro. Nella prossima serie di articoli, definiremo i test unitari, ne copriremo i principali vantaggi, perché dovremmo preoccuparci di farlo e alcune delle risorse che sono disponibili per noi da utilizzare nel nostro lavoro.
Sebbene non esista un codice da utilizzare per questo particolare tutorial, dovrebbe fornire una solida base su cui si basa l'applicazione pratica degli articoli precedenti.
Prima di immergermi nell'articolo, penso che sia importante considerare i motivi per cui uno dovrebbe preoccuparsi di testare temi e plug-in.
Fino a poco tempo fa, WordPress è stato visto principalmente come piattaforma di blogging e come sistema di gestione dei contenuti. Fa entrambi molto beh, ma come gli sviluppatori stanno scoprendo la sua ricca API, sta diventando sempre più popolare creare alcuni tipi di applicazioni usando WordPress come piattaforma sottostante.
Inoltre, i temi sono più di skin per un sito Web: sono più di un foglio di stile e alcuni file di modello per la visualizzazione dei dati. In effetti, ora, forse più che mai, intere squadre dedicano tempo (e persino guadagnandosi da vivere) a produrre temi per WordPress. Quindi non lasciatevi fuorviare dalla parola "tema": i temi sono come le applicazioni per WordPress. Aggiungono funzionalità, pre-elaborano e post-elaborano i dati e spesso introducono funzionalità significative in WordPress ben oltre il semplice conferire al tuo sito web un lifting.
Infine, i plugin sono quasi di natura applicativa rispetto ai temi. Consideralo in questo modo: i plugin estendono il nucleo di WordPress e spesso lavorano indipendentemente dai temi. Invece, aggiungono nuove funzionalità al nucleo di WordPress da cui trarranno vantaggio tutti i temi.
Dico tutto questo per dare una certa prospettiva sul motivo per cui i test unitari - come stiamo per scoprire - possono ripagare molte volte dato che è usato nel contesto di temi e plugin più complessi.
Abbiamo brevemente toccato questo nel primo articolo della serie. Non voglio fornire un ripasso totale di ciò che è già stato scritto, quindi riassumerò i punti qui:
Ma questo è solo grattando la superficie.
Per capire veramente le unità del tuo tema o plugin, devi pensare a cosa compone un tema. In genere, è una combinazione di:
Sebbene esistano framework di test unitari specifici per JavaScript, ci concentreremo maggiormente sull'aspetto PHP dello sviluppo di WordPress. Dopo tutto, se non fosse per la funzionalità lato server, ci sarebbe pochissima funzionalità unica introdotta in WordPress.
Detto questo, ci sono diversi modi per definire un'unità, ma scommetto che molte persone definiscono un'unità come una funzione. Per la maggior parte, è vero, ma ciò non significa che le nostre funzioni siano le unità più ottimali da testare. Ad esempio, le funzioni sono spesso costituite da più blocchi, forse loop, forse condizionali o forse chiamate ad altre funzioni.
In ogni caso, ci sono spesso unità più piccole di funzionalità contenute nei metodi.
Quindi è davvero corretto dire che il test unitario implica testare ogni funzione che costituisce un tema? Non proprio. Poiché un singolo blocco di codice - o, in alcuni casi, una singola istruzione - è responsabile del raggiungimento di un compito specifico, questi costituirebbe vere unità di codice.
E se dovessimo scrivere test unitari, come scrivere test per le unità che esistono all'interno delle nostre funzioni?
Ricordiamo che all'inizio della serie, ho detto:
È qui che si verifica uno dei più grandi cambiamenti nella scrittura del codice testabile dell'unità: si stanno estraendo unità di funzionalità nel più piccolo pezzo atomico possibile. Certo, questo spesso si traduce in un numero elevato di funzioni molto piccole, ma è una cosa negativa?
Nel fare questo, ogni funzione ha veramente un unico scopo. E supponendo che la tua funzione faccia una cosa sola, ci sono solo tanti modi per nominare la funzione che alla fine può risultare in un codice molto più leggibile.
Naturalmente, c'è un compromesso in quanto potresti in realtà introdurre qualche riga in più di codice mentre scrivi queste funzioni aggiuntive, ma quando lavori su un prodotto con un team di altre persone che verrà utilizzato da migliaia di clienti, devi chiederti se il codice aggiuntivo vale la qualità che puoi ottenere nel testare correttamente il tuo lavoro. Fatto bene, la tua squadra dovrebbero essere in grado di seguire più facilmente la logica del codice e il prodotto avrà un livello di qualità che è spesso difficile da raggiungere senza scrivere test di unità.
Una cosa fondamentale da riconoscere sui test unitari è che non dipendono l'uno dall'altro. Un test di una singola unità dovrebbe testare una e una sola cosa. Inoltre, questo significa che un test unitario dovrebbe in realtà includere solo una singola asserzione (ma ci sono eccezioni che sono dimostrate qui).
Ricorda: lo scopo di un test unitario è valutare la qualità di una singola unità di codice. Alcune unità accettano argomenti, alcune unità no, alcune unità restituiscono valori, altre no. Qualunque sia il caso, il tuo test unitario dovrebbe valutare tutti i casi. Raramente una singola unità di codice ha un singolo test.
Invece, direi che una buona regola empirica è che il numero di test associati a un'unità di codice si adatta in modo esponenziale in base al numero di input che accetta.
Per esempio:
Ha senso? La chiave da prendere qui è che avrai molti più test di quante siano le unità; non c'è un rapporto 1: 1.
Infine, quando si eseguono i test delle unità, si vedrà spesso la parola "suite di test" o "suite" usata per discutere i test. Questo può variare in base al contesto in cui si sta verificando il test; tuttavia, quando si lavora con WordPress, questo di solito si riferisce a una raccolta di test unitari.
Quindi diciamo che hai un file che è responsabile per testare tutte le funzionalità intorno alla scrittura e alla pubblicazione di un post: questo file sarebbe la suite di test per i post. Abbastanza facile, giusto? È importante comprendere questa terminologia se ci si imbatte in ulteriori letture in quanto può differire leggermente se si sta lavorando, ad esempio, su Rails o .NET..
Infine, il test unitario non è una nuova metodologia e non è strettamente limitato a PHP. In effetti, il test unitario (o lo sviluppo guidato da test nel suo insieme) è in circolazione da oltre un decennio.
È possibile trovare framework di testing unitario per Java, .NET, Rails, PHPUnit (ovviamente) e così via.
Ma la sua adozione è stata mista: alcune persone vivono e muoiono, altri la odiano, e poi ci sono quelli che stanno cercando di cominciare a farlo, ma devono trovare un equilibrio tra l'applicazione pratica di portarlo in un progetto esistente e capire quantità di refactoring che potrebbe richiedere.
Per quanto riguarda la teoria, stiamo appena iniziando.
Nel prossimo articolo, daremo uno sguardo specifico sui principali vantaggi dei test unitari e su come ciò può ripagare nel nostro sviluppo basato su WordPress. Esamineremo anche i vantaggi che l'unit test porta all'architettura, al design e alla documentazione.
Ovviamente, il test unitario non è privo di svantaggi, quindi guarderemo anche quelli.
Accentsconagua