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 »

Da qualche tempo - come avrete notato dalla mia sezione del.icio.us - sto studiando a tempo perso una argomento molto interessante: i domain specific languages. Nei prossimi post vorrei parlarne con voi. Inizio con un brevissimo post giusto per rompere il ghiaccio.

Per farla breve, i dsl sono linguaggi di programmazione creati specificamente per descrivere un particolare dominio, e che possono anche non essere Turing-completi. Per fare un esempio banale, il seguente file di configurazione è un dsl (detto esterno):

TransazioneAttivita.View = Attivita TransazioneAttivita.IdAttivita.UI.Update = False TransazioneAttivita.TipoAttivita.UI.Update = True TransazioneAttivita.Indirizzo.UI.Update = True

Questo semplice linguaggio è costruito appositamente per descrivere le caratteristiche di transazione applicativa, in particolare sono mostrati quali sono i campi su cui è possibile fare l'update per l'oggetto di dominio Attivita. E' chiaro che con questo specifico linguaggio non sarà possibile descrivere nient'altro che non riguardi alcune proprietà di una transazione.

Fin qui solo limiti. Ciò che però rende questo linguaggio di "valore" è il fatto che chiunque non sia un programmatore, ma che sappia che cosa è un'attività programmata, può modificare a suo piacimento la transazione di modifica delle attività programmate. Sottovalutare questo aspetto vorrebbe dire non avere compreso quanto sia importante la comunicazione tra esperti di dominio e sviluppatori.

La cosa interessante è che se avessimo dovuto descrivere le stesse proprietà della transazione di attività programmate in Java, tale descrizione sarebbe stata fruibile solo da uno sviluppatore che conosce Java.

La domanda quindi è: più un linguaggio di programmazione è espressivo e più ristretta è la comprensione dai non addetti ai lavori? O la relazione è tra astrazione del linguaggio e comunicazione?

Ai prossimi post la risposta.