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.