行为驱动开发之一，推广篇
敏捷的历史
上上个周四，我在组里做了个内部演讲，题目是“使用Cucumber实现行为驱动开发”。考虑到组内成员并不系统的敏捷背景，我是从历史开始的。扯软件开发的历史是我最喜欢的项目之一，大部分搞软件的读书读到历史基本都跳过去，我却很喜欢看看那些过往的小故事。所以每次跟人聊起来，我都尽量吹他个昏天黑地，反正也没人知道对错。
我所介绍的软件开发的历史主线如下：
- 1956年，缺陷（Bug）这个概念产生，寻找缺陷的过程包括了测试和调试两部分；
- 1979年，测试与调试分离，Glenford J. Myers等推动了这个运动，GM同时也是“软件测试艺术”一书的作者。此运动的直接导致了测试与开发的分离，测试开始有自己的职位招聘与组织结构，研发与测试开始分支，背靠背工作，靠文档进行沟通。
- 1990年，轻量级软件测试发展，以减少传统软件测试的浪费为目的
- 1995年，轻量级开发方法登上舞台，Scrum/XP/Lean Development
- 2001年，轻量级开发方法的倡导者走到一起，敏捷宣言诞生
W瀑布模型
介绍了历史，我们一起看了下传统软件开发的基石，W模型，并以此为基础，讨论了下其中的浪费：
- 重复
- 需求文档（Requirement）与验收性测试用例（Acceptance Test）的重复
- 功能文档（Function Specification）与系统测试用例（System Test）的重复
- 设计文档（Design）-即每个模块的功能与模块测试/集成测试（Integration Test）用例重复
- 文档本身也包含着Bug
- 始终保持着一个组空闲
- 在W模型的左边，属于开发周期，研发人员忙碌
- 在W模型的右边，属于测试周期，测试人员忙碌
- 文档无用
- 高质量的代码，可以提供设计模式参考与复用，文档则不行
- 为了保持文档与代码的同步，需要花很大力气
- 如，测试用例的文档描述与自动化代码的同步，设计文档与实施代码的同步等
- 瀑布模型导致修改困难
- W模型越靠后，修改所带来的代价越高
BDD的概念
接下来，我们集体讨论了如何使用BDD的由外向内（outside-in）方法，来避免这些浪费。
- 使用自动化验收性测试用例来代替需求文档
- 使用自动化系统测试用例代替功能文档
- 使用自动化模块测试用例代替设计文档
- 当模块通过单元测试后，可以陆续进行自动化的模块/集成测试，系统测试，以及验收测试。
这就需要自动化测试用例与自然语言的融合，只有用自然语言把用例描述清楚，才能保证文档与代码的统一，设计与测试的统一。我在此也进行了Cucumber的一个小的演示，用的是项目里的一个真实的例子。使用了数据驱动后，一周内自动化了77个情景Scenario，并发现了一个Bug。
问答：
- 问：如果由外向内开发，那么我每次仅提交一行代码，也要经过漫长的测试，才能知道结果么？
- 答：将需求切分成小的story后，每实现一个story，即进入单元测试。单元测试通过后，提交代码，此时为了证明有了新代码的系统可以提供给用户所有老功能以及新功能，确实需要进行模块/集成测试，系统测试，验收测试，只有通过了所有测试，才能保证当前有了新代码进入的系统是可以交付使用的系统。即使测试时间较长，也必定小于手动测试所需的反馈时间。
- 问：Given/When/Then可以覆盖所有情景么？
- 答：在Robert. C. Martin, "Clean Code"的作者的网站上，我找到了这样一篇论述“the truth about BDD"，并深以为然。 从Bob大叔的观点来看，GIven，When，Then刚好符合测试方法中的状态表法（state transistion)，Given代表第一态，Then代表第二态，When则是从第一态至第二态转变的原因。在”software testing - a craftman“一书中，开篇也有类似的论述：以编程语言的原理来说，所有程序都可以被描述成有向连通图，每张图都有一个入口和一个出口。把Given看作起始点A，Then看作结束点Z，When是导致A向Z这个方向进行的动作，那么将这张图分解成无数小状态转换的话，就成为了若干Scenario。
- 问：由外向内的开发，如果后期出现底层API改变，会否引起变化过多？对于常变的项目，可以先手动，再稳定后，再自动
- 答：从传统项目开发的瀑布流程看，确实如此，因为传统开发，需求分析2-3个月，设计2-3个月，编码2-3个月。如果按照此流程书写大批量的BDD测试用例，那么一旦底层遇到实现难题，需要转换方式，确实会导致浪费。但是敏捷开发中，每个story的周期都很短，大约一周，只要能将story分好，那么在一周内的改变，都可以通过研发与测试的协同工作完成。
