单元测试实施最佳方案（背景、实施、覆盖率统计）

1. 什么是单元测试？

---

对于很多开发人员来说，单元测试一定不陌生

单元测试是白盒测试的一种形式，它的目标是测试软件的最小单元——函数、方法或类。单元测试的主要目的是验证代码的正确性，以确保每个单元按照预期执行。单元测试通常由开发人员来写，通过单元测试，开发人员可以在代码开发阶段及早发现和修复错误，提高代码的质量和可维护性。

1.1 集成测试 != 单元测试

假如在支付系统有一个service，有个支付预下单的方法，逻辑是先根据订单号查询数据库中是否存在支付单，再调营销系统接口查询优惠券信息，然后根据优惠券信息计算实际支付金额，最后再调用支付通道预下单。（不用去理解逻辑细节，这里的重点是，这个方法需要很多外部依赖才能正常执行，数据库、中间件、外部系统等等）

伪代码如下：

@service
public class payservice {

    @autowired
    private orderpayrecordmapper orderpayrecordmapper;
	
    @autowired
    private feishuservice feishuservice;
    
    @dubboreference
    private marketingservice marketingservice;

    public prepayresponse prepay(prepayrequest prepayrequest) {
        prepayresponse response = prepayresponse.builder().orderno(prepayrequest.getorderno()).build();
        // 【查询数据库】校验订单支付记录是否存在
        orderpayrecord existedorderpayrecord = orderpayrecordmapper.getbyorderno(prepayrequest.getorderno());
        if (existedorderpayrecord != null && !paystatusenum.pending.equals(existedorderpayrecord.getstatus())) {
            throw new businessexception("5311991", "存在支付中订单，请勿重复支付");
        }
        // 【调用营销系统】查询优惠信息
        couponresponse coupon = marketingservice.querycoupon(couponrequest.builder().orderno(prepayrequest.getorderno()).build()).getdata();
        // 【写数据库】创建订单支付记录
        orderpayrecord neworderpayrecord = orderpayrecord.builder()
                .orderno(prepayrequest.getorderno())
                .status(paystatusenum.pending)
                .amount(calcrealamount(prepayrequest.getamount(), coupon))
                .build();
        orderpayrecordmapper.insert(neworderpayrecord);
        // 【调用支付通道】预下单
        alipayprepayresponse alipayprepayresponse = alipayclient.prepay(
                alipayprepayrequest.builder().orderno(prepayrequest.getorderno()).amount(neworderpayrecord.getamount()).build()
        );
        if (!"success".equals(alipayprepayresponse.getresult())) {
            feishuservice.sendmessage("通道预下单失败 orderno:%s", prepayrequest.getorderno());
            throw new businessexception("5319997", "通道预下单失败");
        }
        response.setpayno(alipayprepayresponse.getpayno());
        return response;
    }

    /**
     * 计算优惠后的金额
     */
    private long calcrealamount(long originamount, couponresponse coupon) {
        if (coupon != null && coupon.getdiscount() > 0 && originamount > coupon.getdiscount()) {
            return numberutils.max(0l, originamount - coupon.getdiscount());
        }
        return originamount;
    }
}

针对上面这个支付预下单的方法，很多开发人员可能习惯于像下面这样写“单元测试”，构造一下入参，然后调用被测方法，最后打印一下结果：

@runwith(springrunner.class)
@springboottest(classes = application.class)
public class payservicetest {

    @autowired
    private payservice payservice;

    @test
    public void test() {
        prepayrequest prepayrequest = prepayrequest.builder().orderno("123").amount(100l).build();
        prepayresponse prepayresponse = payservice.prepay(prepayrequest);
        system.out.println(prepayresponse);
    }
}

但这是单元测试吗？

在被测方法中，需要查询数据库（查询、保存数据），需要调用营销系统接口查询优惠券信息，需要调用支付通道预下单接口，如果内部系统是微服务调用，还要起注册中心…… 这个“单元”是不是有点大了？

运行单元测试的时候，因为会启动整个spring容器，连接配置中心、注册中心，连接数据库，初始化redis配置等等，所以测试一个方法会很慢很慢；还可能因为数据库没连上，或者营销系统挂了，或者通道接口返回“fail”，单测运行就直接报错了；即使这些所依赖的环境都没问题，如果要测试有优惠券的情况，还要在营销系统中新增优惠券信息，等等。这些限制条件极大影响了测试效率。

