131-java-testing-unit-testing

Use when you need to review, improve, or write Java unit tests — including migrating from JUnit 4 to JUnit 5, adopting AssertJ for fluent assertions, structuring tests with Given-When-Then, ensuring test independence, applying parameterized tests, mocking dependencies with Mockito, verifying boundary conditions (RIGHT-BICEP, CORRECT, A-TRIP), leveraging JSpecify null-safety annotations, or eliminating testing anti-patterns such as reflection-based tests or shared mutable state. This should trigger for requests such as Review Java code for unit tests; Apply best practices for unit tests in Java code; Write fast JUnit unit tests for Java code; Improve Mockito-based Java unit tests; Refactor Java tests to isolate collaborators. Part of Plinth Toolkit

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

70%

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

A well-structured overview with strong validation-gated workflow clarity and clean one-level-deep progressive disclosure. It is weakest on actionability, since the actual test-authoring guidance is abstract and entirely deferred to the reference, and it carries some redundancy with the description.

Suggestions

Add one or two short inline code examples (e.g. a JUnit 5 + AssertJ + Mockito skeleton or a parameterized-test snippet) so the body is actionable without requiring the reference for common cases.

Remove or condense the "When to use this skill" section since it duplicates the trigger phrases already in the description, recovering token budget.

Specify the recovery action when the final `mvn clean verify` fails (e.g. fix and re-verify) to complete the error-recovery feedback loop.

Dimension	Reasoning	Score
Conciseness	The body is lean and does not explain concepts Claude already knows, but the "When to use this skill" section duplicates the description's trigger phrases verbatim and the "What is covered in this Skill?" list partially overlaps the description, so it could be tightened.	2 / 3
Actionability	Concrete, executable build commands are present ("./mvnw compile or mvn compile", "./mvnw clean verify or mvn clean verify"), but the core test-writing guidance ("Implement or refactor tests using JUnit 5, AssertJ, Mockito, parameterization, and stronger boundary checks") is abstract and fully deferred to the reference with no inline examples.	2 / 3
Workflow Clarity	A clear 4-step sequence (compile before, read reference and evaluate, apply, verify) with an explicit validation gate labeled MANDATORY/SAFETY ("If compilation fails, stop immediately... compilation failure is a blocking condition") and a final VERIFY step.	3 / 3
Progressive Disclosure	The body is an overview pointing to a single one-level-deep reference ("references/131-java-testing-unit-testing.md", which exists), clearly signaled in both the Workflow and the Reference section, with details appropriately split out of SKILL.md.	3 / 3
	Total	10 / 12 Passed

Description

82%

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 richly specific, well-triggered description that clearly states both capabilities and activation conditions. Its main weaknesses are the second-person voice and the absence of disambiguation from sibling framework-specific Java testing skills.

Suggestions

Rewrite in third person (e.g. "Reviews, improves, and writes Java unit tests... Use when the user needs...") to satisfy the voice guideline and recover the specificity point.

Add a scoping/disambiguation clause (e.g. "For Spring Boot or Quarkus tests, use the framework-specific skills instead") to reduce conflict risk with sibling Java testing skills.

Dimension	Reasoning	Score
Specificity	Lists many concrete actions ("migrating from JUnit 4 to JUnit 5, adopting AssertJ..., structuring tests with Given-When-Then, applying parameterized tests, mocking dependencies with Mockito"), which would be a 3, but the description is written in second person ("Use when you need to..."), so specificity is reduced by 1 per the voice guideline.	2 / 3
Completeness	Clearly answers both what (review/improve/write Java unit tests plus the enumerated capabilities) and when via an explicit "Use when you need to..." clause and a "This should trigger for requests such as..." list, so it is not capped at 2.	3 / 3
Trigger Term Quality	Includes natural request phrasing users would actually say ("Review Java code for unit tests; Apply best practices for unit tests in Java code; Write fast JUnit unit tests for Java code; Improve Mockito-based Java unit tests; Refactor Java tests to isolate collaborators") alongside specific tool keywords (JUnit, AssertJ, Mockito).	3 / 3
Distinctiveness Conflict Risk	The Java-unit-testing niche is fairly specific, but the description does not scope itself as framework-agnostic or redirect to the sibling Spring Boot/Quarkus testing skills that the reference file mentions, leaving real overlap with those similar Java testing skills.	2 / 3
	Total	10 / 12 Passed

Validation

100%

Warnings & errors only

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: jabrena/plinth
Commit: aaee915

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.