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分好，那么在一周内的改变，都可以通过研发与测试的协同工作完成。
