tdd和bdd
John Ferguson Smart撰写的“ BDD付诸实践：行为驱动的整个软件生命周期开发 ”是一本书，旨在涵盖BDD实践的所有方面，从需求到以可执行的规范和自动化测试为后盾的生产代码的开发。 因此，本书分为四个部分：BDD简介，需求分析技术，BDD技术技术以及BDD的更广泛使用。
BDD是一个经常被误解的术语（和实践），因此本书花了一些时间来定义BDD（以及它与TDD，ATDD和“示例规范”的区别），并概述了优点，缺点和核心原理。
行为驱动开发（BDD）是一套软件工程实践，旨在帮助团队更快地构建和交付更有价值，更高质量的软件。 它...提供基于简单，结构化句子的通用语言，可促进项目团队成员与业务利益相关者之间的交流。
BDD首先关注于提供业务价值（或称其为功能）的功能，因此，可以理解的是，本书的下一部分将介绍使用BDD进行需求定义以及确保您构建正确事物的重要问题。 对技术进行了全面的概述，例如特征注入，影响映射，基于目标的对齐模型，实物期权和故意发现。
用户需要我们的软件才能为他们提供能够帮助他们实现这些业务目标的功能。 功能是我们交付给用户以支持这些功能的功能。 功能是一项对用户有价值的有形功能……可能在一次迭代中交付也可能无法交付……功能以业务术语和管理层可以理解的语言表达。
然后，本书继续说明将功能分解为可管理的块（用户故事）以进行规划的目的，并使用具体示例来确保理解和澄清任何不确定性。
BDD从业人员使用半结构化的“给定……当……那么”格式将具体示例表示为可执行方案，这些格式对于利益相关者和团队成员都易于阅读。
需求定义部分的一大部分致力于使用Gherkin和JBehave语言格式以及如何使用功能文件和标签来组织可执行方案的技巧和示例，然后再说明如何使它们自动化。
场景描述了高级需求...步骤定义解释场景文本并调用测试自动化层以执行实际任务...测试自动化层与被测应用程序进行交互...使用这样的分层体系结构编写可维护，可读，自动化的验收测试的关键部分。
本书的第三部分从需求转向对编码和自动测试的更多技术关注，并提供了用于代码设计，单元测试，自动测试设计，UI测试和测试非功能需求的多种技术。 同样，本节包含许多使用不同语言的示例，包括C＃，Java，JavaScript和Python，以及Selenium WebDriver，SpecFlow和Thucydides等工具。
当您编写自动接受标准时，使用层可以帮助您将测试的易失性，低层实现细节与高层，更稳定的业务规则隔离开来。“业务规则”层以高层描述了被测需求。业务术语...业务流程层...表示用户在系统中实现特定业务目标的过程...技术层表示用户如何在详细级别上与系统交互—他们如何导航到注册页面，到达页面时输入的内容，如何在HTML页面上标识这些字段等等。
本书的最后一部分涵盖了BDD流程的一些输出，包括实时文档和持续交付流程。
由自动化测试生成的报告...结合了原始的规范，验收标准和测试结果，这些就是我们所说的实时文档...首先，BDD报告记录并描述了应用程序的预期功能，以及他们报告应用程序是否实际正确执行了这些操作。 当您深入研究详细信息时，BDD报告还从用户的角度说明了如何执行特定功能。
总体而言，这是一本非常平衡的书，它使读者从最初的对话到功能开发的需求，开发和测试阶段的旅程。 与该主题的许多其他书籍不同，它涵盖了整个生命周期，同时还涵盖了深入的技术和测试方面，而不会迷失于特定工具或语言的涵盖范围。
对于BDD中的“三个朋友”角色（开发人员，测试人员和业务分析师/产品所有者），这本书应该是很有趣的，整本书都具有很好的可读性，并为均衡的跨职能敏捷团队提供了见识。 但是，这潜在地是书籍的缺点-端到端的特性可能会不幸地使非技术读者感到恐惧，而技术读者可能会认为缺乏对特定工具或语言的深入了解。 无论如何，这本书都很好地涵盖了BDD（以及许多相关技术）的主题，对于任何希望了解BDD或有效实施BDD的人来说，这都是一个不错的起点。
最近，InfoQ与作者John Ferguson Smart取得了有关这本书的信息。
InfoQ：恭喜这本书。 市场上有许多BDD和相关书籍，是什么驱使您编写这本书，您发现它的不同之处是什么？
约翰：我觉得BDD领域缺少一本书，其中涵盖了BDD的全部内容，从需求发现一直到编写应用程序，编写自动化验收测试以及提供实时文档。 人们对BDD的认识通常非常有限，因此我想让人们更多地了解BDD实际上是多么广泛和具有包容性。 Gojko Adzik的“示例规范”是大量案例研究，但是自从那本书问世以来，已经出现并发展了许多新的实践和工具。 关于TDD的书籍也很多，但是我觉得它们没有抓住需求发现和确定业务价值之间的流程，并且过于关注技术方面，并使用了过时的技术堆栈。 而且很少有对Java开发人员立即有用的东西。
InfoQ：人们经常对BDD的定义感到困惑，您的基本解释是什么？
约翰：我首先将BDD描述为一种协作方式，并使用有关具体示例的对话来建立对哪些功能将为组织带来价值的共识。 当这些对话顺利完成后，您可以使用示例为这些功能定义清晰明确的接受标准。 如果自动执行这些验收标准，则可以使用企业可以理解的语言获得有关实际构建的功能的快速可靠的反馈。
您可以在任何级别使用此原理。 在更高的技术水平上，明确的验收标准可帮助我们了解要建造什么，不建造什么以及理解原因。 BDD提倡在编写代码之前为所编写的代码编写可执行的技术规范。 因此，我们获得了经过良好测试的代码以及该代码的可靠规范，这些规范可以作为不断发展的技术文档。 因此，从这个意义上讲，BDD单元测试工具（例如Spock，RSpec和Jasmine）使更容易，更直观地更有效地进行“测试驱动开发”。
但是BDD并不是一套严格定义的实践。 没有“ BDD认证从业人员”证书，也没有官方机构声明什么是佳能BDD，什么不是。 例如，我与世界另一端的许多团队一起工作，以帮助他们更清楚地表达他们的要求，因此协作不一定是面对面的（尽管是这样）。 而且我知道团队使用对话并编写BDD风格的场景来阐明他们对非IT项目要求的理解，因此不涉及自动化。
InfoQ：您在书中谈到了BDD中协作的重要性，尤其是“三个朋友”（开发人员，测试人员以及客户/分析师）之间的协作。 要成功采用BDD，这些角色中的每个角色有哪些主要区别？
约翰：我喜欢说“三个朋友，其中“三个”是介于三到七个之间的数字”。 角色是非常互补的，需要某种创造性的张力才能获得最佳效果。 BA（或产品所有者或客户）的角色实质上是通过讨论有关客户将如何使用该应用程序并从中受益的具体示例来介绍客户的需求或感知到的客户需求。 其他参与者的作用是挑战这些例子，要求反例，以确保不遗漏任何假设。 测试人员倾向于善于发现BA甚至企业可能未考虑的反例或极端案例。 并且开发人员倾向于擅长确保功能在技术上可行，并且可能会建议实现同一目标的替代方法，这些方法可能在技术上更为优越。
InfoQ：除了写这本书之外，您还教了许多课程，并围绕BDD和测试自动化运行了许多dojo。 您是否从参与者那里看到了重复出现的aha时刻？
约翰：最大的“ Aha”时刻是人们意识到协作在其中扮演的角色。 人们经常将BDD视为一种测试自动化实践，或者将其作为编写要求和接受条件的一种不同方式，其中带有大量的“给出..何时..那么”。 但是BDD的真正价值来自产生这些接受标准的讨论中的共识。
InfoQ：人们经常（错误地）将BDD与敏捷的工作方式联系起来。 一般而言，BDD带给软件开发过程的主要好处是什么？
约翰：许多BDD实践对于敏捷和更具规范性的开发过程都是有用的。 例如，以一种可以转化为可执行形式（或“可执行规范”）的方式编写验收标准，可以帮助确保验收标准是明确的和高质量的，尽管如果反馈和复查的次数少的话，反馈和审查周期可能会变慢在定义这些要求期间，BA与其他团队成员之间进行面对面的合作。
也就是说，敏捷的流程使团队有更多的余地来管理不确定性并适应他们对需求和正在建立的解决方案的不断发展的理解，而诸如3个伙伴和协作定义的接受标准之类的实践是消除不确定性的好方法要求。
无论您使用哪种开发过程，都可以使用BDD实践（尤其是为低级API编写“可执行规范”的想法）编写代码，这是生成可靠，经过良好测试和文档证明的代码的好方法既坚固又适合目标。
我还看到了一些BDD的实践和工具，特别是“活动文档”的概念，非常有效地用作将单元测试和验收测试改编为遗留代码库的一种方式。 无论是在单元测试还是在验收测试级别，BDD Test Automation都是了解和记录应用程序功能以及产生具有成本效益和针对性强的回归测试的好方法。
InfoQ：工具是本书的重要组成部分-既要考虑使用哪些工具，又要提供一些使用提示。 您在当今可用的工具中仍然看到哪些差距？
约翰：我发现敏捷项目管理与需求定义，验收测试自动化和报告之间可以有更加流畅的集成。
InfoQ：您是Serenity BDD（以前称为Thucydides）的主要贡献者。 是什么促使您编写它的？它对BDD空间有何帮助？
约翰： 宁静是我关于需求和自动化测试应如何融合在一起并产生有用的，可访问的实时文档的想法的体现，而不仅仅是简单的测试报告。
它建立在诸如Cucumber和JBehave甚至JUnit之类的BDD工具之上，可帮助您编写更简洁，更可维护的自动化验收和回归测试。 Serenity尝试在测试自动化中养成许多良好习惯，例如摘要层和自我记录自动化代码。
宁静还使将验收测试与他们证明的要求联系起来变得容易。 想法是生成报告，这些报告不仅告诉您已执行了哪些测试，而且更重要的是告诉您已测试了哪些需求。
InfoQ：这本书的写作过程通常很漫长。 现在这本书已经出版了，您是否希望将任何主题添加到这本书中？
John：我希望在故事映射上添加更多的材料，这是一种非常强大的需求发现技术，可以与其他BDD实践很好地配合使用。
而且，我还想添加一章，以使用BDD技术定义和测试微服务和Web服务API。 尽管我在书中确实谈到了这一点，但是“消费者驱动的合同”领域中现在出现了一些有趣的工具，例如Pact和Pacto，它们实际上是“可执行规范”的一种形式。
InfoQ：BDD的未来实践会怎样？
约翰：我认为BDD在微服务领域可以发挥重要作用。 例如，消费者驱动的合同测试是微服务测试的一个很好的开端，但是它仍然处于较低水平并且以测试为重点。 集成BDD中的概念有很多范围，例如驱出并发现这些Web服务合同的要求，然后报告由消费者驱动的合同风格的自动化测试，以说明可用的Web服务，如何使用它们。工作，以及它们如何与更高级别的业务需求相关联。
而且，还有许多工作要做，以简化可执行文件规范，有效文档以及所谓的“功能覆盖范围”的概念-不仅报告执行了哪些测试，还报告了已交付的功能和特性。
BDD的中心思想是围绕具体示例进行协作和对话是理解问题领域的有效方法，这种想法不会很快消失。 在技术层面上，这些工具肯定会发展，但是我肯定会看到在各个级别上编写可执行规范的想法逐渐成为一种标准技术实践。
折扣代码“ smartinfoq”可享受“ BDD in Action”优惠40％的折扣-所有格式均在manning.com上 。
tdd和bdd
821
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