真正的单元测试应当独立于外部环境，具有隔离性，应尽量避免其他类或系统的副作用影响。单元测试的目标是一小段代码，例如方法或类，应该只关注被测代码的核心逻辑。外部依赖关系（那些不容易构造的环境或需要灵活返回预期结果的依赖）应从单元测试中移除，改为由测试框架创建的 mock 对象来替换依赖对象。一个对象被 mock 后，在执行测试时不会调用其真实方法逻辑。例如，通过 mockito 框架 mock 的对象，实际上是根据插桩，为真实对象创建了一个代理。运行单元测试时，调用的是代理对象的方法。

举例来说，如果对 orderpayrecordmapper、marketingservice、alipayclient 进行 mock，那么在执行 payservice.prepay() 时，执行到这些 mock 对象的方法时，并不会真正去操作数据库、通过 rpc 调用远程服务、通过 http 调用第三方通道，而是根据插桩返回预期的结果。

通过使用 mock 对象，可以确保测试的独立性、确定性和高效性，从而更好地验证代码的正确性和可靠性。mock 对象不仅提高了测试的执行速度，还保证了测试结果的一致性，使其能够在各种环境中重复执行。

2. 为什么要写单元测试？

---

验证代码正确性，简便地模拟各种场景。 单元测试能够验证代码的基本功能是否按预期工作。每个小的代码片段（如函数或方法）的逻辑是否正确无误。程序运行的 bug 往往出现在一些边界条件、异常情况下，比如网络超时等，在集成环境中模拟这些异常情况都比较困难，通过单元测试可以方便地模拟各种情况。

保证重构后代码的正确性。 重构是开发中的家常便饭，但每次改动都可能带来未知的问题。很多时候我们不敢修改（重构）老代码的原因，就是因为不知道影响范围，担心影响其他逻辑。有了完善的单元测试，重构之后运行一下单测就能迅速验证功能是否依旧正常，极大降低了引入新bug的风险。

阅读单元测试能帮助我们快速熟悉代码。 良好的单元测试，可以作为一个类/方法的“文档”，未来开发人员变更，通过一个方法的单元测试，可以知道指定输入对应的预期输出是什么，不需要深入的阅读代码，便能知道这个方法大概实现了什么功能，有哪些特殊情况需要考虑等等。

单元测试成本很低，有利于集成测试进行，提高效率。 编写单元测试虽然会花费大量精力，但是一旦完成了单元测试的工作，很多基础的bug将会被发现，并且修复这些bug的成本很低（比如开发阶段在本地及时发现、修复这些bug，不用等部署到dev/test等环境运行时遇到某个bug，还得在本地修改，再重新部署到dev/test环境复测……） 。

经过单元测试的对象（接口、函数等）可靠性会得到保证，在将来的系统集成中，可以极大减少在一些简单的bug上花费的时间（比如空指针异常、数组下标越界、代码执行分支和预期不符等），从而可以把精力放在系统交互和全局的功能实现相关的测试上。

capers jones 在《applied software measurement : global analysis of productivity and quality》中有一张图比较形象地描述了在软件生命周期中，bug产生的概率、bug被发现的概率、bug被修复的成本之间的关系：

从这个图中可以发现，bug发现的越晚，修复它的成本就越高。在开发阶段是产生bug概率最高的时候，在开发阶段也是修复bug成本最低的时候，如果暂时抛开tdd不谈，单元测试是性价比最高的测试。

3. 编写单元测试

---

3.1 单元测试的范围是什么？

一般推荐优先对核心业务逻辑代码、有复杂计算（比如金融、支付业务比较重要的计算）、复用性代码（如比较重要的工具类）等进行单元测试。

3.2 什么时候编写单元测试？

• 在编写代码之前
  测试驱动开发（tdd，test-driven development）是一种开发方法，要求在编写实际代码之前先编写单元测试，优点是可以确保每一行代码都有相应的测试覆盖，从而提高代码质量和稳定性。

• 在实现功能代码的同时
  如果没有采用 tdd 方法，可以在实现功能代码的同时编写单元测试。这种方法可以在开发过程中及时发现和修复代码中的问题。

• 在修复 bug 之前
  在修复 bug 之前，先编写一个能重现该 bug 的单元测试，然后修复代码使该测试通过。这可以确保 bug 被修复，并且防止以后再出现同样的问题。

• 在重构代码之前
  在重构代码之前，先编写单元测试来验证当前代码的行为，然后进行重构。这样可以确保重构不会引入新的错误，并且功能保持不变。

