GO — Healthy across the board

• Last commit today
• 10 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• EPL-2.0 licensed
• CI configured
• Tests present
• ⚠ Non-standard license (EPL-2.0) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

JUnit is a mature, programmer-friendly testing framework for Java and the JVM that provides a modular architecture split across JUnit Platform (foundational engine), Jupiter (modern annotation-driven testing), and Vintage (JUnit 4 backward compatibility). It enables developers to write readable, parameterized, and extensible unit tests with minimal boilerplate through a clean API and decorator pattern-based extensions. Multi-module Gradle project (build.gradle.kts) hosting three distinct platforms: junit-platform (core engine with listeners and extensions API), junit-jupiter (annotation processor and test lifecycle), and junit-vintage (legacy JUnit 4 adapter). Source organized by feature domain; documentation generated via Antora (documentation/.tool-versions) from AsciiDoc.

Java and JVM developers (Kotlin, Groovy, Scala) who need to write unit, integration, and end-to-end tests with support for parameterization, dynamic tests, and custom test lifecycles. Enterprise teams building large test suites that require strong IDE integration (IntelliJ, Eclipse) and CI/CD pipeline compatibility.

Production-ready and actively developed. JUnit 6.0.3 (GA, February 2026) and 6.1.0-RC1 preview are current releases. The codebase shows robust CI infrastructure (.github/workflows/main.yml, cross-version.yml), comprehensive code coverage via JaCoCo/Codecov, and Gold sponsorships from JetBrains, indicating institutional backing and stability.

Minimal risk: well-established project with multi-maintainer model (junit-team), automated release pipeline (.github/workflows/release.yml), and DCO enforcement (.github/dco.yml). However, as a foundational testing framework, breaking changes in major versions (current: v6) require coordinated ecosystem upgrades. No single-maintainer bottleneck visible.

Active development toward JUnit 6.1.0 with RC1 released April 2026. CI workflows (.github/workflows/) include cross-version testing, reproducible builds, CodeQL security scanning, and dependency submission to GitHub. Renovate configured (.github/renovate.json5) for dependency updates; issues labeled 'up-for-grabs' indicate community contribution targets.

git clone https://github.com/junit-team/junit-framework.git
cd junit-framework
./gradlew build
./gradlew test

Daily commands:

./gradlew clean build           # Full build with tests
./gradlew test                 # Run test suite
./gradlew jacocoRootReport     # Generate code coverage locally
./gradlew -x test build        # Build without tests

• build.gradle.kts — Root build configuration orchestrating all modules (Platform, Jupiter, Vintage); essential for understanding the multi-module structure and dependency management.
• .github/workflows/main.yml — Primary CI/CD pipeline defining test execution, build verification, and quality gates across all JVM versions and platforms.
• README.md — Entry point documenting JUnit's mission, sponsors, and latest releases; required reading to understand project scope.
• CONTRIBUTING.md — Guidelines for contributors covering coding standards, commit conventions, and PR expectations specific to JUnit team.
• documentation/antora.yml — Documentation site structure; defines how all user-facing guidance is organized and published via Antora.
• .github/workflows/release.yml — Release automation pipeline; critical for understanding versioning, publishing to Maven Central, and GitHub release management.

• JUnit Platform (Java 8+, SLF4J logging) — Foundation layer providing test discovery, selection, and lifecycle management; TestEngine and Extension SPI
  • Failure mode: Failed test discovery → tests silently not executed; broken extension APIs → test invocation failures
• JUnit Jupiter (Java 8+ (lambda-friendly), annotations, reflection-based introspection) — Modern test authoring API with @Test, @BeforeEach, parameterized tests, and nested test classes
  • Failure mode: Incompatible annotation signatures → test class loading failures; lifecycle method ordering issues → test state corruption
• JUnit Vintage (JUnit) — TestEngine adapter translating JUnit 4/3 test structures to JUnit Platform execution model

Add a new documentation page for a feature or guide

