Programmation pilotée par le comportement
Pour les articles homonymes, voir BDD.
La programmation pilotée par le comportement (en anglais behaviour-driven development ou BDD) est une méthode de programmation agile qui encourage la collaboration entre les développeurs, les ingénieurs qualité et les intervenants non techniques ou commerciaux participant à un projet logiciel. Il encourage les équipes à utiliser la conversation et les exemples concrets pour formaliser une compréhension commune de la façon dont l'application doit se comporter. Le BDD combine les techniques et principes du développement piloté par les tests avec les principes de la conception pilotée par le domaine et de la conception orientée objet pour partager une méthode et des outils communs entre les équipes de développement et les autres parties prenantes.
Le BDD est largement facilité par l'utilisation d'un langage dédié simple utilisant des constructions en langage naturel qui peuvent exprimer le comportement et les résultats attendus. Cela permet aux développeurs de se concentrer sur les raisons pour lesquelles le code doit être créé, plutôt que les détails techniques, et minimise la traduction entre le langage technique dans lequel le code est écrit et le domaine de la langue parlée par les entreprises, les utilisateurs, les intervenants, la gestion de projet…
Pratiques BDD modifier
Les pratiques de BDD comprennent :
- La participation des parties prenantes dans le développement de logiciels par le biais de l'extérieur (outside-in software development)
- L'utilisation d'exemples pour décrire le comportement de la demande, ou d'unités de code
- Automatisation de ces exemples pour fournir rapidement des commentaires et des tests de non-régression
- Dans le test logiciel, l'utilisation du mot « devrait » contribue à clarifier la responsabilité et permet la remise en cause de la fonctionnalité du logiciel
- L'utilisation de «vérifier que» permet de différencier les résultats obtenus dans le champ d'application du code en question en provenance des effets secondaires d'autres éléments du code.
- Enfin, l'utilisation de « mocks » en remplacement des modules de code qui n'ont pas encore été écrits
Vu de l'extérieur modifier
BDD est motivée par la valeur commerciale, c'est un avantage pour l'entreprise qui revient une fois que l'application est en production. La seule façon dont cet avantage peut être réalisé est par le biais de l'interface utilisateur à la demande, généralement d'une interface graphique.
De la même manière, chaque morceau de code, à partir de l'interface utilisateur, peut être considéré comme un des intervenants des autres modules de code qu'il utilise. Chaque élément de code prévoit certains aspects de comportement qui, en collaboration avec les autres éléments, prévoit le comportement de l'application. Le premier morceau de code que les développeurs implémentent pour mettre en œuvre BDD est l'interface utilisateur. Les développeurs peuvent alors bénéficier de la rétroaction rapide de savoir si l'interface utilisateur ressemble et se comporte de façon appropriée. Par le biais de code, et en utilisant les principes de bonne conception et de refactoring, les développeurs de découvrir les collaborateurs de l'interface utilisateur, et de chaque unité de code par la suite. Cela les aide à respecter le principe de YAGNI, car chaque morceau de code de production est nécessaire, soit par l'entreprise ou par un autre morceau de code déjà écrit.
