单元测试应该测什么，不应该测什么？

领测软件测试网 自动化的单元测试应该测什么。

最近有朋友提出意见，觉得我写的文章比较空洞，写的很长，但是很不实在。可能原因是这样的：代码太少了。今天就从一段代码开始吧，这段代码描述电信营业系统中的缴费开机的过程：

这是电信营业系统中最常见的的一个业务。电信系统最基础的模型应该说是"三户模型"，三户模型描述的是客户（Customer）、帐户（Account）、用户（User）以及服务（Service）等等概念的一个关系模型。实际的模型比代码里的复杂，这里简化了很多，主要用来举个例子。

要开发一个电信系统，首先要做的就是在系统中实现最基础的几个模型，比如三户模型、联机指令模型、业务办理模型、合作伙伴模型……，其中三户模型处于非常重要的地位。首先要做的是在软件系统中真实的反映这个模型，绝不可以将其隐含扩散在各个业务过程中。然后就可以在这个基础上，从一到二、从二到三、从三到万，实现各个子系统和复杂多变的业务需求。

按照TDD的开发思路，我们应该先写测试代码，再来写实际程序，用测试来推动开发的前进。这里先把代码写出来，表达一下业务。下面我就说一下，单元测试代码应该测什么。

我们拿User举个例子，现在我们要写User类的测试代码。

需要测什么？

我们需要测试User类的外在表现。比如我们要测试pay方法，应该这样：

我们建立一个User对象，这个User余额是0，欠费38元。现在缴费100元，缴费完成后，余额应该是62元，欠费应该为0，这是一个Case。

我们建立一个User对象，这个User余额是30，欠费0。现在缴费50元，缴费完成后，欠费应该仍然是0，余额应该是80元。这是第二个Case。

我们建立一个User对象，这个User的余额是0，欠费150元。现在缴费70元，缴费完成后，欠费应该是80元，余额应该是0。这是第三个Case。

我们应该测试的是User类的外在表现，而不应该过问他如何实现。

在测试的时候，我们需要一个可以重复的稳定的环境（真实环境往往不行），有时候无法直接建立User对象（比如User对象要依赖一个数据集），有时候真实的环境很难实现一些测试条件（比如边界值、非正常值）。这时候，我们就可以使用Mock、Stub这样的方法，把User建立起来，也把环境建立起来，然后测试User的表现。

不需要测什么？

还是拿User举例子，还是测试pay方法，我们不应该测试这些东西：

缴费如何实现，这个费用保存到哪个数据表的哪个字段里去了，是否符合某种数据关系。

缴费以后的余额、欠费按照什么变量加减或者从某个数据字段中得到自己的值。这个不需要测。User类应该负责自己的费用问题，不应该把任何业务逻辑暴露给其他类（费用保存到哪里、什么数据结构，User应该负责）。外界只关心User的表现。

缴费后应该不应该向交换机发送开机的指令，这个就更不需要测试了，这是User的调用者应该负责的事情。

测试代码保证了什么？

测试代码只保证接口是正确的，至于业务正确不正确不是最关心的事情。比如User的测试代码，User把费用保存在数据表里、还是写在文件里，他是不关心的。甚至根本没有持久保存，他也不管，只要接口正确就通过。当然，内在实现上的错误总会通过接口表现出来。假如User没有把用户缴费保存起来，当我们在另外的空间中建立相同ID的另一个User对象时，就会得到错误的余额和欠费。

单元测试究竟有什么用？

从某种角度上说，单元测试并不能保证业务的正确性，而只能保证接口的正确性（严格的说，其实连接口的正确性也无法保证，他只能保证接口"没有这些错误"）。如果一个类总是自己在默默的工作着，不提供接口告诉外界他干了什么，测试他的业务是很难的（也不应该去测试，否则必然要插手他的业务）。那么单元测试究竟有什么用呢？

单元测试保证模块修改后的兼容性。可以通过单元测试来判断一个模块在修改后是否与修改前保持兼容、多大程度上不兼容、影响范围有多大。开发者就可以更加专注于模块内部的业务。单元测试无法代替人工的工作，他能够做到的是衡量一个模块修改后会不会影响其他模块的工作。这对程序的维护和升级有非常大的好处。

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 单元测试