1. Create a new .adoc file in the appropriate module under documentation/modules/ROOT/pages/ (e.g., extensions/, running-tests/, advanced-topics/) (documentation/modules/ROOT/pages/extensions/overview.adoc)
2. Add an entry to the navigation file to index the new page (documentation/modules/ROOT/nav.adoc)
3. Follow AsciiDoc syntax conventions and link to related pages using xref blocks (documentation/modules/ROOT/pages/overview.adoc)
4. Build and test documentation locally via documentation/documentation.gradle.kts before committing (documentation/documentation.gradle.kts)

Release a new JUnit version

1. Update version numbers and release notes in the codebase and commit with proper conventions (RELEASING.md)
2. Push tag to trigger the release.yml GitHub Actions workflow (.github/workflows/release.yml)
3. Monitor the workflow which automatically publishes to Maven Central and creates GitHub releases (.github/scripts/create-github-release.js)
4. Verify reproducible build artifacts match expected checksums (.github/workflows/reproducible-build.yml)

Contribute a bug fix or feature

1. Fork the repository and create a branch following the naming conventions documented in CONTRIBUTING.md (CONTRIBUTING.md)
2. Sign commits with DCO compliance (Developer Certificate of Origin) as enforced by .github/dco.yml (.github/dco.yml)
3. Submit a pull request using the PR template, which auto-checks code style and runs the main CI pipeline (.github/PULL_REQUEST_TEMPLATE.md)
4. Ensure all checks in main.yml pass before merge (cross-JDK testing, code quality, reproducible builds) (.github/workflows/main.yml)

• Gradle (Kotlin DSL) — Modern polyglot build system supporting multi-module projects, dependency management, and cross-JVM compilation; native Kotlin DSL aligns with JVM ecosystem tooling.
• GitHub Actions — Native CI/CD integration for automated testing across multiple JDK versions, reproducible build verification, and release automation without external service overhead.
• Antora + AsciiDoc — Documentation-as-code approach enabling version-controlled, searchable user guides with component-based authoring and static site generation.
• Renovate — Automated dependency update management reducing manual maintenance burden and keeping security patches current.

• Single monorepo for Platform, Jupiter, and Vintage

  • Why: Enables coordinated releases, shared infrastructure, and consistent versioning across the JUnit ecosystem
  • Consequence: Larger repository size; all modules update in lockstep; contributors must understand multi-module Gradle structure

• Documentation in AsciiDoc within the main repository

  • Why: Keeps docs versioned alongside code; enables CI validation of documentation correctness
  • Consequence: Release cycle tightly couples docs to code; learning curve for AsciiDoc syntax; documentation builds on every push

• DCO-required commit signing

  • Why: Ensures legal compliance and clear IP provenance for open-source contributions
  • Consequence: Raises barrier for casual contributors; requires git configuration and tooling education

• Cross-JDK testing (11, 17, 21+) in main CI

  • Why: Validates compatibility across Java version migration paths
  • Consequence: Longer CI runs; higher infrastructure cost; catches platform-specific bugs early

• JUnit does not provide runtime mocking libraries (use Mockito, PowerMock, etc. alongside JUnit).
• JUnit is not a testing framework for non-JVM languages (Java and JVM-based languages only).
• JUnit does not provide built-in performance benchmarking (use JMH or other dedicated tools).
• JUnit Platform does not execute tests in distributed or remote environments natively (third-party plugins required).

Gradle wrapper (./gradlew) required—do not run bare gradle command. Test discovery depends on ServiceLoader configuration in junit-platform-engine/src/main/resources/META-INF/services/org.junit.platform.engine.TestEngine—adding new test engines requires META-INF registration. Cross-version CI tests multiple JDK versions (see .github/workflows/cross-version.yml); local builds may behave differently on non-LTS Java. Release process requires Maven Central credentials configured in GitHub Actions (see .github/actions/maven-central-user-token/).

