Votre patron n'appréciera pas TDD : essayez cet exemple de développement basé sur le comportement

Essai. Il est souvent laissé à la dernière minute, puis coupé parce que vous manquez de temps, que vous dépassez le budget ou quoi que ce soit d'autre.

La direction se demande pourquoi les développeurs ne peuvent pas simplement "faire les choses correctement du premier coup", et les développeurs (en particulier sur les grands systèmes) peuvent être pris au dépourvu lorsque différentes parties prenantes décrivent différentes parties du système, comme l'histoire des aveugles décrivant un l'éléphant.

Il est inévitable, cependant, que la première étape de chaque projet soit une discussion sur les comportements du logiciel ou de la fonctionnalité à construire. Un client ou un homme d'affaires s'approche d'un membre de l'équipe de développement et lui explique ce qu'il veut.

Parfois, ces interactions prennent la forme d'une user story Agile. Parfois, ils se présentent sous la forme de documents de conception, comme dans l'entrée de blog de Chris Fox l'année dernière. Ils peuvent également se présenter sous forme d'organigrammes ou de maquettes dans Keynote, ou même d'appels téléphoniques précipités.

À partir de ces seules communications, un développeur est responsable de la construction d'un système qui "fonctionne tout simplement". Cela est particulièrement difficile pour les pigistes travaillant en dehors du système plus large.

Pourquoi les tests sont-ils coupés ?

Il y a une lacune évidente ici : si le propriétaire de l'entreprise a envisagé les comportements du système au départ, pourquoi tester que ces comportements fonctionnent réellement est souvent l'étape qui est supprimée ?

La réponse peut être d'une simplicité aveuglante : les tests ne sont souvent pas considérés comme un capital partagé ; ils ne sont pas considérés comme ayant une valeur pour le projet, car « ils sont réservés aux ingénieurs », ou de la même manière, apportant de la valeur à un seul service ou groupe de personnes.

Comment fait-on pour tester ce capital partagé, cette liste de comportements du système ? En adoptant non seulement le développement piloté par les tests (TDD), mais aussi le développement piloté par le comportement (BDD).

Qu'est-ce que BDD ?

Le développement axé sur le comportement doit être axé sur les comportements commerciaux que votre code implémente : le « pourquoi » derrière le code . Il prend en charge un flux de travail centré sur l'équipe (en particulier interfonctionnel).

J'ai vu Agile BDD fonctionner très bien lorsqu'un développeur et le propriétaire du produit Agile ou un analyste métier s'assoient ensemble et écrivent des spécifications en attente (à remplir plus tard par le développeur) dans un éditeur de texte brut :

1. L' homme d'affaires spécifie les comportements qu'il souhaite voir dans le système.
2. Le développeur pose des questions en fonction de sa compréhension du système, tout en écrivant des comportements supplémentaires nécessaires du point de vue du développement.

Idéalement, les deux parties peuvent se référer à la liste des comportements actuels du système pour voir si cette nouvelle fonctionnalité va casser les fonctionnalités existantes.

J'ai trouvé que cet acte simple me donne suffisamment de contraintes pour que je puisse penser comme un développeur : "étant donné que je dois implémenter ces tests, comment cela me contraint-il/tout le monde à des spécifications que je peux implémenter dans le code" ? Puisqu'il s'agit de spécifications en attente, elles sont rapides et faciles à écrire au cœur de la collaboration.

Cette approche collaborative me permet de me concentrer sur ce que la fonctionnalité offre à l'utilisateur final, et le fait d'avoir l'homme d'affaires juste là me contraint à parler de comportement, pas de mise en œuvre. Cela met en évidence les différences entre BDD et TDD.

Voyons un exemple de développement basé sur le comportement

Le scénario : Vous êtes développeur dans une équipe responsable du système comptable de l'entreprise, implémenté dans Rails. Un jour, un commerçant vous demande de mettre en place un système de relance pour rappeler aux clients leurs factures en attente. Parce que vous pratiquez BDD selon ce tutoriel; (par opposition à TDD), vous vous asseyez avec cet homme d'affaires et commencez à définir des comportements.

