L’argomentazione utilizzata per minimizzare l’utilità dei test è la semplicità dell’esercizio, al che ho pensato a come l’avrei risolto in Erlang, mi sono detto che “effettivamente la soluzione è semplice”, ho iniziato a scriverla provandola nella shell del linguaggio e subito ho provato un senso di fastidio

Continuavo a scrivere e riscrivere (va bhe, la shell ti da la possibilità di richiamare i comandi passati, ma il discorso non cambia) le stesse invocazioni verificando ad occhio il risultato, al che ho capito il senso di fastidio: che differenza c’è fra quello che stavo facendo e scrivere dei test unitari? Nessuna, tranne che i primi sono effimeri e non ti possono venire in aiuto quando sarai chiamato a fare refactoring. Quindi, amici dei linguaggi funzionali, perchè non vedete i test unitari come delle sessioni di interazione con la shell permanenti e automatiche?

Vi dirò di più, la soluzione che avevo inizialmente pensato era sbagliata :-) Dopo aver passato tutti i test che Martin aveva fatto nella presentazione di cui sopra, mi sono chiesto se potevo rompere il codice in qualche modo, ho visto che non erano coperti dei corner case, per esempio c’è la partita peggiore (tutti 0), ma non c’è la partita migliore (tutti strike), scrivo un test… e non passa :-)

Come vedete qui sotto, utilizzo una variabile per tenere il conto dei frame elaborati, inizialmente non lo facevo e nel caso di uno strike nell’ultimo frame, i due tiri di bonus successivi metchavano con la terza clausola e venivano considerati dei frame normali, quindi il “perfect game” che dovrebbe avere uno score di 300 aveva score 320

Alla fine ho guardato il codice e quella variabile arbitraria per contare il numero dei frame proprio non mi andava giù e senza cambiare i test sono arrivato a questa seconda soluzione

Che non mi piace perchè anche se rende più esplicito (forse anche più imperativo?) il conto dei frame, secondo me si capisce di meno, sopratutto non mi piace score_frame perchè si occupa sia di calcolare lo score di un frame (e fin qui), sia di selezionare i tiri rimanenti eliminando quelli del frame corrente

Cosa ne dite? Quale vi piace di più?

“Why do we never have enough time to do it right, but always have enough time to do it over?

LOL! Nel libro ci sono anche spunti interessanti che riguardano l’attività di planning, infatti visto che ufficialmente non terrò nessun talk all’AgileDay almeno porterò un paio di argomenti sul planning da discutere in uno degli open space disponibili, sempre che ci sia qualcuno interessato :-)

Ultimamente ho dovuto affontare uno di questi problemi: in YouRank abbiamo una definizione di domain che consente data un’url di ricavare quello che noi consideriamo essere il dominio di quell’url. Quello che facciamo è eliminare il protocollo, generalmente “http://” e la parte iniziale dell’url se e solo se questa corrisponde a “[wW]{3}[^.]+\.”. Quindi l’url “http://www.gabrielelana.it” avrebbe come identificativo di dominio “gabrielelana.it”

Questo tipo di operazione (estrazione dell’identificativo univoco del dominio di un’url) deve essere eseguita in contesti differenti: sia durante l’elaborazione dei dati di navigazione grezzi (quindi in javascript), sia durante l’esecuzione di query sul database (banalmente per raggruppare i risultati per dominio). Inizialmente, proprio per evitare di duplicare il codice, ho optato per un’implementazione in javascript “yr.uri.Http#domainWithoutPrefix” (metodo domainWithoutPrefix della classe yr.uri.Http), che richiamavo all’interno delle query di sqlite “JS_CALL(“DOMAIN_WITHOUT_PREFIX”, urlOfDomain)” [1], per ogni record del result set dovevo creare un oggetto “yr.uri.Http” solo per poter utilizzare il metodo “domainWithoutPrefix, questo unito al costo del marshalling fra sqlite e javascript, si è rivelato essere superiore al budget :-)

I miei sensi di ragno mi facevano venire la nausea tutte le volte che pensavo all’ovvia soluzione del problema: implementare in C la funzione “DOMAIN_WITHOUT_PREFIX” da richiamare direttamente in sqlite. Ho passato giorni a tentare di immaginarmi soluzioni alternative al problema senza trovare niente. Alla fine ho mollato, ho iniziato a scrivere il primo test automatico e subito ho capito

Stavo sostanzialmente riscrivendo i test che a suo tempo scrissi per “yr.uri.Http#domainWithoutPrefix”, questo si che sarebbe stato veramente sbagliato! Potevo ancora conservare in un’unico punto autorevole la definizione del concetto di identificato di dominio: nei test. In pseudo codice

