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)上运行这些测试，经由过程这种方法来测试体系是否相符请求。因为这些测试如今是真正运行在临盆体系上，所以我们知道临盆体系是正常的。此外，假如体系不正常那么测试会失足并生成警报，告知我们临盆体系涌现了什么问题。当然，这只是全部测试驱动基本架构的一种模式。所以，我们转变了开辟人员历久以来的工作方法，即编写代码和测试代码。如今，他们可以用这些办法来测试和开辟代码，然后我们将它们运用到运维上。我们把基本架构也视为代码，可以编写测试，描写基本架构应当有的状况，然后再修正网站扶植的基本架构，使这些测试可以或许经由过程，这时就解释基本架构是正常的。