Spec, spec delle mie brame
Joel Spolski non è esattamente un fan di XP, ma mi piace il suo Joel Test:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. … Give your team 1 point for each “yes” answer.
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
Spolski è un fan di lavorare con una specifica (vedi voce 7), infatti quello che faceva in Microsoft prima di mettersi in proprio era scrivere la specifica del Visual Basic incorporato in Excel.
Joel mi ha aperto gli occhi su come dovrebbero essere scritte le
specifiche. Prima di allora pensavo che una specifica dovesse per forza essere
basata su un farraginoso template (word),
tipo quelli propugnati da Steve McConnell nel suo libro Software Project Survival
Guide. Joel ha scritto, in Painless
Functional Specifications, che una spec dovrebbe essere
divertente da leggere. Dovrebbe essere scritta in uno stile e in un
formato inventato apposta per il tuo progetto, piuttosto che copiata da un
template. Dovrebbe raccontare storielle su Miss Piggy e le sue
avventure a mo’ di esempi.
Parlando di esempi, le spec scritte nel solito stile triste, verboso e farraginoso ne sono di solito prive. Eppure sono gli esempi la cosa più importante. Quando c’è un dubbio su quello che la spec vuol dire, è il momento di fare un esempio e vedere come il sistema si deve comportare. Questo in effetti è lo stile di spec prediletto dagli XPer, con l’aggiunta del fatto che gli esempi devono, a un certo punto, essere eseguiti automaticamente sul sistema.
Lavorare con una spec non è anatema per gli XPer. Come spiega bene Zio Bob:
On XP/Agile teams, programmers don’t just have a spec. They have a spec that executes. They have a spec that is unambiguous and cannot get out of sync with the application. They have a spec that is run against the system on a daily, or even hourly basis. On an XP team it is against the rules to check in code that breaks the spec.
La specifica per gli XPer è un insieme di test di accettazione, scritti in uno stile il più possibile vicino al linguaggio del cliente, in modo che il cliente possa capirla, confermarla, e —idealmente— scriverla.
Quello che un team agile non fa è
- scrivere tutta la specifica prima di iniziare l’implementazione
- fare scrivere la specifica a un analista che poi non partecipa all’implementazione
- scrivere i test di accettazione dopo che la feature funziona
Ci sono molti diversi sistemi per realizzare i test di accettazione. In ogni caso l’obiettivo è arrivare a un minilinguaggio che sia comprensibile per l’utente (Marick dice: business facing piuttosto che “technology facing”). Il concetto chiave è che non è necessario complicarsi la vita con lex e yacc e i diagrammi sintattici. E’ sufficiente un semplice parser realizzato in 4 righe di Java, Ruby, o simili.
In Extreme Programming Adventures in C#, Ron Jeffries scrive un semplice editor XML per suo uso e consumo. I test di accettazione sono degli script, in un semplice linguaggio inventato da lui, che permettono di specificare in maniera semplice il comportamento dell’editor.
*input
This is the first p|aragraph.
This is the second paragraph.
*end
*enter
*output
This is the first paragraph.
|
This is the second paragraph.
Questo esempio specifica che se premo “enter” quando il cursore sta in mezzo a un paragrafo (il cursore è rappresentato dalla linea verticale nella seconda riga), il risultato deve essere di aprire un nuovo paragrafo e posizionare il cursore fra il tag di apertura e quello di chiusura.
Uno strumento consolidato per realizzare test di accettazione è fitnesse. In fitnesse i test sono specificati come tabelle di dati, e inseriti in un wiki. Le pagine del wiki possono facilmente essere modificate dal cliente o dagli sviluppatori, per riflettere la continua evoluzione della comprensione dei requisiti da parte di entrambi. Sull’argomento “specifiche sotto forma di tabelle”, è interessante questo raccontino di Brian Marick. Rick Mugridge ha scritto un libro di test Fit for Developing Software, dedicato a Fitnesse.
Esistono tool di accettazione specifici per applicazioni web. Selenium rappresenta i test come tabelle html conservate sul server, che vengono interpretate come programmi dal browser. Watir pilota Internet Explorer attraverso l’automazione COM. Questi tool violano una convenzione abbastanza accettata che i test debbano bypassare la interfaccia utente. Infatti rendono abbastanza difficile scrivere test che siano concisi e orientati al business.
Nel mio piccolo, mi sono trovato molto bene nello scrivere test di accettazione come semplici script nel linguaggio della shell di Unix, Bash. Sicuramente sarebbe stato più elegante usare Ruby; il mio problema è che sono tuttora molto più abile con bash che con Ruby (ha ragione Giuliano!)
PS: nell’ultimo progetto che ho lavorato, il nostro punteggio-Joel è stato di 7-8. Sigh.