是否可以在没有TDD经验的情况下研究BDD？

我在TDD和BDD方面都没有经验。是的，我已经为现有代码创建了很多单元测试，但在这里并不相关。此外，我不能在工作中使用TDD/BDD，但我想尝试一些爱好项目

我不确定我目前是否正确理解了TDD和BDD之间的区别。目前，我只是将BDD看作是一种进化的TDD，其最关键的特性是能够处理比TDD更高级别的抽象（用户故事）。在TDD中，您基本上得到相同的用户故事，但它们不像BDD中那样明确。对吗

在工具方面，假设上面的语句是正确的，对于TDD，我应该使用TestNG或JUnit之类的工具，对于BDD，我将受益于JBehave之类的工具

现在的问题是，我是否应该首先从TestNG和TDD开始，并且只有在获得了一些成功的经验之后才能迁移到JBehave和BDD？或者这只是浪费时间，没有任何理由阻止我从一开始就尝试使用Jbehave和BDD

更新：

在收到关于我的问题的两个很好的答案后，我花了一些时间额外阅读这个主题，我忍不住添加了一个链接到我发现的一个很好的主题。它只是重复了下面这个问题的两个答案中的相同想法，但可能有更多细节。文章中我最喜欢的部分：

正如您所看到的，BDD不仅仅是正确完成TDD。你可以用 BDD的词汇表可以改进TDD，但这就像使用 只有BDD提供给我们的一些好处。当我们使用 这两种技术的优势我们将拥有 与“工作的软件”一样重要

---

尽管大多数文献将TDD作为单元测试，BDD作为验收测试，但这并不是它们的区别

---

在实现级别上，BDD基本上是TDD，特别关注语言。BDD并不难学，但由于BDD面向团队沟通，您将错过它的大部分价值

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

---

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

BDD专注于测试应用程序的功能，并确保它符合用户故事中所述的应用程序验收标准

TDD倾向于集中于较低级别的代码，在每个类的基础上进行测试，而不是在每个功能单元的基础上进行测试

如果你对你想在用户故事中实现什么有一个很好的想法——足以列举出该功能应该做和不应该做的事情的列表——那么你就可以开始BDD了。您可以从该列表中编写一个BDD功能文件，在编写一段代码之前这样做可以让您思考该功能并将您的想法具体化。这将帮助您编写更简洁正确的代码

我建议将Cucumber JVM作为实现BDD测试的工具，但我听说JBehave在功能上类似

最后，对我来说，BDD和TDD是相互补充的技术，而不是相互竞争的技术——事先做BDD可以更容易地考虑需要什么，这可以更容易地考虑需要什么低级功能，这反过来也可以更容易地提前编写单元测试。代码编写完成后，您就可以进行一系列测试，以证明应用程序符合验收标准

我执行BDD的方式如下：

1） 检查用户故事中的用户接受标准
2） 编写一个包含测试场景的功能文件（英文），以测试每个条件。
3） 实现该功能
4） 使用Cucumber/JBehave以编程方式实现功能文件中的测试
5） 确保所有测试都通过

然后，我们维护这些测试的库，并将它们作为持续集成的一部分运行

要素文件包含特定措辞的说明，例如：

给定用户访问我们的应用程序
当用户单击搜索链接时
然后，搜索窗口打开 用户在搜索框中输入XXX
然后用户按enter键

---

搜索结果将显示

“但您将错过BDD的大部分价值，因为它面向团队沟通。”-这是一个有趣的部分。我同意这一说法，但它立即带来了另一个问题：“对于中等规模和复杂度的单人项目（目前估计开发时间为300-500小时），BDD的主要好处是什么？”与TDD相比，它可以帮助您更好地理解功能，生成文档，关注重要内容，当你回去的时候，要明白你做了什么。有一个TTD过程的标准图：。我是否正确理解您的建议是以BDD方式编写用户故事，然后以TTD方式应用图表中的流程，直到用户故事完成，然后再编写另一个用户故事并重复该循环？我将更新我的答案-请参阅上文，感谢您的澄清，再问几个问题，以确保我理解正确。在您的方法中，单元测试是用Cucumber/JBehave实现的吗？在您的示例中，您的验收测试是什么？就是那个用普通语言实现Cucumber测试的特性文件（第4部分中的Cucumber测试是单元测试，对吗？）？所以基本上，我对用于验收和单元测试的工具之间的差异感兴趣。单元测试是使用JUnit实现的，并在类级别上进行测试—确保正确测试每个分支和代码行。黄瓜测试结果令人失望

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.