Les grandes lignes du BDD: https://www.youtube.com/watch?v=hQyXgKENDtg.
Speaker: Seb Rose -> core contributeur Cucumber, auteur de plusieurs livres sur le BDD
- Comment réduire le stress de livrer un produit ?
- Tout est une histoire de communication, comment fait-on pour bien communiquer ?
- Le métier doit exprimer des besoins métier, pas des solutions
- Les développeurs / QA comprennent parfois mal les besoins métier, ils implémentent ce qu'ils pensent être la bonne solution mais ça ne correspond pas toujours à la réalité
- Nos logiciels ne correspondent pas aux besoins de nos clients, ils sont de mauvaise qualité et contiennent des bugs
- Le coût des changements augmente très rapidement avec le temps
- Au bout d'un moment, on ne sait plus ce que fait le logiciel, il devient donc impossible de le faire évoluer, pas plus qu'il est possible de le ré-écrire car on en connait pas les exigences. La seule exigence est: le nouveau système doit être meilleur que l'ancien, mais en fait, on ne sait même pas ce que fait l'ancien !
- Comment donc améliorer la communication qui semble être l'origine de tous les problèmes ?
- Pour qu'un projet réussisse
- la connaissance doit être partagée
- il faut donc une bonne communication cad, pas d'ambiguïté sur le vocabulaire (MIM)
- il faut savoir quand un dev est terminé
- En BDD, quand les tests sont OK, on sait que le dev est terminé et que l'on peut passer au suivant
- il faut savoir ce qu'il faut faire une fois une fois le dev terminé
- En BDD, pour savoir ce qu'il reste à faire, avoir des tests d'acceptance KO nous permet tout de suite de comprendre le RAF, ce qu'il va falloir coder.
- Fail fast: les tests doivent échouer le plus vite possible dès lors que l'on introduit une régression. -> il faut en finir avec la philosophie "la QA vérifiera plus tard si ça marche"
- la connaissance doit être partagée
- La découverte
- Créer une base de connaissance commune des exigences de manière collaborative, par exemple, en organisant une discussion structurée sur les exigences et les exemples
- De manière collaborative = avec l'équipe (devs, QA, PO, MOE)
- Il faut vraiment aller dans les détails au cours de cette réunion pour faire ressortir tous les besoins, c'est très important que les devs/QA soient impliqués à cette réunion
- Cette étape s'appelle la découverte car il y a toujours des choses que l'on ignore sur son projet
- Nous sommes déjà en train de tester: non pas le code mais notre connaissance du projet
- Toute question qui ressort durant ce point est une question que se serait potentiellement posé le dev/QA plus tard, et qui l'aurait peut-être poussé à interpréter de travers, en plus de l'interrompre dans son travail s'il décide de poser la question et d'attendre la réponse (qui peut être asynchrone)
- Pour Seb Rose, la phase de découverte est la plus importante quand on fait du BDD
- La formulation
- Les exemples décrivant le comportant attendu du produit doivent être écrits en Language métier
- Le plus important est de n'utiliser que le language métier et d'être précis avec les termes -> appeler un chat un chat comme j'aime bien le dire :) Ainsi, on peut donner la spéc à n'importe quel partie prenante du projet qui la comprendra sans ambiguïté
- L'automatisation
- C'est la 3ème et certainement pas la plus importante des parties
- Les frameworks de tests n'ont jamais vraiment marché car on cherche avant tout à automatiser avant même de savoir ce qu'on veut tester -> on adapte donc sans cesse le framework de test qui au passage devient hyper spécifique
- Technique des post-it avec 4 couleurs positionnés de facon hiérarchique
- Si vous avez beaucoup de bleu (=d'exigences), vous avez donc une grosse story, probablement à découper en 2
- S'il y a beaucoup de rouge(=de questions), c'est sans doute que la story est mal comprise, peu claire
- Si vous avez du bleu (=des règles) sans exemples, comment allez-vous pouvoir tester l'exigence ?
- Cette technique est très visuelle et efficace d'après Seb Rose
- Seb Rose est un membre de la team Cucumber, il parle naturellement d'expression en Gherkin, mais précise que ce n'est pas obligatoire, il peut exister d'autres langages de description
- Feature=exigence (transposition des cartes bleues) -> décrit de façon concise l'exigence, on peut mettre un laïus plus complet au dessous de la première ligne
- Scenario=exemple (transposition des cartes vertes) -> cf exemples Gherkin
- Pour le speaker, la story n'a pas sa place dans les feature files, on peut la jeter une fois qu'on a traduit les exigences et les exemples. Le risque sinon, c'est que les gens pensent que c'est ce que le système fait, or c'est faux, ce sont bien les exigences qui expriment ce que fait le système (il cite Jira qui utilise beaucoup la notion de Story).
Un feature file est dans le code, il est versionné, il représente donc à tout moment et à n'importe quel endroit dans l'historique, l'état des fonctionnalités du système, ce n'est pas le cas de la story qui se trouve décorellée dans Jira.
- Ce sont les phases de découverte et de formulation qui guident la phase d'automatisation, et surtout pas l'inverse = on automatise uniquement à partir du moment ou on a terminé les 2 phases précédentes
- Cucumber ne se préoccupe que des feature files et de la glue (=du code d'intégration des phrases décrites dans les feature files) -> Le type d'application n'a aucune importance, il ne fait qu'appeler le code correspondant à chaque phrase.
- Cucumber peut donc fonctionner avec la plupart des languages, quelle que soit la technologie qui sert à l'implémentation de la grue (test unitaire, test d'intégration)
-
Quelle méthode pour apprendre le Gherkin ?
- Par l'exemple
- Le speaker a prévu de publier de nouveaux exemples sur cucumber.io d'ici peu
- Par l'exemple
-
Comment justifier le cout de mise en place du BDD sur un petit projet ?
- il faut le démontrer par l'exemple: un produit réalisé en BDD à une durée de vie beaucoup plus longue car ses specs et sa SDT sont à jour by design, ce qui est rarement le cas d'un projet classique, et c'est encore plus vrai pour les projets pendule où on a vite fait de faire l'impasse sur les specs, les tests ou la doc
Screenshot 1:
Screenshot 2: