BDD est-il évolutif pour les projets de moyenne à grande envergure?

Dans chaque site Web que vous lisez sur BDD (Behaviour Driven Development), vous trouverez un bel exemple très simple vous montrant à quel point il est évident et facile de définir vos besoins. Mais essayer d'implémenter ce processus dans un gros produit (pas un exemple de calculatrice) m'a montré que les choses peuvent devenir (ou vont devenir) assez complexes et illisibles; en particulier, la modification des demandes à un stade ultérieur signifie beaucoup de travail pour corriger les tests d'intégration pour cela.

Je me demande donc si le BDD en vaut vraiment la peine? Cela résout-il un problème que d'autres techniques ne résolvent pas?

Je pense que l'une des meilleures ressources sur BDD est le livre Specification by Example . Il en dit long sur la façon d'organiser les tests BDD et sur la façon dont ils doivent être écrits afin qu'ils ne provoquent pas autant de retouches lorsque les exigences changent.

Si les choses deviennent complexes ou trop compliquées dans vos tests, vous faites probablement quelque chose de mal. C'est la même chose avec BDD et TDD. Écrire de bons tests est difficile et il faut des mois pour l'apprendre.

Il pourrait être utile de réaliser que le BDD se concentre sur les conversations . BDD est vraiment un outil d'analyse qui fournit des tests de régression comme un joli sous-produit.

J'ai utilisé des scénarios à toutes sortes de niveaux dans la conversation; de l'identification des différentes parties prenantes pour voir si une version est susceptible d'être bien reçue, à l' élaboration du comportement d'un module ou d'une classe .

Il y a quelques trucs et astuces que je peux suggérer pour rendre cela plus facile.

Si vous ne l'avez jamais fait auparavant, cela va changer.

Tout ce qui est nouveau dans le domaine ou dans l'entreprise est susceptible de changer. Vous pourriez vous rendre compte que vous êtes dans cet espace si vous discutez des scénarios, les remettez en question et que l'entreprise dit: "Oh, je ne suis pas sûr." C'est un bon signe d'arrêter d'essayer de faire du BDD et de faire quelque chose pour obtenir des commentaires plus rapides, pour aider l'entreprise à déterminer ce qu'elle veut. Une fois les idées stabilisées, les scénarios peuvent être écrits rétrospectivement.

Tous les projets ont un aspect nouveau ou vous ne le feriez pas.

Si vous l'avez déjà fait, c'est ennuyeux.

En plus des aspects nouveaux et différenciants , les projets ont généralement des aspects banalisés qui sont similaires à ceux déjà réalisés. Par exemple, si je produisais un nouveau téléphone mobile, il faudrait quand même passer des appels. «Faire un appel téléphonique» est un scénario tellement connu que nous n'aurions pas besoin d'en parler. De même, des choses comme «connexion» ou même «enregistrement d'utilisateur» sont ennuyeuses.

Dans la mesure du possible, utilisez des bibliothèques pour celles-ci, et vous n'aurez alors pas à écrire de scénarios autour d'elles. En outre, faire les autres premiers bits - ont déjà un utilisateur connecté et travailler ce que l' exploitation forestière est lui en pour . Il est peu probable que ces zones changent, vous pouvez donc vous en sortir malgré tout avec des tests manuels.

Si quelqu'un l'a déjà fait, parler de scénarios peut aider.

Il y a un peu entre où nous avons des exigences spécifiques au domaine, des choses qui sont relativement bien comprises par quelqu'un , et où l'incertitude réelle concerne principalement la portée plutôt que le comportement réel du système.

L'examen des scénarios peut aider l'équipe de développement à découvrir le comportement, à s'appuyer sur les connaissances d'un expert et à s'assurer que le comportement connu et précieux est capturé.

