Le migliori pratiche per i test di regressione sui siti Web WordPress?

Ciao a tutti,

Mi piacerebbe sapere cosa altri che stanno offrendo soluzioni non blog complesse ai clienti con WordPress come piattaforma cosa stanno usando per i test di regressione automatizzati ?

Per coloro che non hanno familiarità con il termine "test di regressione", Wikipedia lo definisce come:

Il test di regressione è qualsiasi tipo di test del software che cerca di scoprire errori software dopo che sono state apportate modifiche al programma (ad esempio correzioni di bug o nuove funzionalità), eseguendo nuovamente il test del programma. L'intento del test di regressione è garantire che una modifica, come una correzione di bug, non abbia introdotto nuovi bug.

Altro che dice Wikipedia dice quanto segue che è esattamente quello che sto vivendo in un progetto in questo momento:

L'esperienza ha dimostrato che, man mano che il software viene risolto, l'emergere di nuovi e / o riemergere di vecchi guasti è abbastanza comune. A volte si verifica la ricomparsa perché una correzione viene persa a causa di scarse pratiche di controllo delle revisioni (o semplice errore umano nel controllo delle revisioni). Spesso, una correzione per un problema sarà "fragile" in quanto risolve il problema nel caso ristretto in cui è stato osservato per la prima volta, ma non in casi più generali che possono sorgere durante la vita del software. Spesso, una correzione per un problema in un'area causa inavvertitamente un bug del software in un'altra area. Infine, spesso accade che quando una funzione viene riprogettata, alcuni degli stessi errori commessi nell'implementazione originale della funzione sono stati commessi nella riprogettazione.

Con la natura globale di azioni e filtri sto scoprendo che la complessità inizia a dilagare quando aggiungo più funzionalità richieste dal cliente e diventa difficile ottenere un plugin complesso stabile, specialmente se utilizza molte chiamate WP_Querye aggiorna molto il database .

La soluzione nella mia mente sarebbe quella di impostare test di regressione con una serie di "casi di test" per comprendere una "suite di test". In teoria non è così difficile quando si sta testando l'output HTML delle richieste HTTP GET. Ma diventa un po 'più complicato quando devi testare le cose quando accedi tramite la console di amministrazione e / o per testare le interazioni jQuery.

Lo sto configurando come un wiki della comunità nella speranza che qui possiamo raccogliere le migliori pratiche, ma sono davvero ansioso di ascoltare i processi che stanno utilizzando altri professionisti di WordPress.

PHPUnit verrebbe in mente se la suite di test WP non fosse così rotta e se WP fosse stato progettato e scritto in modo tale da poter essere effettivamente testato correttamente. ;-)

Più seriamente, puoi testare i tuoi plugin tutto ciò che vuoi dal loro punto di vista funzionale con test unitari e simili. Il problema è che questi test non garantiranno che colpiranno sottili possibilità introdotte dagli aggiornamenti di WP, figuriamoci che continueranno a funzionare una volta collegati a un'installazione WP personalizzata.

Tra le cose colorate che ho visto accadere:

• Una leggera modifica nell'API WP influisce sulla funzionalità del tuo plug-in, ad esempio l'hook su cui sei abituato per ottenere un termine id e ora sta ottenendo un termine id tassonomia. (È probabile che i termini del test abbiano lo stesso ID per entrambi).

• Una leggera modifica nell'API WP comporta la ricezione di un WP_Erroroggetto invece del valore precedentemente previsto falsecome input errato.

• Il plug-in viene aggiunto dalla cartella mu-plugins, determinando un flusso di codice leggermente diverso.

• Il tuo plugin ha funzionato bene fino a quando memcached o qualche altro archivio persistente sono stati abilitati.

• Il tuo plugin ha funzionato bene fino a quando il disprezzato switch_to_blog () è stato chiamato.

• Un plugin cambia l'hook sul quale risiede quando viene chiamato e lo interrompe inconsapevolmente come effetto collaterale.

• Un plug-in (un?) Confonde consapevolmente con i tuoi dati di input o output al punto in cui le cose sembrano rotte anche se non sei in errore.

Potrei espandere la lista ancora e ancora, ma quelli sarebbero gli elementi chiave che hanno rotto i miei plugin. I due articoli sono discutibili con i test unitari. Anche i prossimi due, se sei abbastanza paziente, ma direi che WP non dovrebbe cambiare il modo in cui le cose funzionano quando si verificano. Nessuna quantità di test funzionerà attorno all'implementazione buggy di switch_to_blog (). E gli ultimi due sono irrimediabilmente non verificabili.

Oh, e ... non farmi nemmeno iniziare dall'assalto di allegati, bozze automatiche, revisioni, voci di menu e ciò che non finisce nella tabella dei post.

In bocca al lupo... :-)

Dovresti considerare fortemente il selenio .

Ti consente di registrare azioni (ad es. Immissione di dati in un modulo, fare clic su un collegamento) e quindi eseguire affermazioni. Si integra anche con PHPUnit. Consiglio vivamente di dare un'occhiata alla demo di due minuti.

Il selenio è probabilmente utilizzabile, ma penso che nei tempi moderni troverai Codeception migliore e più facile da usare. Per il test di regressione visiva più semplice , ha anche un'estensione che prenderà schermate e le confronterà automaticamente per te.

Naturalmente, i test Codeception WebDriver possono andare oltre ed eseguire test di regressione funzionale . Puoi compilare e inviare moduli, fare clic su pulsanti e collegamenti sul sito, eseguire qualsiasi JS, ecc. Puoi utilizzare un browser di vita reale come Firefox o Chrome nei tuoi test o puoi eseguire test senza testa con PhantomJS . Ciò significa che puoi anche eseguire i test WebDriver per il tuo plug-in come parte del suo processo di generazione su Travis CI, se lo desideri.

Esistono anche diverse librerie specifiche di WordPress per aiutarti a iniziare:

• WP Browser
• WP Codeception