Piu’ volte su questo blog ho parlato di quanto sia importante la qualità per abbattere i costi totali.

Con questo post voglio riflettere piu’ nel dettaglio per comprendere quando una soluzione comoda e magari poco elegante possa avere senso. Inoltre quando paga rifattorizzare una soluzione dal forte grado di accoppiamento tra le componenti?

Di seguito un piccolo sunto del paragrafo “When to refactor” di “Refactoring, improving the design of existing code“:

• Regola dei tre strikes: “la prima volta implemento la piu’ semplice, la seconda volta, consapevole della duplicazione, duplico, la terza volta che faccio qualcosa di simile, rifattorizzo”
• Quando si fixa un bug: codice piu’ chiaro e/o si migliora la testabilità
• Quando una nuova funzionalità deve innestarsi in codice poco chiaro: migliorare la comprensibilità per diminuire il rischio di interventi non corretti
• Quando rende piu’ veloce implementare una nuova funzionalità: migliorare la malleabilità

Alla base del refactoring vi è l’idea di minimizzare il costo di cambiamenti futuri non con una previsione degli stessi, ma creando un design che per la sua semplicità sia in grado di essere modificato e reso pronto a qualsiasi cambiamento con poco sforzo. L’effort di tali modifiche (aka mosse di Refactoring) rimane relativamente basso se e solo se il design è mantenuto ragionevolmente semplice. La pratica del TDD a questo fine è un arma molto potente.

Sappiamo tuttavia che anche con un processo scope-oriented e con un team Agile, molto spesso ci si trova ad avere applicazioni o zone dell’applicazione con del debito tecnico. In questi casi cercare di scontare quel debito di design seguendo unicamente le linee guida sopra elencate per la mia esperienza non è efficace. Spesso in presenza di un forte debito tecnico ereditato dal passato, i refactoring sarebbero molto, troppo estesi. Dire semplicemente facciamoli a piccoli passi non mi aiuta molto: servono delle euristiche che tengano conto del contesto e dei particolari vincoli di risorse.

Read the rest of this entry »

Uno dei principi più importanti di XP, nonché uno dei valori fondanti, è: scegli la via più semplice.

Ad esempio, se ci si trova a dover scegliere tra due soluzioni, una che prevede un’infrastruttura più ampia, utile anche in futuro, ed una invece con un’infrastruttura ad uso esclusivo della business story attuale, XP guida nella scelta con l’euristica:

“scegli la soluzione più semplice, che non fa assunzioni sulle necessità future e che presuppone lo sviluppo solo dell’infrastruttura necessaria adesso, così da minimizzare il time-to-market e da non precludere alcuna strada futura”.

E’ l’essenza dello sviluppo iterativo.

La domanda ora è: scegliere in base a questa euristica, ottimizza il ritorno di investimento finale?

Nel corso di questo post per mezzo di un’analisi finanziaria comprenderemo in quali situazioni l’euristica XP è vincente rispetto ad una scelta con architettura up-front.

Read the rest of this entry »

Ultimamente si parla spesso di BDD, aka Behoviour Driven Development. Cosa è il BDD? Altro non è che il TDD rivisto nel linguaggio utilizzato, per fornire maggiore focus verso le specifiche.

I più navigati con il TDD infatti, sanno bene che la T di Test è un po’ fuorviante, dal momento che in realtà ogni metodo di test dovrebbe riflettere una specifica, ed ogni classe di test, avendo in comune i metodi di setUp e di tearDown, dovrebbe incapsulare un preciso stato (o il contesto) dell’oggetto/i sotto test. A questo si può arrivare “meccanicamente” rimuovendo le duplicazioni tra i test e cercando l’estrema chiarezza dei test stessi.
Questo modo di vedere il TDD ha vari vantaggi, tra i quali, manco a dirlo, il ridurre il gap tra la dichiaratività delle specifiche (dettate dal customer), e la loro implementazione imperativa. In altre parole ridurre la distanza tra il mondo degli sviluppatori (e tester) e quello degli esperti del dominio del quale i primi vogliono essere a supporto.

Venendo ad un po’ di codice Read the rest of this entry »

“[…] a good programmer in these times does not just write
programs. […] a good programmer does language design,
though not from scratch, but building on the frame of a base
language.”
— Guy Steele Jr.

Dopo più di un mese di latitanza dal blog e più di 8 post in draft, inizio l’anno senza troppi fronzoli con una citazione che condivido in pieno.

Lo spunto nasce dal rilascio di una libreria che reputo molto utile per scrivere non solo test, ma anche codice di produzione in modo più chiaro, soprattutto per validazioni o Specification. La libreria si chiama Hamcrest e permette di definire vincoli e regole di match in modo dichiarativo. Non si tratta solo di zucchero sintattico, ma di codice (di test) più chiaro e che invita a pensare alle specifiche, permettendo di creare in modo semplice un proprio DSL per i test del nostro dominio, riutilizzabile anche nel codice di produzione.
Read the rest of this entry »

