# JUnit 6: Jupiter, Platform and Vintage in One Repository

> JUnit is the programmer-friendly testing framework for Java and the JVM. The junit-team/junit-framework repository hosts JUnit Platform, Jupiter and Vintage, and the latest GA release is JUnit 6.1.3 from August 7, 2026.

**junit-team/junit-framework** — ✅ The programmer-friendly testing framework for Java and the JVM

- Repository: https://github.com/junit-team/junit-framework
- Website: https://junit.org
- Stars: 7,057 · Forks: 1,707
- Language: Java
- License: EPL-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/junit-team-junit-framework

## What JUnit 6 Solves and Who It Is For

JUnit is a testing framework for Java and the JVM, and the junit-team/junit-framework repository is the home of three pieces that are usually discussed as one thing: JUnit Platform, Jupiter and Vintage. That split matters when you are deciding what to put on a classpath. Jupiter is the modern programming model and engine. Vintage is the engine that runs older JUnit-style tests. Platform is the layer underneath both: it discovers tests, launches engines and reports results.

The audience is JVM developers who want tests that read like ordinary Java. The README describes the project as the programmer-friendly testing framework for Java and the JVM, and the topics list names Kotlin and kotlin-testing alongside the Java entries, so the target is not only Java source files. If your build runs on the JVM and you want assertions, lifecycle callbacks and parameterized cases without a separate DSL, this is the default choice.

Who it is not for: anyone looking for browser automation. JUnit tests Java code; Selenium drives browsers. The two are often used together, which is why so many search queries pair them, but JUnit alone will not click a button in a page.

## How JUnit Platform, Jupiter and Vintage Fit Together

The repository layout makes the architecture visible. At the top level you find junit-platform-commons, junit-platform-engine, junit-platform-launcher, junit-platform-console and junit-platform-console-standalone, plus junit-jupiter-api, junit-jupiter-engine, junit-jupiter-params and junit-vintage-engine. The naming is not decorative: it maps to a layered design.

Jupiter supplies the annotations and the engine that executes them. Vintage supplies an engine that runs tests written against the older model. Both register with the Platform, which owns discovery and execution. The launcher is the entry point that IDEs, build tools and the standalone console use to ask the Platform to run something. The console-standalone module exists so you can run tests without wiring a launcher yourself.

That separation is why the same test source can be executed by Gradle, Maven, an IDE or the console. It also explains a common confusion: adding junit-jupiter-api gives you annotations to compile against, but the engine is what actually runs them. The Dependency Metadata section of the User Guide is the authoritative list of artifacts, and the README points there rather than reproducing coordinates.

## Building JUnit from Source with the Gradle Wrapper

The README does not give a copy-paste install snippet for consumers. It links to the Dependency Metadata appendix of the User Guide for the list of artifacts, and the Maven Central badges show the org.junit.jupiter, org.junit.vintage and org.junit.platform namespaces. What the README does document is building the project itself. It states that you need JDK 25, and that Gradle toolchains are used to detect and potentially download additional JDKs for compilation and test execution.

All modules can be built and tested with the Gradle Wrapper using the following command, quoted from the README.

```bash
./gradlew build
```

The README also documents publishing to a local Maven repository for consumption in other local projects.

```bash
./gradlew publishToMavenLocal
```

For coverage, the README gives a separate command and names the report location. The results appear under build/reports/jacoco/jacocoRootReport/html/index.html.

```bash
./gradlew clean jacocoRootReport
```

If you want to consume JUnit rather than build it, the README directs you to the Dependency Metadata section of the User Guide and to the examples repository, and it does not list the artifact coordinates inline. The README is also explicit that no preview, milestone or release candidate is currently offered, so there is no early-access channel to opt into from the repository page.

## Where JUnit 6 Stops Being the Right Tool

JUnit is a unit and component testing framework. It has no browser driver, no HTTP client and no load generator. If your test needs to open a page, JUnit will host the test method but Selenium or another driver does the work. Treating JUnit as an end-to-end testing product leads to a suite that is slow and hard to debug.

There is also a migration boundary inside the project itself. Vintage exists to run older tests, but the README does not promise that every legacy feature is carried forward, and the repository keeps junit-jupiter-migrationsupport as a separate module rather than folding old behaviour into Jupiter. Teams with large legacy suites should verify their specific patterns against the User Guide before assuming a drop-in path.