• 在添加新功能之前
  在添加新功能之前，编写单元测试可以确保新功能的正确性，并且不会破坏现有功能。

3.3 通过junit和mockito编写单元测试

junit是java中最流行的测试框架，目前主流的mock工具有mockito、spock、jmockit、powermock、easymock等， mockito的语法简介，易上手，使用者众多，因此我们选择使用junit来写单元测试，使用mockito来mock对象。

一般写单元测试的步骤为：构造被测方法入参 -> 对依赖插桩 -> 执行被测方法 -> 断言

junit基础用法

maven依赖：

<dependency>
    <groupid>junit</groupid>
    <artifactid>junit</artifactid>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

用一个@test注解就能定义一个方法为测试方法，用assert进行断言：

import org.junit.assert;
import org.junit.test;

public class junittest {
    @test
    public void testfact() {
        int calcresult=math.addexact(1,1);
        assert.assertequals(2, calcresult);
    }
}

junit大家很熟悉，这里不再赘述。更多junit的使用，比如rule、timeout，junit5中的参数化测试等等，可以参考官方文档，文档中有很多demo供参考：

junit4： https://junit.org/junit4/ 或者 https://github.com/junit-team/junit4/wiki/

junit5： https://junit.org/junit5/docs/current/user-guide/

mockito基础用法

这里只列举一下mockito常见的用法，在项目中有其他场景可以参考mockito官方文档https://javadoc.io/static/org.mockito/mockito-core/4.5.1/org/mockito/mockito.html

maven依赖（spring-boot-starter-test已经包含mockito-core，如果已经引了spring-boot-starter-test就不需要再引mockito-core了，另外mockito-inline是在mock静态方法的时候需要使用）：

<dependency>
    <groupid>org.mockito</groupid>
    <artifactid>mockito-core</artifactid>
    <version>4.5.1</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.mockito</groupid>
    <artifactid>mockito-inline</artifactid>
    <version>4.5.1</version>
    <scope>test</scope>
</dependency>

（1）mockito中的mock对象

在 mockito 中，主要有三种对象类型，分别由 @injectmocks、@mock 和 @spy 注解来定义：

• @injectmocks：用于被测试的类。mockito 会通过反射创建这个类的实例（类似于 spring 容器为 @component 修饰的类创建实例）。如果该实例有依赖，mockito 会自动将标记为 @mock 或 @spy 的对象注入到这个实例中。单元测试执行时，会真正执行这个实例的方法。
• @mock：用于需要被 mock 的依赖（类或接口）。mockito 会通过字节码生成框架（bytebuddy）为其创建代理对象。单元测试执行时，不会调用真正的方法，而是根据插桩返回预期的结果。
• @spy：用于部分模拟的对象。spy 对象既可以调用真实对象的方法，也可以模拟其行为。默认情况下，调用的是实际对象的方法；当对其插桩后，调用的是模拟后的行为。

简而言之，用 @injectmocks 来修饰被测试的类（只能是类，不能是接口），用 @mock 或 @spy 来修饰需要 mock 的对象（类或接口都行）。

（2）写单元测试时，就不能用 @runwith(springrunner.class) 和 @springboottest(classes = application.class) 了，因为我们不需要真正初始化所依赖的对象，也就不需要加载spring应用上下文。

在单元测试类上添加@runwith(mockitojunitrunner.class)注解，用来初始化mockito，自动注入mock对象等，比如要对上面payservice类写单元测试：

@runwith(mockitojunitrunner.class)
public class payservicetest {

    @injectmocks
    private payservice payservice;

    @mock
    private orderpayrecordmapper orderpayrecordmapper;

    @mock
    private marketingservice marketingservice;

    @test
    public void testprepaysuccess() {
        // 单元测试内容
    }
}

（3）对mock对象的非静态方法插桩，比如：

假设当通过orderpayrecordmapper.getbyorderno(string orderno)查询订单号为80984234938472的支付订单时，返回null；

假设当通过marketingservice.querycoupon(couponrequest request)查询优惠券时，返回null；

可以这样写：

@runwith(mockitojunitrunner.class)
public class payservicetest {

    @injectmocks
    private payservice payservice;

    @mock
    private orderpayrecordmapper orderpayrecordmapper;

    @mock
    private marketingservice marketingservice;

