“单元测试要做多细？”
这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests? ”。一个有13.8K的分的人（ John Nolan ）问了个关于TDD的问题，这个问题并不新鲜，最亮的是这个问题的Best Answer，这个问题是——
“TDD需要花时间写测试，而我们一般多少会写一些代码，而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了，这会不会太过分了？那么，我们写单元测试的这个单元的粒度到底是什么样的？并且，是不是我们的测试测试得多了点？”
答案
StackOverflow上，这个问题的答案是这样的——
“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.”
老板为我的代码付报酬，而不是测试，所以，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信 （我觉得这种的自信标准应该要高于业内的标准，当然，这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。 我倾向于去对那些有意义的错误做测试，所以，我对一些比较复杂的条件逻辑会异常地小心 。当在一个团队中，我会非常小心的测试那些会让团队容易出错的代码。
这个回答对TDD似乎有一种否定， 最亮的是这个问题是由 Kent Beck ，Kent是XP和TDD的创造者，是敏捷开发实践方法的奠基人 。以致于还有人调侃到——
(
29
人打了分，平均分：
4.00
)
Loading...
这篇文章的原文在这里（