• Service Provider Interface (SPI) — JUnit's extensibility is built on SPI: TestEngine, TestExecutionListener, and Extension interfaces use ServiceLoader discovery, allowing third-party frameworks (Spock, Kotest) to integrate without forking the codebase
• Test Lifecycle Callbacks (BeforeEach, AfterEach, BeforeAll, AfterAll) — Jupiter's extension points (junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/) allow fine-grained control over setup/teardown ordering and exception handling—critical for resource management in integration tests
• Parameterized Tests (@ParameterizedTest) — Enables data-driven testing; JUnit generates multiple test invocations from single method using ArgumentsProvider and ArgumentsSource SPIs—reduces test boilerplate for testing multiple input scenarios
• Test Discovery and Filtering — TestDiscovery and TestSelector APIs (junit-platform-engine) separate test finding logic from execution, enabling selective test runs by class/method/tag—essential for large test suites and CI parallelization
• Extension Model (Extension Interface) — Single Extension marker interface combined with named callback methods (beforeTestExecution, afterTestExecution, etc.) allows composable cross-cutting concerns—replaces JUnit 4's Rule/Runner pattern with less rigid contract
• TestTemplate and Invocation Context — @TestTemplate decouples test method from invocation count; TestTemplateInvocationContextProvider generates multiple invocations dynamically—powers dynamic tests and enables frameworks like Kotest to provide parametrization
• Reproducible Builds — JUnit enforces bit-for-bit identical JAR artifacts across builds (.github/workflows/reproducible-build.yml, .github/scripts/checkBuildReproducibility.sh)—critical for supply chain security and binary verification in regulated environments

• mockito/mockito — De-facto standard mocking library for Java; works alongside JUnit 5 for behavior verification in unit tests
• rest-assured/rest-assured — REST API testing DSL; commonly paired with JUnit 5 for integration test suites
• testcontainers/testcontainers-java — Docker-based container lifecycle management during tests; integrates with JUnit 5 via @Container annotation extension
• assertj/assertj — Fluent assertion library providing readable matchers; often used as drop-in replacement for JUnit's built-in assertions
• gradle/gradle — Build tool used by this project (build.gradle.kts); understanding Gradle's test task execution model is essential for modifying test infrastructure

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Action workflow for documentation build validation

The repo has extensive Antora-based documentation (documentation/antora.yml, documentation/antora-playbook.yml) with multiple extensions (@antora/collector-extension, @antora/lunr-extension, @asciidoctor/tabs, etc.), but there's no dedicated CI workflow to validate documentation builds on PR. The deploy-docs.yml workflow exists but only runs on releases. Adding a pre-commit validation workflow would catch broken documentation references, missing images, and malformed AsciiDoc syntax early.