    @test
    public void testprepaysuccess() {
        prepayrequest prepayrequest = prepayrequest.builder().orderno("80984234938472").amount(100l).build();
        // 插桩 假设是第一次下单，数据库中还没有相同订单号的支付记录(执行到orderpayrecordmapper.getbyorderno时，不会真正查数据库，会直接返回null)
        mockito.when(orderpayrecordmapper.getbyorderno(prepayrequest.getorderno())).thenreturn(null);
        // 插桩 假设没有优惠券(执行到marketingservice.querycoupon时，不会真正调营销系统接口，会直接返回null)
        mockito.when(marketingservice.querycoupon(mockito.any())).thenreturn(response.buildsuccess(null));
        // 执行被测方法
        prepayresponse prepayresponse = payservice.prepay(prepayrequest);
        // 断言
        assert.assertnotnull(prepayresponse);
        assert.assertnotnull(prepayresponse.getpayno());
    }
}

（4）参数匹配，上面在对orderpayrecordmapper.getbyorderno()进行插桩时，方法入参可以传真实的，也可以传任意值，比如对marketingservice.querycoupon()进行插桩时，方法入参传的mockito.any()表示参数为任意值的时候都返回thenreturn()指定的结果。此外，还有mockito.any(class type)、mockito.anystring()、mockito.anylong()……

（5）上面例子中支付通道预下单接口是通过一个静态方法alipayclient.prepay()来调用的，mockito3.4.0之后支持对静态方法打桩（需要依赖mockito-inline）：

@test
public void testprepaysuccess() {
   prepayrequest prepayrequest = prepayrequest.builder().orderno("80984234938472").amount(100l).build();
   mockito.when(orderpayrecordmapper.getbyorderno(prepayrequest.getorderno())).thenreturn(null);
   mockito.when(marketingservice.querycoupon(mockito.any())).thenreturn(response.buildsuccess(null));
   // 插桩 假设调用支付通道预下单接口返回成功
   mockedstatic<alipayclient> alipayclientmockedstatic = mockito.mockstatic(alipayclient.class);
   alipayclientmockedstatic.when(() -> alipayclient.prepay(mockito.any())).thenreturn(
       alipayprepayresponse.builder().payno("123").result("success").build()
   );
   // 执行被测方法
   prepayresponse prepayresponse = payservice.prepay(prepayrequest);
   // 断言
   assert.assertnotnull(prepayresponse);
   assert.assertnotnull(prepayresponse.getpayno());
   // 注意mock的静态对象使用完毕要调用close()来释放，或者用try-with-resources方式
   alipayclientmockedstatic.close();
}

注意为了保证测试隔离性、避免内存泄漏，mock的静态对象使用完毕要调用close()来释放，或者用try-with-resources方式来释放，也可以在@before中初始化（junit5中是@beforeeach），在@after中释放（junit5中是@aftereach）：

private mockedstatic<alipayclient> alipayclientmockedstatic;

@before
public void setup() {
	alipayclientmockedstatic = mockito.mockstatic(alipayclient.class);
}

@after
public void teardown() {
	alipayclientmockedstatic.close();
}

@test
public void testprepaysuccess() {
    prepayrequest prepayrequest = prepayrequest.builder().orderno("80984234938472").amount(100l).build();
    mockito.when(orderpayrecordmapper.getbyorderno(prepayrequest.getorderno())).thenreturn(null);
    mockito.when(marketingservice.querycoupon(mockito.any())).thenreturn(response.buildsuccess(null));
    // 插桩 假设调用支付通道预下单接口返回成功
    alipayclientmockedstatic.when(() -> alipayclient.prepay(mockito.any())).thenreturn(
        alipayprepayresponse.builder().payno("123").result("success").build()
    );
    // 执行被测方法
    prepayresponse prepayresponse = payservice.prepay(prepayrequest);
    // 断言
    assert.assertnotnull(prepayresponse);
    assert.assertnotnull(prepayresponse.getpayno());
}

（6）验证方法执行，对于一些有返回值的方法，可以通过断言来进行预期判断，对于一些没有返回值的void方法，可以通过verify来验证这个方法是否执行（成功），比如在上面例子中，验证feishuservice.sendmessage()这个方法是否被成功执行：

mockito.verify(feishuservice).sendmessage(mockito.any()); // 验证feishuservice.sendmessage()方法成功执行了1次
mockito.verify(feishuservice,mockito.times(2)).sendmessage(mockito.any()); // 验证feishuservice.sendmessage()方法成功执行了2次

（7）异常断言，当预期某个分支会抛异常时，可以通过如下方式：

