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, il primo passo per incamminarsi su questa strada può essere quello di utilizzare un semplice xsl sui report prodotti da JUnit, per cominciare a misurare quanto ad oggi, siamo orientati alle specifiche ed ai comportamenti, invece che alle classi ed ai metodi. Tale xsl assume che ogni test JUnit sia una collezione di specifiche, ad esempio scritta un questo modo:

   package org.whoever.foo;
   import junit.framework.TestCase;

   public class TestANewlyInitialisedFoo extends TestCase {
         public void testShouldHaveZeroLength() {
                 ...
          }

          public void testShouldHaveNoMembers() {
              ...
          }

          public void testShouldThrowExceptionOnPop() {
              ...
          }
      }

..e produce un report così fatto:

A newly initialised foo

* should have zero length
* should have no members
* should throw exception on pop

Non male vero? Immaginiamo ad esempio che il cliente ci chieda di modificare una specifica su un certo scenario: scorrendo il nostro report siamo in grado in tempo zero di identificare quale porzione di codice modificare, o di cogliere eventuali errori di consistenza di specifiche.
In altre parole non solo stiamo tracciando senza sforzo e molto dettagliatamente le specifiche, ma addirittura le stiamo legando in modo molto forte alla loro implementazione, cosa che i metodi formali hanno sempre cercato di fare, ma con scarsi risultati di praticabilità!

Un ulteriore passo avanti su questa strada è utilizzare un vero e proprio DSL, in via di implementazione in Java con JDave:

import jdave.Block;
import jdave.Context;
import jdave.Specification;

public class StackSpec extends Specification> {
    public class EmptyStack {
        private Stack stack;

        public Stack create() {
            stack = new Stack();
            return stack;
        }

        public void isEmpty() {
            specify(should.be.empty());
        }

        public void isNoLongerEmptyAfterPush() {
            stack.push("anything");
            specify(should.not().be.empty());
        }
    }

    public class FullStack {
        private Stack stack;

        public Stack create() {
            stack = new Stack(10);
            for (int i = 0; i < 10; i++) {
                stack.push(i);
            }
            return stack;
        }

        public void isFull() {
            specify(should.be.full());
        }

        public void complainsOnPush() {
            specify(new Block() {
                public void run() throws Exception {
                    stack.push(100);
                }
            }, should.raise(StackOverflowException.class));
        }

        public void containsAllItems() {
            for (int i = 0; i < 10; i++) {
                specify(stack, contains(i));
            }
        }

        public void doesNotContainRemovedItem() {
            stack.remove(3);
            specify(stack, does.not().contain(3));
        }

        public void containsAllButRemovedItem() {
            stack.remove(3);
            specify(stack, containsAll(1, 2, 4, 5, 6, 7, 8, 9));
        }
    }
}

Scusate il mio entusiasmo, ma qui davvero metodi quali il Design By Contract ed il Test Driven Development si sposano in un idillio fatto di alta comprensibilità e garantita affidabilità, perché raggiunte per costruzione incrementale!

Ancora una volta il linguaggio utilizzato non è apparenza, ma sostanza.

Altro link interessante: Zio Bob parla di BDD.