Share
Negli ultimi due articoli, abbiamo esaminato attentamente la teoria alla base dei test unitari e in che modo può aiutarci nei nostri sforzi di sviluppo di WordPress. Abbiamo definito i test unitari e esaminato vari modi in cui può aiutarci nei nostri progetti.
Ma abbiamo ancora molto da coprire.
In questo articolo finale, esamineremo il motivo per cui dovremmo anche preoccuparci di fare test delle unità e riassumeremo i vantaggi e gli svantaggi di farlo. Successivamente, vedremo come possiamo eseguire il retrofit di test nei nostri progetti esistenti. E per concludere, riassumeremo un elenco di risorse che sono disponibili specificamente per noi sviluppatori di WordPress che aiuteranno a iniziare a testare i nostri temi unitari.
Il tema generale di questa intera serie è stato il motivo per cui dovremmo preoccuparci dei test unitari, ma se non è stato affermato in modo succinto, ecco perché:
Il test unitario ci aiuta a scoprire i problemi in anticipo, a fornire agli sviluppatori un livello di codice auto-documentante e ci fornisce un livello superiore di qualità del software.
Certo, questo presuppone che continuiamo a praticare buone tecniche di test unitario. Naturalmente, questo è stato trattato in modo molto dettagliato nell'articolo precedente, ma vale la pena ribadire.
Una cosa importante da notare - specialmente se si sta tentando di applicarlo in un contesto più aziendale o nel contesto di un'azienda più grande - è che il test delle unità non è solo qualcosa che gli sviluppatori fanno da soli. La qualità è a due facce: avvantaggia il cliente e ne beneficia l'azienda.
Fornendo un livello superiore di qualità per il cliente, ovvero un software più accuratamente testato, dovrebbero riscontrare meno errori. Dal momento che i bug portano al tempo in cui gli sviluppatori devono impegnarsi a risolvere anziché lavorare su nuovi progetti o nuove funzionalità di prodotti esistenti, ciò può in ultima analisi risparmiare denaro.
Fornendo un livello superiore di qualità per il business, gli sviluppatori sono più fiduciosi nei loro sforzi perché possono eseguire una serie di test ogni volta che viene apportata una modifica, sapendo in che modo il loro lavoro ha interessato l'intera applicazione. Se un test fallisce, allora sono in grado di risolverlo prima di metterlo in produzione.
Il test unitario riguarda la qualità e riguarda non solo quelli che scrivono il codice, ma anche l'azienda che lo consegna e i clienti che lo utilizzano.
La verità è che abbiamo già coperto i vantaggi dei test unitari. Per completezza, riassumiamoli qui (anche se puoi sempre rivederli in dettaglio!). Test unitario ...
Tutto suona alla grande, giusto? E sì, è previsto che gli sviluppatori si assumano la responsabilità di standard e pratiche elevati quando si tratta di implementare concretamente questo lavoro quotidiano, ma il test unitario non è privo di svantaggi.
Questo è stato detto in tutta questa serie: i test unitari richiedono un investimento significativo nel tempo. Certo, se stai iniziando un nuovo progetto, l'investimento in termini di tempo è molto inferiore rispetto a quando lo stai inserendo in un'applicazione esistente, ma sei ancora dover scrivere più codice che senza test.
Perché stai scrivendo più codice, ti stai prendendo più tempo - di nuovo, alla fine del progetto. I vantaggi dei test unitari spesso non arrivano più tardi, ma se un progetto ha una data obiettivo specifica per il rilascio e quella release include un certo numero di funzionalità, non è probabile che tu possa adattare tutti i test unitari e le funzionalità in il rilascio.
Se si desidera evitare set di funzionalità più piccoli al momento del rilascio o date di scadenza ritardate, si avere per costruire in tempo per i test unitari.
Li hai sentiti tutti: la complessità uccide, tienila semplice stupida, meno è più, e così via.
Onestamente, tutti questi sono veri e hanno il loro giusto posto nello sviluppo, ma il fatto è che i test unitari è codice aggiuntivo e codice aggiuntivo sempre introduce più complessità. Pertanto, dobbiamo assicurarci di avere un modo corretto di gestire e organizzare tutti i nostri test unitari.
Forse è l'organizzazione dei file, o la spaziatura dei nomi, o le convenzioni di denominazione, o test di versione, o tutto quanto sopra. Qualunque cosa si stia facendo, i test unitari non dovrebbero essere trattati come cittadini di seconda classe nel mondo del software - dovrebbero essere soggetti agli stessi principi di progettazione di altre classi o funzioni il più possibile.
Sì, nell'ultimo articolo abbiamo detto che il test delle unità può aiutare a guidare la progettazione di un'applicazione e può aiutare a promuovere un design che renda l'intera applicazione più testabile. Questo è ancora vero, ma ha un costo: a volte il design testabile più unità non è il più chiaro.
Con ciò intendo che poiché un insieme di funzioni - o anche di una classe - è completamente testato in unità, la coesione ha il potenziale per essere compromessa perché stiamo facendo sacrifici per accedere a determinate funzioni per verificare il loro trattamento dei dati. Certo, questa non è una regola dura e veloce e questo potrebbe non essere un problema per alcuni, ma devi decidere su cosa stai per essere dogmatico: è un insieme di classi e funzioni o un sistema contiguo di test e funzioni che funzionano insieme?
In definitiva, credo che dipenda da come consideri i test come una parte più ampia del tutto. Se fanno parte del design della tua applicazione, il design potrebbe non risentirne. Ma se si visualizzano i test come un ripensamento, la progettazione dell'applicazione principale potrebbe essere compromessa solo leggermente.
Come si suol dire, il software non viene mai fatto e dal momento che i test unitari fanno parte di un software, non è mai stato fatto.
Poiché l'applicazione si evolverà sempre - sia che i bug vengano schiacciati, che vengano introdotte nuove funzionalità (o addirittura rimosse), i test associati dovranno essere aggiunti o aggiornati. E torna sempre indietro nel tempo.
Inoltre, se lavori in un team di sviluppatori, la mancanza di test di aggiornamento può influire negativamente sul team in quanto i risultati dei test possono essere falsi positivi o falsi negativi. Una volta scritti i test, è imperativo che vengano aggiornati; altrimenti, possono risultare in un prodotto molto povero.
Unit Testing è una vendita molto più semplice quando si inizia con un progetto, ma se si sta cercando di integrarlo in un'applicazione esistente (o tema o plugin, nel nostro caso), ci vorrà un po 'di tempo e sforzo.
E anche se non c'è una pallottola d'argento su come puoi eseguire perfettamente su questo, ci sono alcuni buoni modi per iniziare a implementare la pratica nel tuo lavoro quotidiano:
Se segui i passaggi precedenti, alla fine finirai con una quantità significativa di copertura del codice. Sì, ci vuole tempo e sì probabilmente dovrai rielaborare gran parte del codice, ma quello stesso investimento temporale produrrà dividendi nel futuro del tuo prodotto.
Ecco un riepilogo delle risorse che possono contribuire a testare con successo i tuoi progetti basati su WordPress:
Tra la prima serie di articoli e questa serie di articoli, è stata posta una solida base sulla quale è possibile continuare a sviluppare le proprie pratiche di test unitario.
Accentsconagua