assertDomainWithoutPrefixIs("gabrielelana.it", "http://www.gabrielelana.it")
assertDomainWithoutPrefixIs("blog.yourank.com", "http://blog.yourank.com")
assertDomainWithoutPrefixIs("example.com", "http://www1.example.com")
assertDomainWithoutPrefixIs("example.com", "http://www123.example.com")
assertDomainWithoutPrefixIs("w12.example.com", "http://w12.example.com")
...

dove

assertDomainWithoutPrefixIs = function(expected, given) {
    assertEquals(expected, storage.call("DOMAIN_WITHOUT_PREFIX", given));
    assertEquals(expected, yr.uri.Http(given).domainWithoutPrefix);
}

Quindi, la lezione che ho imparato è: “Se non è possibile mantenere la definizione di un concetto in un unico punto all’interno del codice, testa tutte le implementazioni esistenti con un unico test automatico, in modo da far diventare il test quell’unico punto”

Link of the week
Quote of the week

No problem. “Easy” in the developer sense, of course, which translates in real life to “theoretically possible and I have a vague plan”

[1] Abbiamo implementato un meccanismo attraverso il quale è possibile invocare delle funzioni javascript (previo setup) da delle query sqlite, niente di esoterico (anche il wrapper a sqlite di mozilla implementa lo stesso meccanismo) solo una precisazione nel caso qualcuno se lo fosse chiesto

mocks, stubs, dependency injection, IoC containers, Extract & override technique, Record\Replay, AAA and more

da rendere troppo ripida la curva d’apprendimento per un programmatore inesperto. Questa secondo Roy sarebbe uno dei freni alla diffusione dei test unitari (e a seguire del TDD) come pratica di programmazione

Concordo sul fatto che nella maggior parte dei casi tutta la sovrastruttura messa in campo per abilitare/facilitare la scrittura di test unitari sia sostanzialmente un bad smell. E’ inutile proporre il test unitario come strumento di design dicendo che il “codice facilmente testabile è anche dotato di buone proprietà quali basso accoppiamento, alta coesione, ecc…” quando poi vengono proposti framework e strategie per facilitare il test unitario di codice difficilmente testabile :-) I framework citati sono nati per permettere ai programmatori di testare in maniera automatica

• codice legacy
• codice che “vive” hai confini del proprio sistema e che “parla” con altri sistemi (ex: DBMS, file system, network, ecc…)
• codice che usa librerie proprietarie
• ecc…

Nel resto dei casi sarebbe meglio rifattorizzare il codice per renderlo facilmente testabile e fargli acquisire le buone proprietà di cui sopra, da qui la legge implicita del test unitario: “Se scrivere un test unitario per un pezzo di codice è troppo difficile, non riscrivere il test, riscrivi il codice”

Il talk sarà sulle tecniche di test automatico, porrà l’accento sul test di applicazioni web ed in particolare quelle sviluppate con il linguaggio di programmazione php, ovviamente non mancheranno riferimenti al mondo delle metodologie agili e quindi su come i test dovrebbero essere integrati nel ciclo di sviluppo del software. Ho scelto di affrontare questo argomento perchè nella mia esperienza di coach/mentore/trainer/? ho notato che molti team possono ottenere grandi guadagni in termini di produttività e qualità dedicando maggiore attenzione ai test e sopratutto ai test di tipo automatico. Volete sapere perchè? Volete sapere come? Ci vediamo il 18 Maggio a Verona ;-)

Titolo:

Testing Web Applications

Abstract:

Lo scopo del talk sarà quello di portare all’attenzione della comunità la “pratica” del “test automatico” come mezzo per aumentare non solo la robustezza, ma anche la qualità e la flessibilità, del codice sviluppato

Verranno elencate le principali tipologie di test automatici per applicazioni web, si parlera’ di: test unitari, test di integrazione, test di accettazione, smoke tests e database tests. Per ogni tipo di test presentato, verra’ data risposta alle seguenti domande:

• Quali obiettivi possono essere raggiunti?
• Come posso realizzare questo tipo di test? (per ogni tipo di test verranno presentati framework, tools e best practices)
• La scrittura di questo tipo di test dove si colloca all’interno del ciclo di sviluppo? (verranno fatti particolari riferimenti alle metodologie agili)
• Ci sono controindicazioni?

Parleremo inoltre di pratiche agili a sostegno dei test come la continuous integration