Il ponte pasquale e la partita di Champions League del Milan hanno colpito e il numerico presente in sala era di 9 indomiti, verso le 18:45 Uberto ha iniziato la sua presentazione: "JWebUnit + Fit/Fitness"; una panoramica delle possibilità offerte dall'utilizzo di questi strumenti.

Come prima cosa Uberto ha mostrato come è possibile "navigare" attraverso le pagine web di un sito utilizzando JWebUnit che, come ci ha spiegato Uberto, non è niente altro che un wrapper a HttpUnit, al quale aggiunge alcune facilitazioni consentendo di scrivere codice più compatto. A seguire una rapida introduzione a Fit/Fitness, abbiamo visto in cosa consiste, come eseguire i test, come modificare il Wiki e infine il funzionamento della ColumnFixture e della DoFixture: la prima utile nel caso il test riguardi i "dati" presenti all'interno della pagina web, la seconda indispensabile nel caso si voglia verificare un percorso di navigazione all'interno del sito

Infine Uberto ci ha spiegato come lui utilizza l'accoppiata di cui sopra: il suo team ha realizzato una fixture custom che prende i dati dal Wiki di Fitness e utilizza JWebUnit per accedere all'applicazione web che deve essere testata. La presentazione si è conclusa con una breve sessione di domande dalle quali è emerso che:

• Se si vuole automatizzare l'esecuzione dei test di Fitness non è necessario passare dall'interfaccia del Wiki, ma si può sempre utilizzare direttamente Fit da linea di comando
• Una delle comodità offerte da Fitness è la possibilità di importare/esportare dati da fogli di calcolo tanto cari ad alcuni manager
• Grazie alla sua facilità d'uso, Fitness risulta essere utilizzabili anche direttamente dal Customer, eventualmente coadiuvato da un programmatore del team
• Fitness risulta molto utile nel caso in cui i test siano più "data oriented" che "logic oriented", ovvero test che non contengono una logica particolarmente complessa (e quindi facile da generalizzare all'interno di una fixture facilmente riutilizzabile), ma implichino l'utilizzo di dati che sarebbero difficilmente gestibili all'interno del codice dei test

La serata è proseguita con una proposta di Gabriele: Il PairProgramming è una delle pratiche centrali di XP, ma per sua natura è poco praticabile/sperimentabile in solitaria o in luoghi di lavoro dove il management non è consenziente, quindi volevo proporvi di far pratica durante i nostri incontri sperimentando alcuni pattern di comportamento della coppia, per ora ne ho individuati tre, potremmo sperimentarne due a sera (30 minuti di PP utilizzando un pattern, 30 minuti utilizzandone un'altro) e poi durante la settimana potremmo valutarne pregi e difetti in relazione a valori/principi di XP, così ripassiamo anche questi ultimi. Di seguito i tre pattern individuati

Driver/Navigator

Il classico PairProgramming come viene presentato in letteratura, prima il programmatore A ha il controllo, ovvero programma in TDD metre il programmatore B lo coaudiova facendo CodeReview, mantenendo il focus sugli aspetti piu' importanti, ecc... passato un certo lasso di tempo (n.d. Gabriele: secondo la vostra esperienza, chi decide quanto tempo?) i ruoli si invertono

Ping/Pong

Inizia il programmatore A scrivendo un test, dopodichè passa il controllo della tastiera al programmatore B il cui compito è quello di scrive il codice per far passare il test appena scritto da A, subito dopo toccherà a B scrivere il nuovo test che A dovrà soddisfare e così via. La R all'interno della tabella sta per refactoring, Franco ha giustamente chiesto perchè il refactoring fosse associato all'attività di coding e non a quella di test, effettivamente uno dei programmatori, prima di scrivere il nuovo test, potrebbe fare refactoring, del resto si dovrebbe fare refactoring anche del codice dei test... tutte cose che sperimenteremo.

Questo pattern viene utilizzato per stimolare alcuni aspetti cognitivi di gioco/sfida fra i due programmatori, ovvero: quando il programmatore A scrive un test, lo scriverà tentando di mettere in difficoltà il compagno, B a sua volta farà i suoi interessi cercando di superare il test nella maniera più semplice possibile nel tentativo di non fare "concessioni" ad A. In questo modo, sfruttando la "sfida" fra i due programmatori, si otterrebbe codice semplice, e una CodeCoverage di tutto rispetto.

La paura è quella che l'attenzione si sposti più sulla sfida che non sulla realizzazione del task che si sta lavorando, complicando di conseguenza il codice, anzichè semplificarlo... anche in questo caso sperimenteremo

Attacker/Defender

Il programmatore A e il programmatore B a turno giocano due ruoli differenti, in un primo momento A scrive i test che devono essere fatti passare da B, trascorso un certo periodo di tempo (da stabilire), i ruoli si invertono e tocca a B scrivere i test che dovranno essere soddisfatti dal codice scritto da A

Questo pattern è stato pensato per risolvere la difficoltà che molti programmatori incontrano applicando TDD, ovvero la difficoltà di giocare il ruolo di tester e di coder quasi contemporaneamente, infatti nel microciclo del TDD il programmatore scrive il test e subito dopo scrive il codice per farlo passare. Utilizzando questo pattern un programmatore ha la possibilità di giocare il ruolo di tester/coder per un certo lasso di tempo, in alcuni casi ciò ha comportato un aumento della produttività della coppia

Il dubbio in questo caso è la "rottura" del microciclo del TDD che in questo caso non viene più completato da un programmatore solo, ma viene spezzato rigidamente fra i due programmatori della coppia, c'e' il rischio di perdere dimestichezza con il TDD? Si vedrà

La serata si è conclusa con due pomodori di lavorazione dei task rimasti della prima iterazione da parte di 4 coppie di baldi programmattori

prima di incamminarci al ristopizzarocinese Gabriele/Marco e Uberto/Franco hanno espresso pareri positivi alla loro esperienza di utilizzo del pattern Ping/Pong