• [ ] Create .github/workflows/validate-docs.yml that runs on pull_request events for documentation/* paths
• [ ] Configure the workflow to run Antora build from documentation/ directory using the antora-playbook.yml
• [ ] Add failure condition if Antora build exits with non-zero status or produces warnings about broken xrefs
• [ ] Reference this workflow in .github/PULL_REQUEST_TEMPLATE.md to inform contributors
• [ ] Test with a PR that intentionally breaks a documentation link to verify the workflow catches it

Add missing GitHub Actions for multi-Java version testing coverage gaps

The cross-version.yml workflow exists but .github/actions/setup-test-jdk/action.yml suggests configurable JDK setup. However, examining the main.yml and other workflows, there's no explicit matrix testing across supported LTS JDK versions (17, 21) and latest versions. For a framework supporting 'Java and the JVM', adding explicit matrix jobs for each supported Java version would catch version-specific compatibility issues early.

• [ ] Review build.gradle.kts to identify supported Java version ranges (check sourceCompatibility, targetCompatibility properties)
• [ ] Create a new .github/workflows/java-matrix-test.yml that tests against minimum supported, LTS, and latest Java versions
• [ ] Use .github/actions/setup-test-jdk/action.yml to configure each JDK version in matrix
• [ ] Ensure gradle tasks run with different Java versions (e.g., java17Test, java21Test tasks if they exist)
• [ ] Update .github/PULL_REQUEST_TEMPLATE.md to note that Java version compatibility is tested automatically

Add integration tests for Antora documentation extension configurations

The documentation/antora.yml and antora-playbook.yml use multiple external extensions (@springio/antora-extensions, @antora/lunr-extension, @asciidoctor/tabs) but there are no integration tests validating these extensions work correctly together. The documentation/ folder lacks a test subdirectory to validate build outputs (e.g., correct search index generation, tab functionality compilation, cross-references resolution).

• [ ] Create documentation/test/ directory with sample AsciiDoc files demonstrating each extension's features (tabs, xrefs, custom macros from @springio/antora-extensions)
• [ ] Add a test script (documentation/test/validate-build-output.sh) that runs Antora build and validates generated HTML/JSON artifacts
• [ ] Verify lunr search index is generated correctly in documentation/test/validate-build-output.sh
• [ ] Add .github/workflows/validate-docs.yml step to run documentation/test/validate-build-output.sh (pairs with first PR suggestion)
• [ ] Document the testing approach in documentation/README.md for maintainers

• Add missing @ParameterizedTest documentation examples for CSV, JSON, and database sources in documentation/ (current docs focus on @ValueSource; CSV parsing behavior unclear for edge cases like escaped commas)
• Implement assertion messages for newly-added fluent assertion API in junit-jupiter-api (AssertThat, which() methods exist but lack descriptive error output parity with legacy Assert.assertEquals)
• Extend TestTemplate lifecycle tests in junit-jupiter-engine/src/test/java to cover edge case where BeforeEach throws exception before first test invocation (currently untested per code coverage report)

The JUnit Framework repository demonstrates generally good security practices with signed JAR releases, OpenSSF compliance badges, and a security policy in place. However, the project relies on several alpha/pre-release versions of Antora and related dependencies, which pose medium-risk concerns. The main vulnerabilities are related to dependency management rather than code-level issues. The project should prioritize updating to stable releases and maintaining a comprehensive dependency audit process. Overall security posture is above average but could be improved through more aggressive dependency maintenance and complete documentation of security procedures.

• Medium · Outdated Antora Version — package.json - devDependencies. The project uses antora 3.2.0-alpha.11, which is an alpha/pre-release version. Alpha versions may contain unresolved security issues and are not recommended for production use. Fix: Update to the latest stable release of Antora (currently 3.1.x or later stable version). Alpha releases should not be used in production environments.
• Medium · Outdated highlight.js Dependency — package.json - dependencies. highlight.js version 11.11.1 is used, but this version may have known vulnerabilities. Regular dependency updates are critical for security patches. Fix: Review and update to the latest stable version of highlight.js (11.11.1+). Run 'npm audit' to identify specific security vulnerabilities and update accordingly.
• Low · Alpha/Pre-release Antora Extensions — package.json - dependencies. Multiple Antora extensions use pre-release or alpha versions (@springio/antora-xref-extension: 1.0.0-alpha.5, @antora/lunr-extension: 1.0.0-alpha.13), which may have stability and security concerns. Fix: Evaluate whether alpha versions are necessary. Consider upgrading to stable releases when available. Document and monitor these pre-release dependencies for updates.
• Low · Missing npm Dependency Lock File Visibility — Repository root. While package.json is provided, the presence of package-lock.json or yarn.lock is not indicated. This could lead to non-reproducible builds and dependency confusion attacks. Fix: Ensure package-lock.json (for npm) or yarn.lock (for yarn) is committed to version control and reviewed in pull requests to maintain reproducible builds.
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated in the provided content. The reporting vulnerability section is incomplete, which could confuse users about proper security reporting channels. Fix: Ensure SECURITY.md is complete and clearly documents all security reporting procedures, including private reporting mechanisms and expected response times.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/junit-team/junit-framework shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live junit-team/junit-framework repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/junit-team/junit-framework.

What it runs against: a local clone of junit-team/junit-framework — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in junit-team/junit-framework | Confirms the artifact applies here, not a fork | | 2 | License is still EPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of junit-team/junit-framework. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/junit-team/junit-framework.git
#   cd junit-framework
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of junit-team/junit-framework and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "junit-team/junit-framework(\\.git)?\\b" \\
  && ok "origin remote is junit-team/junit-framework" \\
  || miss "origin remote is not junit-team/junit-framework (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(EPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"EPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is EPL-2.0" \\
  || miss "license drift — was EPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "build.gradle.kts" \\
  && ok "build.gradle.kts" \\
  || miss "missing critical file: build.gradle.kts"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "documentation/antora.yml" \\
  && ok "documentation/antora.yml" \\
  || miss "missing critical file: documentation/antora.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/junit-team/junit-framework"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.