不要为了 Unit Test 而写 Unit Test

不管是哪种测试，都是为了确保程序码的品质，以及是否符合需求规格。而单元测试是工程师确保自身产出的一种方式，怎麽确定自己写的单元测试涵盖所有的函式呢？

以 Android Studio 是提供了行数、类别和函式数单元测试覆率计算。但每一个开发团队对於覆盖率的定义都不一样，但是先问问你自己写单元测试是为了什麽？

写了这些测试，未来逻辑异动是不是也能确保这些内容无误，毕竟写了这些程序码将来就是会有维护的成本。所以考虑覆盖率的同时，不妨也考量後续的维护成本。

最後，重构之前要不要写单元测试保护确保逻辑。通常说出这句话的，有两种情境：

一、原有逻辑没有单元测试：依需要重构的状况，有些逻辑可以包进物件里、逻辑优化、架构改善或是换其他程序语言做改写等等。像逻辑包进物件里，就很适合在重构前先进行验证。

二、原有逻辑乱到没人想要了解逻辑如何运作：工程师面临大挑战，有些时候不是想慢慢拆，而是它本身就是个陨石坑，谁踩到就爬不出来。

如果有测试团队可能还可以从测试情境中捞出一些验证条件做辅助。

若没有就只能考量是不同的阶段进行优化，但一步步进行虽然没办法看到很大的改变，可是却是最稳的做法，只是考验大家的耐性，以及团队对技术债给予的空间。

相信在技术债上是很多开发团队的痛，而这些痛通常都得过且过，但只到他大爆炸的时候，反而会让开发团队处於紧张跟压力巨大的困境之中。

与其让他将来有机会发生，不如让它早早被看见被处理，让每一天好好工作不用担心是不是有未爆弹。