Riguardo alla faccenda mi preme segnalare un nuovo punto di vista per affrontare il problema della valutazione di un framework proposto da Chris Hartjes che sul suo blog parla per esperienza diretta data dall’ultimo progetto su cui sta lavorando. A poco dal rilascio (colpevolmente) si è trovato a dover scrivere dei test per verificare in modo semplice e sicuro che le varie parti funzionassero a dovere anche dopo l’inserimento di nuove funzionalità o modifiche, utilizzando Code Igniter per il progetto si è posto una semplice domanda: dove sono i test e gli strumenti per realizzarli?

Allargando anche agli altri framework sulla piazza ne esce quanto segue:

• Code Igniter: 0 test per il core, atto di fede verso gli sviluppatori
• Zend Framework: ha una grossa quantità di test che vengono richiesti per ogni contributo dalla community
• CakePHP: vedi sopra, i test coprono l’80% del codice
• symfon: ha il suo testing framework dalla nascita con oltre 8800 test per la copertura dell’80% del codice base

Chris aggiunge che vista la disponibilità di strumenti per il testing non ci possano essere scuse per la mancanza di test a supporto delle funzionalità di un’applicazione. Pagare adesso, o paga dopo, sicuramente dovrai pagare per risolvere qualche bug nella tua applicazione. Pagare ora è semplicemente più economico.

I test sono la prova che il codice si comporta come ci si aspetta, inoltre il codice testabile è molto spesso più facile da modificare man mano che il tempo passa.

Quando si scrivono applicazioni e programmi in genere si cerca di partire sempre con il piede giusto prestando particolare attenzione alla struttura del codice per avere sorgenti “puliti” e facilmente mantenibili da noi o da terze parti. Si scrive quindi con un occhio di riguardo al futuro cercando di scrivere codice migliore e più aperto possibile. Tuttavia è pressochè certo che durante la fase di sviluppo (e non durante la progettazione o la stesura delle specifiche) il committente varierà le specifiche iniziali o i tempi ed i modi in cui vuole che la sua applicazione venga realizzata. Questo porterà inesorabilmente il programmatore di inserire parti di codice non previste, sviluppate in poco tempo e contro i propri consigli che andranno a degradare la qualità del codice prodotto facendogli perdere leggibilità ed apertura a modifiche future.

Purtroppo visto che i tempi da dedicare allo sviluppo sono sempre inferiori a quelli che realmente servirebbero per scrivere delle applicazioni in modo pulito e ragionato non è possibile concentrarsi contemporaneamente sulla scrittura del codice e sul suo refactoring. Quando impegnarsi quindi per migliorare il design del proprio codice? Esisteranno sicuramene molte scuole di pensiero a riguardo (se ve ne piace qualcuna in particolare ditecelo pure nei commenti) ma quella che preferisco è quella teorizzata da Fowler come “La regola del 3” (Rule of Three):

La prima volta che fai qualcosa, semplicemente la fai. La seconda volta che farai qualcosa di simile, probabilmente controvoglia la duplicherai comunque. La terza volta che farai qualcosa di simile sarà arrivato il momento di compiere il refactoring.

Gli approcci alle attività di refactoring sono sostanzialmente due e possono essere svolte prima di introdurre una nuova modifica o dopo la sua introduzione. Nel primo caso si tratterà di preparare il codice per ospitare nuove funzionalità andando a migliorare il design dell’applicazione dove possibile al fine di rendere meno vincolanti alcune operazioni presenti nel codice già scritto. In questo modo si potrà risparmiare tempo nel momento in cui si renderà necessaria l’implementazione di nuove funzioni. Nel secondo caso, forse quello più comune, si lavora sul codice presente al fine di migliorarne la sua strutturazione immediatamente dopo aver aggiunto una nuova funzionalità. In questo modo il codice sarà lasciato sempre nella migliore delle condizioni per poterci lavorare in seguito. Le fasi di sviluppo saranno quindi due: inizialmente ci si concentra sul raggiungimento dell’obiettivo della funzionalità per poi passare al refactoring per ristrutturare e riorganizzare quanto appena prodotto.

