立即测试与单一测试的效率产出比较：
（左：立即测试模型，右：单一测试模型）
从长远看来，使用“立即测试模型”的代价比“延后测试模型”的代价要低。在你编写实现代码的时候，同时编写独立的测试代码，在项目最后就可以避免出现做了无用功的问题；代码中的bug也会更少，因为你所依赖的都是已经测试的代码。于是，通过在开发过程中多花一点时间在编写单元测试上面，你就可以在最小化在项目后期花费大量时间的风险。
从上图中可以看到，“立即测试”与“延后测试”之间并没有权衡可言；而是直线效率和指数效率之间的对比，而且对于后者而言，复杂度会不断增加，并且在项目后期，很多工作需要从头再来。所有这些额外的工作都会影响你的工作效率。
显然，单元测试也并非免费的午餐。在立即测试模型中，单元测试是有开销的（在时间和金钱上面）。但是如果你查看右边曲线的方向，你会发现它花费了更多的开销－－效率曲线急剧下降；而且生产率甚至会变成负值；这些生产率损耗可以很容易导致一个项目失败。
因此，如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：
1、对于所编写的代码，你在调试上面花了多少时间？
2、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面？
3、对于一个别人报告的bug，你花了多少时间才找出导致这个bug的源码位置？
对于没有使用单元测试的程序员而言，上面这些问题所耗费的时间的递增速度是很快的，而且随着项目的深入，递增速度会变得更快；而另一方面，适当的单元测试却可以很大程序地减少这些时间，从而能够为你腾出足够的时间来编写其它的单元测试，或者你所谓的“正事”－－Coding
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。