L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Une des règles de base du TDD, le dévelopement piloté par les tests, est "avant d'écrire une ligne de code, écrire un test qui ne passe pas". Le ligne de code sert ainsi à faire passer le test. Cette approche permet d'écrire le code le plus simple possible, au sens où celui-ci n'a aucune ligne superflue, et de découvrir facilement le code à écrire puisque celui-ci découle du test.

Tout ceci serait très facile si le problème de l'inception de code n'était pas repoussé vers les tests. Certes, on découvre facilement le code à écrire. Encore faut-il trouver le bon test à faire passer !
Le BDD, le développement piloté par le comportement ("behaviour") apporte une réponse à ce problème en proposant une structure des tests basée sur le comportement observable des éléments du système.

Je ne vais pas ici développer le BDD en long et en large. Il y a de très bon sites pour cela, http://behaviour-driven.org/ entre autres.

Un développeur qui commence à pratiquer le TDD y trouve rapidement un bénéfice : sa confiance dans le code ne cesse de grandir car il met en place des centaines de garde-fous qui, à tout instant, le remettent dans le droit chemin.
Dans un 2ème temps, au delà de cet aspect de contrôle des régressions, un développeur va trouver dans le TDD un bon moyen pour documenter son code : les tests sont alors des exemples d'utilisation. Mais ce n'est que lorsqu'on approche le TDD comme technique de conception que l'on peut en mesurer toute la puissance.

Le BDD est l'évolution naturelle du TDD. Le pilotage par les tests permet littéralement de découvrir les interfaces du code à écrire. Et c'est là que le BDD entre en action en proposant un canevas : "étant donné un contexte, si un évènement survient, alors le système vérifie un certain nombre de conditions".

Prenons un exemple. Une fonctionnalité de mon système consiste à fournir le transfert d'argent d'un compte épargne vers un compte courant.
Pour le tester, je peux donc décrire un contexte :

• Si le compte épargne est en crédit de 100
• Et le compte courant est en crédit de 10

Puis initier un évènement :

• Quand je transfère 20 vers le compte courant

Et enfin vérifier le nouvel état du système :

• Le solde du compte épargne est 80
• Et le solde du compte courant est 30

Un test facilement lisible va respecter ces étapes. Par exemple, en C# avec NUnit, je peux décrire mon contexte initial sous la forme d'un héritage de classes (une classe par condition initiale) :

namespace SiLeCompteEpargneEstEnCreditDe100 {
  public class C_SiLeCompteEpargneEstEnCreditDe100 {
    protected Compte leCompteEpargne;
    public void Given() { leCompteEpargne = new Compte() { Solde = 100 }; }
  }
}

namespace SiLeCompteEpargneEstEnCreditDe100.EtSiLeCompteCourantEstEnCreditDe10 {
  public class C_EtSiLeCompteCourantEstEnCreditDe10 : C_SiLeCompteEpargneEstEnCreditDe100 {
    protected Compte leCompteCourant;
    public void Given() {
      base.Given();
      leCompteCourant = new Compte() { Solde = 10 };
    }
  }
}

Pour que cette description de contexte compile, il me faut déclarer la classe Compte avec une propriété Solde : je viens de découvrir un "objet métier" de mon système.

public class Compte {
  public int Solde { get; set; }
}

A partir de là, je peux écrire un test qui lance l'évènement de transfert de compte à compte :

namespace SiLeCompteEpargneEstEnCreditDe100.EtSiLeCompteCourantEstEnCreditDe10 {
  [TestFixture]
  public class QuandJeTransfere20VersLeCompteCourant : C_EtSiLeCompteCourantEstEnCreditDe10 {
    [SetUp]
    public void When() {
      base.Given();
      leCompteEpargne.TransfererVers(leCompteCourant,20);
    }
  }
}

Si je veux compiler ce test, il me faut enrichir ma classe Compte : je viens de découvrir le besoin d'avoir une méthode de transfert.

public class Compte {
  public int Solde { get; set; }
  public void TransfererVers( Compte unAutreCompte, int montant ) {}
}

Maintenant, je peux vérifier mes conditions :

namespace SiLeCompteEpargneEstEnCreditDe100.EtSiLeCompteCourantEstEnCreditDe10 {
  [TestFixture]
  public class QuandJeTransfere20VersLeCompteCourant : C_EtSiLeCompteCourantEstEnCreditDe10 {
    [SetUp]
    public void When() {
      base.Given();
      leCompteEpargne.TransfererVers(leCompteCourant,20);
    }
    [Test]
    public void LeSoldeDuCompteEpargneEst80() {
      Assert.That(leCompteEpargne.Solde, Is.EqualTo(80) );
    }
    [Test]
    public void LeSoldeDuCompteCourantEst30() {
      Assert.That(leCompteCourant.Solde, Is.EqualTo(30) );
    }
  }
}

En lançant, l'exécution du test, je découvre rapidement qu'elles ne sont pas satisfaites mais, au moins, je sais pourquoi : mes résultats de test ne souffrent d'aucun manque de lisibilité !

Pour faire passer mes tests, il me faut implémenter la méthode de transfert :

public class Compte {
  public int Solde { get; set; }
  private void AjouterAuSolde( int montant ) {
    Solde = Solde + montant;
  }
  public void TransfererVers( Compte unAutreCompte, int montant ) {
    if( Solde > 0 ) {
      unAutreCompte.AjouterAuSolde(montant);
      AjouterAuSolde(-montant);
    }
  }
}

Et voilà !

A noter que si j'avais été très rigoureux, j'aurais rajouté mes conditions à vérifier une par une et j'aurais écrit le code correspondant au fur et à mesure.

A l'usage, on constate rapidement que l'écriture de tels tests avec un outil de TDD "classique" est fastidieuse. Plusieurs toolkits ont donc vu le jour pour s'adapter à ce genre d'approche "contexte/évènement/vérification". La page anglaise du BDD sur Wikipédia en propose une liste.

Voilà donc, en quelques mots, comment le BDD apporte :

• un canevas d'écriture de test proche du langage humain : la spécification exécutable n'est pas très loin tout en gardant un outil proche du développeur !
• une démarche de conception logicielle pilotée par les comportements attendus du système.

A mon avis, le BDD peut apporter bien plus que ça, notamment en termes de documentation du système développé et de communication entre les intervenants.
A suivre dans un prochain billet... Stay tuned !