Ouarzy's Blog

Pour ceux qui seraient arrivés sur cette page en errant sur le web: attention, cet article ne parle pas de Base de données. Cet article parle de Behaviour Driven Development. Tout comme mon billet sur la philosophie TDD, je voudrais parler ici des idées qui se cachent derrière le BDD.

En effet, le TDD commence à être assez bien admis (quoique encore trop peu utilisé à l'échelle industrielle) par la génération de développeur 2.0. Probablement parce-que le TDD a un impact très technique, qui fait plus facilement vibrer la corde sensible du développeur que l'aspect fonctionnel. Et pourtant, comme le dit Jérémie Grodziski dans son excellente introduction au DDD: "Votre premier boulot de développeur, c'est de comprendre le métier, pas d'écrire du code". Voilà donc un ensemble de bonnes raisons d'ajouter une couche BDD à votre approche TDD.

1>Ne plus porter d'œillères 

Se focaliser sur des problèmes techniques, c'est regarder dans la mauvaise direction. Le problème constant est de savoir si le problème technique qu'on veut traiter répond à un vrai besoin du métier. J'ai sur ce point une expérience professionnelle tellement frappante, qu'elle sert d'exemple dans l'entreprise ou j'étais pour convaincre de l'intérêt du BDD.

Jeune artisan plein de bonne volonté, je découvrais avec passion les pratiques TDD. Ayant eu droit à un renfort inespéré pour mon projet, une stagiaire, je décidais sans attendre de lui apprendre ces pratiques. J'en profitais au passage pour utiliser cet expérience comme un POC avec mon supérieur (j'étais alors le seul à pratiquer le TDD dans la boite) "Regarde, je vais te prouver qu'une stagiaire peut faire un excellent boulot avec cette méthode".

L'idée était de lui faire faire une interface graphique pour la création de compte utilisateur sur l'application. Sans rentrer dans le détail, il y'avait un certain nombre de règles métier à valider, qui fait qu'il y'avait au final une bonne dizaine de chemins possibles pour créer un compte (en fonction d'informations potentiellement présentent en base). En gros à la main, et à grand renfort de procédures stockées, il me fallait environ 15 minutes par compte. Au début (création de 2-3 comptes par mois) je le faisais systématiquement. Le jour où j'ai reçu une liste de 30 comptes à créer, je me suis dit qu'on allait changer le processus.

De fait, sachant exactement ce qu'il y'avait techniquement à faire, j'ai pu produire des specs vraiment précise pour ma stagiaire "tu regardes dans telle table, si telle valeur tu peux faire ça, sinon tu dois vérifier telle table" ainsi de suite. 1 mois de développement plus tard, j'obtenais un soft robuste et testé.

