BDD: Pour commencer

Je commence par BDD et voici mon histoire:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

J'ai quelques doutes ...

Dois-je écrire mes scénarios avant de coder quoi que ce soit ou dois-je d'abord écrire un scénario, puis écrire du code, réécrire un scénario, puis écrire du code, etc. ...?

Si je devais écrire mes scénarios avant, mes étapes peuvent-elles être approuvées et le code de production ne se fait toujours pas?

Quand dois-je refactoriser mon code? Une fois la fonctionnalité terminée ou après la mise en œuvre de chaque scénario?

De l'histoire, je déduis que vous codez vous-même.

Normalement, le but de BDD est de permettre des conversations, en particulier entre l'entreprise et les développeurs, afin que l'équipe puisse être sûre d'avoir atteint une compréhension commune. Nous aimons également inclure des testeurs, car ils peuvent repérer les scénarios manqués.

Si vous faites cela par vous-même, prenez un canard en caoutchouc et expliquez le comportement de votre application au canard. Donnez quelques exemples de la façon dont cela devrait fonctionner. Ce seront vos scénarios.

Pour commencer, je suggère de ne pas automatiser ces scénarios. Vous pouvez les noter si vous le souhaitez. N'oubliez pas que les résultats commerciaux que vous avez partagés avec le canard sont à peu près au bon niveau pour les exprimer. Vous devriez maintenant avoir une idée du comportement de l'application et vous pouvez exécuter les scénarios manuellement. J'aime traiter tout ce qui ne fonctionne pas encore comme un bug . Je l' ai parfois commencé avec l' automatisation, mais seulement quand je sais très bien comment le système fonctionne, je suis familier avec les outils et l'interface utilisateur est bien comprise. Même alors, je dois souvent le retravailler un peu quand j'ai écrit le code.

À un niveau inférieur, dites à votre canard comment chaque classe va se comporter. Donnez quelques exemples. Les canards en caoutchouc sont parfaitement capables de comprendre le langage technique. Vous avez maintenant votre BDD au niveau unitaire, alias tests unitaires. Le cycle rouge-vert-refactor se produit ici. (Je n'ai plus tellement besoin de refactoriser, car je pense aux responsabilités de mes cours, je les formule dans un langage orienté affaires, et ça a tendance à tomber de façon assez belle de toute façon. Mais je ça fait un moment maintenant. C'est OK si tu le fais.)

Ne le refacturez pas trop. Nous voulons toujours obtenir des commentaires sur notre code, car il y a toujours des choses que nous ne savons pas que nous ne savons pas . La perfection est votre ennemi ici. Rendez-le assez bon, lisez-le, puis passez à autre chose. Si vous devez faire quelque chose de parfait pour apporter d'autres modifications, faites-le lorsque vous effectuez d'autres modifications.

Si vous avez la possibilité d'obtenir des commentaires sur vos scénarios de la part des parties prenantes de l'entreprise, mais qu'ils ne sont pas assis avec vous, vous pouvez leur envoyer des scénarios dès que vous avez écrit, puis avant de les automatiser. Vous pouvez également envoyer une maquette de l'interface utilisateur, afin qu'ils puissent corréler les mots aux actions. Ne soyez pas trop en avance sur le codage avec cela. Travaillez avec l'hypothèse que ce que vous avez déjà fait est mal , et vous devez obtenir des commentaires pour savoir comment.

Comme dernier indice, ne formulez généralement pas d'histoires du point de vue d'un utilisateur (scénarios, oui, mais pas d'histoires). Ce ne sont pas des user stories. Il devrait probablement lire quelque chose comme:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

Il y a de toute façon un objectif de niveau supérieur que vous recherchez. Cela vous aidera également à tirer parti des capacités dont vous avez besoin. Bonne chance et excuses pour le message extra-long.

Dois-je écrire mes scénarios avant de coder quoi que ce soit ou dois-je d'abord écrire un scénario, puis écrire du code, réécrire un scénario, puis écrire du code, etc. ...?

Les deux fonctionneront. Choisissez-en un.

Peu importe.

Plus vous avez de scénarios, plus vous pouvez concevoir à l'avance.

Plus vous avez de scénarios, plus il faut de temps pour faire quelque chose.

Quand dois-je refactoriser mon code? Une fois la fonctionnalité terminée ou après la mise en œuvre de chaque scénario?

Non. Vous refactorisez quand il devient difficile de concevoir le scénario suivant .

Utilisez des verbes descriptifs

Feature: CONVERT Months and days to days

Ne prenez pas de décisions de conception dans les histoires ["J'ai besoin d'une page Web" est une décision de conception]

As a date conversion fan
I want to convert days and months into days

Utiliser des objectifs de valeur commerciale dans les histoires

So that [some business reason]

Écrivez autant de fonctionnalités et d'histoires que possible avant de commencer à coder; les histoires s'informent mutuellement , influencent les caractéristiques et informent la conception.

Refonte après chaque histoire. Red-Green-Refactor.