Thinking in TDD

来 ThoughtWorks 之前，我是个很自信的人。

我在一家初创公司过着朝九晚五的生活，薪水体面，很少加班。那家公司的开发人员很少，完全没有自动化流程，像是刀耕火种的原始作坊。每当新版本发布，所有人都忙于测试、集成、部署、上线的流程。

我一度以为软件开发就是这样，觉得自己可以静待公司上市、股票套现、财务自由、人生巅峰。直到我偶然看到一个名词 —— TDD。

网上不乏吹嘘 TDD 的文章。但对我而言，其价值在于启发了我对软件开发工程化的思考。无知如何求知？

我是带着问题来的。但当我真正接触到 TDD 的时候，又觉得它有些不可理喻。

按照 TDD 的理论，假设我们想写一个类，那我们应该先写测试用例。显然，在没有任何功能代码的情况下，第一个测试用例只能测构造函数能不能生成我们期望的实例。

但这毫无意义。只要按照语法标准定义，按照函数声明传参，不可能生成不了我们期望的实例。这个测试用例的唯一作用，就是在重构的时候，让我们多改一处代码。

想像一下如果每个类我们都写这样的测试会怎么样。

随着我对 TDD 的了解愈深，我对测试粒度的不解也愈深。什么时候我们应该写测试，什么时候应该测试先行，要如何把握测试与开发的平衡

StackOverflow 上有个关于测试粒度的讨论（How deep are your unit tests?），最高赞的回答是

老板为我的代码而不是测试付报酬。所以，我对此的价值观是 —— 测试越少越好，少到你对你的代码质量达到了某种自信（我觉得这种的自信标准应该要高于业内的标准。当然，这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。我倾向于去对那些有意义的错误做测试，所以，我对一些比较复杂的条件逻辑会异常的小心。当在一个团队中，我会非常小心地测试那些会让团队容易出错的代码。

意外的是，这个回答是由 TDD 的创造者之一 Kent Beck 给出的。这个回答似乎一定程度上解答了我的困惑。但当我跟同事交流时，他给出的答案却是

你不知道团队里的人会不会犯那些你以为不会犯的错误，你也不知道后续维护代码的人水平如何，所以覆盖率还是越高越好。

社区的讨论从未结束，这个问题不会有答案，我的思考也远未停止。