Visto che trovo ben poco materiale in italiano sulla questione TDD, ho deciso di scrivere un articolo banale banale per raccontarvelo. Qualche tempo ha ho scritto un post su come configurare PHPUnit con NetBeans e xampp. Spero che questo nuovo post serva per completare il quadro del tdd.
Cosa significa la sigla TDD?
Significa Test Driven Development ovvero sviluppo guidato dal testing.
Più precisamente?
Significa che per sviluppare un software, si scrivono prima i test, e poi il codice vero e proprio. Per dirla in un modo più amichevole: sapendo che cosa deve fare una applicazione, noi dobbiamo prima scrivere del codice che si basa sulle specifiche di un progetto e che afferma che ciascun metodo deve risultare determinati valori.
Troppo complicato? Proviamo con un esempio semplice: scriviamo i test per implementare il metodo somma.
Immaginiamo di dover implementare una calcolatrice e di avere un metodo somma($addendoUno,$addendoDue); Va da se che somma(1,3) dovrà restituire 4. E’ un requisito del metodo. Bene, prima di implementare una qualsiasi riga di codice per la somma, scriviamo il test che controlla che dati due precisi valori, restituisca un terzo nel modo corretto. Scriviamo diversi test. Molto bene: i requisiti della nostra funzione somma, sono che la somma funzioni. (lol)
Abbiamo scritto i test, ed ora?
Ora lanciamo i test.
I test falliranno tutti, perchè non abbiamo ancora scritto nessun codice. Quindi procediamo e scriviamo il nostro metodo.
Testiamo il codice!
Adesso che abbiamo implementato il codice, lo possiamo testare e se il metodo somma funziona correttamente, farà andare a buon fine tutti i test. Bene! Il codice che abbiamo creato è stato testato e funziona.
Perchè ho scritto un test?
I testi si possono scrivere per varie ragioni ed ora elenco alcuni vantaggi che ho visto fino a questo momento:
- è facile intuire, che dicendo al codice come deve comportarsi quando è corretto (scrivere un test) ci porterà a ridurre i bug e, per esempio, a non avere errori di logica nella programmazione.
- possiamo fare refactoring e ritestare tutto il codice. Se i test vanno a buon fine, non dobbiamo chiederci se ci sono errori “in giro”. Il codice funziona bene come prima del nostro operato quindi siamo felici e tranquilli =). Abbiamo fatto un buon lavoro.
- vengono testate le singole funzionalità, o unità (unità di test appunto) ed si cicla in questo modo: si decide la funzionalità, si scrive il test, si scrive il codice e lo si modifica se e fino a quando il test non è soddisfatto. Da quel momento in poi, non dovremo più preoccuparci di nulla.
- ogni test è documentazione, in quanto spiega il funzionamento di ogni piccola unità di codice. Talvolta può persino sostituire la documentazione stessa.
Molto bene, non entro oltre nel dettaglio anche perchè se devo essere sincero, solo oggi ho realizzato una classe usando il TDD. In particolare ho pensato di scrivere del codice oop per realizzare una pagina html5 di base. Ho ragionato in questo modo: so come è fatto un documento scritto in HTML5, implemento dei test in modo che mi vengano restituite delle parti di codice nel modo esatto che desidero. Implemento il codice e via di seguito.
Ancora più semplicemente, vediamo gli steps:
- scrivo un test
- faccio fallire il test (per assicurarmi che la funzionalità non è stata implementata)
- metto mano al codice in produzione fino a che il test non ha esito positivo
- torno al passo 1
Ma scrivere un test dopo aver scritto il codice di produzione non è uguale?
Di primo acchitto potrebbe sembrare. Difatti, però, scriveremmo dei test influenzati dal codice, e di conseguenza non sarebbero test rivolti allo scopo dell’applicazione ma del codice appena scritto. Per ora il post lo concludo qui. Spero che sia utile a qualche lettore …
