小架构step系列11:单元测试引入

1 概述

在还没有写什么代码之前,就引入单元测试,是要强调单元测试的重要性。当一套代码的生命周期比较长的时候,单元测试更加重要。生命周期长的代码,不管是产品人员还是开发人员,可能都会换了一批又一批,维护才是成本的大头。后来的人缺乏这套代码的历史知识,改起来就会bug频出,质量堪忧。如果有单元测试代码,则每次的修改如果有问题,就能够通过单元测试代码暴露出来,这样改代码会比较让人放心。但单元测试代码是一项做了则太平无事看不出作用的事情,但不做则经常要灭火而追悔莫及的事情。如果公司不强制要求或者工期比较紧张的,很可能是被忽略的,等到代码积累多了、历史知识又丢失了不少的时候,再来想补,就困难重重了。

所以,在此要先引入单元测试的基础设施,并在写代码的时候都加上单元测试,以达到编写代码达到100%的测试覆盖率。这个“100%”如果变成什么“80%”之类的,效果就会差很多,因为哪些测了哪些没测就分不清楚了,就很难监督单元测试的执行了。如果实在有些是测不了的,那么应该在工具中排除掉,排除掉的代码应该尽量少,在此基础上保持“100%”的覆盖率,使得能够比较好的监督单元测试有没有在正常执行。

2 单元测试

2.1 引入依赖

Springboot已经对测试给出了自己的推荐,也是目前比较流行的选择,如果没有什么特殊需求的话,直接选用即可。

首先,在<dependencies>中引入test的依赖:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

就是这样一个依赖,就基本足够了。

2.2 具体依赖

找到 https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot-starter-test/2.7.18/spring-boot-starter-test-2.7.18.pom 文件,看看里面的具体依赖:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>2.7.18</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-test</artifactId>
        <version>2.7.18</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-test-autoconfigure</artifactId>
        <version>2.7.18</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.assertj</groupId>
        <artifactId>assertj-core</artifactId>
        <version>3.22.0</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest</artifactId>
        <version>2.2</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.8.2</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>4.5.1</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>4.5.1</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

上面是一些主要依赖的摘录,前三个是引入springboot的基础,单元测试库junit已经是事实标准,通过junit-jupiter一起引入;断言库同时引入了assertj和hamcrest,它们各有各的优势,这里优先使用assertj;mock库则选用了mockito。mock对象,进行单元测试,最后断言结果,这是测试的三个步骤,分别使用了对应的库,这几种库的语法需要学一学。

单元测试的代码要求逻辑简单,就做上面三件事情,不要有什么业务逻辑,单元测试之间也不要有什么关系,保证单元测试代码简单,因为没有人再来测试单元测试代码了。

3 测试覆盖率

单元测试是一个做了不好看到效果,如果没有限制,那做多多少全凭开发的心情,那大概率很快就会荒废掉。所以需要有监督方式,其中就是引入测试覆盖率工具,这里选用JaCoCo,通过它来生成测试覆盖率,每次写完代码都应该检查测试覆盖率,确保单元测试覆盖所有预期的代码。

3.1 工具引入

引入JaCoCo,只需要在pom.xml中的里增加插件,版本根据情况选比较新的:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.13</version>
</plugin>

3.2 生成测试覆盖率

3.2.1 IDEA生成测试覆盖率

在IDEA中,选中单元测试用例类(可以整个目录),然后右键选择菜单“Run Tests in project_name with Coverage”:

IDEA会执行对应的测试用例,如果是在测试的根目录执行,则可以得到所有测试用例的测试覆盖率,并把结果展示到一个“Coverage”窗口里:

针对那些覆盖率不到100%的类进行检查和补充测试用例,如果要看详情则可以导出报告:

导出的报告里有个index.html,打开该文件会展示各个类的测试覆盖率,选择覆盖率不到100%的类,里面是绿色的则是覆盖的,红色的则是未覆盖的,针对红色部分的代码进行补充测试用例。