① 通过自定义方式：

@test
public void testprepaytimeout{
    try {
        payservice.prepay();
        assert.fail();
    } catch (exception e) {
        assert.asserttrue(e instanceof timeoutexception);
        assert.assertequals("超时啦",e.getmessage());
    }
}

② 通过mockito的方式，当判定某个分支是否抛异常时，可以通过@rule来定义异常断言，比如

@rule
public expectedexception thrown = expectedexception.none();
@test
public void testprepaytimeout{
    thrown.expect(timeoutexception.class); // 当执行payservice.prepare()时，预期抛出timeoutexception异常
    thrown.expectmessage("超时啦");         // 当执行payservice.prepare()时，预期抛出异常message是"超时啦"
    payservice.prepay();
}

③ 通过junit的方式，如果只对指定的异常类做断言，junit中还有一个比较简单的方式，直接在@test注解上定义预期的异常：

@test(expected = timeoutexception.class)
public void testprepaytimeout{
    payservice.prepay();
}

（8）private方法如何测试？一般private方法不建议进行单元测试，可以在测public方法的时候来测。当然也可以通过spring-test测试私有方法，通过reflectiontestutils.invokemethod调用被测方法：

prepayresponse prepayresponse= reflectiontestutils.invokemethod(payservice, "prepay", prepayrequest);

3.4 人工写单元测试太累？要学会站在巨人的肩膀上

一个项目中，能坚持写单元测试是一件很不容易的事情，可能开发人员没有写单元测试的习惯，或者由于赶业务而没有时间去写，或者是在项目后期为代码编写单元测试工作量巨大，觉得编写单元测试浪费时间，总之有很多理由导致坚持不下去。

所以可以借助一些工具来为我们自动生成单元测试，比如idea中有一些专门用来生成单元测试的插件比如testme、squaretest、jcode5等，也可以利用ai插件比如通义灵码来生成单元测试。具体用什么，哪个好用，看个人习惯。不够有些工具自动生成的单元测试，可能参数什么的不符合要求，或者运行不通过，需要重新调整一下才可以。

4. 单元测试覆盖率检测

---

测试的时候，我们常常关心，是否所有代码都测试到了，这个指标就叫做“代码覆盖率”（code coverage），代码覆盖率是一个非常重要的质量指标。它可以帮助我们了解代码中哪些部分被测试覆盖，哪些部分可能存在风险。通常我们关注的覆盖率有几个测量维度：

• 类覆盖率：测试用例覆盖的类的百分比。
• 方法覆盖率：测试用例覆盖的方法的百分比。
• 行覆盖率：测试用例执行的代码行数占总行数的百分比。
• 分支覆盖率：代码中每个条件分支（如 if-else 语句）被测试用例执行的情况。
• 指令覆盖率：测试用例执行的字节码指令占总指令数的百分比。

jacoco是一款比较强大的单测覆盖率检测工具，idea中已经集成了jacoco单元测试覆盖率检测，也可以通过它的maven插件来检测，在jenkins等持续集成平台上打包部署的时候也可以进行检测（原理也是执行maven插件）。

4.1 通过idea中集成的jacoco检测单元测试覆盖率

在idea右上configuration -> edit

modify options -> specify alternative coverage runner

然后在code coverage那就能选择jacoco了（默认是idea）：

配置好之后，运行覆盖率检测：

就能检测当前单元测试对被测代码的覆盖率了，在右边栏coverage里就是单元测试覆盖率结果，有类覆盖率、方法覆盖率、行覆盖率、分支覆盖率，双击类名，可以看到代码左边有不同颜色的标识，默认绿色表示完全覆盖，黄色表示部分覆盖，红色表示未覆盖：

4.2 使用jacoco的maven插件进行单测覆盖率检测

如果是简单的maven项目，直接在pom文件中添加下面两个插件：

<plugin>
    <groupid>org.apache.maven.plugins</groupid>
    <artifactid>maven-surefire-plugin</artifactid>
    <version>2.18.1</version>
    <configuration>
        <skiptests>false</skiptests>
        <testfailureignore>true</testfailureignore>
        <argline>${jacocoargline}</argline>
    </configuration>
</plugin>
<plugin>
    <groupid>org.jacoco</groupid>
    <artifactid>jacoco-maven-plugin</artifactid>
    <version>0.8.6</version>
    <executions>
        <execution>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
            <configuration>
                <propertyname>jacocoargline</propertyname>
            </configuration>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

