很多公司都有要求程式要写 Unit Test，Unit Test 固然可以提升程式的品质，但是到底要写多少 Unit Test 才够呢? 我想没有人可以给一个答案。
Code Coverage
Code Coverage 是指程式测试的涵盖率，但涵盖率是否要达到 100 percent 才算是好呢 ? 80 % vs 90 % vs 100%，从数据上看 100% 一定是最好的，程式品质最高。
先来看看 Code Coverage 的算法吧，假如我写了一个档案 A，档案 A 里面共有 10 行程式，然后我再写一个 Unit Test ，这个 Test 总共有执行了档案 A 其中 5 行的 Code ，这样 Code Coverage = 50% 。
从 Code Coverage 的算法来看，Unit Test 只是执行了 5 行程式，但并不代表那 5 行程式就一定会是正确无误的，一个 function 的测试，不可能单单的靠一个 test 就能够测试完毕的，通常我们会测试很多种不同的变数型态与区间，来保证程式的正确性。
但就连这样还是无法保证程式是正确的，别忘了，当我们的功能越来越强大，每一样功能之间会有关联性，所以我们必须再花时间去测试每一种关连性，但这些尔外的测试，虽然可以提升程式的品质，却无法提升 Code Coverage，这就产生了工程师与老板的盲点。
一个不懂程式也没有任何 sense 的老板，当你问大老板说程式 Code Coverage 的目标要多少，大老板一定豪不疑问的说 100% ，当然 100% 等同於完美，大老板当然不想搞死工程师，毕竟专案还是要完成，但是又没有一个好的方法可以保证程式的正确性，所以大老板们就会订出 80 ~ 90 % 之间的标准，要求每一个工程师写出来的程式，都要完成 Code Coverage 的标准。
我觉得订出这个标准是一个不负责任的想法， 工程师为了达到 90% 的 Code Coverage ，他就必须花很多的时间，为了一堆不重要的程式，补上 Unit Test ，但是反而没办法好好的测试主功能，如果时程上有压力，最后就会变成程式非常的不稳定， 90% 的 Code Coverage 也只是骗人骗已。
Code Coverage 90 % 的目标，应该要用在一个已经稳定上线的 Project ，对於一个上线中的 Project 来说，工程师已不用追时程、赶专案，这时才会有比较多的时间提升 Code Coverage ，另外一个上线中的专案，需求的变动也会比较小。
若是说我们正在开发一个新的专案，那么 Code Coverage 就一点也不重要，开发中的专案，很容易因为一开始系统设计不良、或是需求变更、底层 Library 有 Bug 等等因素而改变程式的作法，一旦有变更， 写过的 Unit Test 就变成了垃圾，而且新改的程式，又要再补上新的 Unit Test，所以对於新专案来说，应该先要求主功能的正确性，然后交由资深的工程师决定有那些功能必需撰写 Unit Test ， 根据我的经验，光是将主功能完完整整的测过一遍， Code Coverage 就将近会有 50% 左右了。
Test Code Coverage 小故事
有一天，有一个新手工程师，跑去问大师说：
Code Coverage 要完成多少才行呢?
大师回答
不用管 Code Coverage ，只要写一些好的 Unit Test 就行了
新人点点头，就回去工作了。
第二天，另一个工程师，也去跟大师问相同的问题，大师则问工程师说
我应该往这个锅子里放多少米呢?
工程师有点困惑，回答说
我无法回答这个问题，这要看有多少人需要吃饭，他们有多饿
「没错!」 大师这样说道，工程师点点头，就回去工作了。
第三天，又有一个工程师，跑去问大师这个问题，大师用严厉的口气回答说
80 %，不多不少
工程师又点点头，就回去工作了。
后来，大师的学徒，问大师说为什么他们问一样的问题，可是你却有不同的回答呢，大师站了起来，并回答
第一个工程师是个新手，才刚开始学习如何写 Unit Test ，他还有很多东西要学习，如果这个时候要求他较高的 Code Coverage 标准，他也无法做到，不如让他只写几个完整的 Unit Test，以后再来想 Code Coveage 的问题；而第二个工程师已经很资深，能够独力完成 Coding 与 Unit Test，当我问工程师，锅里要放多少米的问题，其实我是想提醒他， Code Coverage 应该要看专案有多少个功能要测试，以及专案的大小，进度，我并不了解工程师正在开发的专案，所以我没办法给他一个答案，这个问题必需由他自已找个答案。
学徒又问，即然 Code Coverage 比率是没办法随便订标准的，那为何你要跟第三个工程师讲说「Code Coverage 需达到 80%」呢，大师回答说
第三工程师只想要一个简单的答案，就算是没有答案的东西，他也要想要一个数字，而且就算我给他答案，他也不会按照答案的方式做。