本文探讨了单元测试的重要性，强调尽早编写单测的益处，并介绍了TDD（测试驱动开发）方法。文章指出，开发过程中应边写代码边写单测，以保证代码的可测性和质量。此外，文章还提到了单元测试的覆盖范围选择，以及如何编写高效、可重复执行的单测。最后，总结了编写单元测试的关键原则。
编写单测的时机，一般是 The sooner, the better（越早越好）。尽量不要将单测拖延到代码编写完之后，这样带来的收益可能不尽如人意。
TDD（Test-Driven Development）测试驱动开发，是一种软件开发过程中的应用方法，以其倡导先写测试程序，然后编码实现其功能得名。
测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。
当然TDD是一种理想的状态，由于种种原因，想要完全遵守TDD原则，是有一定难度的，毕竟PM的需求往往是可变的。
边开发边写单测，先写少量功能代码，紧接着写单测，重复这两个过程，直到完成功能代码开发。
其实这种方案跟第一种已经很接近，当功能代码开发完时，单测也差不多完成了。这种方案也是最常见和推荐的方式。
开发后再补单测，效果往往是最差的。首先，要考虑的是代码的可测性，已经完成的代码可能并不具备可测试性，毕竟写代码的时候可以任意发挥。
其次，补单测时容易顺着当前实现去写测试代码，而忽略实际需求的逻辑是什么，导致我们的单测是无效的。
Which
究竟哪些方法需要进行单测？这个困扰笔者很久的一个问题！如上文所说，单测覆盖率当然是越高越好，不过我们在考虑ROI时难免会做出一些妥协。
接受不完美，对于历史代码，全覆盖往往是不现实的。我们可以根据方法优先级（如照成资损，影响业务主流程）针对性补全单测，保证现有逻辑能正常运行。
对于增量代码，笔者认为没有必要全部覆盖，一般根据被测方法是否有处理（业务）逻辑来决定。
比如常见的JavaWeb项目代码中，Controller层，DAO层以及其他仅涉及接口转发相关的方法，往往不需要单测覆盖。而业务逻辑层的各种Service则需要重点测试。
对于自定义的工具类，正则表达式等固定逻辑，也是必须要测试的。因为这部分逻辑一般都是公共且通用的，一旦逻辑错误会产生比较严重的影响。
How
好的单测一定是能够自动执行并查执行结果的，也不应当对外部有依赖，单测的执行应当是完全自动化，并且无需部署，本地IDE就能运行。
在写单侧前，不妨参考以下前人总结好的First原则。
F—Fast：快速
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
