Lascio a voi la lettura dell’articolo completo (in inglese).

Eccoli:

• PHPUnit
• Selenium RC
• PHP CodeSniffer
• Phing
• XDebug
• PHPDocumentor
• phpUnderControl
• Zend Framework (o un framework a piacere)
• Subversion
• Jira

Escludendo PHPUnit (al quale anche noi stiamo dedicando una serie di articoli), XDebug (personalmente non l’ho mai usato, ma ha una buona fama), PHPDoc (che conosciamo quasi tutti, e al quale credo in un futuro non troppo remoto dedicherò qualche post), a Subversion (indispensabile per lo sviluppo di software in collaborativa) e al framework di turno, gli altri strumenti mi risultano se non nuovi quantomeno poco conosciuti.

Cosi scopro che Selenium RC è un tool che può essere utilizzato insieme a PHPUnit allo stesso scopo; PHP CodeSniffer invece è un pacchetto disponibile su Pear che analizza il codice scritto e rileva eventuali infrazioni rispetto ad un insieme di standard di programmazione.

Phing invece opera sulla falsariga di Ant (per Java), il quale se non ricordo male è implementato pure su symfony. Diciamo che è un utility per automatizzare certe operazioni da linea di comando.

PHPUnderControl sinceramente ho capito solo che serve per tenere il controllo sullo stato dell’applicazione. Rimando al sito per ulteriori informazioni.

Last but not least, Jira. Da quanto leggo si tratta di un tool per il bug tracking, simile a trac., e per progetti “seri” strumenti simili sono sempre consigliati.

Non sono strumenti assolutamente indispensabili, ma almeno alcuni sono più che consigliati nella realizzazione di progetti di una certa consistenza.

E voi? Avete i vostri strumenti ai quali non rinuncereste mai? Ditecelo nei commenti!

Se ricordate le puntate precedenti uno dei compiti di un framework come PHPUnit è quello di far risparmiare tempo al programmatore che sarà meno impegnato in compiti di debug potendosi concentrare maggiormente sullo sviluppo e l’implementazione delle funzionalità delle proprie classi. Vediamo quindi alcune delle funzioni avanzate più importanti in termini di tempo risparmiato e di utilità all’interno del framework.

Fixtures
Sicuramente una delle funzionalità che permette di risparmiare più tempo quando si devono preparare ed eseguire i test per la verifica del corretto funzionamento delle nostre classi. Le fixtures permettono di partire con i test da uno stato ben preciso per tornarvi poi quando ogni singolo test è stato eseguito. Immaginate di dover testare dei metodi che abbiano a che fare una base di dati: invece che ripetere ogni volta il codice per la connessione al database, l’inizializzazione dei dati, la pulizia delle tabelle alla fine del test basterà definire tutte queste operazioni una singola volta per poi richiamare semplicemente il metodo così definito. I metodi in questione sono setUp() e tearDown() che conterranno rispettivamente il codice di inizializzazione e di pulizia dell’ambiente di test. In questo modo eviteremo la scrittura di codice ridondante e renderemo più semplici e chiari i nostri test.

Questi due metodi vengono richiamati automaticamente dal framework ogni volta che viene eseguito un metodo di test. Inoltre, per fare in modo che ogni test non sia per assolutamente influenzato dagli altri, i metodi vengono richiamati ogni volta su nuove istanze della classe che implementa il TestCase.

I metodi setUp() e tearDown() sono in teoria simmetrici ma non lo sono in pratica. Infatti l’implementazione di tearDown() è richiesta solo quando nel setUp() sono state allocate risorse esterne come socket o file. Se nel setUp() sono solo stati allocati oggetti PHP appartenenti alla classe l’implementazione di tearDown() può essere tralasciata. Ad ogni modo se nel setUp() sono stati creati molti oggetti è sempre buona cosa eseguire l’unset() delle variabili che puntanto agli oggetti nel tearDown() per fare in modo che vengano gestiti dalla garbage collection.

Performance
Un concetto molto importante parlando di testing è sicuramente quello che riguarda le performance. Volendo eseguire dei semplici test sulle performance di un metodo possiamo ricorrere alla classe PHPUnit_Extensions_PerformanceTestCase da cui estendere le nostre classi di test. Grazie a questa classe possiamo verificare che il test in esame venga eseguito entro un termine di tempo ben preciso che passiamo che parametro.

Code coverage
Ora che siamo in grado di scrivere i test per il nostro codice non resta che fare di quest’esperienza un’abitudine. Lavorare con classi semplici non implica nessun tipo di problema, man mano che il codice e la portata del nostro progetto aumentano diventa più complesso anche avere una visione d’insieme dei test e dei metodi che realmente sono coperti da un test.

Il framework PHPUnit ci viene ancora una volta in soccorso: sfruttando una funzionalità di Xdebug permette di analizzare la copertura del codice da parte dei test scritti. Si parla proprio di Code Coverage Analysis ed è la rappresentazione del codice delle nostre classi che viene utilizzato mentre si eseguono i test. Grazie a quest’analisi otterremo una serie di file di report che specificano le righe di codice interessate dall’esecuzione di un determinato test. In rosso saranno evidenziate le righe non interessate, in verde quello eseguite. Sulla base dei risultati ottenuti si potranno quindi affinare i propri test al fine di ottenere una copertura del 100% del codice in esame.

Sulla base del randomPasswordTest per la classe di generazione casuale delle password realizzato la nella puntata precedente ho realizzato i report che potete analizzare qui. Come potete vedere la coperturaè del 100%.

Generazione automatica dei test
Aggiungendo alcune annotazioni ai metodi delle proprie classi PHPUnit fornisce la possibilità di generare automaticamente semplici test partendo dal codice sorgente stesso. Queste annotazioni verranno interpretate da PHPUnit e serviranno da base per la generazione dei test. Si parla in questo caso di Skeleton Generator.

Le annotazioni sui test da far generare al framework vanno aggiunte utilizzando il solito @assert, quindi per una semplice classe Calculator avremo il seguente codice:

Le possibilità di test con @assert sono molteplici, non prevedono solo l’uguaglianza, rimando alla documentazione ufficiale per l’elenco completo.

CONCLUSIONE
In questa mini serie di tre articoli sullo unit testing abbiamo coperto l’argomento dalla teoria alla pratica focalizzando la nostra attenzione sul framework PHPUnit che è lo strumento di unit testing per eccellenza del campo della programmazione PHP. Abbiamo parlato dei vantaggi legati allo unit testing e del perchè è bene scrivere i test mentre si scrive il codice e non solamente alla fine, abbiamo visto come applicare queste regole al fine di migliorare il codice prodotto ed anche il proprio lavoro nel senso dell’azione e non del fine.

Chiaramente questa piccola guida non è esaustiva sull’argomento ma spero serva da introduzione ad un mondo che vorrete scoprire da soli affascinati ed incuriositi da quello che avete letto qui. Ora tocca a voi, come diceva un mio illustre docente universitario di Sistemi Operativi “è ora di sporcarsi le mani, alzate il cofano e guardate cosa c’è sotto“.

I commenti sono sempre apprezzati, sentitevi liberi di esprimere le vostre idee e i vostri dubbi siamo qui per parlarne.