Credo che tutti abbiamo avuto questa esperienza: scrivere applicazioni che dopo x giorni si sono rivelate non più mantenibili, per le quali si impiegava meno tempo a riscriverle che a modificarle. Complice la tecnologia utilizzata, l’effort per riscrivere parti dell’applicazione  lasciava comunque il committente non contento dei nostri tempi di risposta e quindi del costo del software. In sostanza la bassa qualità del software prodotto si traduceva in alti costi di manutenzione.

La frustrazione provata in queste occasioni ci ha portato a chiedere: dove cercare la soluzione?

Sostanzialmente vi sono due strade opposte:

• addossare la colpa alla tecnologia utilizzata, e quindi cambiarla alla luce di questa affermazione
• cercare di migliorarci per costruire skill e capacità che ci permettano di non cadere nella trappola dell’applicazione zombie

Read the rest of this entry »

Gli ultimi due post (peccatore, e la rivincita), sono stati da me dedicati a parlarvi di un bug che mi ha tenuto occupato per più giorni. Come spesso accade il bug è tanto più infido e difficile da trovare, quanto banale nella sua soluzione.
In questo caso si trattava (appunto banalmente) di un doppio submit fatto da una form con un pulsunte di submit mal scritto. Il button era così scritto: Read the rest of this entry »

Per testare una possibile soluzione a questo bug avevo la necessità di testare l’utilizzo della CPU di un’applicazione Java che in alcune situazioni può creare N thread in parallelo.

L’occasione è stata ghiotta per sperimentare un’estensione di JUnit che permette di testare ambienti multithread. JUnit infatti non offre supporto nativo per questo task, ed anzi il testing in multithread è stato visto dai TDD-scettici come un forte limite all’adozione reale del TDD, ma con GroboUtils o TestNG è ormai banale riuscire a lanciare N thread e a testare che valgano delle proprietà alla morte di tutti i thread in questione, piuttosto che testare che i thread muoiano entro un periodo di tempo, eccetera.
Read the rest of this entry »

Oggi vado a casa da peccatore: ho risolto un bug su un’applicazione non scritta da me, e il codice corretto sarebbe da rifattorizzare, ma ho paura. Ho paura perché quel codice non ha nessun test automatico, e perché non mi è chiaro fino in fondo quali requisiti funzionali quel codice implementa.

Inutile dire inoltre che non sarebbe così facile e rapido scrivere dei test “post coding”, magari con l’aiuto dell’esperto di dominio, a causa del design del codice stesso. Persistenza (su più db), service layer e business layer sono una cosa sola, e l’ereditarietà la fa da padrone.

Ma poche scuse: oggi vado a casa da peccatore perché non sono ancora abbastanza bravo da scrivere i test nelle condizioni più ostili: IDE ostile, design ostile, tempi stretti e un ambiente di test di fatto non utilizzabile.

La domanda che mi pongo è: “Quanto voglio diventare bravo?“

L’esperto di Java per eccellenza (Bruce Eckel) scrive in un post non proprio recente (i grassetti sono miei):

In fact, what we need is

Strong testing, not strong typing.

So this, I assert, is an aspect of why Python works. C++ tests happen at compile time (with a few minor special cases). Some Java tests happen at compile time (syntax checking), and some happen at run time (array-bounds checking, for example). Most Python tests happen at runtime rather than at compile time, but they do happen, and that’s the important thing (not when). And because I can get a Python program up and running in far less time than it takes you to write the equivalent C++/Java/C# program, I can start running the real tests sooner: unit tests, tests of my hypothesis, tests of alternate approaches, etc. And if a Python program has adequate unit tests, it can be as robust as a C++, Java or C# program with adequate unit tests (although the tests in Python will be faster to write).

Quindi: attenzione a passare ai linguaggi dinamicamente tipati: non avrete nessuna scusa per non fare TDD!

Nel primo articolo dedicato ad Abbot ho spiegato come creare i jar per testare GUI Swing e GUI SWT con Abbot.Vediamo ora come agganciare Abbot a Fitnesse così da poter scrivere i nostri test di accettazione.

Installare Fitnesse è davvero banale: scaricate lo zip dal sito di Fitnesse, unzip e siete pronti!

Sfruttando il jar di esempio che abbiamo creato, testiamo che tutto sia installato correttamente e che Fitnesse, FIT e abbot comunichino correttamente, facendo eseguire da Fitnesse tutta la suite di unit test di abbot.swt.example. Read the rest of this entry »