> 技术文档 > 单元测试:规范_1、编写单元测试通常需要覆盖哪些场景

单元测试:规范_1、编写单元测试通常需要覆盖哪些场景


单元测试:规范

单元测试编写原则与边界值覆盖

全面覆盖原则

在编写测试方法时,尽可能覆盖业务方法中所有可能出现的情况,尤其是边界值。这是因为边界值往往是代码容易出现问题的地方。
它强调要毫无遗漏地覆盖所有业务场景,这不仅仅是针对正常的业务逻辑,更要将目光聚焦在那些容易被忽视的边界情况上。

边界值测试具体场景

  1. 字符串参数的边界情况:对于字符串类型的参数,如身份证号,以下这些边界情况犹如一颗颗“定时炸弹”,在企业实际运行中极易引发线上 bug,因此必须毫无遗漏地纳入测试范围。
    • null:这代表着数据的缺失,在实际业务中,可能由于前端数据传输错误或者数据库读取异常等原因导致。例如,当用户未填写身份证号,而系统未对这种情况进行妥善处理时,就可能引发空指针异常等问题。
    • 空字符串\"\":与null值不同,空字符串表示用户虽然进行了输入操作,但输入内容为空。这同样需要系统进行特殊处理,否则也可能导致业务逻辑出现混乱。
    • 长度不足:如“110”这样长度明显不足的情况,可能是用户输入错误或者数据在传输过程中发生截断。系统必须能够识别并正确处理这类异常输入。
    • 长度超出:假设出现 19 位的身份证号,这显然不符合常规的身份证号格式,系统应该有相应的机制来拒绝这种非法输入,避免后续业务逻辑因错误数据而产生错误结果。
  2. 正常情况的完整性:在覆盖异常场景的同时,对于正常情况的测试也不能有丝毫马虎。必须确保覆盖业务逻辑的所有分支,就像身份证号倒数第二位为奇数代表男性,偶数代表女性,这两个分支都要进行测试。如果只关注其中一种情况,就会陷入测试的片面性陷阱,可能遗漏掉一些潜在的问题。

断言与异常处理规范

  1. 断言要求:用断言操作来验证预期结果与实际结果是否一致。
  2. 必须使用Assertions工具类来精准验证结果。比如,使用assertEquals方法来判断正常返回值是否符合预期,使用assertThrows方法来验证异常类型是否正确。严禁出现那种仅仅执行方法却不验证结果的情况,因为这样就如同只生产产品却不进行质量检测,根本无法保证业务逻辑的正确性。
  3. 异常处理:对于不符合要求的输入明确抛出特定异常,如IllegalArgumentException。而在测试用例中,要像侦探一样精准验证这些异常场景,确保异常处理逻辑的正确性。在企业规范里,异常场景覆盖与正常场景覆盖具有同等重要的地位,任何一方的缺失都可能导致系统在面对异常情况时出现不可预测的错误。

测试覆盖率分析

单元测试:规范_1、编写单元测试通常需要覆盖哪些场景

覆盖率核心指标解析

单元测试:规范_1、编写单元测试通常需要覆盖哪些场景

  1. Class(类覆盖率):当类覆盖率达到 100%时,就意味着这个被测类中的每一行代码都在测试过程中被执行过。
  2. Method(方法覆盖率):方法覆盖率,确保所有方法都能得到充分验证。
  3. Line(代码行覆盖率):它反映的是代码行被执行的比例。意味着部分代码逻辑没有得到验证,存在潜在的风险,需要进一步优化测试用例,增加对更多代码行的覆盖。
  4. Branch(分支覆盖率):比如在条件判断语句(if/else)中,不同的分支就像道路的不同岔口,分支覆盖率就是指这些岔口被覆盖的比例。必须尽可能覆盖所有分支,否则就可能遗漏一些隐藏在特定条件下的逻辑漏洞。

覆盖率统计配置技巧

单元测试:规范_1、编写单元测试通常需要覆盖哪些场景
单元测试:规范_1、编写单元测试通常需要覆盖哪些场景
单元测试:规范_1、编写单元测试通常需要覆盖哪些场景

  1. 精准统计:在 IDEA 中,可以通过Edit Configurations → Code Coverage进行设置。指定仅统计核心类,比如。这样就能避免那些无关代码对覆盖率统计结果的干扰,让我们更准确地了解核心业务代码的测试覆盖情况。
  2. 报告分析:当我们生成覆盖率报告后。报告中红色标记的部分就是未覆盖的代码行和分支,需要我们针对性地补充测试用例。通过不断分析报告并优化测试,逐步提高代码的覆盖率。

开发规范

核心规范要求

  1. 场景覆盖:企业级单元测试必须做到全方位覆盖所有业务场景,正常逻辑、边界值以及异常情况一个都不能少。这就如同建造一座大厦,每一块基石都至关重要,缺少任何一块都可能导致大厦不稳。
  2. 覆盖率标准:对于核心代码,确保达到 100%的覆盖率;非核心代码也不能掉以轻心,要保证不低于企业规定的阈值,比如 80%。不同的覆盖率标准就像是不同的质量关卡,确保代码质量在各个层面都能得到保障。
  3. 代码规范:测试类命名要遵循XxxTest的规则,就像给每个测试类取了一个统一格式的名字,便于识别和管理。测试方法命名要清晰明了,如test异常场景,让人一看就知道测试的是什么内容。同时,使用@DisplayName注解可以大大提升测试的报告可读性,就像给测试报告添加了清晰的目录,方便开发人员快速定位和理解测试内容。
  4. 单一职责:每个测试方法应该专注于测试一个特定的场景,就像每个士兵都有自己明确的任务。例如,将“测试null值”单独写成一个方法,这样在测试出现问题时,能够迅速定位到具体的场景,便于排查和解决问题。
  5. 复用资源:利用@BeforeEach/@BeforeAll注解来初始化资源,既减少了重复代码,又提高了测试的效率和一致性。