Le retour des automates avec le BDD

La vérité sur le Behavior Driven Developement.

Un des réalisations dont je me souviens de ma vie de développeur, c'est l'écriture d'un générateur de code à partir de tables décrivant un automate. Plutôt un moteur d'automate, capable de lancer les actions élémentaires d'une transition suite à la réception d'un événement dans un état. A l'époque je travaillais à Telic-Alcatel dans le monde des autocommutateurs (PABX). Le comportement du poste téléphonique était décrit avec des automates à états finis. On disait simplement automate. Attention, c'était de gros automates. Autant que je me souvienne, on arrivait à des automates à 40 états avec une vingtaine de transitions en moyenne par état.
Les automates, j'ai continué pendant de nombreuses années à les utiliser, puis à les enseigner et les faire utiliser. On les retrouvera dans SDL puis UML, appelés machines à états (en anglais Finite State Machines ou FSM).

Les FSMs reviennent dans le monde de l'Agilité par le BDD, c'est que dit Robert Martin dans The Truth about BDD.
Robert Martin, c'est le célèbre Uncle Bob. Je l'ai cité il y a quelques mois pour un article qui montrait l'équivalence entre spécifications et tests. Dans cet article, il basait sa démonstration sur FIT.

Le BDD correspond tout à fait à ma culture (des automates), c'est pour ça que je l'ai tout de suite adopté pour formaliser les tests d'acceptation.

L'Agilitateur laisse entendre que tout le monde peut comprendre des tests écrits en BDD. Pour avoir essayé, je ne serai pas aussi affirmatif. Seuls ceux qui ont une bonne connaissance des automates ou machines à états finis y arrivent facilement. Mais c'est vrai que nous avons une pratique différente du BDD : son exemple est proche du code, alors que j'utilise le BDD pour les tests d'acceptation liées à une story, comme Dan North dans What's in a Story ?. Les interlocuteurs sont différents. Avant de leur apprendre le BDD, il serait utile d'expliquer à certains le fonctionnement d'un automate à états.