单元测试要作多细

这篇文章主要来源是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的创造者，是敏捷开发实践方法的奠定人。以至于还有人调侃到——

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don’t always adhere to Test First religiously. But I’m surprised too.

只是要地球人都不会以为Kent Beck会这么说啊！咱们有大堆程序员在忠实的追求着100%的代码测试覆盖率，由于这些程序员以为Kent Beck也会这么干！我告诉过不少人，你在你的XP的书里说过，你并不老是支持“宗教信仰式的Test First”，可是今天Kent这么说，我仍是很惊讶！

后面还有一些人不一样意Kent， 我一会儿从这个事中想到了《fight club》里的那个精神分裂者建立了一个连本身都反对的地下组织。呵呵。

其实我是很是赞成Kent的，怎么合适怎么搞，爱怎么测试就怎么测试，只要本身和团队有信心就能够了。没有必要就必定要写测试，必定要测试先行。

其它答案

八卦完了，咱们仍是来认认真真地看看这个问题中其它的其它答案，由于这个问题的也是国人爱问题的问题。

第二个答案：值得借鉴

• 开发过程当中，单元测试应该来测试那些可能会出错的地方，或是那些边界状况。

• 维护过程当中，单元测试应该跟着咱们的bug report来走，每个bug都应该有个UT。因而程序员就会对本身的代码变动有两个自信，一是bug 被 fixed，二是相同的bug不会再次出现。

第三个答案：给敏捷咨师看的答案

这个答案在说，咱们只注意到了TDD中的T，而忽略了第一个D，就是Driven…… bla bla bla… 又这扯这些空洞的东西了，国内的各类不学无术的敏捷咨询师最好这一口了。

第四个答案：致那些什么都要测试的人

若是咱们须要测试一个像 int square(int x) 这样的开根函数，咱们须要40亿个测试（每一个数都要测试）。

事实上这种状况可能还更糟糕，若是有这样一个方法 void setX(int newX) 不会更改其它的成员变量，如：obj.z, Obj.y，那么，你是否是还要去测试一下别的变量没有被改变？

咱们只可能测试那些有意义的，确实要测试的案例。

个人观点

我在《TDD并无看上去的那么美》一文中说过个人观点了，我就再也不多说了。我仍是把下面这些观点列出来，供你们思考和讨论：

1）我国的教育对咱们最大的洗脑不是掩盖事实，而让咱们习惯于标准答案，习惯于教条，从而不会思考！敏捷开发中的若干东西彷佛都成了软件开发中对某种标准答案的教条，实在是悲哀！

2）软件开发是一种脑力劳动，是一种知识密集型的工做，就像艺术做品同样，创做过程和成品是没有标准答案的。

3）软件的质量不是测试出来的，而是设计和维护出来的。就像工匠们在一点一点地雕琢他们的做品同样。

UT的粒度是多少，这个不重要，重要的是你会不会本身思考你的软件应该怎么作，怎么测试。