单元测试要做多深？——测试驱动开发（TDD)引发的争论，测试驱动开发tdd

单元测试要做多深？——测试驱动开发（TDD)引发的争论，测试驱动开发tdd

著名的IT技术问答网站www.stackoverflow.com上浮现了这么一篇有趣的贴子：

单元测试要做多深？

发问的人是一个注册ID为：John Nolan 的用户，TA问到：

“我发现驱动测试开发需要花很多时间才能把测试环境设置好，而我又是个懒人，希望代码写得尽可能越少越好。一般来说我在操作的时候会先测试构造函数是否设置了所有属性，但是这样做是不是有点儿太过了？

所以我的问题是：你们在写单元测试代码的时候，一般都把粒度控制到什么级别啊？

..还有，有没有那种测试过度的案例啊？”

敏捷开发的先驱和领袖，极限编程的创始人Kent Beck

目前，对于该问题置顶的回复，是大名鼎鼎的敏捷领袖 Kent Beck , 他的观点是：

“我拿了工资是要去写运行良好的程序，而不是为了测试。所以我的观点是，在可信任的范围内，测试得越少越好（译注： 猜想Kent的意思应该是“单元测试要集中自己没有把握的地方，对于自己认为没有问题、可以信任的代码，测试越少越好。毕竟开发不能为了单元测试而去做单元测试”） 。如果我不是那种经常容易犯低级错误（比如什么在构造函数里错误设置了属性）的人，那我就不会去每次写代码测试它。我更倾向于去测试那些逻辑错误，所以，当我在处理比较复杂的逻辑条件的时候，我会非常小心谨慎。当我在一个团队里编程时，我会调整我的策略，我会非常小心地去测试那些大家写的，容易出错的代码。

当然，基于我上述的观点，不同的人会有不同的看法。不过，如果真要为“测试工作怎样才能最好地适用于编码内循环”这个问题找答案，目前也没有人能给出真正成熟的见解。鉴于这种情形，我认为我的的观点还是可以立足的。从现在起的10到20年间，还会有更多的统一理论教导我们应该写哪些测试，不应该写哪些测试，以及二者有何区别。同时，各种说法的试验也都在进行当中。”

大牛的观点自然是相当火爆的，Kent Beck自己做为XP和TDD的创始人，貌似对自己的领域唱出了反调！下面毫无疑问地跟帖无数，褒贬不一，在此就不一一翻译了。感兴趣的同学可以去原文围观。

敏捷开发和测试驱动开发，作为读者的你们，是怎么看的呢？请在评论或者微博中留言吧！

 

英文原文：How deep are your unit tests ，编译：Wld5- 黄小非

【如需转载，请在正文中标注并保留原文链接、译文链接和译者等信息，谢谢合作！】