什么是单元测试?
《单元测试的艺术》中对单元测试的定义:
一个单元测试是一段自动化的代码,这段代码调用被测试的工作单元,之后对这个单元的单个最终结果的某些假设进行校验。
单元测试几乎都是用单元测试框架编写的;只要产品代码不发生变化,单元测试的结果是稳定的。
为什么需要单元测试?
在我看来,单元测试的意义可以总结如下三点:
- 单元测试是保证你写的代码是你想要的结果的最有效办法;
- 单元测试帮我们塑造设计;
- 单元测试是最好的文档之一。
单元测试描述了代码的预期行为,可以最有效地保证代码正确运行,减少代码缺陷;由于单元规模较小,当因为代码变更出现问题的时候,可以帮助我们快速定位问题;有单元测试覆盖的代码,让我们更有信心,敢于放心做代码重构。
写单元测试的过程往往伴随着代码重构,如果发现一段代码单元测试很难写,就需要反思我们的设计,进而重构促进代码设计的优化,帮助我们塑造设计。
同时单元测试也是一个最佳的、自动化的、可执行的文档;没有单测覆盖的代码,是很难被维护的。
什么是有效的单元测试?
可读、可维护、可信赖、快速执行!
《单元测试的艺术》中描述优秀单元的特性:
- 它应该是自动化的,可重复执行;
- 它应该很容易实现;
- 它应该第二天还有意义;
- 任何人都应该能一键运行它;
- 它应该运行速度很快;
- 它的结果应该是稳定的(如果运行之间没有进行修改的话,多次运行一个测试应该总是返回同样的结果);
- 它应该能完全控制被测试的单元;
- 它应该是完全隔离的(独立于其他测试的运行);
- 如果它失败了,我们应该很容易发现什么是期待的结果,进而定位问题所在。
可读性
“一般程序员写得出计算机能读懂的代码。优秀程序员写得出人能读懂的代码” — 马丁·福勒
可读的代码才是可维护的;难以阅读和理解的测试用例,最终的结果就是删掉它,因为维护成本过高。可读性高于纯粹的性能。
可维护性
团队内使用一套范式的结构,有助于使之更好用,快速定位问题;消灭代码中的坏味道。
可信赖
可信赖的含义:
- 测试可重复;
- 测试与依赖环境隔离;
- 只测试不进行验证是不可靠的测试;
- 在测试类中不要依赖与测试的顺序;
- 测试的结果是精准的:校验的精准以及错误问题的精准定位。
快速执行
保证单测快速执行,缩短反馈时长。
为什么有效的单元测试如此重要?
无效的单元测试是没有意义的,反而会增加维护成本,最终导致单元测试的失败!
如上图所示,坐标中任意一个点,其与横纵坐标垂直线所形成的矩形面积代表CI为团队带来的价值,那么在我看来有两个关键的因素:横坐标是单元测试的基础能力建设,纵坐标则是有效的单元测试。
没有有效的单元测试,基础能力做出花来也毫无意义!完善的基础能力同时也帮助我们更低成本的写出有效的单元测试。
如何写有效的单元测试?
我们以Flutter为例,来一起讨论如何写有效的单元测试;
使用测试框架
Flutter官方提供的测试框架:
- flutter_test
- integration_test
统一的编码约定
不论是AAA(Arrange-Act-Assert)还是GWT(Given-When-Then),统一的编码约定帮助保证测试代码的可读性、可维护性。
使用测试替身
测试替身帮助我们隔离被测试代码,加速执行速度,保证测试代码是可信赖的。
- Dummy:一种什么也不做的实现方式。接口中的每个方法什么也不做,如果方法有返回值,返回的值尽量接近null或者0。
- Stub:Dummy的一种,Stub的函数并不返回null或0,而是返回能推动函数沿预定路径被测试的值。
- Spy:Stub的一种,它返回测试所需的特定值,推动系统沿着我们期望的路径前行。然而,Spy能记住对它所做的事,并允许测试询问。
- Mock:Spy的一种,它返回测试所需的特定值,推动系统沿着我们期望的路径前行,而且还会记住对它所做的事。不过,Mock还知道我们的预期,基于这些预期,判断测试是否通过;换而言之,Mock中写明了测试断言。
- Fake:Fake是一种模拟器,它实现基础业务规则,这样测试就能要求该Fake按需要的路径执行。
一个测试应当只检查一件事
明确测试意图,一旦出错可以精准定位问题。
一个测试只有一个模拟对象
避免过多模拟对象,一个测试用例的校验内容尽量简单。
避免冗余测试