企业官网建设流程全解析

• 测试

本指南以 junit-framework 仓库根目录 README.md 为骨架，面向希望从源码层面理解并上手 JUnit 的开发者，系统梳理 JUnit Platform、Jupiter、Vintage 三大技术栈的仓库布局、版本现状、从源码构建的完整流程，以及支撑这些组件的模块化工程与质量基础设施。读完本文，你将能够正确选择所需依赖坐标、独立完成本地构建与安装、读懂仓库内各模块的职责边界，并快速定位到可直接运行的示例代码。

仓库定位：JUnit Platform、Jupiter 与 Vintage 的统一代码库

本仓库是 JUnit 系列测试框架的官方代码库，同时承载了三个层次分明的技术栈：

• JUnit Platform：测试发现与执行的基础设施层，负责在 JVM 上启动测试框架，定义统一的引擎 SPI（org.junit.platform.engine）与 Launcher API，是构建在其上的任何测试引擎的运行底座；
• JUnit Jupiter：JUnit 5+ 风格测试的核心引擎与编程模型，提供@Test、@BeforeEach、@AfterEach、@ParameterizedTest等注解以及完整的断言与扩展 API，是绝大多数新项目的默认选择；
• JUnit Vintage：兼容层测试引擎，专门用于在 Platform 之上运行基于 JUnit 4 和junit.framework编写的旧测试，实现平滑迁移。

三者共用一套构建体系与发布节奏，任何关于"JUnit 6"的讨论，实际上都指向这三者的整体演进。

版本现状与发布节奏

README 明确给出了当前的版本状态（截至仓库当前内容）：

• 正式版（GA）：JUnit 6.1.3，发布于 2026 年 8 月 7 日；
• 预览版（Milestone/RC）：当前无（N/A）。

仓库自身的 gradle.properties 进一步印证了开发分支的状态：version = 6.2.0-SNAPSHOT，同时apiBaselineVersion = 6.1.3用于向后兼容性校验，说明主分支正处于 6.2.0 的快照开发阶段，并以 6.1.3 作为 API 兼容性基线。这意味着：

• 想使用稳定版本的开发者应选择 6.1.3 及之后的 GA 版本；
• 愿意尝鲜里程碑版或快照版的开发者，可以通过本地构建获得 6.2.0-SNAPSHOT 产物，并针对新功能向项目提交 issue。

文档生态：四条官方获取路径

README 将官方资料分为四类，仓库内均有对应源码：

• User Guide（用户指南）：完整的 AsciiDoc 源文件位于 documentation/modules/ROOT/pages，按 writing-tests（编写测试）、running-tests（运行测试）、extensions（扩展模型）、advanced-topics（进阶主题）等主题组织；
• Javadoc：本地静态版可在 documentation/src/javadoc/junit-overview.html 查看，各模块的 API 文档由 javadoc 构建任务生成；
• Release Notes（发布说明）：见 documentation/modules/ROOT/pages/release-notes.adoc 及 documentation/modules/ROOT/partials/release-notes 下按版本拆分的增量说明；
• Examples（示例）：官方推荐示例代码的 Java 版本就在仓库内 documentation/src/test/java/example，Kotlin 版本在 documentation/src/test/kotlin/example/kotlin，这些示例同时作为文档内嵌代码片段与可运行测试存在。

从源码构建：环境要求与三条核心命令

前置环境：JDK 25 与 Gradle Toolchains

README 明确要求构建 JUnit 需要JDK 25。构建系统通过 Gradle Toolchains 自动探测并（必要时）自动下载编译与测试所需的额外 JDK——这意味着即使本机主 JDK 版本不同，构建脚本也能自动选取合适版本，开发者无需手动切换。

实际使用的 Gradle 版本由 gradle/wrapper/gradle-wrapper.properties 锁定为Gradle 9.8.0（并校验了发行包 SHA-256），配合 gradle.properties 中开启的org.gradle.parallel、org.gradle.configuration-cache与org.gradle.isolated-projects等特性，大型多模块构建可以保持较快的反馈速度。