Di pari passo con il refactoring va il testing che deve accompagnare l’implementazione in tutto il suo processo al fine di evitare spiacevoli sorprese al momento della messa in produzione della nuova funzionalità. Quando si applicano delle modifiche al codice sorgente è possibile che si inseriscano degli errori nel codice. Spesso capita che una modifica in un punto generi un errore in un’altra parte del programma come abbiamo visto quando abbiamo parlato di PHPUnit. Ogni volta che aggiungete una funzione scrivete subito un piccolo test che controlli il suo funzionamento, poi sviluppate la funzione ed eseguitelo. Se tutto va bene siete sicuri che il codice inserito funziona e che la modifica di questo non ha influito in modo distruttivo sul resto del codice. Quando applicate refactoring del codice eseguite spesso questi test; questo vi assicura che l’interfaccia del software sia sempre la stessa, e che tutto funzioni correttamente.

Alcuni link consigliati:

• Il sito di Martin Fowler sul Refactoring
• Refactoring: Improving the Design of Existing Code
• Code refactoring

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.

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

Sappiamo tutti che l’approccio di un programmatore verso un progetto è qualcosa di puramente soggettivo, le tecniche utilizzate ed il metodo con cui si procede sono quelli dettati dall’(in)esperienza del programmatore stesso e dalle convinzioni che ognuno ha nei propri mezzi. Purtroppo nella maggior parte dei casi queste convinzioni sono alla base dei problemi che affliggono gran parte dei progetti software nei primi mesi di vita: scadenze non rispettate, bug, funzionalità non implementate secondo specifiche…

Chiaramente ogni progetto è qualcosa di unico visto che le variabili in gioco sono talmente tante che non si può definire un metodo di sviluppo minuzioso, è perciò fondamentale sfruttare la tecnologia che viene in nostro aiuto approfittando del testing automatico al fine di limitare gli errori in fase di rilascio di un’applicazione garantendo il corretto funzionamento del prodotto.

Il funzionamento corretto di ogni componente di un sistema dipende dalla correttezza delle funzioni che implemente e dall’interazione con gli altri componenti con cui comunica. Quindi ma mano che si sviluppano le varie classi e si modificano i package ci si deve ricordare di verificare il funzionamento corretto di tutto ciò che ha a che fare con il codice aggiornato. Piccoli cambiamenti in una classe possono causare danni inauditi a del codice che riteniamo molto distante dalle modifiche apportate. Molta attenzione e perfetta conoscenza di un sistema possono non bastare ad evitare disastri. Una strada per evitare questo tipo di problemi è rappresentato dal test dei singoli componenti eseguito in modo regolare e magari automatizzato.

Lo Unit Testing ha un approccio di tipo bottom-up lavorando sulle classi con metodi di test raggruppati in test case che si occupano di verificare in modo rigoroso il corretto funzionamento di ogni componente che deve rispondere come specificato nel test. Sfruttare lo Unit Testing è un buon metodo per assicurare la qualità della progettazione di un sistema infatti esso permette di tenere sotto controllo le responsabilità di ogni classe e di ogni funzione.

Pensate ora ad una piccola modifica al codice apportata un venerdì sera (cosa che sconsiglio sempre) senza un framework per eseguire tutti i test del caso. Alcune prove di funzionamento fatte manualmente non hanno manifestato errori e date per scontato che tutto funzioni correttamente. Pensate ora alla telefonata che vi arriva dal cliente o dal capo e vi fa uscire dal pub, dal ristorante o peggio vi toglie dal vostro divano “Cosa hai fatto a $applicazione? I clienti non riescono ad entrare nel sistema!“.

Ricordate: i bug peggiori non provocano errori che si manifestano bloccando in modo palese l’applicazione, sono quelli che senza creare segnali agiscono sulla logica del vostro progetto. I peggiori bug non si manifestano dove state lavorando, sono causati lì ma si manifestano da tutt’altra parte magari giorni se non settimane dopo. Eseguire test regolari vi può salvare nella maggior parte di questi casi, quindi scrivete i test mentre scrivete il codice. Se qualcuno vi riporta un bug scrivete prima il test che lo conferma e poi eseguite il fix richiesto, i bug hanno l’abitudine di ripresentarsi.

In PHP il framework per lo unit testing si chiama PHPUnit che contiene vari tool e librerie che permettono di eseguire tutte le azioni utili al test del codice. Nella prossima puntata vedremo come sfruttare PHPUnit con degli esempi pratici sul codice della classe per la generazione casuale di password presentata poco tempo fa.

SECONDA PUNTATA
PHPUnit: dalla teoria alla pratica