小程序中的大道理之四--单元测试

2023-11-26 08:30

本文主要是介绍小程序中的大道理之四--单元测试,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在讨论领域模型之前, 先继续说下关于测试方面的内容, 前面为了集中讨论相应主题而对此作了推迟, 下面先补上关于测试方面的.

测试覆盖(Coverage)

先回到之前的一些步骤上, 假设我们现在写好了 getPattern 方法, 而 getLineContent 还处于 TODO 状态, 如下:

public String getPattern(int lineCount) {if (lineCount < 1) {throw new IllegalArgumentException("行数不能小于1!");}if (lineCount > 20) {throw new IllegalArgumentException("行数不能大于20!");}StringBuilder pattern = new StringBuilder();for (int lineNumber = 0; lineNumber < lineCount; lineNumber++) {pattern.append(getLineContent(lineCount, lineNumber));}return pattern.toString();
}private String getLineContent(int lineCount, int lineNumber) {// TODO Auto-generated method stubreturn null;
}

显然, getPattern 已经是 OK 的了, 那么我们也应该为它写上一些测试了.

有人可能会想, 现在到底能测试什么? 毕竟它所调用的 getLineContent 还没有实现呢, 这里好像没有什么业务逻辑可测试的.

异常测试

但这里其实还是有些逻辑可测试的, 最明显的, 前面的两个前提条件, 它是否能如我们所愿拦住那些错误的参数呢? 对第一个条件让我们来测试一下:

@Test(expected = IllegalArgumentException.class)
public void testGetPatternSmallerThan1() {Pattern p = new Pattern();p.getPattern(0);
}

这里用了一个小于 1 的参数"0"去调用它, 并期待它能抛出相应的异常.

如果还想验证它的异常信息, 可以这样写:

