PHPBlog.it

PHPUnit: dalla teoria alla pratica

Seconda puntata della mini serie dedicata allo Unit Testing con un occhio di riguardo al framework PHPUnit, dopo la prima parte di teoria passiamo oggi alla pratica vedendo alcuni esempi. Prendiamo in esame la classe per la generazione di password casuali presentata non molto tempo fa, lavoreremo su quel codice per realizzare i primi test ed i primi esempi. Pronti? Partiamo!

PHPUnit è un framework scritto da Sebastian Bergmann per lo Unit testing in PHP, la sua distribuzione avviene attraverso PEAR ed è composto essenzialmente da uno script richiamato da linea di comando per l’esecuzione dei test e da una libreria che ci guida nella realizzazione dei test stessi. Segnalo subito il link alla documentazione che vi tornerà molto utile, viste la sua chiarezza e completezza sotto ogni aspetto ogni vostro dubbio troverà risposta lì.

Come detto nella puntata precedente lo Unit Testing è un’attività di supporto allo sviluppo e al programmatore che permette di risparmiare parecchio tempo altrimenti destinato al debug potendolo assegnare ad altri compiti maggiormente utili. Realizzare degli unit test utilizzando un framework permette di risparmiare tempo prezioso per la loro scrittura e sfruttare in futuro gli stessi test massimizzando il riutilizzo del codice anche sotto quest’aspetto.

Il primo passo (una tantum) è quello di installare PHPUnit sul proprio sistema utilizzando PEAR:

pear channel-discover pear.phpunit.de
pear install phpunit/PHPUnit


Ora siamo veramente pronti. Vediamo quindi quali sono i passaggi che affronteremo per la realizzazione dei nostri test:

1. individuazione delle funzionalità implementate e loro isolamento
2. scrittura di snippet di codice necessari alla verifica delle singole funzionalità identificate al passo precedente sia per casi di successo che di insuccesso
3. raggruppamento degli snippet in TestCase
4. raggruppamento dei TestCase in TestSuite
5. eventuale raggruppamento di più TestSuite tra di loro
6. esecuzione delle TestSuite e correzione degli errori verificatisi

Nella classe di generazione casuale di password abbiamo un solo metodo getPassword(), in questo caso il punto 1 della lista precedente è molto semplice. La funzionalità da testare è solamente quella. Dovremo quindi scrivere uno snippet di codice che verifichi in primo luogo che la lunghezza della password generata coincida con la lunghezza richiesta e passata come parametro alla classe, in secondo luogo verificheremo anche che la quantità di cifre inserite nella password genera sia conforme alla richiesta anch’essa eseguita via parametro.

In questo semplice test possiamo vedere alcune convenzioni adottate nella scrittura del test stesso:

• la classe che rappresenta il TestCase ha il nome della classe da testare seguito da Test, questo per identificare in modo semplice la classe che si sta testando
• la classe di test estende PHPUnit_Framework_TestCase
• i vai snippet di codice che compongono un test sono metodi pubblici che non accettano parametri ed iniziano con la parola test*
• all’interno del codice, per controllare che le operazioni eseguite abbiano avuto il risultato corretto, vengono utilizzati i metodi assert*. Questi metodi controllano che un’operazione abbia fornito un risultato adeguato quando eseguita

A questo punto non resta che eseguire il test e vedere se il codice scritto è corretto:

phpunit randomPasswordTest.php

che restituisce i seguenti dati:

PHPUnit 3.2.15 by Sebastian Bergmann.
..
Time: 0 seconds
OK (2 tests)


I test presenti nel TestCase vengono eseguiti uno alla volta in modo sequenziale ed il loro esito è specificato attraverso un carattere:

• . (punto) test eseguito correttamente
• F test fallito
• E errore nell’esecuzione del metodo di test
• S test saltato
• I test incompleto o non ancora implementato

In questa seconda puntata abbiamo introdotto in modo pratico lo Unit Testing e la sua realizzazione attraverso il framework PHPUnit. Il mio consiglio è quello di fare alcune prove in prima persona magari partendo dal codice completo che potete scaricare come sempre passando poi all’applicazione su qualche vostro progetto implementando quindi dei test da zero.

Ricordate sempre Martin Fowler: Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. – Ogni volta che siete tentati di scrivere qualcosa in un print o in un’espressione di debug scrivetela invece come un test.

I commenti qui sotto sono a vostra disposizione per domande, critiche, suggerimenti…che aspettate?

TERZA PUNTATA
PHPUnit: tecniche avanzate