六种方式改进行为驱动开发

行为驱动开发（BDD）的做法经常与常用的推荐做法相矛盾。在分享自己的经验以及同BDD 思想领袖进行讨论的过程中， Joe Colantonio 阐述了他注意到的六个常见问题以及如何进行改进。

保持BDD 实现独立。包含实现细节，如GUI 中的按钮，会使维护更加困难。应该重点关注用户做什么，而不是怎么做。一种实现方式是，在编写场景时，保持一种声明式风格而不是一种命令式风格。Colantonio 认为，团队在BDD 实现中包含实现细节的一个原因是，他们试图将BDD 当作一个自动化测试框架使用，而不是按照它的初衷当作协作工具。

自动化是额外收益，而不是BDD 的初衷。Colantonio 提到了 Seb Rose ，后者曾表示，同业务或客户那边的人协作失败就是一个将 BDD 工具当作自动化测试工具使用的反模式。2008 年， Aslak Hellesøy 创建了 BDD 工具 Cucumber 。他强调，Cucumber 首先是一个协作工具，旨在使所有的团队成员有一个共同的认识。Cucumber 特性应该在编码实现该特性之前编写。当使用BDD 编写示例时，回归测试是一个副产品，测试并不是活动本身。

一切均关乎对话。在Colantonio 看来，BDD 的优点在于，提供了一个避免错误假设和误解的机会，使人能够在编写代码之前发现潜在的Bug。虽然他认为，对于某些团队而言，专注于对话而不是写下需求可能会成为一个新的现实，但他同时指出，转而采用BDD 和敏捷的团队应该注意，不要将场景当作需求。

一个场景不是一项需求。它们有关系，但是，一个场景集合对应一项需求。Colantonio 发现，将一个场景视为一项需求会导致各种各样的问题，他倾向于在同产品经理讨论的过程中创建小型示例，比如， Gojko Adzic 在 Specification by Example 上所描述的技术。

不要把什么都当作 UI 测试。场景是以用户的视角编写的，但 Colantonio 指出，这并不是说功能一定要通过 UI 进行测试，应用程序 UI 的内部测试组件又快又稳定。今年早些时候，Konstantin Kudryashov阐述了如何将BDD 同领域驱动设计（DDD）一起使用，减少面向UI 的场景的数量。首先检查工作域，只增加对UI 而言非常关键的场景。

实施Scrum 并不等于说实施敏捷。通过实施Scrum，团队常常会认为，他们自然而然地也在实施敏捷，但Colantonio 认为，这常常是不对的。在代码编写完成后编写单元测试，或者事后编写某种验收或集成测试，可能由一个单独的团队编写，在他看来，这些都表明团队没有采用一种敏捷方法。

查看英文原文： Six Ways of Improving Behaviour-Driven Development