Vous ouvrez votre éditeur de texte et commencez à créer des spécifications en attente pour les comportements souhaités par l'utilisateur métier :

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Cet accent mis sur le comportement pendant le développement rend le test utile pour vérifier que vous construisez la bonne fonctionnalité, et pas seulement que votre code est correct. Notez que la formulation est en langage métier, et non dans le langage d'implémentation interne du système. Vous ne voyez pas ou ne vous souciez pas qu'une facture belongs_to un compte, car personne en dehors de l'équipe de développement ne s'en soucie.

Certains développeurs préfèrent écrire des cas de test sur place, en appelant des méthodes dans le système, en définissant des attentes, comme ceci :

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

La suite de tests échouera car nous n'avons pas encore écrit le code pour définir le reminder_date .

Vis-à-vis des spécifications défaillantes

Je comprends les développeurs qui écrivent des spécifications défaillantes, mais avec l'homme d'affaires à mes côtés, cela n'a jamais fonctionné pour moi. La mauvaise personne d'affaires sera soit distraite par les détails, soit prendra ces nouvelles connaissances et essaiera de microgérer des choses que le développeur connaît mieux (conception appropriée de la base de données, réutilisation du code).

D'après mon expérience, écrire plus qu'un aperçu d'une ligne d'un comportement spécifique ennuiera l'homme d'affaires. Ils y verront une mauvaise utilisation de leur temps ou deviendront anxieux à l'idée de décrire le prochain comportement pendant qu'ils le pensent.

En quoi BDD diffère-t-il de TDD ?

Regardons cela d'une manière différente, avec une approche de développement piloté par les tests, et écrivons les tests en attente :

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Ces tests sont utiles, mais seulement utiles à un groupe de personnes : les ingénieurs. BDD est utile pour communiquer avec chaque membre d'une équipe produit interfonctionnelle.

Vous pouvez certainement faire du développement en testant d'abord dans un état d'esprit BDD grâce à l'utilisation de comportements en attente. Tout d'abord, écrivez le test; puis lancez-le (rouge); puis faites-le fonctionner (vert) ; puis corrigez (refactor).

Beaucoup de travail dans la communauté BDD a été fait pour que les vérifications d'assertion à l'intérieur du test se lisent comme de l'anglais. Voici un test RSpec stéréotypé :

 a = 42 a.should == 42

Ce format facilite la lecture ultérieure. Mais rappelez-vous que ce n'est pas ce que nous faisons ici - le but est d'obtenir des comportements aussi rapidement que possible - et d'appliquer le principe "un comportement testé par spécification". Idéalement, le titre de la spécification en attente devrait vous indiquer ce que vous testez.

BDD n'est pas une façon fantaisiste de valider vos résultats ; il s'agit de partager les comportements attendus entre tous les membres de l'équipe.

Le développement axé sur le comportement concerne la collaboration et la communication

Revenons à notre scénario : travailler sur le système comptable de l'entreprise.

Vous parcourez la fonctionnalité de l'élément avec l'homme d'affaires, vous analysez le système à travers ses éléments internes (comment les objets s'emboîtent en interne) et eux analysent le système de l'extérieur.

Vous pensez à certaines conditions et demandez à l'analyste métier ce qui se passe dans les scénarios suivants :

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Et vous obtenez des réponses . Il est important que l'homme d'affaires comprenne que vous n'essayez pas de percer des trous dans son idée favorite ou que vous n'êtes pas trop pédant.

De cette manière, le Behavior-Driven Development est un outil pour faciliter la collaboration et entamer une conversation entre les deux départements. C'est aussi un moyen de clarifier la portée d'une fonctionnalité souhaitée et d'obtenir de meilleures estimations de la part de l'équipe de développement. Peut-être vous rendez-vous compte qu'il n'y a aucun moyen de calculer 10 jours ouvrables à partir d'un moment donné ; il s'agit d'une fonctionnalité supplémentaire et distincte que vous devrez implémenter.

Les développeurs auront des considérations de développeur ("Qu'est-ce que vous voulez dire exactement quand vous dites 'jour' ?"), tandis que les hommes d'affaires auront leurs propres considérations ("Veuillez ne pas utiliser le terme en retard ici, cela signifie quelque chose de différent"). Le fait qu'un groupe ou l'autre se lance et essaie d'écrire lui-même ces tests de comportement de logique métier (la promesse de Cucumber) supprime la précieuse contribution de chaque côté.

C'est aussi un bon substitut lorsque le client Agile n'est plus physiquement dans la pièce : pour avoir ses désirs sur papier, mélangés à l'analyse (et à la traduction) du développeur de ce que vous construisez.

