Extreme Enthusiasm

Ho appena finito di leggere Testing Extreme Programming di Lisa Crispin e Tip House.

Descrive il ruolo dei tester in un team XP. Si concentra quindi sugli acceptance tests. Per me gli AT erano un po’ misteriosi; sono riuscito a praticare bene gli unit test, ma gli AT li ho sempre un po’ trascurati. A volte con risultati disastrosi: una mia debacle è stata dovuta, fra l’altro, al fatto di non avere pronti degli AT che dimostravano che gli interventi tecnici fatti da qualcun’altro sul nostro progetto avevano distrutto 90% delle storie funzionanti. Ma sto divagando.

Il grosso del libro è discorsivo e spiega il ruolo del tester nelle varie fasi del progetto XP. La parte che per me è stata più utile sono invece i brevi capitoletti su come tecnicamente realizzare gli AT. Lo stile che viene presentato qui è assurdamente semplice, e per questo mi piace molto!

In pratica gli AT vengono realizzati con JUnit, con la differenza che si cerca di renderli il più possibile vicini al linguaggio del cliente, con cui sono espresse le user stories. Ho cercato di applicare questa lezione nel progettino che stiamo realizzando nell’XP user group di Milano.

Per esempio, la user story Pagina contenente le news ha un test di accettazione che dice, in italiano:

IF una news è presente nel sistema THEN appare nella pagina

Riscritto in JUnit diventa:

public void testIfInseritaThenAppare() {
  insertNews("Titolo", "Testo testo testo", 
             insertedToday(), expiresTomorrow());
  assertEquals(1, numberOfNewsInPublicPage());
  assertNewsPresent("Titolo", "Testo testo testo", 
                    insertedToday());
}

Forse si può migliorare ancora, ma mi sembra che il codice parli a sufficienza.

UPDATE: Gabriele (sempre lui!) mi ha segnalato questo articolo: Literate
Programming with jMock. Molto carino: presenta tecniche su come
rendere gli acceptance test sempre più parlante, sempre più
vicino a qualcosa che si legga come lingua naturale.

Non sono convintissimo che sia questo però quello che Knuth aveva in
mente quando parlava di literate programming. Lui si preoccupava
soprattutto di cose come il fatto che i commenti fossero dentro al
codice, piuttosto che essere il codice dentro a un documento
leggibile dagli esseri umani. Giustissimo! Ad esempio, anche se il
codice di un dato programma è scritto benissimo, in generale non è
chiaro da dove mi conviene iniziare a leggerlo. In literate
programming, l’autore prepara un percorso di lettura ideale, che non
necessariamente parte con il main.

L’ideale di codice parlante degli XPer invece è una cosa diversa.
Si tratta di limare e ripulire il codice fino a quando non
c’è bisogno di altri commenti. Il codice di Knuth non è
esattamente leggibile. Anche il linguaggio TeX, che Knuth ha
inventato, è molto poco leggibile. Credo che gli XPer facciano cose
che sono nello spirito di LP, ma molto diverse nell’esecuzione.

This entry was posted on 12 May 2006 at 22:00 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.