BDD：入门

我从BDD开始，这是我的故事：

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.

我有些疑惑 ...

我应该在编写任何代码之前先编写脚本还是先编写脚本然后编写代码，再编写脚本然后再编写代码，等等...？

如果我应该之前编写方案，是否可以批准我的步骤并且仍然无法完成生产代码？

什么时候应该对代码进行重构？完成该功能之后还是在每个方案实施之后？

从故事中，我推断您是自己编写代码。

通常，BDD的目的是促进对话，尤其是在业务与开发人员之间的对话，以便团队可以确保他们已经达成共识。我们还喜欢包括测试人员，因为他们可以在我们错过场景时发现。

如果您自己执行此操作，请抓住橡皮鸭，并向鸭蛋说明您的应用程序的行为。举例说明它应该如何工作。这些将是您的方案。

首先，我建议不要自动执行这些方案。您可以根据需要写下来。请记住，与鸭子共享的业务成果是正确的表达方式。现在，您应该了解应用程序的行为方式，并且可以手动运行这些方案。我喜欢将所有无法正常工作的东西都视为错误。我也有时开始与自动化，但只有当我非常清楚地知道系统是如何工作的，我很熟悉的工具，和UI是很好理解的。即使这样，当我编写代码时，我也经常不得不对其稍作修改。

在较低的层次上，告诉你的鸭子每个班级的表现如何。提供一些示例。橡皮鸭完全能够理解技术语言。现在您有了单元级的BDD，又称单元测试。红绿色重构循环在这里发生。（我不需要再进行太多重构，因为我正在考虑班级的职责，以面向业务的语言来措辞，无论如何它都倾向于以一种非常漂亮的方式出现。但是我'已经这样做了一段时间。如果您这样做，就可以了。）

不要过多地重构它。我们仍然希望获得有关我们代码的反馈，因为总有一些事情我们不知道，我们不知道。完美是您的敌人。使它足够好，使其可读，然后继续。如果您需要做一些完美的事情来进行进一步的更改，请在进行进一步的更改时进行。

如果您有机会从业务利益相关者那里获得有关方案的反馈，但是他们并不陪伴您，则可以在编写完之后以及自动化之前将方案发送给他们。您可能还希望发送UI的模型，以便它们可以将单词与动作相关联。与此相距不要太远。在假设您已经做的事情是错误的情况下进行工作，并且您需要获取反馈以了解如何做。

最后一个提示是，通常不要从用户的角度来讲故事（场景是，但不是故事）。它们不是用户故事。它可能应该显示为：

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

无论如何，您都在寻找更高的目标。这也将帮助您利用所需的功能。祝您好运，对于冗长的帖子，我们深表歉意。

我应该在编写任何代码之前先编写脚本还是先编写脚本然后编写代码，再编写脚本然后再编写代码，等等...？

两者都会起作用。选一个。

没关系。

您拥有的场景越多，您可以进行的设计就越多。

您拥有的场景越多，完成任务所需的时间就越长。

什么时候应该对代码进行重构？完成该功能之后还是在每个方案实施之后？

不可以。当难以设计下一个方案时，您可以进行重构。

使用描述性动词

Feature: CONVERT Months and days to days

不要在故事中做出设计决策[“我需要网页”是一个设计决策]

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

在故事中使用业务价值目标

So that [some business reason]

开始编写代码之前，请尽可能多地编写功能和故事。故事相互交流，影响功能并传达设计。

在每个故事之后进行重构。红绿重构。