3.2.2 命令行生成测试覆盖率

IDEA会在底下默默做一些事情,让操作比较简单,这对开发人员比较友好。但如果想在持续集成工具如Jenkins上也能够生成测试覆盖率,那么还需要增加点配置:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.13</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory/}coverage_reports</outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

上面<plugin>配置增加了一个<execution>,可以通过命令mvn clean test在执行测试用例的时候就把覆盖率报告生成到coverage_reports目录下,该目录可以根据需要进行修改。

3.2.3 覆盖率100%

作为开发人员,覆盖率就应该追求覆盖率100%。在制度上也应该这样设定,这样比较容易监督。实在无法测试或者没有必要测试的则可以排除掉,排除的类也可以定期进行检查,看看是否真的符合排除的条件。这个需要在工具上能够检测,使用mvn jacoco:check命令进行检测:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.13</version>
    <configuration>
        <excludes>
            <exclude>com/qqian/stepfmk/srvpro/SrvproApplication.class</exclude>
        </excludes>
        <rules>
            <rule>
                <element>PACKAGE</element>
                <limits>
                    <limit>
                        <counter>LINE</counter>
                        <value>COVEREDRATIO</value>
                        <minimum>1</minimum>
                    </limit>
                </limits>
            </rule>
        </rules>
    </configuration>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory/}coverage_reports</outputDirectory>
            </configuration>
        </execution>
        <execution>
            <id>check</id>
            <phase>verify</phase>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

上面配置中增加了check的<execution>节点,同时在这个插件的根里增加了配置:

1、排除掉一部分无法测试的类(可以用*、**来模糊匹配),如springboo的启动类没有必要进行测试;

2、增加<rules>节点指定按行(LINE)检查覆盖率,要达到100%。规则的配置可以参考:https://www.jacoco.org/jacoco/trunk/doc/check-mojo.html

3.2.4 黑盒测试覆盖率

公司一般还有专门的测试部门,他们做的主要是黑盒测试。Jacoco也支持在java程序在运行的过程中收集测试覆盖率信息,这样就可以了解到黑盒测试到底覆盖了哪些代码,哪些没有被覆盖到。

在启动Java程序的时候,增加一个agent服务器,用于后面dump测试覆盖率的report:

java -jar srvpro-1.0.0-SNAPSHOT.jar -javaagent:jacocoagent.jar=excludes=com/qqian/stepfmk/srvpro/SrvproApplication.class,output=tcpserver,address=127.0.0.1,port=6300

-javaagent:jacocoagent.jar的格式为:-javaagent:[yourpath/]jacocoagent.jar=[option1]=[value1],[option2]=[value2],即其value是一个key-value对形式,用逗号分隔,key和value用等号分隔。更详细可参考:https://www.eclemma.org/jacoco/trunk/doc/agent.html

jacocoagent.jar包下载:https://www.eclemma.org/jacoco/index.html

执行测试后,需要用cli命令先dump出数据,然后用report命令把数据转为hmtl文件才可以看:参考https://www.jacoco.org/jacoco/trunk/doc/cli.html

# dump数据
java -jar jacococli.jar dump [--address <address>] --destfile <path> [--help] [--port <port>] [--quiet] [--reset] [--retry <count>]
例子:java -jar jacococli.jar dump --address 127.0.0.1 --port 6300 --destfile /path/jacoco.exec

# 转成report
java -jar jacococli.jar report [<execfiles> ...] --classfiles <path> [--csv <file>] [--encoding <charset>] [--help] [--html <dir>] [--name <name>] [--quiet] [--sourcefiles <path>] [--tabwith <n>] [--xml <file>]
例子:java -jar jacococli.jar report /path/jacoco.exec

4 架构一小步

1、通过spring-boot-starter-test引入测试库junit、断言库assertj、mock库mockito;

