测试驱动开发与举动驱动开发有甚么差别?

tdd的进修难度很大。我以为bd在不少方面都是对td0的科充和修 bdd是在tdd泛起5年之后才面市的，bdd是tdd的延续，由于正。bdd修正了咱们对付例试的界说和定名，还对编写这些测试的要领以及合适职员提出了必然的建设性定见。在已往六七年中，bdd一直在向前发展一也可以有8年时间了，我以为是从200年起头的。以是，对付我而育，此刻bd更可能是关于利益相干者、测试职员、程序员和用户之间的交流。

在疾速变革的环境中，连续集成和测试将阐扬甚么作用?它是否老是能阐扬应有的作用?

咱们在一天内总会收到许多代码修改要求，而且会在一天内做屡次修改，也会在一天内屡次部署代码。在这类疾速变革的环境中，真的不需求所谓的执行规范，由于咱们可以用其余的反应机制来代替bdd或执行规范。可是，这其实不料味着执行规范、bdd、 cucumber或雷同的东西不首要，理论上仍是要由详细环境而定的。

基本问题在于，为甚么项目一块儿头就要编写测试?咱们之以是编写测试，是由于咱们信赖连续集成。甚么是连续集成呢?连续集成是一种反应机制，它能够注明咱们正在做的事情恰是营业所需求的，以是它是一个用户需求的特点，而且它要求编写的代码不会粉碎现有的其余特点。咱们编写测试来强化代码和包管代码不会泛起问题，而且经由过程测试来获得反应。连续集成的关键是给处于特定开发周期里的开发职员提供反应周期。最首要的就是反应，而不是获得反应的体式格局。以是，在一些变革速率烦懑的环境中，单位测试或 cucumber测试(或其余测试框架)就是能够提供这类反应的机制。在咱们此刻所处的环境中，它的差别的地方是终极用户数目较少，以是咱们获得反应的速率更快。在部署到出产环境之后，由于不消编写测试就能够直接从用户获得反应，以是可以更快更高效地获得反应。更快的反应体式格局是，用户直接面临面地通知咱们:“请帮我修改一下这个字体，请帮我修改一下这个单位格的背景颜色。”若是开发者可以直接获得反应，修改后直接推送到出产环境，这类速率会快不少，由于他们不需求花更多的时间去编写测试和等候反应。

我曾经认识到这一点，可是许多公司和大大都商品并无采用这类体式格局。我以为，bdd能够提供更多的执行规范。我以为它有很大代价，原理很简略:当没法疾速响应和挨近终极用户时，咱们需求运用其余交流要领获取反应，而 cucumber如许的bdd框架正好能阐扬它们的作用运维职员和开发职员均可以运用 cucumber等框架去编写测试。

在我的上一家公司里，有几位共事在 norwegian national dairy(家奶牛养殖公司)等公司的项目中运用了 cucumber框架。他们的软件的确很难测试，由于差别的奶牛有差别的豢养流程。软件里有许多庞大的营业规则，而他们编写的零碎需求处置一切的营业规则。他们对一名年近60岁的养殖专家进行了培训。她其实不是程序员，但理解养殖手艺。他们教她怎样用 cucumber形容软件的事情体式格局，而后她就一直写这方面的东西。在她写出需求之后，开发职员就按照她形容的营业规则实现响应的特点。培训过程很简略，由于 cucumber从一块儿头就是面向非程序员设计的。以是，我以为教会非手艺职员编写可执行规范的要领的确适合许多团队运用。

cucumber- nagios的核心原理是用 cucumber编写wweb应用的一些终极可承受测试，而后在出产零碎(运用 nagios)上运转这些测试，经由过程这类体式格局来测试零碎是否契合要求。由于这些测试此刻是真正运转在出产零碎上，以是咱们知道出产零碎是正常的。别的，若是零碎不正常那末测试会出错并生成警报，通知咱们出产零碎泛起了甚么问题。当然，这只是整个测试驱动根蒂根基架构的一种形式。以是，咱们改动了开发职员恒久以来的事情体式格局，即编写代码和测试代码。此刻，他们可以用这些要领来测试和开发代码，而后咱们将它们应用到运维上。咱们把根蒂根基架构也视为代码，可以编写测试，形容根蒂根基架构应该有的状况，而后再修改网页制作的根蒂根基架构，使这些测试能够经由过程，这时候就注明根蒂根基架构是正常的。