Par Benoît Faurie – TheExpert Digital Factory chez Squad
Alors on a tous plus ou moins en tête les valeurs de base de l’Agile !?… ok, un rappel au cas où ?
Les 4 valeurs proposées par le manifeste agile sont…
- Les individus et leurs interactions plus que des processus et les outils
- Des logiciels opérationnels plus qu’une doc exhaustive
- La collaboration avec les clients plus que le négo contractuelle
- L’adaptation au changement plus que le suivi d’un plan
… et découpés en 12 principes qui sont… non on s’égare là.
Et le TDD / BDD dans tout ça ?
D’abord le TDD
Le Test Driven Developement (ou développement piloté par les tests pour les bilingues) est une méthode de développement de logiciel qui consiste à écrire chaque test avant d’écrire le code source d’un logiciel, de façon itérative. Le TDD s’appelait même le Test First Design initialement, mais patience et longueur de temps faisant plus que force ni que rage (elle est pour toi La Fontaine), le concept de base a évolué et est devenu le TDD. Celui-ci retiendra les 3 valeurs suivantes :
- Vous devez écrire un test qui échoue avant de pouvoir écrire le code de production correspondant
- Vous devez écrire une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation
- Vous devez écrire le minimum de code de production pour que l'assertion du test actuellement en échec soit satisfaite
Voilà, c’était poussif mais on y arrive petit à petit. Du coup on résume, le TDD c’est… ? Une méthode de développement qui permet de développer un logiciel mieux conçu, mieux testé (indeed) et plus fiable. Bref, on augmente la qualité et on est dans les targets de l’Agile. La classe ! Ah, cette approche porte le nom de ATDD (Acceptance Test Driven Development).
Le BDD
Le Behavior Driven Development est également une méthode à Gilles, qui encourage la collaboration entre les intervenants techniques et non techniques. Et là, tout développeur qui me lit se dit : « Ouais alors déjà faire comprendre aux non techniques que je ne fais pas que des if/else c’est compliqué, mais si en plus ils commencent à mettre les mains dedans je fais comment moi pour travailler ?? » C’est là que c’est (presque) magique, en fait le BDD met en avant le langage naturel et les interactions dans le processus de développement logiciel.
Je schématise : l’analyste / chef de projet / ton boss écrit en langage (presque) naturel l’objectif et le bénéfice du code. Des specs en fait, et généralement proche d’un format « user stories ».
Une solution : Les concombres c’est sympa, les cornichons aussi
Hein ???!!
Oui parce qu’en fait je bosse surtout sur des technos LAMP/MEAN (bon là c’est direction wikipedia sinon ça va être encore plus long) et du coup j’utilise Cucumber (concombre en anglais) pour mes développements TDD. L’avantage de cet outils c’est qu’il fonctionne à la fois pour des projets JavaScript que pour des projets PHP.
Voilà, vous y êtes, du coup Gherkin (cornichon en anglais) est utilisé pour les BDD et il correspond à la syntaxe reconnue par Cucumber pour rédiger la « spécification » de ton boss.
Voici un exemple et pour les plus curieux je vous invite à aller faire un tour sur la doc : https://docs.cucumber.io/gherkin/reference/#feature
