没有TDD经验，能学习BDD吗？

Question

我既没有TDD也没有BDD的经验。是的，我经常为现有代码创建单元测试，但这与此处无关。而且我不能在工作中使用TDD/BDD，但想在一些业余项目中尝试。

我不确定我目前是否正确理解了TDD和BDD之间的区别。目前我只是将BDD视为进化版的TDD，其最显著的特点是能够在比TDD更高的抽象层次（用户故事）上进行工作。在TDD中，你基本上会得到相同的用户故事，但它们不像BDD那样明确。这正确吗？

就工具而言，假设上述陈述正确，对于TDD，我应该使用类似于TestNG或JUnit的东西，对于BDD，我将受益于像JBehave这样的工具。

现在问题是，我应该先从TestNG和TDD开始，只有在成功使用后才迁移到JBehave和BDD吗？还是这只是浪费时间，根本没有任何理由阻止我从一开始就尝试使用Jbehave和BDD？

更新：

在收到两个很好的回答并花费一些时间阅读有关该主题的其他资料后，我忍不住要添加一个我发现的非常好的 文章 的链接。它只是重复了下面两个问题的答案中的相同想法，但可能更详细。我最喜欢的文章部分是：

The best way to do that is to leverage BDD and TDD. Here is an approach:

 1. Write requirements as user stories using the BDD grammar/structure.
    Do this collaboratively with the key stakeholders. 

 2. Enter the User
        Stories (feature + scenarios) in a BDD tool. 
 3. Write code to map the
            User Stories to tests.
 4. Write production code using TDD to make the
            tests pass.

As you can see, BDD is not just TDD done right. You could use just the vocabulary of BDD to improve TDD but that would be like using only some of the benefits that BDD has to offer us. When we use the the strengths of both these techniques we will have “Software that matters” along with “Software that works”.

- GrayR

Answer 1

BDD专注于测试应用程序的功能，并确保其符合用户故事中描述的应用程序所述的接受标准。TDD倾向于集中在低级别代码上，以每个类为基础进行测试，而不是每个功能单元为基础进行测试。如果您对要在用户故事中实现的内容有很好的想法，足以列举出该功能应该和不应该做的事情清单，那么您就可以开始使用BDD。您可以从该清单编写BDD特性文件，并在编写任何代码之前这样做将允许您考虑该功能并使其形象化。这将帮助您编写更简洁正确的代码。我建议您使用Cucumber-JVM作为实施BDD测试的工具，但据我所知，JBehave在功能上类似。最后，对我来说，BDD和TDD是互补而非竞争的技术。预先进行BDD使得更容易思考所需的内容，这使得更容易考虑所需的低级别功能，进而使得更容易编写您的单元测试。一旦代码编写完成，您就可以拥有一套测试套件，以证明应用程序符合接受标准。我进行BDD的方式如下：1）检查用户故事的用户验收标准2）编写包含测试场景的功能文件（英语），以测试每个条件3）实现该功能4）使用Cucumber/JBehave从功能文件中编程实现测试5）确保所有测试都通过。然后，我们维护这些测试的库，并将其作为我们的持续集成的一部分运行。特性文件包含特定措辞的说明，例如：给定用户转到我们的应用程序时，当用户单击搜索链接时，搜索窗口打开，用户在搜索框中输入XXX并按Enter键，则显示搜索结果。

- TrueDub

---

有一个TTD流程的标准图表：链接。我的理解是，您建议以BDD方式编写用户故事，然后按照TTD方式应用图表中的流程，直到完成用户故事，之后再编写另一个用户故事并重复这个循环，我理解得对吗？ - GrayR

我会更新我的答案 - 请见上方。 - TrueDub

感谢您的澄清，还有几个问题，请确保我理解得正确。在您的方法中，使用Cucumber / JBehave实现单元测试吗？您的示例中是什么验收测试？是不是那个用简明语言编写的功能文件，为其实现了Cucumber测试（第4部分的那些Cucumber测试，它们是单元测试，对吗）？所以基本上我对应用于验收和单元测试的工具的差异很感兴趣。 - GrayR

单元测试使用JUnit实现，对类进行测试 - 确保每个分支和代码行都得到适当的测试。黄瓜测试本质上是验收测试，尽管它们不太适合在maven构建的验收测试阶段运行。我们将Web应用程序部署到测试服务器，然后运行我们的验收测试以针对已部署的应用程序进行测试。功能文件用于驱动验收测试 - 有关该概念的更详细说明，请参见http://aslakhellesoy.com/post/20006051268/cucumber-jvm-1-0-0的教程。 - TrueDub

好的，现在我想我明白了。谢谢，并且对于问了太多问题感到抱歉。 - GrayR

没问题，很高兴能帮忙。 - TrueDub

Answer 2

尽管大部分文献都将TDD视为单元测试，BDD视为验收测试，但这并不是它们的区别所在。

在实现层面上，BDD基本上就是带有额外语言关注的TDD。学习BDD并不会更加困难，但如果你只关注个人而非团队沟通，那么你将错过BDD的大部分价值。

我的建议是，如果你还没有学习JUnit，那么先学习它，因为它是最普遍的框架。开始TDD/BDD最困难的部分是弄清楚如何先编写测试并设计可测试性。

如果你想要学习纯粹的TDD/BDD，那么首先编写验收测试（可执行规范），然后让它们驱动你的单元测试和代码。对于小项目来说，这可能有些过度，但是这是一个很好的练习。

- Garrett Hall

---

“但是，如果您只是一个人在进行中等规模和复杂度的项目（当前估计需要300-500小时的开发时间），那么您将错过BDD的大部分价值，因为它是针对团队沟通而设计的。” 这是有趣的一部分。我同意这个说法，但它也立即带来了另一个问题：“对于一个中等规模和复杂度的单人项目，BDD的主要好处是什么？” - GrayR

与TDD相比，它可能有助于更好地理解功能、生成文档、关注重要内容，并在回顾时理解自己所做的事情。 - Garrett Hall