Documents de conception

Un précédent article du blog Toptal, Chris Fox, parlait des documents de conception, en particulier au début d'un projet. Comprendre et extraire les comportements de l'entreprise va des projets où le système est quelque peu connaissable à ceux qui nécessitent des décennies d'années de programmeur pour être accomplis et qui ont des centaines ou des milliers de spécifications comportementales.

L'article de Chris mentionne également les comportements à l'écran des éléments, et c'est un domaine dans lequel je suis constamment en désaccord avec les concepteurs : « À quoi ressemble ce bouton lorsqu'il est sombre » ou « À quoi cela ressemble-t-il sur les écrans 11 », car cette page est évidemment conçue pour les écrans 24 pouces ?" Ce va-et-vient avec l'homme d'affaires peut trouver des lacunes dans les éléments graphiques d'un projet ou la mise en page d'une page.

Dans les très grandes équipes interfonctionnelles, il y a de nombreux membres de l'équipe avec leurs propres préoccupations : les concepteurs, les développeurs, éventuellement quelqu'un des opérations, l'administrateur de la base de données - peut-être des personnes chargées de l'assurance qualité (oui, il y a une place pour tout le monde dans TDD et BDD !), chacun avec leurs propres préoccupations et questions. BDD peut piloter cette collaboration plus que le développement piloté par les tests. De "que se passe-t-il lorsque les données sont trop volumineuses pour cette table ?" à "Hmmm, ce sera une requête coûteuse, nous voudrons mettre cela en cache d'une manière ou d'une autre" à "Attendez, l'utilisateur devrait-il voir toutes ces informations confidentielles ?", il peut y avoir plus en jeu qu'un simple développeur et un analyste commercial ayant des questions sur cette nouvelle fonctionnalité

Le développement axé sur le comportement concerne les artefacts partagés

Qu'est-ce qu'un artefact partagé ?

J'aime penser aux «artefacts» en génie logiciel comme des éléments potentiellement physiques qui décrivent le projet ou l'équipe de projet, et qui peuvent être trouvés six mois plus tard. De bons artefacts expliquent pourquoi les choses sont comme elles sont.

Les conversations de couloir ne sont pas des artefacts. Les dessins sur tableau blanc non plus. Les dessins sur tableau blanc qui se transforment en documents de grande classe ou en documents de conception - ce sont des artefacts. Les procès-verbaux des réunions sont aussi des artefacts.

Un artefact est un code source enregistré dans un référentiel ou un espace partagé, et des tickets dans le système de tickets, ou des notes sur le Wiki interne, ou même des journaux de discussion persistants.

Les artefacts partagés sont, à mon avis, les meilleurs artefacts . Ils montrent non seulement pourquoi quelque chose est tel qu'il est, mais pourquoi il existe dans l'application .

Comment les utilisez-vous dans BDD ?

Les comportements doivent être un artefact d'équipe partagé - les tests ne doivent pas seulement être une tâche ardue pour les programmeurs ! Bien qu'il soit préférable d'avoir un système dans lequel toute l'équipe peut facilement voir les spécifications actuelles (peut-être que le système de déploiement extrait et enregistre également la liste des comportements dans une zone privée du site ou un wiki), vous pouvez également le faire manuellement chaque sprint.

Le nom du jeu est "aider les développeurs à créer les spécifications dont nous avons besoin pour fournir plus rapidement de la valeur commerciale, collaborer entre les services et faire de meilleures estimations".

Cette compréhension à l'échelle de l'entreprise de ce que fait le système est également une forme de capital. C'est le « pourquoi » du « comment » du code.

Conclusion

Comment résolvons-nous le problème des logiciels bogués livrés aux clients ? En veillant à ce que les tests ne soient pas considérés comme quelque chose dont "seuls les développeurs se soucient".

Décrire et comprendre les besoins d'un système a une tonne d'avantages au-delà de l'exactitude du code : établir un dialogue interdépartemental et s'assurer que toutes les préoccupations des parties prenantes sont satisfaites (et pas seulement les parties prenantes avec de gros titres fantaisistes). Utiliser le développement axé sur le comportement pour comprendre ces besoins dès le départ et tester les comportements commerciaux externes auxquels toute l'équipe se soucie , c'est un excellent moyen de garantir un projet de qualité.