C'est le bit où BDD fonctionne le mieux. Mon conseil est d'écrire les scénarios les plus intéressants en haut du fichier de fonctionnalités (ou wiki, si vous n'êtes pas en train d'automatiser) et de supprimer tous les scénarios qui sont dupliqués ou faciles à déduire en conséquence.

Dans la mesure du possible, utilisez les scénarios comme exemples du fonctionnement de l'application . Par exemple, si vous souhaitez montrer comment fonctionne la validation, montrez quelques exemples de la façon dont l'application aide l'utilisateur à remplir un formulaire. Vérifiez que la validation est rigoureuse à l'aide de tests unitaires, ce qui est beaucoup plus facile à maintenir et plus rapide à exécuter.

Lectures complémentaires

Si cela vous intéresse, voici quelques éléments que j'ai écrits qui pourraient vous aider.

BDD dans le grand

Cynefin for devs , qui aborde ces trois domaines plus en détail

Mes diapositives de didacticiel , qui sont toutes agréables et annotées pour vous, et couvrent également toute la pile.

Nous avons construit un projet assez complexe ( complexité du domaine ) l'automne dernier et je peux dire en toute honnêteté que le travail initial dans BDD a sauvé le projet. J'ai vu une forte corrélation entre la complexité du domaine et les avantages du BDD.

Permettez-moi de retirer une chose: tester des règles commerciales complexes est difficile. La question est, voulez-vous essayer de vous souvenir de tous les scénarios fous chaque fois que vous effectuez un changement, ou voulez-vous que le filet de sécurité vous prévienne lorsque vous avez brisé la spécification. Passez du temps à l'avance et élaborez tous les scénarios, notez-les et, éventuellement, écrivez tous les tests pour eux.

Et lorsque vous revenez plus tard pour essayer de donner un sens aux choses, avoir cette spécification testable est un épargnant de vie.

BDD est un processus de développement basé sur TDD (Test Driven Development) Voici quelques avantages et inconvénients de TDD tirés de mon expérience personnelle:

• TDD, s'assure que votre portée est bien définie. De cette façon, vous concevez d'abord vos cas de test. Définissez ainsi une attente pour le morceau de code que vous êtes censé écrire.
• TDD est un moyen de protéger votre code. Supposons que vous écriviez une fonction simple, puis que vous ajoutiez ultérieurement une condition de commutation complexe dans cette même fonction. Demain, si quelqu'un d'autre veut modifier cette fonction, il pourra se référer au cas de test. S'il veut changer votre fonction, alors, il doit aussi changer le cas de test (la plupart du temps). Cela lui permet de comprendre qu'il y avait un raisonnement derrière ce que vous avez écrit.
• TDD permet un développement logiciel plus rapide. Chacun de nous aurait dû faire face à ce problème lors du codage. Nous commençons par une idée. Et en perdre lentement la trace. Nous finissons par mettre des morceaux de code indésirables pour gérer certains scénarios. Dans TDD, vous définissez les attentes dès le départ. Vous vous empêchez ainsi de vous éloigner trop loin de l'objectif.
• TDD vous permet d'attraper d'éventuels bugs avant la mise en ligne du projet. Cela a principalement à voir avec la qualité des cas de test qui sont écrits.

Les inconvénients:

• Au début, TDD peut être un peu délicat. Beaucoup de gens ne comprennent pas le concept d'un cas de test pour le développement.
• TDD, peut parfois conduire à d'énormes efforts de maintenance. Cela a à voir avec les cas de test indésirables ou sans signification.
• Le TDD doit être pris avec une pincée de sel. Aucun développeur n'aime passer du temps sur un cas de test écrit par quelqu'un d'autre. Déchiffrer la signification de la valise de test peut parfois provoquer un mal de tête majeur.

Je travaille sur un projet avec plus de 900 000 lignes de code. Et je continue à suivre BDD.Une chose importante que vous devez considérer est le nombre d'erreurs possibles que vous pourriez attraper uniquement en raison des cas de test. Quelques années plus tard, vous ne jurerez que par BDD!