小架构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对象、测试业务逻辑、断言三件事,测试代码要保持简单,不能有业务逻辑。

本项目构建于RASA开源架构之上,旨在实现一个具备多模态交互能力的智能对话系统。该系统的核心模块涵盖自然语言理解、语音转文本处理以及动态对话流程控制三个主要方面。 在自然语言理解层面,研究重点集中于增强连续对话中的用户目标判定效能,并运用深度神经网络技术提升关键信息提取的精确度。目标判定旨在解析用户话语背后的真实需求,从而生成恰当的反馈;信息提取则专注于从语音输入中析出具有特定意义的要素,例如个体名称、空间位置或时间节点等具体参数。深度神经网络的应用显著优化了这些功能的实现效果,相比经典算法,其能够解析更为复杂的语言结构,展现出更优的识别精度与更强的适应性。通过分层特征学习机制,这类模型可深入捕捉语言数据中隐含的语义关联。 语音转文本处理模块承担将音频信号转化为结构化文本的关键任务。该技术的持续演进大幅提高了人机语音交互的自然度与流畅性,使语音界面日益成为高效便捷的沟通渠道。 动态对话流程控制系统负责维持交互过程的连贯性与逻辑性,包括话轮转换、上下文关联维护以及基于情境的决策生成。该系统需具备处理各类非常规输入的能力,例如用户使用非规范表达或对系统指引产生歧义的情况。 本系统适用于多种实际应用场景,如客户服务支持、个性化事务协助及智能教学辅导等。通过准确识别用户需求并提供对应信息或操作响应,系统能够创造连贯顺畅的交互体验。借助深度学习的自适应特性,系统还可持续优化语言模式理解能力,逐步完善对新兴表达方式与用户偏好的适应机制。 在技术实施方面,RASA框架为系统开发提供了基础支撑。该框架专为构建对话式人工智能应用而设计,支持多语言环境并拥有活跃的技术社区。利用其内置工具集,开发者可高效实现复杂的对话逻辑设计与部署流程。 配套资料可能包含补充学习文档、实例分析报告或实践指导手册,有助于使用者深入掌握系统原理与应用方法。技术文档则详细说明了系统的安装步骤、参数配置及操作流程,确保用户能够顺利完成系统集成工作。项目主体代码及说明文件均存放于指定目录中,构成完整的解决方案体系。 总体而言,本项目整合了自然语言理解、语音信号处理与深度学习技术,致力于打造能够进行复杂对话管理、精准需求解析与高效信息提取的智能语音交互平台。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值