@Test
public void testGetPatternBiggerThan20() {Pattern p = new Pattern();try {p.getPattern(21);// 如果没有抛出异常, 测试失败fail();} catch (Exception e) {// 检查抛出异常的类型及信息assertThat(e instanceof IllegalArgumentException).isTrue();assertThat(e.getMessage()).isEqualTo("行数不能大于20!");}
}

当然, 异常信息很简单, 就是从源码中拷贝过来而已. 可以让它带上所输入的参数, 这样提示更有意义, 从而也让我们的测试更有意义, 如下:

assertThat(e.getMessage()).isEqualTo(“行数不能大于20!输入值: 21”);

那么现在测试自然是不通过了, 可以再运行一次来确认. 那么现在再修改一下源码, 在抛出异常信息的地方改成:

public String getPattern(int lineCount) {if (lineCount < 1) {throw new IllegalArgumentException("行数不能小于1!输入值: " + lineCount);}if (lineCount > 20) {throw new IllegalArgumentException("行数不能大于20!输入值: " + lineCount);}// ......
}

保存, 再运行测试, 如果这次通过了, 那么你基本可确认你已经实现了需求.

以上实践已经非常接近 测试驱动开发(TDD: Test Driven Development) 所倡导的方式:

  1. 根据需求先写一些测试, 而所测试的方法还没有实现这些需求, 因此这些测试还不能通过;
  2. 接着再写源码实现那些需求并让测试通过.

这就是所谓的测试驱动.

说完了异常方面的测试, 还有什么可测试的呢? 这里真的没有其它业务逻辑可测试了吗?

行为测试

没错, getLineContent 确实还是空的, 但不要纠结于这里, 比方说: 输入一个 3, 你调用了 4 次 getLineContent, 这不就错了吗? (可能的原因是在 for 循环部分的边界判断上没有写好)

那么怎么确切地去证明你的代码里只会不多不少只调用了 3 次呢? 可以借助 Mockito 中的行为测试来验证这些逻辑:

@Test
public void testGetPatternTimes() {Pattern pattern = Mockito.spy(new Pattern());pattern.getPattern(3);// 验证方法调用的次数, 但不关心方法的参数Mockito.verify(pattern, Mockito.times(3)).getLineContent(Mockito.anyInt(), Mockito.anyInt());
}

以上代码中, 用 Mockito 来构建了一个 pattern, 并调用了 getPattern 方法, 接着再断言 getLineContent 被调用了 3 次( Mockito.times(3) ).

至于用 Mockito.spy 而不是用 Mockito.mock, 原因是 mock 方式会让所有方法被覆盖, 除非显式使用 when...then 来指定方法的行为;

spy 则会保留原有方法的行为, 除非显式 when...then 来显式指定新的行为.

现在我们想测试 getPattern 方法, 所以用 spy.

如果你对 Mockito 还不太熟悉, 也没关系, 你只要明白这里在验证方法调用的次数就够了. 可以改变一下, 比如改成 times(4), 再跑下就会发现以下错误提示:

image

另一方面, 你可能已经注意代码中的 Mockito.anyInt 方法, 你大概也能猜出这表示不考虑具体传递的参数是什么, 但传递的参数其实也是很重要的逻辑.

虽然在调用次数上正确了, 但如果没有传递正确的参数, 自然也不能算正确调用了方法. 让我们来验证这一点:

@Test
public void testGetPatternParam() {Pattern pattern = Mockito.spy(new Pattern());pattern.getPattern(3);// 这里会验证方法调用的参数, 但并不会验证方法调用的顺序Mockito.verify(pattern).getLineContent(3, 2);// 等价于Mockito.verify(pattern, Mockito.times(1)).getLineContent(3, 2);Mockito.verify(pattern).getLineContent(3, 0);Mockito.verify(pattern).getLineContent(3, 1);
}

请注意, 我们这里假定行号从 0 开始, 这与之前的约定一致. 因此三次调用的参数分别是 (3,0),(3,1) 和 (3,2).

如果你再用一个 (3,3) 去验证呢? 显然, 代码中不会产生这样的调用, 因此将报错:

image

另外, 你可能还注意到了, 代码中先验证了 (3, 2), Mockito.verify 并不关心方法调用的顺序, 它只关注方法是否按照给定的参数被调用. 但方法调用的顺序自然也是逻辑正确与否的一个重要方面, 怎么去确保这一点呢?

因为 getPattern 方法有返回值, 我们正好可利用这一点:

@Test
public void testGetPatternOrder() {Pattern pattern = Mockito.spy(new Pattern());// getLineContent尚未实现, 我们先模拟它的行为Mockito.when(pattern.getLineContent(3, 1)).thenReturn("world");Mockito.when(pattern.getLineContent(3, 2)).thenReturn("!");Mockito.when(pattern.getLineContent(3, 0)).thenReturn("hello ");// 因为方法有返回值, 且由所调用方法的返回值顺序组装而成, 因此可以间接利用来验证调用的顺序String content = pattern.getPattern(3);assertThat(content).isEqualTo("hello world!");
}

这里体现了用 Mockito.spy 的好处, 一方面我们保留了 getPattern 方法的行为, 因为这是我们想测试的;

另一方面我们又可以去指定其它方法的行为, 比如 getLineContent 的行为.

需要注意的是, 指定 getLineContent 的行为必须在调用 getPattern 方法之前.

在上面的测试中, 我们用了一些比较随意的内容, 你当然可以模拟得更加正式一些, 如下:

@Test
public void testGetPattern() {Pattern pattern = Mockito.spy(new Pattern());// 可以模拟得很像, 但通常是没必要的. 因为在验证时的result也是由你来给出的. // 对getPattern方法而言, getLineContent究竟返回什么并不重要// 重要的getPattern是否以正确的顺序, 正确的参数去调用了getLineContentMockito.when(pattern.getLineContent(3, 0)).thenReturn("  *" + System.lineSeparator());Mockito.when(pattern.getLineContent(3, 1)).thenReturn(" ***" + System.lineSeparator());Mockito.when(pattern.getLineContent(3, 2)).thenReturn("*****" + System.lineSeparator());String content = pattern.getPattern(3);String result = "  *" + System.lineSeparator() + " ***" + System.lineSeparator() + "*****" + System.lineSeparator();assertThat(content).isEqualTo(result);
}

但正如注释中所说的那样, 在这里所进行的测试, 关注的其实是 getPattern 的逻辑. 在这一层面上, 我们假定 getLineContent 能正常工作, 然后考察依赖于它的 getPattern 方法的行为是否正确, 比方说是否以正确的参数进行了调用, 是否正确处理了返回的结果等等, 这些显然都是 getPattern 方法的职责.

如果我们通过 Mock 方式已经测试到了 getPattern 的方方面面, 理论上而言, 只要 getLineContent 正确了, 最终结果也会是正确的. 更重要的是, 当我们断言 getPattern 能正常工作时, 我们并不依赖于 getLineContent 的任何具体实现, 正如最开始时那样, getLineContent 甚至可以是尚未实现的.

关注点的分离(SoC: Separation of Concerts)

我们说前面的测试关注的是 getPattern 的逻辑, 而前提则是 getPattern 必须专注于自己的逻辑. 在代码中, 我们正是这么做的, 我们没有让 getPattern 方法大包大揽, 而是把生成每一行具体内容这一关注点分离到了 getLineContent 中, 从而让 getPatternt 专注于集成 getLineContent 返回的内容上.

SoC 是一种重要的设计原则, 你或许更常在 AOP(Aspect-Oriented Programming, 面向切面编程)的实践中听到所谓的 横切关注点(cross-cutting concerns), 也即所谓的切面了.

自然, AOP 也实践了 SoC 这一原则, 但 SoC 本身是一个更宽泛的原则, 你当然可以怀疑套用在这里是否有点牵强, 但我认为不必过于狭隘地去理解它.

单一职责原则(SRP: Single Responsibility Principle)

可以看到, getPattern 方法并没有过多的职责, 生成每一行具体内容的职责被委托到了 getLineContent 上. 正如我们前面用一个"hello world!"形式去验证那样, 具体返回什么那已经是 getLineContent 的职责了, getPattern 做好自己的事情就行了, 它不受其它变化的影响.

SRP 同样也是一种重要的设计原则, 你更常听到的可能是一个类或一个模块应该具有单一的职责. 在这里我们说的是方法, 你当然可以继续怀疑套用在这里是否有点牵强, 但我还是那句话, 不必过于狭隘地去理解它. 重要的是领会这些思想的精神实质, 你或许还能隐约感受它与 SoC 有点关系.

Robert C. Martin 把"职责"定义成"更改的原因"(reason to change), 认为一个类或一个模块应该有且只有一个更改的理由(a class or module should have one, and only one, reason to change.).

实际上, Mockito 不赞成使用 spy 方法, 它认为, 如果你要用 spy, 你的设计可能存在一些问题. 事实上, 如果增加一个叫 Line 的类, 并把 getLineContent 移到它的里面(或许名字还可改成更短的 getContent), 让 Pattern 类依赖于这一 Line 类, 那么就可以用 Mockito.mock 来构造 Line 的实例去测试 Pattern 类, 正像前面测试 PatternFilePattern 时那样, Pattern 类也能因此变得更加简单.

当然, 由于这是一个很小的例子, 你可以怀疑是否值得这么去做. 但在现实中, 如果你发现一个类正在不断膨胀, 你或许应该停下来好好想想它是否承担了过多的职责, 也许你已经到了一个值得拆分它的时间点.

这篇关于小程序中的大道理之四--单元测试的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/425391

相关文章

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟&nbsp;开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚&nbsp;第一站:海量资源,应有尽有 走进“智听

EMLOG程序单页友链和标签增加美化

单页友联效果图: 标签页面效果图: 源码介绍 EMLOG单页友情链接和TAG标签,友链单页文件代码main{width: 58%;是设置宽度 自己把设置成与您的网站宽度一样,如果自适应就填写100%,TAG文件不用修改 安装方法:把Links.php和tag.php上传到网站根目录即可,访问 域名/Links.php、域名/tag.php 所有模板适用,代码就不粘贴出来,已经打

跨系统环境下LabVIEW程序稳定运行

在LabVIEW开发中,不同电脑的配置和操作系统(如Win11与Win7)可能对程序的稳定运行产生影响。为了确保程序在不同平台上都能正常且稳定运行,需要从兼容性、驱动、以及性能优化等多个方面入手。本文将详细介绍如何在不同系统环境下,使LabVIEW开发的程序保持稳定运行的有效策略。 LabVIEW版本兼容性 LabVIEW各版本对不同操作系统的支持存在差异。因此,在开发程序时,尽量使用

CSP 2023 提高级第一轮 CSP-S 2023初试题 完善程序第二题解析 未完

一、题目阅读 (最大值之和)给定整数序列 a0,⋯,an−1,求该序列所有非空连续子序列的最大值之和。上述参数满足 1≤n≤105 和 1≤ai≤108。 一个序列的非空连续子序列可以用两个下标 ll 和 rr(其中0≤l≤r<n0≤l≤r<n)表示,对应的序列为 al,al+1,⋯,ar​。两个非空连续子序列不同,当且仅当下标不同。 例如,当原序列为 [1,2,1,2] 时,要计算子序列 [

这些心智程序你安装了吗?

原文题目:《为什么聪明人也会做蠢事(四)》 心智程序 大脑有两个特征导致人类不够理性,一个是处理信息方面的缺陷,一个是心智程序出了问题。前者可以称为“认知吝啬鬼”,前几篇文章已经讨论了。本期主要讲心智程序这个方面。 心智程序这一概念由哈佛大学认知科学家大卫•帕金斯提出,指个体可以从记忆中提取出的规则、知识、程序和策略,以辅助我们决策判断和解决问题。如果把人脑比喻成计算机,那心智程序就是人脑的

uniapp设置微信小程序的交互反馈

链接:uni.showToast(OBJECT) | uni-app官网 (dcloud.net.cn) 设置操作成功的弹窗: title是我们弹窗提示的文字 showToast是我们在加载的时候进入就会弹出的提示。 2.设置失败的提示窗口和标签 icon:'error'是设置我们失败的logo 设置的文字上限是7个文字,如果需要设置的提示文字过长就需要设置icon并给

基于SpringBoot的宠物服务系统+uniapp小程序+LW参考示例

系列文章目录 1.基于SSM的洗衣房管理系统+原生微信小程序+LW参考示例 2.基于SpringBoot的宠物摄影网站管理系统+LW参考示例 3.基于SpringBoot+Vue的企业人事管理系统+LW参考示例 4.基于SSM的高校实验室管理系统+LW参考示例 5.基于SpringBoot的二手数码回收系统+原生微信小程序+LW参考示例 6.基于SSM的民宿预订管理系统+LW参考示例 7.基于

Spring Roo 实站( 一 )部署安装 第一个示例程序

转自:http://blog.csdn.net/jun55xiu/article/details/9380213 一:安装 注:可以参与官网spring-roo: static.springsource.org/spring-roo/reference/html/intro.html#intro-exploring-sampleROO_OPTS http://stati

未来工作趋势:零工小程序在共享经济中的作用

经济在不断发展的同时,科技也在飞速发展。零工经济作为一种新兴的工作模式,正在全球范围内迅速崛起。特别是在中国,随着数字经济的蓬勃发展和共享经济模式的深入推广,零工小程序在促进就业、提升资源利用效率方面显示出了巨大的潜力和价值。 一、零工经济的定义及现状 零工经济是指通过临时性、自由职业或项目制的工作形式,利用互联网平台快速匹配供需双方的新型经济模式。这种模式打破了传统全职工作的界限,为劳动

springboot+maven搭建的项目,集成单元测试

springboot+maven搭建的项目,集成单元测试 1.在pom.xml文件中引入单元测试的依赖包 <!--单元测试依赖--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></depen