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
深入 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-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
深入 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-01-19
线程安全与锁优化
版本说明：本文主要基于 JDK 6 ~ JDK 14 的 HotSpot 虚拟机实现。需要注意的是，从 JDK 15 开始，偏向锁已被默认关闭并标记为废弃（JEP 374）。如果你使用的是 JDK 15+，文中关于偏向锁的内容仅作为历史参考。 线程安全 什么是线程安全 “当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象就是线程安全的。” 相对的线程安全，可以分成五个等级。但在深入讨论线程安全的分类之前，我们需要先理解 Java 内存模型——它是理解线程安全问题的理论基础。 Java 内存模型基础 Java 内存模型（Java Memory Model，JMM）是 Java 语言规范的一部分，定义了多线程程序中共享变量的访问规则。理解 JMM 是理解线程安全问题的基础。 为什么需要内存模型？ 现代计算机系统中，CPU 与主内存之间存在巨大的速度差异。为了弥补这一差距，硬件层面引入了多级缓存（L1、L2、L3 Cache）。这带来了一个问...
2026-05-21
回到工程：计算理论怎样改变写代码的眼光
这个系列从《计算的本质》重新出发，用 Python 重写核心实验，再把每个模型映射到 Java 程序员熟悉的工程结构。一路走下来，主题并不是记住更多术语，而是换一种方式观察程序。 程序可以是语法树，执行可以是规约，协议可以是自动机，嵌套可以靠栈，通用计算可以由解释器承载，分析工具也可以承认不精确并保持有用。 本文不再引入新模型，只把前面十几篇文章收束成一张工程地图。 概念地图 先把系列里最重要的模型压成一段可运行的概念地图。 12345678910concept_map = [ ("AST / 语义", "解释器、DSL、规则执行"), ("DFA / NFA / 正则", "协议状态、校验器、词法分析"), ("PDA / 栈", "parser、嵌套结构、调用栈"), ("图灵机 / 通用性", "VM、脚本引擎、程序作为数据"), ("停机问题 / 抽象解释", &...