The build requirement is a real constraint too. Building JUnit from source needs JDK 25, and the README notes that Gradle toolchains detect and may download additional JDKs for compilation and test execution. That is fine on a developer machine and awkward on a locked-down build agent with no network access to a toolchain provider. The README does not document rollback or downgrade steps for the build itself.

## JUnit Compared with TestNG

TestNG is the alternative most often weighed against JUnit, and the difference is in the model rather than the assertion syntax. TestNG was designed around suite-level configuration: XML suite files, groups, dependencies between methods and parallel execution declared in configuration. JUnit splits that responsibility. The Platform handles discovery and launching, Jupiter handles the programming model, and build tools or the launcher decide how runs are organised.

That means a JUnit setup leans on Gradle, Maven or an IDE to express what TestNG expresses in a suite file. The repository reflects this: junit-platform-suite-api and junit-platform-suite-engine exist as separate modules for suite-style execution, and junit-platform-configuration-api and junit-platform-configuration-processor handle configuration rather than a single suite document.

Which is better depends on where you want the control. If your organisation already drives test selection and parallelism from build configuration, JUnit's layering fits. If you want a portable suite definition that travels with the tests, TestNG's approach is more direct.

## Release Cadence, Licence and Upgrade Cost

JUnit ships on a steady cadence. The recent releases list shows r6.1.1 on June 28, 2026, r6.1.2 on July 12, 2026 and r6.1.3 on August 7, 2026, with the README marking 6.1.3 as General Availability and stating that no preview, milestone or release candidate is currently offered. The last push to the default branch was on 2026-09-21, so the repository is not archived.

Upgrade cost is mostly a classpath exercise. Because Platform, Jupiter and Vintage are separate artifacts, a version bump means keeping those coordinates aligned; the junit-bom module exists to manage that alignment for you. The README also points to the Release Notes for behaviour changes, which is where a breaking change would be documented.

The licence is EPL-2.0, and the repository carries LICENSE.md and NOTICE.md at the top level alongside a KEYS file for release signing. EPL-2.0 is a file-level copyleft licence with patent terms; how it interacts with your distribution model is a question for your own legal review, not something a project README can settle. The README also lists commercial sponsors, which is worth knowing when you assess how the project is funded.

## Conclusion

Adopt JUnit if you write Java or JVM tests and want the engine, the launcher and parameterized tests from one project. Do not adopt it if you need browser automation: that is Selenium, not JUnit. Before upgrading, check the Dependency Metadata appendix of the User Guide for the exact artifact coordinates.

## FAQ

### Which is better, JUnit or TestNG?

They solve the same problem with different control points. TestNG centres on suite-level configuration such as groups and method dependencies, while JUnit splits discovery and launching into the Platform and the programming model into Jupiter, leaving run organisation to your build tool or launcher. The repository reflects that split with dedicated suite and configuration modules.

### What is the difference between Selenium and JUnit?

JUnit is a testing framework for Java and the JVM: it discovers and runs test methods and reports results. Selenium drives browsers. They are frequently combined, with JUnit hosting the test method and Selenium performing the browser actions, but JUnit on its own does no browser automation.

### What is the difference between JUnit and unit testing?

Unit testing is the practice of testing small pieces of code in isolation. JUnit is one tool that supports that practice on the JVM, providing annotations, assertions and a platform that discovers and executes the tests.

### What are the key differences between JUnit 5 and JUnit 6?

The README documents JUnit 6.1.3 as the current General Availability release and the recent releases list shows 6.1.1 and 6.1.2 before it, but the README does not enumerate the changes between the major versions. The Release Notes, which the README links to, are where those differences are documented.

### What is the JUnit framework?

JUnit is the programmer-friendly testing framework for Java and the JVM. The junit-team/junit-framework repository hosts three parts: JUnit Platform for discovery and launching, Jupiter for the modern programming model and engine, and Vintage for running older tests.

## Sources

- [junit-team/junit-framework on GitHub](https://github.com/junit-team/junit-framework)
- [License: EPL-2.0](https://github.com/junit-team/junit-framework/blob/main/LICENSE)
- [Project website](https://junit.org)
- [README](https://github.com/junit-team/junit-framework/blob/main/README.md)
- [Releases](https://github.com/junit-team/junit-framework/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/junit-team-junit-framework