如果是maven父子项目，可以在父项目添加上面两个插件（可以检测所有子项目代码的覆盖率），jacoco只能针对每个maven子项目生成单独的覆盖率报告，如果想要把生成的报告聚合在一起，可以找一个maven子模块来做报告聚合（比如我们可以让***-starter子项目来做报告聚合），需要保证两点：1 做报告聚合的模块需要添加对应报告模块的maven依赖；2 在***-starter子项目的pom文件中添加如下插件（还可以通过exclude标签来禁止对某个包、类等生成单测覆盖率）：

<plugin>
    <groupid>org.jacoco</groupid>
    <artifactid>jacoco-maven-plugin</artifactid>
    <version>0.8.6</version>
    <configuration>
        <excludes>
            <exclude>
                **/com/danny/test/mapper/**
            </exclude>
        </excludes>
    </configuration>
    <executions>
        <execution>
            <id>my-report</id>
            <phase>test</phase>
            <goals>
                <goal>report-aggregate</goal>
            </goals>
            <configuration>
                <excludes>
                    <exclude></exclude>
                </excludes>
            </configuration>
        </execution>
    </executions>
</plugin>

写完单元测试，执行 mvn clean test 后，maven单模块项目会在 target\site\jacoco、聚合项目会在 target\site\jacoco-aggregate 目录生成单元测试覆盖率报告，打开index.html就可以看到整个项目、某个包、类的单测覆盖率：

每个指标的含义：

• instructions：java 字节指令的覆盖率
• branches：分支覆盖率
• cxty(cyclomatic complexity)：圈复杂度，jacoco 会为每一个非抽象方法计算圈复杂度，圈复杂度的值表示在一个方法里面所有可能路径的最小数目，简单的说就是为了覆盖所有路径，所需要执行单元测试数量，圈复杂度大说明程序代码可能质量低且难于测试和维护。
• lines: 行覆盖率，只要本行有一条指令被执行，则本行则被标记为被执行。
• methods: 方法覆盖率，任何非抽象的方法，只要有一条指令被执行，则该方法被计为被执行。
• classes: 类覆盖率，所有类，包括接口，只要其中有一个方法被执行，则标记为被执行（构造函数和静态初始化块也算作方法）。

点进去某个被检测的项目 -> 包 -> 类，可以看到代码中具体哪个方法、哪一行没有覆盖：

在最左边可以看到有不同颜色（红、黄、绿）的小钻石，每行代码还可能有不同颜色（红、黄、绿）的背景。

其中钻石代表分支覆盖情况：

• 红色钻石：当前行所有的分支都没有被覆盖

• 黄色钻石：当前行只有部分分支被覆盖（鼠标放上去可以查看详情）

• 绿色钻石：当前行所有分支都被覆盖

背景代表指令覆盖情况：

• 红色背景：当前行没有任何指令被执行

• 黄色背景：当前行只有部分指令被执行，这里解释下

• 绿色背景：当前行所有指令都被执行

通过单元测试覆盖率，能够清晰地了解到某个类、某个方法、某行代码、某个分支等是否被覆盖，从而能够促使开发人员更高效地完善单元测试。

那单元测试覆盖率达到多少才算合理呢？答案是并没有明确的要求，70%-80%的覆盖率已经足够优秀，能够有效发现和避免大多数问题。不需要一味追求100%的覆盖率。

然而，部分公司团队可能是为了保证代码的严谨性，或者是“领导要求”，对单元测试覆盖率要求很高（甚至要求达到100%），这种做法看似合理，但实际上并不可取，原因有：

• 边际效应递减：在覆盖率达到一定水平后，继续增加覆盖率的边际效应会递减。换句话说，达到80%的覆盖率和达到100%的覆盖率所付出的努力和资源差别巨大，而带来的质量提升却有限。

• 实际价值有限：为了达到100%的覆盖率，开发人员可能会编写大量低质量、仅为了覆盖率的测试。这些测试不仅无法提高代码质量，还可能增加维护负担，降低开发效率。

• 时间和成本：编写和维护高覆盖率的单元测试需要大量的时间和成本。在实际项目中，需要权衡项目进度和代码质量，合理分配资源，而不是一味追求高覆盖率。

最后：单元测试覆盖率只能代表你测试过哪些代码，不能代表你是否测试好这些代码！不能盲目追求代码覆盖率，而应该想办法设计更有效的案单测用例！

---

转载请注明出处