有一种说法：程序猿測自己的代码效果不好。由于測试是找错。程序猿不愿意去证明自己是错的，别人測效果才好，对吗？这样的说法是根本错误的，误导了无数人。正好相反，单元測试要自己測效果才好。别人測则差点儿没有效果。除非有函数级的具体文档。
单元測试的三种方式：程序猿编码同一时候測试、程序猿编码后測试、由别人測试，成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这是指一般的开发过程，其特征是没有函数级的具体文档。
我们先来看看大家耳熟能详的几个概念：需求、设计、实现。需求是“要做什么”，设计是“具体怎么做”。实现是“做出来”。
写一个函数，无论写不写文档，需求、设计、实现仍然是必经的过程，仅仅只是面对的目标非常小而已。
写一个函数，程序猿要想清晰“要做什么”和“具体怎么做”，这是所想。显然，所想的就是需求和设计。把代码写出来则是实现。这是所做。
假设在写代码同一时候測试。測试用例一定是根据“所想”而设计的。測试的结果是验证“所做”是否符合“所想”。也就是说，測试的结果是：验证实现是否符合需求。这样的方式，需求是清晰的（尽管仅仅是在程序猿的脑子里），所以效果最好，而用例仅仅需根据“所想”直接设计即可，还可以利用測试来驱动开发，所以成本最低。
程序猿编码后測试，“所想”已经忘了一部分，要根据代码来“恢复”，可是不可能所有“恢复”。測试的结果。有可能是“验证实现是否符合需求”，也有可能不是，所以效果会打折扣，由于要花时间来“恢复”所想，且不能利用測试来驱动开发。所以成本也会高得多。
由别人測试，用例设计的根据是什么？除非程序猿在编码时把“所想”记录下来。形成函数级的具体文档，否则，“别人”仅仅能读代码来确定需求，实际上，这个“需求”是实现本身，測试的结果是：验证实现是否符合实现，俗称“跟着代码走”。这样的測试有什么意义？成本方面。须要读代码来确定需求。无疑非常费时间。所以成本最高。
举个简单的样例来说明。程序猿要一个加法函数。结果写成了：
int fun(inta, int b)
{
return a - b;
};编码时測试，程序猿一定知道自己要写的是加法函数，用例为a=1; b=2;ret==3，当然能发现错误。
编码后測试，程序猿有可能想起这是加法函数，測试能发现错误。也有可能忘了，读代码后觉得这是一个减法函数，这样測试就没意义了。
别人測试，仅仅能读代码，觉得是减法函数。測试没意义。
当然，实际的情形不会那么单纯，代码可能有一些凝视。“别人”或许能了解代码的大致需求。所以“别人”測试也会有一些效果。可是，单元測试主要做的，是找出实现与需求之间的细微偏差，比如。一些输入下代码是正确的，一些输入下。代码有问题（未分类处理这些输入或处理错误），“别人”即使可以了解代码的大致需求，也难于了解所有需求。測试效果总是非常有限的。
或许有人会说。边编码边測试，尽管根据的是代码的需求（小需求），可是这个需求是否符合系统的总体需求（大需求）呢？换几句话说，本来这个函数要做的是A功能。但程序猿所想的是B功能，那測试不是没有意义吗？一、由别人測试，跟着代码走，这个问题相同存在；二、这样的错误在集成后非常easy发现；三、这样的错误非常少。用小需求不一定符合大需求来否定程序猿測试自己的代码。那就是因噎废食了。
总之，一般情形下，程序猿编码同一时候測试、程序猿编码后測试、由别人測试。三种方式的成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这个比例仅仅是定性，我无法精确证明，信不信由你，反正经过十多年的实践，我是信的。