Effective Unit Test:代码面前并非人人平等

这里的观点非常值得探讨, 所有的产品代码就像是一项投资, 有些代码的价值大, 因此需要写更多的单元测试来提高测试覆盖率. 另外有些代码的单元测试编写非常困难, 下面的一些因素可以用来帮助我们理解每个单元测试的价值:
1.代码被用的次数和它的价值成正比.
2.被依赖程度决定测试价值. 如果其他代码严重依赖被测试代码, 那么对应的测试价值大, 如果被测试代码严重依赖其他代码, 那么这个代码将难以测试. 而且不易于发现问题.
3.对I/O(网络, DB, 文件)依赖的代码难以测试, 需要使用mock技术, 而mock代码工作量大, 维护成本高
4.多线程代码更难以测试.
5.代码越复杂越需要测试.
6.被更多人所熟识的代码, 测试更容易. 因为问题将会被更快的发现和处理.

单元测试另外一个关注点就是维护问题, 这时应该将我们的每个单元测试看成一支股票, 有些股票会不断增值, 需要长期持有. 单元测试也是这样. 每个单元测试都有一个初始价格(上市价格). 如果通过单元测试发现代码改动产生了一个bug或者测试跑出了一个bug, 那么这个测试的价值将增加. 而从来没有帮助我们发现bug的测试价值则下降. 随着业务的发展, 需要对代码和测试进行重构, 这种情况下单元测试的价格不变.

但对单元测试的各项值的计算属于机器学习的范畴, 这里不做讨论.

参考原文:http://www.javacodegeeks.com/2012/01/effective-unit-testing-not-all-code-is.html