这几天在看《BDD In Action》第十章，靠 google 翻译，磕磕吧吧看完两节。做了些摘译，也按着书中例子尝试一下开发。
BDD 与 TDD 共同特点是
- 用可执行的办法描述需求文档和设计文档。
具体到框架语言 BDD 的文档是 cucumber/gherkin。 TDD 的文档是 NUnit。
BDD 的整个开发流程，应该是这样的： 1. 语言、技术框架的选择 2. 需求分析，写成可执行标准文档 3. 根据可执行文档标准进行设计分析 4. 根据设计分析得出类及api，并用 Unit Test 将其行为与预期结果描述出来 5. 实现api，直到通过 unit testing 6. 如有必要，对包括单元测试在内的代码进行重构 7. 执行可执行文档，直到其通过。
这样做的比较明显的好处是： 1. 几乎所有代码都是有测试覆盖的 2. 不会写需求之外的代码
在阅读实践的过程中，最容易犯的错误是：不愿意为简单逻辑写单元测试，其实本质上，单元测试也不应该为简单逻辑进行测试的，但书中有一个特殊的例子，一个 getter/setter 要不要写单测，写一个等价的实现：
1
class Person(val firstName:String, val lastName:String);
书中的观点是，以上类，在调用方看来，会写成 Person("Jill","Smith") 但从接口看，并不清楚哪个是 firstName, 哪个是 lastName，因此设计上是个隐藏的内容，如果要把这个设计明确地表达出来，那用单元测试来描写是有必要的。 原文是 Java，发现 kotlin 的 Data class 根本就不可能出现这种问题。（所以说，不同的语言，会让你生产效率产生巨大变化）