每个程序员在修改代码的时候都希望有测试,而在写代码时,都不想写测试。
为什么要写单元测试
首先,只有经过测试的代码,代码质量才会更高。其次,如今早已不是单打独斗的时代,团队中的服务不是你自己一个人在维护,如果你不写测试,别人(可能包括未来的自己)修改你的代码时,可能会影响你的原有逻辑。如果你的代码经过单元测试保证后,别人修改了,测试用例跑不过,他就会进一步检查自己的修改是否正确。因此,编写测试相当于为代码加了一层防护网。
可能有些人会说,我只是开发,测试的工作应该交给测试同学,这其实是一种极其不负责任的表现。开发和测试,对一个系统的视角是不同的,开发对于一个系统的出发点是实现,测试对于一个系统的出发点是业务。测试同学并不会关心你的代码如何实现,他们测试系统时相当于是黑盒测试,作为覆盖,我们还需要自己编写代码的测试进行白盒测试。
单元测试是所有的测试里面最基础、最底层的测试。因为它针对代码中的“方法”,因此它的运行速度比较快,可以尽早发现问题。只有通过单元测试保证了每个组件的正确性,我们才能保证最终系统的稳定性。
单元测试的结构
Junit
是 Java
最常用的测试框架,下面我们使用 Junit
来写一个最基础的测试用例来看下它的结构。
// 业务类
public class CalcService {
public int plus(int first, int second) {
return first + second;
}
}
// 测试类
public class CalcServiceTest {
@Test
public void should_plus_two_numbers() {
// 准备
CalcService calcService = new CalcService();
// 执行
int plus = calcService.plus(1, 2);
// 断言
assertEquals("The result should be", 3, plus);
// 清理
}
}
- 在上面的测试中,我们用
@Test
来标识测试用例,Junit
用这个注解来进行识别。 - 我们定义了一个
public
方法,对于Junit5
,public
可以省略。 - 我们将测试方法命名为了
should_plus_two_numbers
,即should_测试场景
。这是常用的一种命名方式,还有一种是shoule_测试效果_while_条件
。后面这种一般针对反例,即在什么情况下应该是怎样的测试效果。 - 准备:此阶段为测试做准备,比如
mock
一些外部依赖,初始化我们要测试的类、数据等。 - 执行:这是测试的核心阶段,用于触发被测试目标的行为,一般为执行一个方法的调用。
- 断言:负责验证我们的预期。在这个例子中,我们期望函数返回的结果为
3
。 - 清理:用于清理我们在准备阶段做的一些操作,大部分情况下这步是不必要的。但是假如我们有一些改变外部环境的操作,这需要将其复原,比如我们的测试需要创建文件等,则需要在测试完成后将其清理。
另外,假如我们的准备和清理阶段是许多测试方法共用的,我们可以将其移入 setUp
和 tearDown
方法中,从字面意思我们可以知道他们的作用是 装载
和拆除
。示例如下:
// 每个测试方法执行前都会被执行
@BeforeEach
void setUp() {
}
// 每个测试方法执行后都会被执行
@AfterEach
void tearDown() {
}
// 一个测试类开始执行测试方法前会被执行,只执行一次
@BeforeAll
static void beforeAll() {
}
// 一个测试类执行完所有的测试方法后会被执行,只执行一次
@AfterAll
static void afterAll() {
}