Cet article a pour objectif de vous faire découvrir rapidement le BDD ainsi que de vous évoquer la première expérience que j'ai eu avec ce type de développement sur un logiciel open-source (dépôt Github) pour le HAUM.
Présentation du BDD en quelques lignes
Le BDD (Behavior Driven Develoment, pas base de données) reprend les grandes lignes du TDD (Test Driven Development), sauf qu’au lieu de piloter le développement de l’application par les tests il sera piloté par les comportements.
Cet ensemble de comportements décrivent comment l’application devra se comporter dans son ensemble, d’un point de vue utilisateur (et non plus développeur), avant de l’implémenter. Cela consiste donc a décrire en langage naturel, sous forme d’un simple fichier texte, le comportement attendu de votre application par le client.
Le cycle en V appliqué au monde logiciel / image Alex Gorbatchev
Le principal avantage avec le langage naturel c’est que, contrairement à un langage de programmation, votre client comprend ce qui est statué et peut donc approuver les comportements qu’il désire obtenir simplement en relisant les étapes [1].
Ainsi, on cerne beaucoup mieux les besoins du client avant de se lancer dans la réalisation de fonctionnalités inutiles ou inadaptées, tout en sachant à tout moment si le produit est livrable ou non en lançant les tests vérifiant le bon comportement de l’application.
Outils pour faire du BDD
Une des implémentations les plus connues pour faire du BDD est Cucumber pour le langage Ruby. Heureusement, le truc a été bien pensé et les développeurs ont séparé le langage de description de comportement Gherkin de l’implémentation Ruby, ce qui nous permet de réutiliser Gherkin avec d’autres outils de BDD.
D’autres implémentations existent pour de nombreux autres langages ; on retrouve Behave et Lettuce pour mon favori (Python).
J’ai retenu Behave (choix totalement arbitraire) et je l’ai gardé pour la suite après avoir un peu joué avec. La documentation est plutôt bien fournie et on prend ses marques en quelques dizaines de minutes quand on a jamais effectué de BDD auparavant.
Le langage Gherkin
C’est le langage qui va nous permettre de décrire les comportements de notre application.
Je ne vais pas vous détailler complètement comment écrire des scénarios car cet article n’a pas vocation à être un tutoriel complet. Je vais néanmoins vous mettre ici la liste (non exhaustive) des mots clés français à retenir car ils ne sont pas évident à obtenir (trouvés en fouillant dans les sources de Gherkin) :
Scénario Plan du scénario Alors Quand Lorsque Et que Et Mais que Mais Exemples Fonctionnalité Soit Etant donné
Votre éditeur devrait colorer ces mots clés en raison de leur signification spéciale lors de la description des comportements.
Voici un exemple de fichier de description de comportement (extension .feature) directement tiré du logiciel sur lequel j’ai mis en place cet outil :
# language: fr
Fonctionnalité: Afficher les nouveaux liens postés
Scénario: Aucun nouveau lien n’a été posté
Étant donné que aucun lien n’a été posté
Et que les nouveaux liens ont été vérifiés "60" secondes auparavant
Lorsque le programme vérifie les nouveaux liens postés
Alors il n’envoie aucune notification
Scénario: Un nouveau lien a été posté
Étant donné qu’un lien a été posté
Et que les nouveaux liens ont été vérifiés "60" secondes auparavant
Lorsque le programme vérifie les nouveaux liens postés
Alors il envoie une notification avec le nouveau lien
Scénario: Vérification à rythme insoutenable
Étant donné que les nouveaux liens ont été vérifiés "59" secondes auparavant
Lorsque le programme vérifie les nouveaux liens postés
Alors une sécurité empêche la requête vers l’API
Comme vous le voyez, c’est beaucoup plus compréhensible qu’une suite de tests unitaires pour le commun des mortels.
Implémentation des étapes
Une fois les étapes écrites il ne reste plus qu’à les implémenter.
C’est la partie la plus difficile du BDD et il faut mettre les mains dans le cambouis pour réussir à reproduire chaque état décrit dans le fichier .feature. Le but est de tester le bon comportement du logiciel (avec des assertions) en fonction de l’état du programme (obtenu par une suite d’étapes).
Cela prend pas mal de temps et le mocking sera très utile pour enchaîner des étapes dans l’application sans vraiment les réaliser (on appliquera ce principe sur tout ce qui est réseau par exemple pour simuler une réponse d’une API quelconque sans vraiment la solliciter).
Exécution
Une fois que tout est implémenté, on lance behave qui va vérifier que les comportements sont bien reproduits par notre implémentation.
Il vous faudra du temps avant de pouvoir observer tout ce joli vert.
Retour d’expérience, interrogations
Le BDD c’est sympa, mais.
Tout n’est pas rose et certains points laissent à mon avis à désirer et sont évidemment à prendre avec des pincettes étant donné que c’était ma première expérience.
Client et open-source ?
Très souvent les logiciels open-source ne sont pas développé pour répondre à un besoin d’un ou de plusieurs clients car il n’y a pas vraiment de client dans ce monde. En effet nous (les développeurs) écrivons des solutions aux problèmes que nous rencontrons et les mettons à disposition du reste du monde sans avoir répondu à un autre besoin que le notre (du moins à la base).
Un des aspects les plus intéressants du BDD, écrire et relire avec le client les comportements pour mieux comprendre ses besoins, tombe donc à l’eau.
Pire même, étant donné que nous sommes des développeurs, nous parlons le « code » et il est donc facile de comprendre au premier coup d’œil le rôle de tests unitaires écrits directement dans un langage de programmation. Pourquoi donc se casser la tête à mettre tout cela en place alors que on pourrait écrire directement des tests unitaires intelligibles par tous les autres développeurs contribuant et utilisant le produit ?
Internationalisation
Il est courant dans le monde de l’open-source de rédiger l’intégralité du code source ainsi que de la documentation d’un logiciel en anglais, et ce afin de pouvoir être utile à un maximum de développeurs à travers le monde sans se limiter à la francofrance.
Cependant, le BDD nous invite à décrire des comportements dans la langue maternelle du client afin d’éviter les confusions et d’être le plus agréable possible à utiliser. Comment faire si on veut garder cette prédominance de l’anglais pour faire franchir les frontières linguistiques à notre logiciel ?
Je vois actuellement deux solutions :
- Garder les comportements écrits dans ma langue maternelle (en français donc) en prenant le risque qu’un hacker espagnol ne pine pas un mot de mes comportements.
- Écrire ces derniers en anglais mais perdre tout le confort de la langue maternelle et devoir se forcer à écrire des phrases complètes en anglais.
Conclusion
Voilà, cet article est terminé !
Ces interrogations seront sans doute vite levées quand les plus agiles des lecteurs dont vous faites parti auront éclairé ma lanterne.
Je ne sais pas si j’aurai l’occasion de pratiquer du BDD avec un vrai client pro une fois dans ma vie mais je pense que ça en vaut la peine pour ceux qui pratiquent/pratiqueront le développement logiciel à titre professionnel.
| [1] | Fait amusant : la « contrainte » de devoir rédiger les comportements dans un simple document texte déroute certains clients. Heureusement une solution existe. |