Essai. Elle est souvent laissée à la dernière minute, puis coupée parce que vous manquez de temps, que vous avez dépassé votre budget ou quoi que ce soit d'autre.

La direction se demande pourquoi les développeurs ne peuvent pas simplement «bien faire les choses 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 du hommes aveugles décrivant un éléphant .

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

Parfois, ces interactions prennent la forme d'un Agile Histoire de l'utilisateur . Parfois, ils se présentent sous la forme de documents de conception, comme dans Chris Fox entrée de blog l'année dernière. Ils peuvent également venir 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 simplement».

À partir de ces seules communications, un développeur est responsable de la construction d'un système qui «fonctionne simplement». Ceci est particulièrement difficile pour pigistes travailler 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 est-ce que ces comportements sont réellement testés? travail souvent l'étape qui est coupée?

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

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

Qu'est-ce que BDD?

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

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

1. La homme d'affaires spécifie les comportements qu'ils souhaitent voir dans le système.
2. La développeur pose des questions en fonction de leur compréhension du système, tout en notant les comportements supplémentaires nécessaires dans une perspective de 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é interrompt les fonctionnalités existantes.

J'ai trouvé que cet acte simple me donne suffisamment de contraintes pour que je sois capable de penser comme un développeur: 'étant donné que je dois implémenter ces tests, comment cela me contraint / tout le monde à respecter les spécifications que je peux implémenter dans le code'? Puisqu'ils sont en attente de spécifications, ils 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 avoir la personne d'affaires là-bas 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 axé sur les comportements

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 homme d'affaires vous demande de mettre en place un système de rappel pour rappeler aux clients leurs factures en attente. Parce que vous pratiquez BDD selon ce tutoriel; (contre 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 professionnel:

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'

Cette focalisation sur le comportement pendant le développement rend le test utile pour vérifier que vous créez la bonne fonctionnalité, pas seulement que votre code est correct. Notez que le libellé est en langage commercial 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 se soucie de cela.

Le libellé est en langage commercial et non dans le langage d'implémentation interne du système. Vous ne voyez pas ou ne vous souciez pas qu'une facture appartienne à un compte, car personne en dehors de l'équipe de développement ne se soucie de cela.

Certains développeurs préfèrent écrire des cas de test sur place, appeler des méthodes dans le système, définir 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 failing specs

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. Le mauvais homme d'affaires sera soit distrait par les détails, soit utilisera ces nouvelles connaissances et essaiera de microgérer les choses sur lesquelles le développeur en sait plus (conception correcte de la base de données, réutilisation du code).

D'après mon expérience, écrire plus d'un aperçu en une seule ligne d'un comportement spécifique ennuiera l'homme d'affaires. Ils verront cela comme une mauvaise utilisation de leur temps ou deviendront anxieux de décrire le prochain comportement pendant qu'ils les préoccupent.

En quoi BDD diffère-t-elle du TDD?

Examinons cela d'une manière différente, avec une approche de développement piloté par les tests, et notons 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 pour un groupe de personnes: les ingénieurs. BDD est utile pour communiquer avec chaque membre d'une équipe produit transverse.

Vous pouvez certainement faire du développement test d'abord dans un état d'esprit BDD grâce à l'utilisation de comportements en attente. Commencez par rédiger le test; puis exécutez-le (rouge); puis faites-le fonctionner (vert); puis corrige-le (refactor) .

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

a = 42 a.should == 42

Ce format rend les choses plus faciles à lire plus tard. Mais rappelez-vous que ce n’est pas ce que nous faisons ici - le but est de réduire les comportements le plus rapidement possible. et 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 ne concerne pas les moyens sophistiqués 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 les fonctionnalités de l’élément avec l’homme d’affaires, vous analysez le système à travers ses composants internes (comment les objets s’emboîtent en interne), puis vous analysez le système de l’extérieur.

Vous pensez à certaines conditions et demandez à l'analyste commercial 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 réponses . Il est important que l’homme d’affaires comprenne que vous n’essayez pas de percer l’idée de son animal de compagnie ou d’être trop pédant.

De cette manière, le développement axé sur le comportement est un outil pour faciliter la collaboration et démarrer une conversation entre les deux départements. C'est également 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. Vous réalisez peut-être qu’il n’existe 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 mettre en œuvre.

Les développeurs auront des considérations pour les développeurs ('Que voulez-vous dire exactement lorsque vous dites' jour '?'), Tandis que les professionnels auront leurs propres considérations ('Veuillez ne pas utiliser le terme en retard ici, cela signifie quelque chose de différent'). Demander à un groupe ou à l'autre d'essayer d'écrire eux-mêmes ces tests de comportement de logique métier (la promesse de Concombre ) supprime l’apport précieux de chaque partie.

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) par les développeurs de ce que vous construisez.

Documents de conception

Une Article précédent du blog ApeeScape Chris Fox parle de documents de conception , surtout au début d'un projet. Comprendre et extraire les comportements commerciaux passe 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 comportements à l'écran d'éléments, et c'est un domaine où je suis constamment en désaccord avec les concepteurs: «À quoi ressemble ce bouton lorsqu'il est sombre» ou «À quoi cela ressemble-t-il sur des écrans de 11», car cette page est évidemment conçue pour 24 » écrans? » Ce va-et-vient avec l'homme d'affaires peut trouver des lacunes dans les ressources graphiques d'un projet ou la mise en page d'une page.

Dans les très grandes équipes interfonctionnelles, de nombreux membres de l'équipe ont leurs propres préoccupations: concepteurs, développeurs, éventuellement quelqu'un des opérations, l'administrateur de la base de données - peut-être des personnes chargées du contrôle qualité ( oui, il y a une place pour tout le monde dans TDD et BDD! ), chacun avec ses propres préoccupations et questions. BDD peut conduire 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 ce tableau?' à, 'Hmmm, ce sera une requête coûteuse, nous voudrons la mettre en cache d'une manière ou d'une autre' à, 'Attendez, si l'utilisateur voit tout de ces informations confidentielles? », il peut y avoir plus en jeu qu'un développeur et un analyste commercial qui ont 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 choses potentiellement physiques qui décrivent le projet ou l'équipe de projet, et qui sont trouvables six mois plus tard. Les bons artefacts expliquent pourquoi les choses sont telles qu'elles sont.

Les bons artefacts expliquent pourquoi les choses sont telles qu'elles sont. Un artefact est un code source enregistré dans un référentiel ou un espace partagé, ou des tickets dans le système de tickets.

Les conversations dans les couloirs ne sont pas des artefacts. Les dessins sur tableau blanc non plus. Dessins de tableau blanc qui sont transformés en grandes documentations ou documents de conception de longue durée - celles-ci sont des artefacts. Les procès-verbaux des réunions sont également 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, dans mon esprit, les meilleurs artefacts . Ils montrent non seulement Pourquoi quelque chose est comme ça, mais pourquoi il existe dans l'application du tout .

Comment les utilisez-vous dans BDD?

Les comportements doivent être un artefact partagé en équipe - les tests ne doivent pas seulement être un travail très chargé pour les programmeurs! Bien qu'il soit préférable d'avoir un système dans lequel toute l'équipe peut facilement afficher 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 départements et faire de meilleures estimations».

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

Conclusion

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

Décrire et comprendre les besoins d’un système présente une tonne d’avantages au-delà de l’exactitude du code: établir un dialogue interministériel et s’assurer que les préoccupations de toutes les parties prenantes sont satisfaites (et pas seulement les parties prenantes avec de grands 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 qui intéressent toute l’équipe - cette est un excellent moyen d'assurer un projet de qualité.