在那些重Service测试而轻单元测试的项目中,Service测试里的数据安装缺少易用的脚手架,实际上编写出来的诸多Service测试犹如行尸走肉,不但没有测试出缺陷,还降低了测试运行速度,拉长了反馈时间。
实践证明,很多缺陷完全可以通过单元测试来发现,测试金字塔提出者Martin Fowler 强调 如果一个高层测试失败了,不仅仅表明功能代码中存在bug,还意味着单元测试的欠缺。因此,无论何时修复失败的端到端测试,都应该同时添加相应的单元测试。 而越早发现发现Bug,造成的浪费就会越小,单元测试本身就能够提供了快速反馈的机制。
追求卓越是一个优秀程序员必备的态度。优秀的程序员除了能够编写Clean Code,还应该能够编写Clean Test。而Clean Code的基本特征之一是易于测试。单元测试可以充当一个设计工具,它有助于开发人员去思考代码结构的设计,让代码更加有利于测试。知名的开源代码库从来不会缺乏单元测试,而给与他们自信的也正是这些可观的单元测试覆盖率。
考虑到成本与收益比,我们不必保证100%的覆盖率。因为随着覆盖率提升,单元的测试的价值越来越低,而编写的成本却越来越高。所以相比于100%这个漂亮的数字,我们应该去追求那不到100%的单元测试的有效性。
单元测试能为代码库保驾护航的前提是它本身应该有效可靠。
编写单元测试的能力容易培养,但编写有效的单元测试却需要不断地刻意练习,甚至一个有多年经验的Senior开发人员也不一定能够时刻编写出有效的单元测试。
让单元测试有效的一个很好的方式是尽可能让我们的被测代码具备良好的可测性。要做到这点,我们需要尽可能的在编码的过程中掌握必要的代码设计原则。就拿面向对象的编程编程语言来讲,我们在编写代码的时候要时刻思考Robert C. Martin
原文转自:http://sjyuan.cc/significance-of-unit-test-from-other-sight/