命令一：构建并测试全部模块

./gradlew build

该命令会构建并测试仓库中全部模块，包括 18 个对外发布的 Maven 制品与若干内部测试工程（详见下文"模块化结构"）。首次执行时 Gradle Wrapper 会自动下载对应发行版，之后各次构建可复用远端构建缓存加速。

命令二：安装到本地 Maven 仓库

./gradlew publishToMavenLocal

该命令将全部模块安装到本地 Maven 仓库，供其他本地项目直接依赖使用——这是在没有发布到中央仓库的 SNAPSHOT 版本参与本地联调时最常用的方式。

命令三：生成代码覆盖率报告

./gradlew clean jacocoRootReport

报告输出到build/reports/jacoco/jacocoRootReport/html/index.html，可在浏览器中查看各模块、各包的测试覆盖率明细。

构建用户指南（Antora 站点）

如需生成 HTML 版 User Guide，可运行：

./gradlew antora

输出位于build/antora/build/site（详见 documentation/README.md）。该文档还特别提示：在 Linux 系统上，需要预先安装提供/usr/bin/dot的graphviz包，才能生成文档中的 PlantUML 示意图。

构建缓存与可调参数

• 远程构建缓存默认开启：本地构建可直接复用 CI 产生的任务输出。缓存服务器默认位于美国；欧洲开发者可在 Gradle 用户主目录的gradle.properties中加入junit.develocity.buildCache.server=https://eu-develocity-node.junit.org切换至 EU 节点（见 CONTRIBUTING.md）。
• 查看全部构建参数：运行./gradlew :plugins:build-parameters:parameters可列出所有可调参数，例如是否开启 JaCoCo 覆盖率测量、是否禁用 Predictive Test Selection 等。

依赖元数据：如何把 JUnit 引入你的项目

README 指向 User Guide 附录中的 "Dependency Metadata" 章节以获取全部制品坐标。仓库本身通过JUnit BOM（Bill of Materials）统一管理依赖版本，见 junit-bom/README.md 与 junit-bom/junit-bom.gradle.kts。

使用 BOM 可以避免为多个 JUnit 制品分别指定版本、防止版本不一致。三个最核心的坐标族为：

以junit-jupiter聚合器为例，其 junit-jupiter.gradle.kts 显示：它对外暴露junit-jupiter-api与junit-jupiter-params，并将junit-jupiter-engine作为实现依赖打包——这正是"加一个坐标即可开写@Test"的底层原理。

模块化结构纵深：JPMS 模块与 Maven 制品双重视角

顶层工程划分

从 settings.gradle.kts 可以完整看到仓库的全部工程（project），它们被分成三类：

• 对外发布（mavenized + modular）：junit-bom、junit-jupiter、junit-jupiter-api、junit-jupiter-engine、junit-jupiter-migrationsupport、junit-jupiter-params、junit-platform-commons、junit-platform-configuration-api、junit-platform-configuration-processor、junit-platform-console、junit-platform-engine、junit-platform-launcher、junit-platform-reporting、junit-platform-suite、junit-platform-suite-api、junit-platform-suite-engine、junit-platform-testkit、junit-start、junit-vintage-engine；
• 对外发布但不模块化（mavenized）：junit-platform-console-standalone（可独立运行的 fat JAR）；
• 内部测试工程：jupiter-tests、platform-tests、platform-tooling-support-tests，分别承载 Jupiter 与 Platform 自身的测试套件。

真实 JPMS 模块证据

所有对外模块都声明了 Java Platform Module System 模块描述符。以 junit-jupiter-api/src/main/java/module-info.java 为例，模块org.junit.jupiter.api导出org.junit.jupiter.api、org.junit.jupiter.api.condition、org.junit.jupiter.api.extension等包，并requires transitive org.junit.platform.commons与org.opentest4j——说明 Jupiter API 的使用者会自动获得对平台公共 API 与 OpenTest4J 断言模型的传递依赖。

