JUnit4/JUnit5 注解
| junit4 | junit5 | 特点 |
|---|---|---|
| @BeforeClass | @BeforeAll | 在当前类的所有测试方法之前执行。注解在【静态方法】上。 |
| @AfterClass | @AfterAll | 在当前类中的所有测试方法之后执行。注解在【静态方法】上。 |
| @Before | @BeforeEach | 在每个测试方法之前执行。注解在【非静态方法】上。 |
| @After | @AfterEach | 在每个测试方法之后执行。注解在【非静态方法】上。 |
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-07-14
为什么叫"测试夹具"：Fixture 的词源与跨领域漫游
测试夹具这个中文词带着工业感，让第一次听到它的开发者往往去搜索"是不是翻译错了"。词源确实如此：fixture 来自机械加工，后来进入电子测试领域，再由 Kent Beck 引入软件测试框架里。这个词在软件工程里覆盖的范围，也远比"单元测试"要宽。 从车间到代码 fixture 这个词在机械加工里有精确含义：在 CNC 车床或焊接台上，fixture 是一种工装，把工件固定在已知位置，让每次加工操作都从相同的起点开始。与 jig（引导刀具路径的夹具）不同，fixture 的职责只有一件事——把工件钳牢，消除定位误差。 词源上，fixture 来自拉丁语 figere（刺入、固定），经 fixura（固定物）演变为英语词汇，约在 16 世纪末进入法律语言，最初指"永久附着于不动产的动产"——嵌入墙体的管道、固定在地板上的书架，那些不能随意拆走的东西。 电子测试领域用法相似：一块 PCB 插入测试夹具后被固定在已知电气状态，探针才能重复施加相同的激励、在相同节点读取信号，排除接触不稳定的干扰。 三种用法的共同语义：将某个对象...
2026-10-04
深入 Play 29：同一用例在单元、路由与真实 HTTP 中证明什么
金额 1、100 被接受，0、101 被拒绝。这组输入分别通过纯 Java 策略、Helpers.route 和独立进程 HTTP。三个层次都有价值，但相同的结果并不让它们拥有相同覆盖：纯函数没有解析 JSON，路由测试没有经过真实 TCP，网络测试也没有自动变成数据库事务测试。 分层验收需要把每条成功结论限定在它真正经过的边界。一次测试通过，只能覆盖已经执行并断言的行为。 从纯业务规则开始固定输入 ObjectPolicy.amountAllowed 是有限业务规则：amount 大于零且不超过 100。它不依赖请求、Cookie、线程或数据库。纯单元层使用相同四个输入，直接断言 boolean，失败时可以先定位规则或期望，而不必同时排查路由、Content-Type 和服务器启动。 HTTP Controller 还要处理 JSON 形状：字段存在、是整数、能转换为 int，之后才调用金额规则。业务函数能够接受 int，并不证明任意 JSON 数值都能安全进入这个范围。因此应用路由层和 HTTP 层需要补充非法 JSON、错误类型和缺字段等边界；本批实际执行的 parser...
2026-10-04
Java常用类库-35-用JUnit与AssertJ验证调用方责任
测试通过之前，先确认它能够失败 目录服务承诺返回商品列表快照。正常实现调用 ImmutableList.copyOf，测试检查列表包含 A。后来实现被改成直接返回输入列表，测试仍然通过，因为它从未修改原集合，也没有观察快照在源变化之后的内容。 测试执行成功只证明已有断言满足，不证明承诺已经覆盖。这个例子缺少的不是更多测试框架，而是能够区分快照与别名的输入动作：返回之后修改源列表，再检查结果是否变化。 本篇固定 JUnit Jupiter 5.13.4、AssertJ 3.27.6、Mockito 5.20.0。基础测试使用真实 Guava 与 Commons，在 JDK 8、21 运行；外部边界测试只在 JDK 21 运行。运行说明包含正常与受控突变命令，突变失败日志单独保存。 真实资源契约的对照见 第 34 篇；本篇聚焦测试如何发现调用方自身的错误。 按契约组织输入，而不是按方法数量组织测试 基础矩阵覆盖 null、空串、普通空格和制表符。JUnit 的 NullAndEmptySource 与 ValueSource 提供四次参数化调用，每次都调用真实 StringUtils...
2026-10-04
深入 Spring 41：测试边界与提交回调的盲区
订单测试通过，提交后的通知仍然失败 订单方法在事务中插入数据，并注册一个 afterCommit 回调。测试调用该方法，检查插入成功，最后由 Spring Test 自动回滚。整组测试通过，但真实 HTTP 请求一提交就抛异常。这两个结果可以同时成立：测试从未走过提交路径，回调里的错误也从未执行。 测试的价值取决于实际经过的边界。纯函数断言证明金额规则；MockMvc 证明参数绑定和异常到响应的映射；真实服务器加独立数据库连接证明请求线程完成了提交。把三类结果都写成“订单接口测试通过”，会丢掉最需要保留的条件。 实验固定 Spring Framework 6.2.11、Spring Boot 3.5.6、JDK 21 和 PostgreSQL 18.0。Boot BOM 管理本模块依赖，数据库使用独立 spring_final schema。JUnit 实际执行 8 个测试方法，产生 15 条具名断言，没有将手写演示输出当作 JUnit 报告。依赖清单、XML 报告与原始输出随实验工程保留。 从同一个金额错误区分三种证明 业务规则 Store.validate(amount) ...
2026-09-07
从零构建现代搜索引擎（19）：用 HNSW 加速近邻搜索
上一篇用精确扫描完成了向量检索的基线。精确扫描遍历所有向量计算点积，结果是精确的，但复杂度 O(N×D) 不可扩展。1 万个 chunk 只需 5 毫秒，10 万就要 50 毫秒，100 万要半秒——远超搜索服务的延迟预算。 本篇引入 HNSW（Hierarchical Navigable Small World），一种基于图的近似最近邻算法。Lucene 10.x 内置 HNSW 实现，可以直接通过 KnnFloatVectorField 使用。 为什么需要近似搜索 精确最近邻搜索保证找到真正最近的 K 个向量，但时间复杂度是线性的。搜索服务的延迟预算通常在 50 毫秒以内（整个搜索流程，不只是向量检索），线性扫描在大规模数据上无法满足。 近似最近邻（ANN）牺牲少量精度换取数量级的速度提升。具体来说：精确 Top-10 中的某些结果可能在 ANN 的 Top-10 中排到了第 11 或第 12——被遗漏了。但 ANN 返回的 Top-10 中 95% 以上是正确的，搜索质量几乎无损。 HNSW 的分层图结构 灵感来源：跳表 回忆第 11 篇的跳表：底层是完整链表，上层是稀疏...
2026-09-06
从零构建现代搜索引擎（06）：中文、英文和代码怎样变成词项
前五篇完成了文档的采集、导入和评测基线。文档以纯文本的形式进入系统，但搜索是以词为单位进行的——查询 “Java 内存模型” 需要把这五个字拆成能和索引匹配的词项。英文有空格做天然分隔，中文没有；版本号 3.14.1 不应该在小数点处断开；NullPointerException 既需要保留完整形式也需要拆成子词。 本篇设计一个分析器（Analyzer），将原始文本转换为可索引的词项流，记录每个词项的位置和偏移量。 分析器的三阶段模型 文本分析拆成三步： 1原始文本 → Tokenizer → Token Filter → 词项流（Term Stream） Tokenizer 把连续文本切成一个个 token。Token Filter 对 token 做后处理：小写化、停用词移除、同义词展开。每个 token 携带四项信息： 123456public record Token( String term, // 词项文本 int position, // 在词项流中的序号（0-based） int startOffset, // 在原始...
