从现实来看,周边的很多人几乎都没有写单元测试的习惯,就算是计算机专业出身的人,如果公司不要求做单元测试,可能对单元测试的概念都不是很清楚。所幸本人接触到的海外项目中公司都非常重视代码质量,对测试覆盖率也有一定的要求。
什么是单元测试
首先来了解下什么是单元测试,单元测试是为了测试某一个代码单元而写的测试代码,在 OOP 领域中一个代码单元
就是指一个类的一个方法,
通俗的来说单元测试是为了测试某一个类的某一个方法能否正常工作而写的测试代码。
在这里我们要区分单元测试跟集成测试的区别,集成测试是指对一整个流程的测试。
拿我们比较熟悉的账号登录流程来说: 首先在输入框中输入邮箱和密码,点击 button 后请求接口,然后等待接口返回登录结果然后刷新页面
这种测试也叫做自动化测试,当然集成测试也是有必要的,但不是这里关注的重点
举个例子:
我们定义一个简单的功能类
1 | class AdditionUtil { |
那么为了测试这个 AdditionUtil 类的 add()方法,我们可以写如下的单元测试代码:
1 | class AdditionUtilTest { |
这里的 AdditionUtilTest 是 AdditionUtil 对应的测试类。而这里的 testAdd()就是 add()这个方法对应的测试方法。
对于 testAdd()测试方法我们分三步去完成它
- 初始化:创建一个我们要测试的类的对象
- 调用被测试方法:调用我们要测试的方法,得到运行结果
- 验证结果:验证得到的结果跟预期中是否是一样的
其中第三步的验证结果
我们用了 JUnit 框架里的验证结果的方法,最常见的就是调用 Assert 类的一些 assert 方法。除了上面用到的 assertEquals,还有 assertTrue, assertNotNull 等等
当然这是一个很简单的举例,add 方法的入参和出参都非常的简单,所以这里我们只用了 JUnit 测试框架,如果一个类里的方法实现的功能比较复杂,我们就要借助像
Robolectric
、Mockito
或者mockk
等测试框架来帮助我们完成单元测试
为什么要做单元测试
有一个理论叫做Test Pyramid 如下图所示:
Test Pyramid 理论基本大意是,单元测试是基础,是我们应该花绝大多数时间去写的部分,而集成测试等应该是冰山上面能看见的那一小部分。
单元测试之所以是基础是因为单元测试会比较完整的测试每个单元的各种不同的状况、临界条件等等,在开发时能引导更好的代码设计,在重构时能保证重构的正确性,运行速度比集成测试要快,发现 bug 也多,也很容易纳入到正常的开发流程中。
有哪些工具可以帮助我们做单元测试
JUnit、Robolectric、Mockito/mockk、Espresso 等都是为我们提供的,我们可以借助这些工具来帮助我们完成单元测试,后续我们会详细介绍这些工具的使用方式