Enthousiaste, une réunion est organisé avec nos supérieurs: j'étais sûr de réussir à les convaincre de notre réussite tant j'étais moi même agréablement surpris par le résultat. Bilan de la réunion (un chef s'adressant à la stagiaire): "C'est super ce que tu as fait, mais c'est totalement inutile. C'est moche, et incompréhensible pour un utilisateur. Il y'a des termes techniques partout et on ne sait pas où cliquer. Sans compter que tu as mis 1 mois pour produire une interface avec 3 écrans."

Mes œillères techniques sont tombées, j'ai pris ma claque, justifié qu'elle avait fait exactement ce que je lui avais demandé dans le temps demandé, et suis retourné méditer sur mon échec. Et la principale raison était que, pas une seule fois pendant le développement, je ne me suis demandé comment un utilisateur final pourrait utiliser cette interface. Je me suis concentré uniquement sur une solution technique à ma vision technique de la problématique de création de compte.

Le BDD vous aide à rester concentré sur le vrai sujet: le métier.

2>Fluidifier les échanges entre experts métier et développeurs 

A travers l'Ubiquitous Language notamment, l'idée est finalement très simple: tout le monde doit parler le même langage pour se comprendre. Le BDD va vous aider à formaliser ce langage. En créant des tests issus de ce langage, les développeurs vont naturellement reprendre ce nommage dans leur code. Les développeurs utilisent des termes du métier dans leur code, et si ils parlent de l'entité "client", ça a le même sens pour eux que pour celui qui connait le besoin utilisateur.

Idéalement, une personne qui n'est pas technique doit pouvoir comprendre votre code. Cela passe nécessairement par la clarté de nommage et l'utilisation du langage métier au sein même du code.

Petit à petit vous allez voir une équipe de dev utiliser des termes métier pour discuter de problèmes techniques, ce qui permettra à des experts du métier de participer au débat. Et ce jour là vous pourrez vous dire que vous avez avancé: le métier sera le cœur de votre application. Toutes les décisions importantes, y compris techniques, seront centrées sur le métier.

3> Apporter la puissance du TDD au niveau métier

La principale valeur ajoutée du TDD, c'est la réflexion. Forcez vous à décrire ce que vous voulez avant de le concevoir. Cette règle s'applique également très bien quand on demande une fonctionnalité à un expert métier. Le formalisme des User Story répond déjà un peu à ce besoin. "En tant que", on l'imagine bien, "je veux", c'est le plus facile, "dans le but de"...La 1ere fois qu'on pose cette question, on voit déjà que la réponse est moins fluide que sur les 2 points précédents. Dans tous les métiers il y'a des habitudes ou des besoins qui semblent tellement évident, qu'on en devient quasiment incapable de les justifier.

Avec le BDD, on formalise, en plus de l'écriture de la fonctionnalité, l'écriture de scénarios très explicites, concrets, qu'on veut pouvoir appliquer directement à cette fonctionnalité. Ce n'est rien d'autres que la formalisation de cas d'utilisation sous forme de Given (qui?), When (quand?), Then (quoi?). La réflexion du métier est alors poussée bien au delà d'une simple User Story. En tant qu'utilisateur de ce site web, Je veux un écran de saisie email pour m'identifier. Ok, comment définit-on un email valide? Que faire si l'email est invalide? Si il est déjà utilisé? Doit il être confirmé? etc...

De plus, le développeur qui va pouvoir travailler en TDD derrière chaque scénario va faire émerger de nouvelles problématiques métier concrètes. "On a bien géré le cas où l'email est confirmé, mais dans le cas où il ne l'est pas, au bout de combien de temps considérez vous que la demande a expirée, si elle expire?" Et voilà un développeur qui contribue à une réflexion métier!

4> Lier les spécifications et le code

Les méthodes agiles préconisent une documentation utile et adapté (ce qui exclut les Word de 350 pages tenu à jour par une armée de Business Analyst). Avec le BDD on a carrément des spécifications exécutables! Elles deviennent vivantes, on peut donc modifier en temps réel les valeurs qu'on passe en paramètres de nos scénarios pour voir si tel ou tel cas est géré. Et quand un test échoue, ce n'est plus un nom de test unitaire obscure du type "SoundPlayerWithInvalidFileNameShouldRaisedError", mais un nom de scénario concret comme "écouter de la musique avec un nom de fichier son invalide". Là encore on voit très bien la transposition de la technique au métier.

Pour le développeur habitué à Visual Studio (je sais qu'il y a des équivalents dans tous les langages, je ne connais juste pas les raccourcis), un F12 sur une fonction l'amène directement à la définition de cette fonction. Et bien dans l'outil de BDD SpecFlow, un F12 sur une ligne de votre spec vous emmène directement à l'implémentation de cette partie de la spec. Du coup le "Comment avez vous fait cela" devient très simple et concret à relier. Par ailleurs, qui n'a jamais été interpellé par un expert métier qui lui dit "Mais pourquoi vous avez fait cela comme ça?". Ici on pourra très facilement retrouver quelle partie de la spec a justifié que ce soit fait comme cela. Et au besoin on pourra changer si la spec a évoluée.

Conclusion

En résumé le BDD vous permet de sortir la tête du technique, de fluidifier vos échanges avec le métier, d'aider le métier à produire des specs plus complètes en poussant leur réflexion et enfin de lier concrètement vos specs et votre code.

Une fois de plus ce n'est qu'une méthode, donc si vous obtenez tous ces avantages avec une autre méthode, elle sera tout aussi valable. Moi je n'en connais pas d'autre, par contre je connais pas mal de développeurs qui ne sont pas assez axés sur le métier, et même quelques développeurs qui refusent d'entendre parler du métier...

On notera également que l'outil de BDD peut être utilisé en lieu et place du TDD. Je trouve cela un peu dommage de ne pas exploiter la clarté de specs exécutables pour interagir avec le métier, mais j'ai rencontré plusieurs équipes qui l'utilisent pour écrire des scenarios très techniques, comme méthode alternative au TDD. C'est une option viable, mais de mon point de vue le TDD et le BDD doivent être complémentaire, pas équivalent.

Pour ceux qui sont curieux à propos des outils utilisés en environnement Microsoft pour le BDD (à savoir SpecFlow), cette Introduction à SpecFlow  de Vincent Oostenbroek De Lange  est un bon début.