junit-team/junit-framework

1. This is a monorepo for the JUnit ecosystem, split into three major product lines: JUnit Platform, JUnit Jupiter, and JUnit Vintage. The codebase is organized as many Gradle subprojects, with modules published independently and tied together by a shared build, BOM, docs, and compatibility test suites.

2. The lowest architectural layer is junit-platform-commons. It contains shared utilities used everywhere else: reflection and classpath scanning, annotation handling, conversion helpers, resource access, logging, string utilities, and precondition/error types. This module is the common dependency boundary for most other modules.

3. The Platform execution kernel lives in junit-platform-engine. It defines the engine SPI and core model: TestEngine, TestDescriptor, UniqueId, selectors, discovery filters, execution results, reporting types, and the hierarchical execution support used by engines. Engines build descriptor trees during discovery and execute them through the hierarchical executor infrastructure.

4. junit-platform-launcher is the orchestration layer above engines. It aggregates discovery requests, applies filters and listeners, coordinates engine discovery/execution, manages launcher sessions, handles tag expressions and method filters, and adapts engine events into TestExecutionListener callbacks. This is the main entry point used by IDEs, build tools, and command-line tools.

5. junit-platform-console is a CLI and ToolProvider wrapper around the launcher. It translates command-line options into discovery/execution requests, loads test engines via service discovery, and renders results in different output styles. The console layer is how the platform is exposed as a standalone executable tool.

6. junit-platform-reporting sits on the listener side of the launcher and turns execution events into reports. It contains both legacy XML reporting and the newer Open Test Reporting implementation, with service-loader registrations so it can be attached automatically during execution. This module is a post-processing boundary: it does not run tests, it consumes launcher events.

7. junit-platform-suite-api and junit-platform-suite-engine provide test-suite composition. The API defines annotations such as suite selectors, inclusion/exclusion filters, and lifecycle hooks; the suite engine interprets those annotations, creates discovery selectors, and delegates actual test execution to other engines. This is the bridge between “suite definition” and “engine execution.”

8. junit-platform-testkit is a verification tool for engines and launcher behavior. It provides in-process assertions over discovery results, execution events, event statistics, and termination state, and is used heavily by the repo’s own tests to validate engine and launcher behavior.

9. junit-jupiter-api is the user-facing programming model for writing tests. It includes assertions, assumptions, lifecycle annotations, display names, dynamic/repeated/parameterized test support, conditions, extensions, temp directory and parallel-execution APIs, plus Kotlin support in src/main/kotlin. It is the contract that test classes and extensions program against.

10. junit-jupiter-engine is the runtime that discovers and executes Jupiter tests. It translates Jupiter annotations into engine descriptors, applies extension registration and parameter resolution, manages test instances and lifecycle callbacks, and handles features like nested tests, test templates, repeated tests, timeouts, and dynamic tests. This module is the core implementation behind the Jupiter programming model.

11. junit-jupiter-params is a specialized Jupiter extension module for parameterized tests and parameterized classes. It adds argument providers, converters, aggregators, invocation name formatting, and the resolver pipeline that injects argument values into test methods and class templates. It depends on the Jupiter engine infrastructure but adds its own discovery/execution extension points.

12. junit-jupiter-migrationsupport is a compatibility bridge for JUnit 4-era constructs. It adapts selected JUnit 4 rules and ignored conditions into Jupiter extensions, helping legacy tests move forward without rewriting everything at once.

13. junit-vintage-engine is the adapter for running JUnit 3 and JUnit 4 tests on the JUnit Platform. It discovers legacy test classes, wraps runners/descriptions into platform descriptors, and executes them through the platform engine contract so Vintage tests appear alongside Jupiter tests in the same launcher flow.

14. junit-jupiter and junit-start are umbrella/entry modules. junit-jupiter is the aggregate dependency for the Jupiter stack, while junit-start provides a minimal bootstrapping entry point for users who want a simple runtime start class rather than the full platform API surface.

15. The repository is heavily self-tested through dedicated integration suites: jupiter-tests, platform-tests, and platform-tooling-support-tests. These projects exercise cross-module behavior, Kotlin/Groovy interoperability, console output snapshots, build-tool integrations, reporting formats, and launch/execution edge cases. They are as important to the architecture as the production modules because they validate the contracts between modules.

16. Build and packaging are first-class architectural concerns. The project uses Gradle Kotlin DSL, Java modules (module-info.java), service-loader registrations under META-INF/services, JMH benchmarks in selected modules, and generated sources/templates in a few places. Documentation is also a structured subsystem via Antora, with examples and executable snippets that mirror the API/engine split.