而 junit-platform-commons/src/main/java/module-info.java 显示，org.junit.platform.commons模块内部的logging与util包通过exports ... to限定只对 Jupiter、Vintage、Console、Launcher 等官方模块开放——这是从源码层面可以看到的"内部实现不对外暴露"的强封装策略。

这种"构建时按 Gradle 工程切分、运行时按 JPMS 模块切分、发布时按 Maven 坐标切分"的三重结构，正是 JUnit 能够同时服务于类路径与模块路径两种使用场景的关键。

质量基础设施：CI、覆盖率与构建扫描

README 展示了仓库在工程化方面的投入：

• CI：官方构建会对 PR 执行快速检查，并对最新发布版与早期访问版 OpenJDK 运行构建矩阵，保证跨 JDK 兼容性；
• 覆盖率：基于 JaCoCo 的最新覆盖率报告托管于 Codecov；本地可用上文jacocoRootReport任务复现；
• Develocity：用于 Build Scans（构建扫描）、Build Cache（构建缓存）与 Predictive Test Selection（预测性测试选择）。核心团队可向 develocity.junit.org 发布扫描；其他开发者可显式加--scan参数发布到 scans.gradle.com。远程构建缓存默认对所有人开启，使本地构建能够复用 CI 的任务输出。

参与贡献：规范与许可证

仓库对贡献者有清晰约定（见 CONTRIBUTING.md）：

• 所有模块采用Eclipse Public License v2.0（见 LICENSE.md）；
• 新贡献者可从带有up-for-grabs标签、尚未有人认领的 issue 入手；
• 代码提交需遵循既定的命名、格式化（Spotless 强制）、Javadoc、空值注解（JSpecify@NullMarked）与测试命名（测试类必须以Tests结尾）等约定；
• 构建缓存、构建参数等进阶信息也集中在该文件中。

快速上手：第一个 JUnit Jupiter 测试

仓库内的官方示例即最佳入门材料。以 AssertionsDemo.java 为例，可以看到现代 Jupiter 测试的标准写法：

import static org.junit.jupiter.api.Assertions.assertAll; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertTrue; import org.junit.jupiter.api.Test; class AssertionsDemo { @Test void standardAssertions() { assertEquals(2, calculator.add(1, 1)); assertEquals(4, calculator.multiply(2, 2), "The optional failure message is now the last parameter"); // 失败消息支持延迟求值 assertTrue('a' < 'b', () -> generateFailureMessage('a','b')); } @Test void groupedAssertions() { // 分组断言：所有断言都会执行，所有失败会一起报告 assertAll("person", () -> assertEquals("Jane", person.getFirstName()), () -> assertEquals("Doe", person.getLastName()) ); } }

从 Test.java 的 Javadoc 可以进一步确认@Test注解的语义约束：测试方法不能是private或static、不能有返回值，但可以声明由ParameterResolver注入的参数；它还能作为元注解组合出自定义注解，并支持从父类与接口默认方法继承。

总结

JUnit 6 时代的 junit-framework 仓库是一个"单一代码库、多运行时形态"的大型工程：Platform 提供底座，Jupiter 提供现代编程模型，Vintage 保证旧测试的平滑迁移；构建上以 JDK 25 + Gradle Wrapper（9.8.0）为准，一条./gradlew build即可验证全部模块，publishToMavenLocal可快速获得本地可用的 SNAPSHOT 制品；依赖管理上以junit-bom统一版本，代码组织上以 JPMS 模块描述符实现了严格的分层与封装。无论你是刚接触 JUnit 5/6 的新手，还是计划将旧版测试迁移升级的维护者，README.md 连同本文梳理的仓库路径，都能帮你快速找到入口。

• 测试