JUnit+HSQLDB+JPA+Cobertura：DAO测试覆盖率实践

1. 先把这套组合的分工捋清楚一个数据访问层的测试要想跑得起来光有 JUnit 是不够的。你至少还要三样东西一个能装下你实体关系的数据库、一层能把实体映射成 SQL 的持久化实现、一套能量出“我到底测了多少”的度量工具。Cobertura、JUnit、HSQLDB、JPA 这四个词凑在一起说的就是这件事用 JUnit 写用例用 HSQLDB 在内存里撑起一个真数据库用 JPA 走真实的 ORM 映射路径最后用 Cobertura 把行覆盖和分支覆盖统计出来。听起来像流水线实际上每个环节都有坑而且坑的位置很固定基本集中在依赖版本、方言配置和覆盖率数字的解读上。我在几个中型后台系统上反复用过这套组合最有价值的经验不是“怎么让它跑起来”而是“跑起来之后那个数字能不能信”。很多团队把覆盖率做到 85% 就开始庆祝结果上线第一个 SQL 语法问题就把服务打挂了原因是内存库和线上库的方言差异根本没被测到。所以这篇文章不讲虚的从工程骨架、依赖配置、实体设计一路讲到报告解读和排查表你可以直接照着改自己的 pom 和测试类。1.1 四个组件各管一段别互相越界先把角色划清楚后面出问题才好定位。JUnit 负责“执行和断言”它只管把方法跑一遍、把结果比一比不关心数据库是不是真的存在HSQLDB 负责“提供一个真实的关系型数据库”它是纯 Java 实现的可以完全跑在 JVM 内存里进程一退数据就没了JPA 负责“把对象变成 SQL”通过EntityManager完成持久化、查询、级联这些动作Cobertura 负责“数数”它在类加载的时候对字节码做插桩记录哪些行被执行过、哪些判断分支走过。这四者的边界一旦模糊测试就会失真。我见过最常见的越界是拿 Mock 替掉EntityManager然后用 JUnit 断言“我调用了 persist 方法一次”。这种测试跑得飞快覆盖率也漂亮但它验证的是“你有没有写这行代码”而不是“这行代码发出去的 SQL 数据库认不认”。Cobertura 在这类测试里给出的高覆盖率具有很强的误导性因为它数的是执行痕迹不是正确性。如果一个测试里出现了mock(EntityManager.class)那它测的就不是持久化层而是调用编排。这类测试可以留但不能拿它来撑 DAO 的覆盖率。1.2 为什么数据访问层测试要用内存库连真实数据库跑测试当然最真实问题是你得有人在 CI 上维护一个数据库实例、每次构建前清库、处理并发构建之间的数据污染。HSQLDB 的内存模式把这些问题一次性抹掉了连接串里写jdbc:hsqldb:mem:testdb第一个连接建立时库就存在最后一个连接关闭时库就消失构建之间天然隔离。代价是它和线上库不完全一样。方言差异会体现在几个具体位置标识符大小写、保留字、LIMIT语法、函数名、日期类型精度、NULL排序规则。HSQLDB 默认把未加引号的标识符转成大写而不少线上库是大小写不敏感或者保留小写这就导致某些手写 SQL 在测试里过、上线炸。我的做法是JPA 生成的 SQL 交给内存库验手写原生 SQL 必须另有一组连真实库的集成测试做兜底两套测试分属不同 profile不混在一起跑。内存库的另一个好处是速度快。一个实体关系稍微复杂点的项目几十个 DAO 测试全跑完通常在两三秒量级这个反馈速度决定了你愿不愿意在改完一行代码之后立刻跑一遍。1.3 Cobertura 与 JaCoCo 的取舍我为什么还在用它必须说实话Cobertura 是个老工具最后一个正式版本停在 2.1.1 / 插件 2.7对高版本 JDK 的字节码支持很勉强遇到 lambda、invokedynamic会插桩失败报Expecting a stackmap frame at branch target之类的错误。新项目我一般直接用 JaCoCo它是基于 Java Agent 的对现代字节码友好报告也更细。但很多存量工程因为构建链路、报告模板、历史阈值已经绑死短期内换不动。这时候掌握 Cobertura 的脾气就很有必要它插桩是“改写 class 文件再放回 target/classes”所以任何在插桩之后还去动字节码的插件比如某些 ORM 的编译期增强、某些 AOP 织入都可能和它打架。反过来JaCoCo 在运行时挂 agent不碰磁盘上的 class冲突概率低得多。对比项CoberturaJaCoCo插桩方式离线改写 class 文件运行时 Java Agent对 lambda 支持差常见插桩异常好报告粒度行、分支、类、包行、分支、圈复杂度、方法与字节码增强共存容易冲突相对安全阈值校验checkgoalcheckgoal适合场景老工程、已有阈值体系新工程、JDK 8 以上结论很简单如果你现在还要用 Cobertura就把 JDK 版本压到它能接受的范围8 及以下且避开复杂 lambda 的类并把被插桩的范围收窄如果可以选择新项目别犹豫上 JaCoCo。下文的所有配置都以 Cobertura 为主线同时在必要处标注两者的差异。2. 工程骨架与依赖配置一次配好后面省心配置这一步最省时间的做法是先把版本对齐再谈功能。JPA 是一套规范必须有一个实现常见的是 HibernateHSQLDB 2.7 及以上要求 JDBC 驱动类写成org.hsqldb.jdbc.JDBCDriver老的org.hsqldb.jdbcDriver已经废弃JUnit 4 和 JUnit 5 的测试类导入包名完全不同混着写会得到一个“测试类跑零个用例”的诡异结果Cobertura 插件 2.7 依赖的是一套老 API和 Surefire 的某些版本组合时会出现报告生成成功但.ser文件为空的状况。我的经验是一个专门用于测试的 Maven profile把内存库、JPA 实现、测试框架、覆盖率插件全部圈进去scope 一律test插件只在 profile 激活时生效。这样主构建不会因为覆盖率工具拖慢测试 profile 里又能一次跑全。2.1 Maven 依赖清单与版本坑位下面这份依赖清单在多个项目上验证过可以直接抄。注意hibernate-entitymanager在 Hibernate 5.2 之后被合并进hibernate-core如果你是 5.4 及以上只引hibernate-core就够了多引一个会引入冲突的javax.persistence版本。dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.13.2/version scopetest/scope /dependency dependency groupIdorg.hsqldb/groupId artifactIdhsqldb/artifactId version2.7.2/version scopetest/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate-core/artifactId version5.6.15.Final/version scopetest/scope /dependency dependency groupIdjavax.persistence/groupId artifactIdjavax.persistence-api/artifactId version2.2/version scopetest/scope /dependency /dependencies版本坑位有三个值得单独说。第一hibernate-core的版本必须和你的 JPA API 版本匹配5.6 系列对应 JPA 2.2如果你在代码里用了jakarta.persistence的包名那就要换 6.x 系列混用会得到NoClassDefFoundError: javax/persistence/EntityManager。第二HSQLDB 2.7 的 JDBC 驱动类是org.hsqldb.jdbc.JDBCDriver写老类名不会报编译错误只会在运行时报ClassNotFoundException。第三hsqldb的 scope 一定要给test否则会顺着传递依赖漏到生产包里到时候线上启动报驱动冲突排查起来非常费劲。2.2 persistence.xml 里最关键的五行persistence.xml放在src/test/resources/META-INF/下和生产环境的配置完全隔离。整个文件里真正决定测试能不能跑通的就是五个属性驱动类、连接串、方言、建表策略、SQL 打印开关。前四个是必须的第五个是排错时救命用的。persistence xmlnshttp://xmlns.jcp.org/xml/ns/persistence version2.2 persistence-unit nametestPU transaction-typeRESOURCE_LOCAL providerorg.hibernate.jpa.HibernatePersistenceProvider/provider classcom.example.domain.Order/class classcom.example.domain.OrderItem/class exclude-unlisted-classestrue/exclude-unlisted-classes properties property namejavax.persistence.jdbc.driver valueorg.hsqldb.jdbc.JDBCDriver/ property namejavax.persistence.jdbc.url valuejdbc:hsqldb:mem:testdb;sql.syntax_mystrue;hsqldb.default_table_typecached/ property namejavax.persistence.jdbc.user valueSA/ property namejavax.persistence.jdbc.password value/ property namehibernate.dialect valueorg.hibernate.dialect.HSQLDialect/ property namehibernate.hbm2ddl.auto valuecreate-drop/ property namehibernate.show_sql valuetrue/ property namehibernate.format_sql valuetrue/ /properties /persistence-unit /persistence连接串里的sql.syntax_mystrue是个实用开关它让 HSQLDB 兼容一部分 MySQL 语法比如LIMIT的位置、反引号标识符如果你线上是 MySQL加了这个参数能少一批“测试过、线上挂”的方言问题。hsqldb.default_table_typecached让表数据走磁盘缓存模式而不是纯内存模式对略微大数据量的测试更稳代价是稍微慢一点点。exclude-unlisted-classes设成true是一种防御避免 HSQLDB 扫到依赖包里带的实体类然后建出一堆莫名其妙的表。2.3 Cobertura 插件的绑定方式与阈值设置插件配置的重点不在“生成报告”而在“卡阈值”和“排除不该统计的类”。前者让覆盖率变成一个能失败的构建步骤后者决定你的数字是真实还是注水。JPA 项目里一定要排除三类东西生成的静态元模型类命名通常是实体名加下划线、测试类本身、以及criteria相关的 API 生成物。plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.7/version configuration formats formathtml/format formatxml/format /formats instrumentation excludes exclude**/*_.class/exclude exclude**/*Test.class/exclude exclude**/*DTO.class/exclude /excludes ignores ignorecom/example/domain/.*/ignore /ignores /instrumentation check haltOnFailuretrue/haltOnFailure lineRate80/lineRate branchRate60/branchRate totalLineRate80/totalLineRate totalBranchRate60/totalBranchRate /check /configuration executions execution idcoverage-check/id phaseverify/phase goalsgoalcheck/goal/goals /execution /executions /pluginexcludes和ignores的区别很关键excludes是“根本不插桩”ignores是“插桩了但报告里不算”。实体类我一般放进ignores因为它们会被 JPA 增强插桩容易出问题纯数据载体和元模型类放进excludes不给它们浪费任何时间。haltOnFailure设成true意味着构建会真的因为覆盖率不达标而失败。这在团队刚开始推行时会引起抵触所以我建议第一周先设成false观察数据摸清基线之后再打开——一上来就卡太死大家的反应是把测试写成空方法骗过阈值那就彻底跑偏了。3. 实体与 DAO 的写法决定了覆盖率的天花板很多人以为覆盖率是测试写出来的其实从你定义实体的那一刻起能覆盖到的比例上限就基本定了。一个字段命名撞上保留字的实体你连一条插入语句都跑不通后面所有测试全部瘫痪一个用了Lob加Basic(fetchLAZY)的字段在 HSQLDB 上拿到的可能是代理对象断言时直接抛异常。这些问题不是测试技巧能解决的只能靠实体设计阶段的预判。3.1 实体设计里那些“看着没事、跑起来报错”的地方最典型的是保留字。HSQLDB 2.x 的保留字表比 MySQL 长不少YEAR、MONTH、DAY、VALUE、SIZE、POSITION、START、END、TYPE、COMMENT、KEY这几个都在里面。我踩过一次一个叫Plan的实体有个字段叫year在本地 MySQL 上随便跑换到 HSQLDB 直接unexpected token: YEAR整张表建不出来那个模块的覆盖率直接掉到 0。处理方式有两种要么在字段上显式指定列名比如Column(name plan_year)要么在persistence.xml里配hibernate.globally_quoted_identifierstrue让所有标识符都带引号。我更推荐前者因为它不依赖全局开关语义也更清楚后者虽然省事但会让所有生成的 SQL 都带引号日志看起来相当累。第二个高频问题是列类型映射。String不指定length时 Hibernate 默认映射成varchar(255)如果你在测试里塞了一个 300 字符的字符串HSQLDB 会直接报data exception: string data, right truncation而某些线上库在非严格模式下会静默截断。这个差异其实是好事内存库帮你提前发现了隐患所以别去改数据库参数绕过它老老实实把length补上。第三个是布尔和枚举。HSQLDB 对Boolean支持良好但枚举如果用的是Enumerated(EnumType.ORDINAL)并且枚举常量在后续版本里插了新的值历史数据会错位。测试里我一般要求至少有一条用例覆盖“存进去再取出来比对”的路径避免只测写入不测读取。3.2 DAO 中最容易被漏掉的分支分支覆盖率往上做不动九成情况卡在这四个地方null参数校验、查询结果为空、乐观锁冲突、批量操作的空集合。这四类分支在业务代码里通常各占三五行if但一次都没被执行过于是分支覆盖率被这些“小坑”拖住。从下面这个典型的 DAO 方法就能看出问题public ListOrder findByCustomer(String customerId, OrderStatus status) { if (customerId null || customerId.trim().isEmpty()) { throw new IllegalArgumentException(customerId required); } StringBuilder jpql new StringBuilder(select o from Order o where o.customerId :cid); if (status ! null) { jpql.append( and o.status :status); } TypedQueryOrder query em.createQuery(jpql.toString(), Order.class) .setParameter(cid, customerId); if (status ! null) { query.setParameter(status, status); } return query.getResultList(); }这一段有四个分支customerId为 null、customerId为空白、status为 null、status非 null。大部分人的测试只写了“正常查询返回结果”一条四个分支全没走全。补齐的写法是四条用例分别对应空参数抛异常、空白字符串抛异常、只按客户查、按客户加状态查。四条用例加起来不到五十行分支覆盖率立刻上一个台阶。判断一个 DAO 的测试是否合格的快速方法把方法里所有的if、、||、三元表达式标出来逐个问自己“这个条件为真和为假的时候分别哪条用例走到了”。答不上来的就是缺口。3.3 建表策略create-drop 还是脚本初始化hbm2ddl.auto的取值里create-drop是测试环境最省事的选择每个EntityManagerFactory建立时建表关闭时删表。它的好处是永远从干净状态开始不用担心上一次测试留下的脏数据坏处是每次建 EMF 都要跑一遍 DDL如果你的测试类有几十个每个类建一次 EMF累计开销不小。我的做法是把EntityManagerFactory提到类级别用BeforeClass建、AfterClass关配合create-drop实现“一个测试类一个干净的库”。测试方法之间靠事务回滚隔离不依赖删表。这样既能保证干净又不会因为频繁建表拖慢速度。有些团队选择手工维护一份schema.sql理由是“能验证和生产的建表脚本一致”。这个理由在需要严格校验 DDL 的场景下成立但它把维护成本转了回来实体一改就要同步改脚本忘了改就是一堆测试报错。我的看法是单元级测试用create-drop专门的 DDL 一致性校验单独做一个集成测试任务两者别混。4. 测试用例怎么写才算“有效覆盖”覆盖率工具只能证明代码被执行过证明不了行为正确。要让那 80% 的行覆盖率真的有意义测试用例的结构必须守住两条底线一是每个测试方法自己负责准备数据和清理现场二是断言必须落到数据状态上而不是只断言“没抛异常”。这两条听起来是常识但在我 review 过的代码里违反率超过一半。4.1 一个测试类只建一次 EntityManagerFactoryEntityManagerFactory是个重对象内部有连接池、二级缓存、元模型构造成本远高于EntityManager。如果你在每个Before里都建一次一套 DAO 测试跑下来可能从三秒变成三分钟速度一慢开发者就不跑了覆盖率也就没人维护了。正确的结构是这样public class OrderDaoTest { private static EntityManagerFactory emf; private EntityManager em; private EntityTransaction tx; BeforeClass public static void initFactory() { emf Persistence.createEntityManagerFactory(testPU); } AfterClass public static void closeFactory() { if (emf ! null) emf.close(); } Before public void beginTx() { em emf.createEntityManager(); tx em.getTransaction(); tx.begin(); } After public void rollbackTx() { if (tx.isActive()) tx.rollback(); em.close(); } }这段样板代码值得单独抽成一个基类所有 DAO 测试继承它省掉重复。注意After里先判断tx.isActive()再回滚因为有的用例会主动提交事务来验证写入这时候回滚会抛IllegalStateException把真正的问题掩盖掉。4.2 事务边界与回滚数据不落地的关键JPA 的RESOURCE_LOCAL模式下所有写操作必须在事务内进行没有事务的persist会被直接忽略注意是静默忽略不报错。我见过有人的测试“插入成功但查不到”排查了两小时最后发现是漏了tx.begin()。这种错误在覆盖率报告上表现为“persist那行是绿的”工具认为它执行了但业务上什么也没发生。事务回滚是测试隔离的核心机制。每个测试方法开一个事务方法结束时回滚数据库回到方法执行前的状态。这样测试方法之间的执行顺序就无关紧要了任意单跑、全跑、乱序跑结果都一样。有一个边界情况需要留意如果你在同一个测试方法里既调用em.flush()又调用em.clear()再查询时会重新从数据库拉数据这时能看到自己未提交的写入同一个事务内可见。这个特性很有用它让你可以验证“写进去的东西真的能被查出来”而不是只验证了一级缓存。但如果你的用例里出现了跨EntityManager的验证比如开第二个 EM 去查那就会因为事务未提交而查不到这时候必须显式提交。4.3 测试数据构造与断言写法数据构造的写法直接影响测试的可读性和维护成本。我的偏好是一个简单的构造器类把实体的必填字段一次性配好用例里只改自己关心的那几个字段Order order anOrder() .withCustomerId(C-1001) .withStatus(OrderStatus.PAID) .withAmount(new BigDecimal(199.00)) .build(); em.persist(order); em.flush(); em.clear(); ListOrder found dao.findByCustomer(C-1001, OrderStatus.PAID); assertEquals(1, found.size()); assertEquals(new BigDecimal(199.00), found.get(0).getAmount()); assertNotNull(found.get(0).getId());flush()加clear()这个组合是重点。不加flush()SQL 可能延迟到事务提交才发出内存库那边的约束校验就不会触发不加clear()查询会命中一级缓存你测的是缓存而不是 SQL。这两个动作做完你的测试才真的经过了一次“写库—读库”的完整往返。断言部分金额字段一定要用BigDecimal的compareTo或者assertEquals比较注意BigDecimal的equals会比较 scale199.00和199不相等这是最常见的断言失败原因之一。时间字段如果用的是Date精度会被数据库截断直接用assertEquals比较原对象几乎必然失败要么改用Instant加容差比较要么只断言非空。5. 跑覆盖率报告完整实操流程配置写完执行就一条命令的事但顺序搞错就会得到空报告或旧数据。Cobertura 的机制是“先插桩、再跑测试、最后出报告”它的cobertura:coberturagoal 会自动串起这三步所以不要单独跑mvn test那样不会产生.ser文件。5.1 命令、执行顺序与产物位置标准命令是mvn clean cobertura:cobertura -Ptest其中 profile 负责激活测试依赖。加clean不是为了洁癖而是因为插桩会改写target/classes下的 class 文件残留的旧产物会让报告混进上一轮的数据出现“代码早就删了但报告里还有这个类”的怪现象。执行完之后看三个位置产物路径用途HTML 报告target/site/cobertura/index.html人工翻阅看具体哪行没覆盖XML 报告target/site/cobertura/coverage.xml接入持续集成平台或做二次统计插桩数据target/cobertura/cobertura.ser增量合并的基础文件cobertura.ser这个文件值得单独说。它保存了所有命中记录如果你做的是增量插桩比如只对改动过的模块插桩就要靠它和历史数据合并。合并命令是mvn cobertura:cobertura -Dcobertura.serFilexxx.ser但实际使用中合并容易出错大部分团队还是选择全量跑简单可靠。另外提一句如果你的项目在 JDK 9 及以上跑 Cobertura 报插桩异常先别急着换工具可以试试-Dcobertura.jarExcludes把可疑的类排除掉或者把测试任务改到 JDK 8 上执行。这些是权宜之计长期还是要迁到新工具。5.2 报告怎么读行覆盖、分支覆盖和“假高覆盖”点开 HTML 报告先看包级汇总再看类级最后看行级。行级的颜色很有信息量绿色是执行过、红色是一行没执行、黄色是部分分支执行比如只有if的 true 分支走过。真正有诊断价值的是黄色因为它直接指向“条件没测全”。我判断一份报告可信不可信看三个信号。第一分支覆盖率是不是显著低于行覆盖率。如果行覆盖 90%、分支覆盖只有 40%说明测试全是“一条直线走到底”所有判断都只走了一个方向这种测试遇到边界数据基本没有抵抗力。第二catch块是不是大片红色。异常路径不测等于把最容易出问题的地方留空。第三实体类的 getter/setter 有没有被大量覆盖。如果它们贡献了很大比例的行数把这些行剔除之后你的真实覆盖率可能要打个八折。“假高覆盖”这个坑值得专门提一下。有几种情况会让数字虚高一是测试方法里断言极少只要不抛异常就算过二是大量使用try { ... } catch (Exception e) { }把异常吞掉测试永远是绿的三是测试调用了工具类方法而工具类方法内部又调用了一大堆业务代码于是这些业务代码全被算成“被覆盖”。第二种最危险我现在的做法是禁止测试代码里出现空的catch块要捕获就断言异常类型和消息。5.3 把阈值卡进 CIhaltOnFailure 的用法覆盖率只有变成“能让构建失败的门槛”才有约束力。配置里已经写了haltOnFailure和几个lineRate/branchRate需要注意三组阈值的区别lineRate是当前这次插桩的整体行覆盖率totalLineRate是合并历史数据后的总覆盖率packageLineRate是针对每个包的。CI 上我一般用lineRatepackageLineRate前者管全局后者防止某个包被整体放养。阈值定多少合适没有统一答案但我有一个判断方法先让团队在不设阈值的情况下跑两周看折线图的稳定区间然后把阈值定在稳定区间的下沿低两三个百分点。这样它既能拦住明显倒退又不会因为正常的重构波动误伤。另外checkgoal 失败时的报错信息不太友好只会告诉你哪个包不达标具体哪一行没覆盖还是得去看 HTML 报告所以建议在 CI 脚本里把报告路径打印出来省得大家每次都要翻日志。6. 踩坑实录与排查速查表前面几节讲的是“怎么搭”这一节讲“搭好之后会怎么坏”。下面这些故障都是我在实际项目里遇到过的按出现频率排序现象和原因一一对应遇到问题直接查表。6.1 十个真实故障的现象与处理现象根因处理方式测试类跑了但报告里没有任何数据只跑了mvn test没触发插桩改用mvn cobertura:cobertura插桩报Expecting a stackmap frameJDK 版本过高Cobertura 不识别新字节码降 JDK 到 8或迁 JaCoCounexpected token: YEAR建表失败字段名撞 HSQLDB 保留字显式指定列名或开全局引号string data, right truncation字段长度超varchar定义补Column(length...)别改库参数persist无效果、查不到数据忘了tx.begin()检查事务是否开启查出来的对象是旧值查询命中一级缓存查询前em.flush(); em.clear();驱动类找不到用了废弃的org.hsqldb.jdbcDriver改成org.hsqldb.jdbc.JDBCDriver覆盖率忽高忽低残留下target/classes旧产物每次构建前clean分支覆盖率明显低于行覆盖率只测正常路径按if//实体类覆盖率虚增指标getter/setter 被算进行数在ignores里排除实体包表格里“实体类虚增指标”这条我特别想展开说。一个典型的业务实体有十几个字段自动生成的 getter/setter 就有三十来行如果测试里因为比较对象而调用了这些方法它们全部变成绿色。项目里实体一多这部分贡献的行数可能占整体的两到三成直接让你的 80% 看起来像 80%实际业务代码的覆盖率可能只有 55%。所以我的默认配置永远把com/example/domain/.*放进ignores让报告只反映逻辑代码。还有一个比较隐蔽的问题测试顺序依赖。表面上每个测试方法都回滚了事务但如果你的测试用了静态变量缓存数据或者用了BeforeClass里插入的共享数据又被某个测试改了就会出现“单跑通过、全跑失败”。判断方法很简单把测试方法按名字倒序跑一遍Surefire 支持runOrderreversealphabetical如果失败了就是顺序依赖。修法是所有测试数据的创建都放在Before里BeforeClass只放 EMF 这种无状态的东西。6.2 提升覆盖率的几个笨办法覆盖率上不去的时候靠“写更多测试”这种口号是没用的需要具体的动作。我常用的有三个。第一个动作是从红色行反向写用例。打开报告找最红的那个类逐行看哪些行没被执行然后问“什么输入能走到这一行”。这个方法最直接也最容易出成果通常一两个小时能把一个中等大小的 DAO 从 50% 拉到 75%。缺点是它容易写成“为了覆盖而覆盖”的测试所以要配合断言检查每一行补的测试至少要有一个有意义的断言。第二个动作是给每个 public 方法列出输入矩阵。比如查询方法一般有“参数有效 / 参数为 null / 参数为空串 / 结果为空 / 结果多条”五种情况把这五种列成表缺哪个补哪个。这个方法能系统性地把分支覆盖率拉起来比随机补测试靠谱得多。第三个动作是把异常路径当正常路径写。大部分人的测试只覆盖 happy path而业务代码里最容易出错、也最需要验证的恰恰是约束冲突、唯一键重复、乐观锁失败这些异常分支。写法上用Test(expected PersistenceException.class)或者 JUnit 4.13 的assertThrows注意断言具体的异常类型而不是Exception否则这个断言等于没写。6.3 我在实际项目里的几条经验第一别把覆盖率当成目标当成体检指标。要求“必须 80%”会催生一堆没有断言的形式测试而要求“新增代码覆盖率不低于 70%”就合理得多因为它的约束对象是改动不是存量。存量代码的覆盖率低有很多历史原因逼着人一次性补齐产出的多半是垃圾测试。第二测试失败信息要能自解释。断言里不要写assertEquals(1, list.size())要写assertEquals(按客户号应查到 1 条订单, 1, list.size())。半年后回来看失败日志的人可能就是你自己多写一句描述能省很多时间。这个习惯在小团队里传播得很快一旦有人开始这么写其他人会跟着学。第三内存库的方言配置要和线上对齐到“能让测试失败”的程度。我的原则是如果某个差异会导致线上出问题测试环境就要模拟出这个差异哪怕这意味着测试更麻烦。比如线上是严格模式测试环境就不要开宽松选项线上标识符大小写敏感测试环境也不要用不敏感的配置把问题掩盖掉。测试环境的价值在于提前暴露问题而不是让所有测试都变绿。第四DAO 层的测试不要追求“一个方法一个测试”的对称美学。真实情况是一个方法可能需要三四条用例另一个方法一条就够。按分支数量而不是方法数量来分配测试精力才花在刀刃上。最后分享一个我在排查覆盖率异常时的小习惯把coverage.xml用脚本解析一遍按“未覆盖行数”倒序排取前二十个类。这二十个类通常就是整个项目的风险集中区比看那些百分比数字有用得多。这个脚本不到三十行用任何脚本语言都能写值得花半小时做一个。