2、规范:把单元测试放到比较重要的位置,测试覆盖率要达100%;

3、规范:单元测试代码只做mock对象、测试业务逻辑、断言三件事,测试代码要保持简单,不能有业务逻辑。

智慧医药系统(smart-medicine)是一款采用SpringBoot架构构建的Java Web应用程序。其界面设计简洁而富有现代感,核心特色在于融合了当前前沿的生成式人工智能技术——具体接入了阿里云的通义千问大型语言模型,以此实现智能医疗咨询功能,从而增强系统的技术先进性与实用价值。该系统主要定位为医学知识查询与辅助学习平台,整体功能结构清晰、易于掌握,既适合编程初学者进行技术学习,也可作为院校课程设计或毕业项目的参考实现。 中医舌诊作为传统医学的重要诊断手段,依据舌象的颜色、形状及苔质等特征来辨析生理状况与病理变化。近年来,随着计算科学的进步,人工智能技术逐步渗透到这一传统领域,形成了跨学科的研究与应用方向。所述的中医舌诊系统正是这一方向的实践产物,它运用AI算法对舌象进行自动化分析。系统以SpringBoot为基础框架,该框架依托Java语言,致力于简化Spring应用程序的初始化与开发流程,其突出优势在于能高效构建独立、可投入生产的应用,尤其契合微服务架构与云原生环境,大幅降低了开发者在配置方面的负担。 系统中整合的通义千问大语言模型属于生成式人工智能范畴,通过海量数据训练获得模拟人类语言的能力,可在限定领域内生成连贯文本,为用户提供近似专业医生的交互式咨询。该技术的引入有助于提升诊断过程的自动化水平与结果一致性。 在设计与体验层面,本系统强调逻辑明晰与操作简便,旨在降低用户的学习门槛,尤其适合中医知识的入门教学。整体交互模式接近百科全书式查询,功能模块精炼聚焦,因而非常适用于教育场景,例如学术项目展示或毕业设计答辩。通过直观的实践界面,使用者能够更深入地理解中医舌诊的理论与方法。 此外,系统界面遵循简约大气的设计原则,兼顾视觉美感与交互流畅性,以提升用户的专注度与使用意愿。结合AI的数据处理能力,系统可实现对舌象特征的快速提取与实时分析,这不仅为传统诊断方法增添了客观量化维度,也拓展了中医知识传播的途径。借助网络平台,该系统能够突破地域限制,使更多用户便捷地获取专业化的中医健康参考,从而推动传统医学在现代社会的应用与普及。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
【掺铒光纤放大器(EDFA)模型】掺铒光纤放大器(EDFA)分析模型的模拟研究(Matlab代码实现)内容概要:本文介绍了掺铒光纤放大器(EDFA)分析模型的模拟研究,并提供了基于Matlab的代码实现方案。通过对EDFA的工作原理、增益特性、噪声系数等关键性能指标进行数学建模与仿真分析,帮助研究人员深入理解其在光通信系统中的作用机制。文档还列举了多个相关科研方向的技术支持内容,涵盖智能优化算法、路径规划、无人机应用、通信与信号处理、电力系统管理等多个领域,展示了Matlab在科学研究与工程仿真中的广泛应用能力。此外,文中附带网盘链接,便于获取完整的代码资源与开发工具包。; 适合人群:具备一定光学通信或电子信息背景,熟悉Matlab编程,从事科研或工程仿真的研究生、高校教师及技术研发人员。; 使用场景及目标:①用于光通信系统中EDFA性能的理论分析与仿真验证;②支持科研人员快速构建和测试EDFA模型,提升研究效率;③为教学实验、毕业设计及学术论文复现提供可靠的技术参考与代码基础。; 阅读建议:建议读者结合光通信基础知识,按照文档结构逐步运行并调试Matlab代码,重点关注模型参数设置与仿真结果分析,同时可利用提供的网盘资源拓展学习其他相关课题,深化对系统级仿真的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值