CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/jvm-unit-tests

JVM unit testing (Java / Kotlin / Scala / Groovy) with JUnit 5 (Jupiter) as the primary framework - annotations (`@Test` / `@ParameterizedTest` / source providers), lifecycle hooks (`@BeforeAll` / `@BeforeEach`), extension model (`@ExtendWith` + Mockito/Spring), display names, conditional execution, parallel-execution config, JaCoCo coverage, and Maven Surefire / Gradle CI. Includes a per-language framework decision table (Java → JUnit 5, Kotlin → Kotest, Groovy → Spock, Scala → ScalaTest, legacy → TestNG; always match an existing build convention) and test-authoring conventions (framework detection from pom.xml / build.gradle / build.sbt, path conventions, no fabricated methods). References cover Kotest spec styles, Spock given/when/then + data tables, TestNG DataProviders + suites, ScalaTest styles + Matchers, and the AssertJ fluent-assertion catalog. Use for any JVM unit-test task: choosing or configuring a framework, writing or parameterizing tests, wiring coverage and CI.

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable skill body with executable code at every step and clean progressive disclosure to real reference files. The only real gap is the absence of an explicit test-run validation/retry loop and a few trimmable time-sensitive asides.

Suggestions

Add an explicit validation checkpoint after authoring (e.g., 'run the new test in isolation; if it fails, fix the test not the target, then re-run') to close the workflow_clarity feedback-loop gap.

Move the 'released 2017, replacing JUnit 4' contextual note (and similar version-year facts) into the JUnit 4/Vintage migration note so the Overview stays lean.

Consider replacing pinned versions (5.11.0, 0.8.12, codecov-action@v4) with a 'use the current release' pointer or a clearly marked versions note to reduce time-sensitivity.

DimensionReasoningScore

Conciseness

Mostly lean with tight code blocks and no padding about basics Claude already knows, but a few time-sensitive/contextual bits ('released 2017, replacing JUnit 4') and embedded version numbers are minor over-explanation that could be trimmed.

4 / 5

Actionability

Fully executable, copy-paste-ready guidance throughout—Maven pom.xml and Gradle kts snippets, Java test/parameterized/extension/display-name examples, junit-platform.properties, and a GitHub Actions YAML—covering the common cases concretely.

5 / 5

Workflow Clarity

A clean Step 1–Step 8 sequence plus numbered authoring conventions and a guard ('two or more framework signals → stop and ask') gives a clear path, but there is no explicit validate→fix→retry feedback loop, leaving a minor validation gap.

4 / 5

Progressive Disclosure

The body keeps JUnit 5 content inline and pushes per-language depth to one-level-deep, well-signaled references (references/kotest.md, spock.md, scalatest.md, testng.md, assertj.md), all of which exist as real files and are re-listed in a References section.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, specific description that names the domain, enumerates concrete capabilities, and ends with an explicit 'Use for...' trigger clause. Its only soft spot is trigger-term breadth—language/framework names are strong but file extensions and a few synonyms are absent.

DimensionReasoningScore

Specificity

Lists many concrete actions—annotations, lifecycle hooks, the extension model, display names, conditional execution, parallel-execution config, JaCoCo coverage, and Surefire/Gradle CI—giving comprehensive coverage rather than generic verbs.

5 / 5

Completeness

Explicitly answers both 'what' (the full JUnit 5 capability surface) and 'when' via a concrete 'Use for any JVM unit-test task: choosing or configuring a framework, writing or parameterizing tests, wiring coverage and CI.' clause.

5 / 5

Trigger Term Quality

Strong natural coverage of languages and frameworks (JUnit 5, Kotest, Spock, ScalaTest, TestNG) plus build-file names (pom.xml/build.gradle/build.sbt), but it omits common file extensions like .java/.kt and a few synonyms, so it falls just short of the comprehensive anchor.

4 / 5

Distinctiveness Conflict Risk

The 'JVM unit testing (Java/Kotlin/Scala/Groovy) with JUnit 5' framing carves a clear niche with distinct triggers and minimal overlap risk against non-JVM or non-unit-test skills.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents