我今天要捅一个火药桶问题：如何进行单测。因为关于这个话题的争论实在太多了。为了减少非议，首先，我要界定一下问题范围，我这里所说的测试是针对分布式系统服务（微服务）的单元测试，不同的产品形态，测试方法差异很大，比如嵌入式系统、office软件的测试不是我们要讨论的范围。其次，我直接给观点，我认为微服务的单元测试的最佳实践就是：粗粒度单元测试优先，细粒度单元测试补足，关注测试效率（执行效率、代码效率）和代码可测性，不追求数字的代码覆盖率，但求吾心自足。
1.都是概念惹得祸
关于单元测试的定义，教科书上都是这么说的：单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类。工厂在组装一台电视机之前，会对每个元件都进行测试，这就是单元测试。
就和当年的“微服务”概念惹的祸一样，“单元”和“微”直接指向了“小”的意思，导致研发过程中，写了大量细粒度的针对类和方法的单元测试，却收益甚微，投入产出完全不成正比。在这个背景下，有人提出我们要从金字塔测试模式转向菱形测试模式，来解决单元测试效率低下，效益不足的问题：
2.重新定义单元测试
和Martin Fowler当年出来道歉，承认“微服务”这个概念有意无意的诱导很多团队把服务捣碎，弄得一地鸡毛、哀鸿遍野一样。面对单元测试的争议，及其带来的问题，老人家又一次出来开始澄清概念，说我们对“单元”的认知有误解，在这篇讨论关于测试模型的文章中，Martin特意向Kent beck求证了unit test的定义问题，kent说：
From the early days of XP-inspired unit testing there were those who disliked the term “unit test” and proposed using names like “microtest” or “programmer test” instead. （当初起unit test这个名字的时候，就有很多人提出反对意见，可能叫开发者测试更合适一些。）
Martin在这篇文章的核心观点是，你们不要纠结什么金字塔模式和什么菱形模式了，也不要再纠结集成测试（Integration test）和单元测试（Unit test）的边界问题了。他们都属于开发者测试，即开发人员要去做的测试，只要不是QA要做的测试都是Dev测试。所以对于开发人员而言，选择对你效益最大的测试方式，管他是Integration test还是unit test呢。他试图用Dev测试这个概念，来抹平集成测试和单元测试的差异。实际上，也是在变相承认菱形测试模式要比金字塔测试模式更有效的事实。
好吧，我们好像又一次被大佬们（对，Martin、Kent说的就是你们）给玩了。没办法，谁让大佬们占据了软件行业里，概念定义制高点和话语权呢。好在，我没那么容易被忽悠，把问题梳理清楚后，会帮大家及时止血。就像我当年劝大家不要把服务拆的太碎一样，我今天也要劝大家不要把测试写的太碎。更准确的说，也不是太碎，应该是该粗的粗，该细的细。因为粗有粗的方式，细有细的好处。为了区分这个粗和细，我要创造两个新的概念，对不起大家，Martin刚澄清了一个概念，我又搞出两个新概念，没办法，语言就是这么模糊，语言的模糊性也是个哲学问题，有兴趣可以去看看维特根斯坦的“语言游戏说”。这两个新概念是：
粗粒度单元测试（CUT，Coarse-grained Unit Test）：这个概念对应的是我们传统认知上的Integration Test，粗的意思这个“单元”很大，跨了整个应用。 细粒度单元测试（FUT，Fine-grained Unit Test）: 这个概念对应的是我们传统认知上的Unit Test，就是测一个类、一个方法。
导言的时候我说了，要粗粒度测试优先，对于微服务而言，效率最高的测试就是直接从对外接口开始测，这样做的好处至少有两点，首先是我们可以用尽量少的测试代码，覆盖更多的功能逻辑，测试效率高。其次是我们可以在保证接口不变的情况下，对内部逻辑进行重构，重构效率高。能达到同样的效果，谁TM愿意一个类一个方法的写测试，关键是大部分代码都是一坨一坨的（可测性差）屎山，你让我测单个类、单个方法我也不从下手啊。所以，优先考虑集成测试（粗粒度单元测试）就对了。
3. 如何正确实施“粗粒度单元测试”
对于分布式微服务系统而言，“粗粒度单元测试”最大挑战在于如何解决周边依赖问题，对于一个典型的应用而言，它可能会依赖数据库、消息中间件、缓存系统等，以及周边的其它服务。如何处理这些依赖，是我们必须要面对和要解决的问题。其实解决方案只有一种叫Test Double（测试替身），即要用“替身”来代替依赖，从而让程序在没有真正依赖环境的情况下，仍然可以运行，验证功能。这些“替身”有不少fancy的名字，比如dummy、fake、stub、mock、spy等，这里我就不啰嗦这些概念的差异了，也不重要。重要的是我们该如何高效的实施“粗粒度单元测试”。
3.1 Mock做替身
使用mock做“替身”是我们处理外部依赖的最常见做法，有很多的框架比如Mockito，EasyMock支持我们去做mock的事情，比如对于常见的数据库依赖，我们可以通过如下的方式去mock：
import static org.mockito.Mockito.*;
public class UserServiceTest {
@Test
public void testGetUserById() {
// 创建一个模拟的 UserRepository
UserRepository userRepositoryMock = mock(UserRepository.class);
// 创建一个 UserService 实例，将模拟的 UserRepository 传入
UserService userService = new UserService(userRepositoryMock);
// 设置模拟的 UserRepository 的行为
User expectedUser = new User(1, "John");
expectedUser.setAge(35);
expectedUser.setSex("male");
expectedUser.setEducation("doctor");
when(userRepositoryMock.getUserById(1)).thenReturn(expectedUser);
// 调用 UserService 的方法
User actualUser = userService.getUserById(1);
// 验证模拟的 UserRepository 的方法是否被正确调用
verify(userRepositoryMock).getUserById(1);
// 断言返回的用户是否符合预期
assertEquals(expectedUser, actualUser);
}
}
这种方法有效，但存在两个问题：
比较繁琐，当需要构造的对象有大量字段的时候，需要额外写很多的代码。 有些功能测不全，比如这里的SQL语句就不能被测试到，因为数据库的访问是被mock掉的。
3.2 Embedded Server做替身
鉴于以上的问题，我发现很多团队都开始转向embedded方案，即在本地拉起一个真实的内嵌依赖服务，作为依赖的“替身”。比如我用到了Redis缓存，那么我可以使用embedded-redis启动一个本地的redis，从而连接到“真实”的redis环境。使用很简单，只需要加入下面的依赖就可以。在Junit5的Extension帮助下，我们可以很优雅的使用embedded的服务。
类似的，我们常用的中间件比如kafka、MySQL、MongoDB等等都有相对应的embedded的方案。对于非中间件，比如其它服务依赖，我们可以使用wiremock来做其它服务API的“替身”。这些动作在很大程度上可以帮助我们消解依赖问题，这样做可以给我们带来以下好处：
在同样代码覆盖率的情况下，使用embedded的集成测试方案，可以写更少的测试用例和代码，研发效率更高 因为使用的是真实中间件服务，可以让我们的测试更加贴近真实环境，测试的有效性更高 测试的入口是接口。这种更大测试粒度带来的好处是，可以帮助我们更好的重构内部业务逻辑，而不用担心破坏测试用例，如果UT太细的话，重构代码的同时还要重写UT，比较麻烦。
你也许会说，和Mock方案相比，这里的数据准备并没有比Mock少多少啊，实际上的确如此，对于测试数据，我们可以使用测试夹具（Test Fixtures）把测试数据用json/xml的形式放在resource下面，这样可以提升我们的数据复用和数据准备效率。
除此之外，embedded方案还引入了一个比较严重的问题——慢！ 即在运行测试的时候，需要拉起整个环境，整个过程很耗时，一般情况下，如果要启动3个embedded服务，短则一分钟多则几分钟，这显然与我们所期望的单测要“短平快”不相符。“慢”会极大的抑制我们运行UT的积极性，也就不能享受UT带来的quick feedback好处，更不用说TDD了。所以，这不是个小问题，对我这个急性子而言，是必须要解决的大问题！
3.3 提效工具TestsContainer
实际上，对于测试运行慢的问题，我早年在eBay工作的时候，就深受其扰，当时eBay的服务框架很厚重，其init过程慢且繁琐，启动一下测试至少要5分钟，是可忍孰不可忍。忍无可忍的我写了一个小工具，通过hold住服务进程不释放，成功实现了服务“启动一次，多次UT运行”。当我在组内发布这个小工具的时候，它简直成为了团队的救星，设想如果一个开发人员一天要运行20次测试，因为这个工具就能节省100分钟的等待时间，对于每天工作时间只有4个小时的外企来说，这可不是小数字。
后来随着COLA开源，我把这个小工具作为COLA的一个组件一起开源，取名叫TestsContainer，寓意是承载Tests的容器。这么多年，我一直在使用这个小工具，它也的确帮我节省了很多时间。在最近的灵衢项目里，我代码写的比较多，我每天至少都要用这个工具执行近百次的测试用例，没有这个工具的帮助，我的工作效率至少要下降40%。这个神器虽然厉害，但其背后的原理实际上非常简单，它只做了两件事：
用一个while(true)循环hold住Spring容器，并不断监听用户从console的输入，来决定执行哪个用例。 使用Junit5的Launcher执行用例，因为Junit和Spring集成的很好，Launcher会自动处理相关Spring的依赖。然而在Junit5之前，是手动采用反射的方式，注入Spring的依赖，繁琐且容易有bug。
注意：在debug的时候，默认的JVM有很多安全限制，只接收方法体的修改，新增方法如果重新加载的话，就要求Restart Debug Session。为了最大发挥TestsContainer的效用，我们最好采用可以Dynamic修改Class的方案，比如otSwapAgent方案。
除此之外，还有一个工具叫TestContainers，这名字和我的工具很像，但完全不是一回事。它是用Docker容器来代替embedded server方案，这个工具给到我的启示是我们可以用Docker容器把依赖的中间件在本地预置启动好，这样就不用每次都重新拉起新的embedded服务，同样也可以提效。在我最近开发的项目中，因为embedded-GaussDB有问题，我采用的就是用Docker安装了一个本地的GaussDB来解决依赖问题，这种方式可以让我的本地调测更快。不过在CI的环境中，因为没有预安装的数据库，我们还是得采用embedded方式。好在一个应用的test suite只需要启动一次embedded的服务，所以CI的回归测试整体时间损耗也是可以接受的。
3.4 “粗粒度单元测试”小结
说了这么多，总结一下，对于分布式微服务系统而言，我们提倡“粗粒度单元测试”优先的做法，关于“替身”方案我推荐优先使用embedded，其好处是：粗粒度便于内部重构、测试效率高、测试有效性高。缺点是依赖启动时间长，为了解决这个问题。我们可以通过COLA-TestsContainer实现“启动一次，多次UT运行”来实现提效。我们也可以用Docker容器方案，在本地预安装依赖服务，从而减少反复启动带来的时间损耗。
5.“细粒度单元测试”也有它的妙用
熟悉COLA架构的同学，应该知道，我主张把核心的业务逻辑沉淀到domain领域层，为了保证domain层的纯粹和解耦，我们要尽量保证domain里面的逻辑是pojo的，不依赖任何的技术细节（Spring框架、Web框架、中间件等）。对于Domain层，就特别适合单元测试，也就是我这里说的“细粒度单元测试”。因为它粒度小、执行速度快，是货真价实的“短平快”。
举个例子，在最近的灵衢项目里，有一个灵衢网络分配通过配置区间分配vlan的关键业务逻辑。在我重构之前，这段关键逻辑完全是过程式的淹没在一个长方法里。我看了之后，“抽性大发”，抽象了一个VlanScope的概念，专门负责Scope配置解析和vlanId分配，用VlanScope这个专门的Domain Enitity（领域对象）将这个关键逻辑，从不起眼的面条代码中凸显出来，给它足够的重视和尊重——一个领域对象。
重获新生的VlanScope领域对象，其实现逻辑如下：
public class VlanScope {
private static class Scope {
int start;
int end;
private Scope(int start, int end) {
this.start = start;
this.end = end;
}
}
private List
/**
* 使用vlan的配置信息初始化构造VlanScope
*
* @param vlanScopeConfig 配置内容格式为“3000-3390,3500-3600” 表示这两个区间内的vlan是可用的。
*/
public VlanScope(String vlanScopeConfig) {
if (StringUtils.isEmpty(vlanScopeConfig)) {
throw new XlinkException.ConfigError("config vlan_scope can not be empty");
}
String[] vlanScopes = vlanScopeConfig.split(",");
for (String vlanScope : vlanScopes) {
String[] scopeStr = vlanScope.split("-");
Scope scope = new Scope(Integer.valueOf(scopeStr[0]), Integer.valueOf(scopeStr[1]));
scopes.add(scope);
}
}
/**
* 分配vlan，从配置的vlanScope中除去occupiedVlan，选择一个可用的vlan，否则报错
*
* @param occupiedVlans
*/
public int allocateVlan(Set
for (Scope scope : scopes) {
int vlan = scope.start;
while (vlan <= scope.end) {
if (!occupiedVlans.contains(String.valueOf(vlan))) {
return vlan;
}
vlan++;
}
}
throw new XlinkException("no available vlan, allocate vlan failed");
}
}
这种领域能力的沉淀，不仅让原来的业务语义更加清晰，也极大的提升了代码的可测试性。因为这个UT只是测试vlan配置和分配的功能，而且是pojo的，这让我们有机会对关键业务逻辑进行更加充分的测试。对于VlanScope，我们可以用以下的“细粒度单元测试”去覆盖：
public class VlanScopeTest {
@Test
public void testEmptyConfig() {
assertThrows(XlinkException.ConfigError.class, () -> {
VlanScope vlanScope = new VlanScope("");
});
}
@Test
public void testInvalidConfig() {
assertThrows(NumberFormatException.class, () -> {
VlanScope vlanScope = new VlanScope("3000-abc");
});
}
@Test
public void testValidConfig() {
VlanScope vlanScope = new VlanScope("3000-3390,3500-3600");
List
assertEquals(2, scopes.size());
}
@Test
public void testAllocateFail() {
assertThrows(XlinkException.class, () -> {
VlanScope vlanScope = new VlanScope("3000-3001,3500-3501");
Set
vlanScope.allocateVlan(occupiedVlan);
});
}
@Test
public void testAllocateSuccess() {
VlanScope vlanScope = new VlanScope("3000-3001,3500-3600");
Set
int vlan = vlanScope.allocateVlan(occupiedVlan);
assertEquals(3501, vlan);
}
}
可以看到，在本UT中，我们不仅测试了正常情况，也测试了更多的异常情况，因为其可测性好，运行也快，而且又是关键业务逻辑，值得我们多花些时间写UT覆盖更多的场景。而这种敏捷性、灵活性，正是“粗粒度单元测试”所不具备的。所以作为“粗粒度单元测试”的重要补充，“细粒度单元测试”在测试pojo的Domain层逻辑上能发挥妙用。这就是我在导言中说的细粒度测试补足的含义。
6.代码覆盖率，要写多少测试才够
以上介绍的粗粒度单元测试优先，细粒度单元测试补足，是Dev测试的方法。接下来我要聊聊测试哲学问题，即要写多少测试才够？代码覆盖率是不是越高越好？。首先，我要表明一下我的态度，我反对一切单纯追求数字的刻板形式主义。比如什么代码覆盖率必须要90%，否则不能合入代码。这个数字有一些参考意义，但最多只是个手段，最好不要作为管理目标（一定要做，也不要设的太高，80%足以），心里要清楚代码质量才是我们真正的目标。否则即使你完成任务式的（dutifully）实现了100%的覆盖率，但UT里面的assert都没有，也不会对代码质量提升有什么帮助。
这里，我想引用Kent Beck（TDD发明人，敏捷宣言起草人）在一篇stackoverflow回复中关于测试实用主义哲学的言论，因为我也是一个典型的实用主义者，他说：
“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence，If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals.” kent的意思大概是：我的测试哲学是只测试我认为有必要测试的部分，比如这个constructor里面的设值我认为不会出错，我就不测，那个条件分支很复杂容易出错，我就多测。不追求数字的代码覆盖率，但求吾心自足（有足够的信心交付我开发的代码）。
所以，这里我的态度也很明确了：不追求数字的代码覆盖率，但求吾心自足。
7.抓到老鼠就是好猫
这篇文章是我清明假期在图书馆一个人照顾4个娃，一边处理保安投诉说有两个小孩在爬卫生间的门还往里面喷水，一边见缝插针写的，没想到最后尽写成了万字长文。回头来看，总算把这个争论不休的问题说清楚了，解了自己的惑，如果你认真看完全文，我想也能帮你解惑。
Martin Fowler说“微服务”的“微”不代表“微小”；“单元测试”的“单元”也不代表“小构件（类、方法）”，也可以是模块，甚至是整个应用（集成测试）。你能理解他老人家这样说的良苦用心不？他这样说是因为这些重要的技术概念在传播、被学习的过程中，已经发生了严重的变形、曲解。很多软件工程项目，在这些被曲解的概念指引下，被搞得支离破碎，效率低下。实际上，即使他不出来澄清这些概念，当我们趟了足够多的坑，犯了足够多的错之后，也应该自己醒悟，用更好的方式去做事情，而不是执着于概念的教条。
总之，在软件工程领域，永远不要教条的去执行，要用实用主义态度选择对项目有益的方式去做事情，哪怕这个方式是“反模式”，哪怕这个方式是“离经叛道”，哪怕这个方式不能和“概念”对齐。因为软件工程就是这样，永远都是在“摸着石头过河”，在此过程中，“不管白猫、黑猫，抓到老鼠就是好猫”。
最后，对于分布式微服务而言，抛开那些概念的争议，我认为“那只能抓到老鼠的猫”，就是应该好好把以下几件事做好：
粗粒度： 优先使用粗粒度单元测试（集成测试），因为粗粒度测试其效率更高、更有效、更稳定、更有利于重构、ROI（投入产出比）更高 速度快： 使用TestsContainer，或者预安装好的中间件，解决集成测试依赖启动慢的问题，不能实现快速反馈，就会抑制执行测试的积极性，更不用说TDD了 关键逻辑可测： 对关键的业务逻辑，要沉淀为pojo的领域能力，提升其可测试性。然后用细粒度单元测试（单元测试）对其进行充分测试，逻辑越关键、越复杂，越要多测 不追求数字，但求我心安慰： 测试的代码覆盖率差不多就行了（80%？），关键是要有效，无效100%也是白搭。不要为了管理要求弄虚作假，按照上面3个步骤，做到无愧吾心就好
参考链接
您阅读本篇文章共花了： 大家都在找：
单元测试：单元测试是什么
发表评论