Share
Nell'ultimo articolo, abbiamo iniziato a parlare della teoria dei test unitari in WordPress. Nello specifico, abbiamo esaminato il nostro lavoro sui temi dei test unitari e sui plug-in, quindi abbiamo iniziato a discutere delle unità di codice, su come questo ha influito sui nostri test e abbiamo esaminato i test unitari nel più ampio mondo dello sviluppo software.
Continueremo a discutere la teoria dei test unitari in WordPress, ma lo faremo nella prospettiva di come può aiutare a identificare i problemi, guidare l'architettura, documentare il progetto e altro.
Ricordiamo da prima in questa serie, che il modo tradizionale di fare test unitari è questo:
Sì, il primo passo è un po 'dogmatico. Perché sprecare minuti in esecuzione su qualcosa che sai fallirà, giusto? Comunque, hai capito l'idea. Ma mentre inizi ad applicare questa particolare tecnica allo sviluppo, scoprirai che svilupperai un certo ritmo per scrivere il tuo codice e questo fa parte dell'intero obiettivo.
Ma questo è solo la metà di esso - i test di unità possono effettivamente aiutarti a individuare problemi in fase di sviluppo.
Per capire, probabilmente è meglio tornare all'idea.
Supponiamo che tu stia lavorando su una funzionalità per un progetto basato su WordPress in cui consentirai agli utenti di creare un account utente senza accedere effettivamente al dashboard di WordPress. Ciò presuppone che tu abbia una configurazione del modello di pagina per gestire la registrazione, la necessaria validazione in atto e il codice per generare password ed e-mail.
Si carica la pagina nel browser, si tenta di creare alcuni utenti, alcuni con lo stesso indirizzo e-mail, alcuni con password errate, alcuni con caratteri non validi, ecc. Si ottiene il punto: ci sono n-numero di modi per la convalida passare e fallire. Questo è difficile! Ciò significa che ogni volta che viene modificata la funzione di registrazione dell'utente, è necessario eseguire lo stesso n-numero di registrazioni per assicurarsi che non vi sia nulla di rotto.
Oppure puoi scrivere una suite di test per prenderti cura di esso ed eseguirli ogni volta che il codice cambia.
Quindi, sì, i test di unità di scrittura possono richiedere molto tempo in anticipo, ma osservare la quantità di tempo risparmiato ogni volta che si modifica un'unità di codice. Ne vale la pena e questo può aiutare a identificare i problemi nella fase iniziale - cioè, prima che venga rilasciato in produzione - che potrebbe essere stato perso perché qualcuno ha dimenticato di simulare una permutazione del test.
Quando si tratta di scrivere test unitari, non si sta solo migliorando la qualità del proprio codice, assicurando che funzioni effettivamente, ma si sta fornendo intrinsecamente documentazione orientata agli sviluppatori.
Se stai testando la funzionalità che stai creando nel tuo prodotto, fornirai la documentazione su come funzionano le funzioni, quando dovrebbero fallire e quando devono passare.
Ci sono alcune supposizioni che derivano da questo: in particolare, si sta nominando e raggruppando logicamente le proprie funzioni e i relativi test e verificando correttamente ciascuna funzione.
Attraverso PHPUnit, i Test di unità WordPress facilitano l'esecuzione di asserzioni facili da leggere. Basta semplicemente dichiarare assertTrue, assertFalse o qualsiasi altra affermazione disponibile sulle funzioni che compongono il tuo progetto.
Seguendo il nostro esempio sopra, ciò significa che è possibile scrivere una funzione per assicurarsi che la funzione di registrazione utente non riesca quando si cerca di registrarsi con un indirizzo email vuoto:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Un semplice esempio, forse, ma il punto rimane: il tuo codice diventa auto-documentante e richiede solo che tu scriva test unitari chiari.
Forse uno dei vantaggi più sottovalutati dei test unitari è che può aiutare a guidare l'architettura del tuo progetto. In genere, lo sviluppo di temi o plug-in può iniziare in due modi:
Questi non sono intrinsecamente cattivi, ma penso che siano deboli (e sarò il primo ad ammettere che ho fatto più di quanto mi piacerebbe condividere!). Ma il passo "codice di scrittura" presuppone Un sacco, non lo fa?
Per tutti quelli che hanno scritto codice per un ampio periodo di tempo, siete tutti fin troppo familiari e finisci per colpire quel punto in cui ti rendi conto, "Oh ... non ci ho pensato."
Se sei fortunato, questo di solito significa che puoi scrivere un metodo di supporto o un altro condizionale per gestire il caso che hai trascurato, ma nei casi peggiori, significa che potresti dover rielaborare l'intera classe o l'intero set di funzioni per accogliere questo problema.
I test unitari, sebbene non perfetti, possono aiutare a mitigare questo.
Considera il fatto che, fin dall'inizio, stai elencando tutte le funzionalità che vuoi che il tuo tema o plugin offra. Non hai ancora scritto alcun codice, ma forse hai qualche tipo di schizzo dell'interfaccia utente e / o un set di diagrammi di classe.
Quindi, inizi a scrivere i test che stai per scrivere per testare il tuo progetto. Ricorda che parte del test dell'unità sta analizzando il codice dell'unità più atomica possibile, quindi ti viene chiesto di scrivere i test delle unità per ognuno di questi, ahem, unità.
A causa della natura dei test unitari, stai pensando intrinsecamente al tuo codice in modo diverso: invece di "scrivere codice", stai pensando "scrivi test", e poiché stai pensando a un livello più atomico, puoi Aiutateci, ma prendete in considerazione i casi marginali che sono così spesso raggruppati in "codice di scrittura".
Come sviluppatori, siamo fin troppo a nostro agio nell'usare le convenzioni che rafforzano continuamente il codice di scrittura. Con ciò intendo che tendiamo a fornire nomi di variabili abbreviati, nomi di funzioni criptici e nomi di classe che potrebbero non significare nulla per nessuno al di fuori di te o del team che sta lavorando al tuo progetto.
Il test delle unità non è necessariamente la chiave per scrivere il codice che è più facile da leggere, ma può andare un po 'oltre aiutando a fornire nomi di funzioni più puliti.
Ricorda da quel primo libro di programmazione che hai letto, la prima lezione di informatica che hai preso, o il primo pezzo di codice open source che hai visto, i nomi dei metodi sono tipicamente verbi. Perché non dovrebbero essere? I metodi sono modi per incapsulare il codice fa cose. Ma mentre lavoriamo a progetti sempre più lunghi, diventiamo più pigri e pigri e il nostro codice va da "register_user_and_email_password ()" a "nuovo account()".
Ovviamente, il primo è più pulito di quest'ultimo, ma se ci sforziamo di testare le unità di qualità e vogliamo assicurarci che i nostri test unitari siano facili da leggere e affinché siano facili da leggere, i nostri nomi delle funzioni devono essere facile da leggere.
Non è più facile da leggere:
$ this-> assertFalse (register_user_and_email_password (")); Invece di questo?
$ this-> assertFalse (new_account (")); Ancora una volta, forse questo è un semplice esempio, ma il principio rimane: scrivere buoni test unitari per aiutare a documentare autonomamente il codice che guida la lingua delle tue funzioni.
Abbiamo parlato delle nozioni di base sui test unitari e dei principali vantaggi, ma non abbiamo ancora discusso degli svantaggi derivanti dai test unitari e non abbiamo nemmeno dato un'occhiata a come incorporarli nel nostro flusso di lavoro.
Quindi nel prossimo articolo, tenteremo di fare proprio questo.
