JUnit support

Detection#

JUnit detection uses Java build metadata such as pom.xml and relevant package dependencies, together with matching source patterns.

Test Chronicle looks for JUnit usage in Maven and Gradle style projects and then scans matching Java test sources. In multi-module repositories, package or module-level discovery can keep Java tests separate from JavaScript, Python, or behaviour-driven tests.

Parsed information#

Test Chronicle records annotated test methods, source files, line numbers, Java class names as parent groups, and @Tag values. Tests marked with @Ignore are omitted.

JUnit 5 parameterised and repeated test annotations are detected and flagged as parameterised definitions. Runtime cases are not currently expanded into individual tracked definitions.

Limits and configuration#

The dashboard tracks source-level JUnit definitions rather than Surefire, Gradle, or IDE execution output. Generated tests and fixtures should be excluded if they are not maintained as part of the active suite.

Use project areas when a Java monorepo has clear module ownership. Area filters make it easier to see whether specific services are gaining or losing test coverage over time.

History#

Supported tests are still mapped to repository commits and classified as additions, deletions, renames, or maintenance changes.

This supports migration and refactoring reviews. If a JUnit class is moved, renamed, or split across modules, Test Chronicle keeps the change tied to Git commits and contributors instead of presenting only a before-and-after count.