BDD:开始

Question

我从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.

我有点怀疑..。

我应该在编写任何代码之前先编写我的场景，还是应该先编写一个场景，然后编写代码，然后再编写一个场景，然后编写代码，等等？

如果我之前应该编写我的场景，那么我的步骤是否可以被批准，而生产代码仍然没有完成呢？

我什么时候应该对代码进行重构？在完成特性之后还是在每个场景实现之后？

Answer 1

从这个故事中，我推断出你是在自己编码。

通常，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.

无论如何，你还需要更高层次的目标。这也将帮助您提取您需要的功能。祝你好运，并为超长的帖子道歉。

Answer 2

我应该在编写任何代码之前先编写我的场景，还是应该先编写一个场景，然后编写代码，然后再编写一个场景，然后编写代码，等等？

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

没什么关系。

你拥有的场景越多，你可以预先做的设计就越多。

你拥有的场景越多，完成某事所需的时间就越长。

我什么时候应该对代码进行重构？在完成特性之后还是在每个场景实现之后？

不是的。当设计下一个场景变得困难时，您可以重构。

Answer 3

使用描述性动词

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]

在开始编写代码之前，尽可能多地编写特性和故事；故事相互通知，影响特性，并通知设计。

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