Android单元测试实践和探索

为什么要做单元测试

优点

  • 当组内有强迫症的童鞋想重构某块代码时,单元测试就是坚实的后盾,想象如下对话:

童鞋A:项目里这块代码写的不优雅,我要重构

负责人:重构啊,好事啊,可以,只要你重构之后单元测试能全部运行通过。

童鞋A:…

当然,这段对话的前提是建立在单元测试的覆盖率足够高的基础上

  • 优化设计,开发者先编写测试,然后再编写代码,让代码通过测试的方式来开发业务,这也就是 TDD 开发,强迫每个开发者写出易于调试和可测试的代码,并且很好的解耦合。
  • No 文档,单元测试就是一种很好的文档,自己就展示了函数和类的使用。并且这份文档还是可以编译、运行的,与项目代码保持同步
  • 可回归,与 CI 集成之后实现了真正的敏捷开发,重构完、开发完新业务,线上运行测试,而不需要将代码再部署到真机上,然后人肉点点点。

那为什么之前不写呢

首先,是对未知事物的了解导致不理解单测带来的好处和收益,然后就是经典的几个理由:

  • 单元测试太花时间了

平时开发那么忙,业务都写不完,哪有时间写单测!我第一家公司工作时,给自己找的理由就是这个,不过当时确实很忙。

但是,话又说过来,当时负责前端的童鞋却能很快地把业务&单测都写完,还有时间学习和打游戏?!仔细想了想,大家都是前端(Android 也算),为什么他能在写单测的基础上还把业务完成。或许,我们大部分的时间都花在部署代码到真机或者模拟器上,然后人肉测试和调试程序,又或者写代码的时候就能多脏就多脏,管他什么灵活性和设计,使得需求变更的时候又要花很多时间在复杂的代码中艰难前行,找出核心的那一小坨,修修补补,完成新的需求。而对新的改动又毫无信心,只能手动测试、调试。。。如此反复,陷入加班的泥泞,于是,代码越来越乱,难以维护,每天上班看着那一坨名为加班无底洞的东西就很烦。最后在别人现充的时节感叹一句,不是自己不努力,奈何加班太无力啊!

  • 我不是测试,所以

单元测试不该我来写?黑盒测试,也就是人眼验证UI和人肉点点点确实不是开发的工作,但是白盒测试,也就是了解代码的前提下来写测试,那还真是开发童鞋的锅,得接好!毕竟,谁能比开发自己更熟悉自己写的业务代码呢?

  • 单测太难写了

这个理由可能是大部分非常想写单测但是却难以落地的童鞋的心声了。比如我,大部分时候都是接二手项目,而到手的项目,别说单测了,可能代码本身的结构、逻辑都一塌糊涂,还充斥着大量的bug。这个时候,应该试着去熟悉这些代码,然后调整代码,使少部分能被测试的代码先通过单元测试,让整个程序慢慢变得可测试起来。

单元测试,有总好过没有

如何落地呢

TODO