到底BDD、TDD、ATDD、看板和Scrum与瀑布方法有什么不同？

Question

我不明白以下几个术语之间的区别：

• BDD - 行为驱动开发
• TDD - 测试驱动开发
• ATDD - 验收测试驱动开发
• 看板
• Scrum

这些术语在敏捷方法中是如何工作的？与瀑布方法有什么不同？

Answer 1

我见过TDD/BDD/ATDD与Scrum/Kanban/Agile交替使用，所以混淆是可以理解的。以下是我对这些差异的看法：

• 瀑布是一种软件开发方法，每种开发活动都发生在一个单独的阶段(需求收集、设计、开发、测试.)。通常，瀑布项目在软件要解决的问题是完全可知和明确定义的情况下工作得最好。并不是很多软件项目都符合这个标准--是未知的未知因素导致了问题。
• 敏捷是一种软件开发理念，它的目标是更多地关注短周期，所有开发活动同时进行(尽管不在同一时间内项目的相同部分--随着新需求的发现，团队将它们构建到设计中，同时开发和测试他们在前一个周期中设计的领域)。有许多敏捷方法，包括：
  • Scrum，它专注于团队成员之间通过频繁的简短仪式进行持续的交流。我经常看到Scrum被用作敏捷过程的框架，看板被用作与团队之外的人交流进度的主要工具。
  • 看板，重点是看板(至少在我的经验)。委员会保存为迭代商定的任务，团队成员在工作时选择任务将其移动到不同的状态列。
  • 还有其他的敏捷方法，但是Scrum/Kanban组合是更常见的方法之一。

• TDD/BDD/ATDD是可以在任何方法中使用的软件开发技术，尽管这三个方面通常都是团队敏捷方法的一部分。
  • TDD是测试驱动的开发:其思想是首先编写单元测试，然后编写足够的代码使测试通过。纯TDD周期是编写一个失败的单元测试，然后编写足够的代码通过测试。然后是第二个失败的单元测试，然后足够多的新代码通过两个测试。以此类推。
  • BDD是行为驱动的开发:该技术的操作级别略高于TDD，同时仍然遵循编写测试的基本原则，然后编写代码以通过测试。BDD通常是使用给定的时-时模式来描述测试的最低级别。“考虑到我已经登录，当我单击My链接时，我将被定向到订单列表页面”)。很难区分BDD和ATDD --这里的差别是微妙的。
  • ATDD -是接受-测试驱动的开发:在我的经验中，这和BDD经常是可以互换使用的，特别是如果验收测试是以给定的时间-时间-然后的模式表示的(例如：“假设我是登录用户，那么当我进入我的订单时，我会看到我在系统中下的所有订单的列表，从最近的到最旧的。”)

• 看到所有三种技术的混合使用并不少见：。
  • 用户需求被写成一个或多个用户接受测试(失败)。
  • 每个验收测试被分解为一个或多个行为测试(失败)。
  • 每个行为测试被分解为一个或多个单元测试(失败)。
  • 此时，编码开始，每个级别迭代，直到所有用户接受测试都通过为止。

Answer 2

凯特的答案很好，但我想为区分TDD/BDD/ATDD贡献我的2分钱。

TDD首先编写测试，让这些测试驱动应用程序的开发。这引入了红色/绿色/重构的思想。基本程序是：

1. 写不及格的测试
2. 使用应用程序代码通过测试。
3. 重构应用程序代码以提高可维护性、性能等(同时保持测试的绿色)

请注意，TDD是一个高级别的概念，可以应用于金字塔中的任何级别的测试(单元、集成、接受)。

BDD是一种进行TDD的技术。您可以设置测试框架，以便测试应用程序行为，而不是特定的场景。这似乎有点微妙，而且确实如此。这也是BDD与TDD和ATDD交替使用的原因。考虑一下这个测试：

describe Calculator do
  it "returns 2 when I add 1 and 1" do
    expect(Calculator.add 1, 1).to eq 2
  end
end

这个测试是什么？好吧，我们把它设计成只测试1 + 1 == 2。我们不是在测试一个行为，而是一个特定的数据集。我们不能证明2 + 1 == 3。或99 + 1 = 100.

但如果我们像这样设计我们的测试呢？

describe Calculator do
  context "when adding 1 to a number" do
    it "returns the next sequential number" do
      expect(Calculator.add 1, 1).to eq 1.next
    end
  end
end

这看起来非常微不足道(我的例子肯定是这样)，但是这个测试证明了1 + 1 == 2、6 + 1 == 7和1500 + 1 == 1501。

简单地说，这就是BDD。

BDD也是一个高层次的概念，可以应用于测试金字塔的任何级别。声明式的验收测试方法本质上是一种BDD。但是，您可以进行命令式验收测试，这些测试更多地与具体内容联系在一起，而且本质上通常更少BDD。

在我看来，单元测试应该是BDD。我发现它经常是这样的，尽管它并不经常是这样的。

ATDD正在从业务的角度进行测试。我们关心的不是如何，而是什么。

如果单元测试或集成测试与实现有关( API返回正确的状态代码)，则验收测试与结果有关(用户可以登录)。

ATDD采用了验收测试、自动化测试的原则，并让这些测试驱动应用程序的开发。因此，您可以看到TDD是如何适应ATDD的。

当然，所有这些术语都是混合的，被分离的，并且被重新定义了太多次。当我和同事讨论它们的实现时，我认为定义它们以建立一个共同的基础是有帮助的。我的BDD并不总是我的同事所指的BDD。ATDD和(在较小程度上) TDD也是如此。

编辑

换了一点关于BDD的东西来澄清我的想法。

TDD是一个过程。BDD和ATDD是进行TDD的技术。编写单元测试，然后编写代码以使单元测试通过也是TDD。

但是TDD已经成为最后一个例子的同义词，我认为这就是很多混乱的根源所在。

Answer 3

看板和Scrum是敏捷化过程框架，因此与瀑布项目较长的单独阶段相比，迭代开发周期较短。敏捷项目的重点是在短时间内获得一个工作产品，每次迭代都应该交付一段可部署的产品。

BDD、TDD和ATDD不是开发方法，可以用于瀑布项目。它们是设计需求和测试用例的技术，可以被自动化。它们通常用于敏捷软件开发，因为它们为正在开发的需求和代码提供了一个快速的反馈周期。

因为敏捷开发没有一个单独的测试阶段，因此重要的是，大多数(如果不是全部)测试都是自动化的。应用BDD或TDD可以确保每个新开发都具有自动化的测试覆盖范围，并且迭代后的行为是安全的保护迭代。这就是为什么这些实践在敏捷开发中比瀑布更重要的原因。

我会读敏捷艺术的书，尽管它描述了另一种敏捷风格的eXtreme编程。它清楚地描述了类似于TDD的技术，以及它们的使用方式和原因。另一个好的读物是敏捷测试。