测试驱动开发与行为驱动开发有什么不同?

发布：2018-12-09 17:39:54 浏览：3933

TDD的学习难度很大。我认为BD在很多方面都是对TD0的科充和修BDD是在TDD出现5年之后才面市的，BDD是TDD的延续，因为正。BDD修正了我们对于例试的定义和命名，还对编写这些测试的方法以及适宜人员提出了一定的建设性意见。在过去六七年中，BDD一直在向前发展一也可能有8年时间了，我认为是从200年开始的。所以，对于我而育，现在BD更多是关于利益相关者、测试人员、程序员和用户之间的交流。

在快速变化的环境中，持续集成和测试将发挥什么作用?它是否总是能发挥应有的作用?

我们在一天内总会收到许多代码修改请求，而且会在一天内做多次修改，也会在一天内多次部署代码。在这种快速变化的环境中，真的不需要所谓的执行规范，因为我们可以用其他的反馈机制来替代BDD或执行规范。但是，这并不意味着执行规范、BDD、Cucumber或类似的东西不重要，实际上还是要由具体环境而定的。

根本问题在于，为什么项目一开始就要编写测试?我们之所以编写测试，是因为我们相信持续集成。什么是持续集成呢?持续集成是一种反馈机制，它能够说明我们正在做的事情正是业务所需要的，所以它是一个用户需要的特性，而且它要求编写的代码不会破坏现有的其他特性。我们编写测试来强化代码和保证代码不会出现问题，并且通过测试来获得反馈。持续集成的关键是给处于特定开发周期里的开发人员提供反馈周期。最重要的就是反馈，而不是得到反馈的方式。所以，在一些变化速度不快的环境中，单元测试或Cucumber测试(或其他测试框架)就是能够提供这种反馈的机制。在我们现在所处的环境中，它的不同之处是最终用户数量较少，所以我们获得反馈的速度更快。在部署到生产环境之后，由于不用编写测试就可以直接从用户获得反馈，所以可以更快更高效地获得反馈。更快的反馈方式是，用户直接面对面地告诉我们:“请帮我修改一下这个字体，请帮我修改一下这个单元格的背景颜色。”如果开发者可以直接获得反馈，修改后直接推送到生产环境，这种速度会快很多，因为他们不需要花更多的时间去编写测试和等待反馈。

我已经认识到这一点，但是许多公司和大多数产品并没有采用这种方式。我认为，BDD能够提供更多的执行规范。我认为它有很大价值，道理很简单:当无法快速响应和靠近最终用户时，我们需要使用其他交流方法获取反馈，而Cucumber这样的BDD框架正好能发挥它们的作用运维人员和开发人员都可以使用Cucumber等框架去编写测试。

在我的上一家公司里，有几位同事在NorwegianNationalDairy(家奶牛养殖公司)等公司的项目中使用了Cucumber框架。他们的软件确实很难测试，因为不同的奶牛有不同的饲养流程。软件里有许多复杂的业务规则，而他们编写的系统需要处理所有的业务规则。他们对一位年近60岁的养殖专家进行了培训。她并不是程序员，但了解养殖技术。他们教她如何用Cucumber描述软件的工作方式，然后她就一直写这方面的东西。在她写出需求之后，开发人员就根据她描述的业务规则实现相应的特性。培训过程很简单，因为Cucumber从一开始就是面向非程序员设计的。所以，我认为教会非技术人员编写可执行规范的方法确实适合许多团队使用。

Cucumber-Nagios的核心原理是用Cucumber编写Wweb应用的一些最终可接受测试，然后在生产系统(使用Nagios)上运行这些测试，通过这种方式来测试系统是否符合要求。因为这些测试现在是真正运行在生产系统上，所以我们知道生产系统是正常的。此外，如果系统不正常那么测试会出错并生成警报，告诉我们生产系统出现了什么问题。当然，这只是整个测试驱动基础架构的一种模式。所以，我们改变了开发人员长期以来的工作方式，即编写代码和测试代码。现在，他们可以用这些方法来测试和开发代码，然后我们将它们应用到运维上。我们把基础架构也视为代码，可以编写测试，描述基础架构应该有的状态，然后再修改网站建设的基础架构，使这些测试能够通过，这时就说明基础架构是正常的。