Use when you need to write fast unit tests for Quarkus applications — including pure tests with @ExtendWith(MockitoExtension.class), @QuarkusTest with @InjectMock for full CDI mock replacement, @InjectSpy for partial CDI bean mocking, REST Assured for resource-focused tests, @ParameterizedTest with @CsvSource / @MethodSource, QuarkusTestProfile for test-specific configuration overrides, and naming conventions (*Test → Surefire, *IT → Failsafe). For framework-agnostic Java use @131-java-testing-unit-testing. This should trigger for requests such as Add or improve unit tests in a Quarkus project; Reduce slow @QuarkusTest usage with Mockito-first tests; Add @InjectSpy partial mocking or QuarkusTestProfile configuration in Quarkus tests; Convert repeated test methods to @ParameterizedTest with @CsvSource or @MethodSource. Part of cursor-rules-java project
74
67%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/421-frameworks-quarkus-testing-unit-tests/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that is highly specific, includes rich trigger terms covering both natural language and framework-specific annotations, and clearly answers both what the skill does and when to use it. The explicit disambiguation from the general Java testing skill is a strong touch that reduces conflict risk. The only minor weakness is verbosity — it could be slightly more concise — but the detail serves the purpose of accurate skill selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and technologies: pure tests with @ExtendWith(MockitoExtension.class), @QuarkusTest with @InjectMock, @InjectSpy, REST Assured, @ParameterizedTest with @CsvSource/@MethodSource, QuarkusTestProfile, and naming conventions for Surefire/Failsafe. | 3 / 3 |
Completeness | Clearly answers both 'what' (write fast unit tests for Quarkus applications with specific techniques) and 'when' (explicit 'Use when' clause at the start, plus 'This should trigger for requests such as...' with concrete examples). Also includes a disambiguation pointer to the framework-agnostic Java testing skill. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would say: 'unit tests', 'Quarkus', '@QuarkusTest', 'Mockito', '@InjectMock', '@InjectSpy', 'REST Assured', '@ParameterizedTest', '@CsvSource', '@MethodSource', 'QuarkusTestProfile'. Also includes explicit trigger phrases like 'Add or improve unit tests in a Quarkus project' and 'Reduce slow @QuarkusTest usage'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — narrowly scoped to Quarkus-specific testing patterns and explicitly disambiguates from the general Java testing skill (@131-java-testing-unit-testing). The Quarkus-specific annotations and terminology create a clear niche unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill functions primarily as a routing document to an external reference file, providing almost no actionable content in the body itself. While the workflow structure and constraints are reasonable, the complete absence of concrete code examples, test patterns, or executable guidance means Claude would need to read the reference file before being able to do anything useful. The skill would benefit significantly from inline examples of the key patterns (pure Mockito test, @InjectMock test, parameterized test) to provide immediate actionability.
Suggestions
Add at least 2-3 concrete, executable code examples inline — e.g., a minimal @ExtendWith(MockitoExtension.class) test and a minimal @QuarkusTest with @InjectMock test — so Claude can act without reading the reference file first.
Consolidate the 'What is covered' bullet list and 'When to use this skill' section, which overlap significantly, to reduce token waste.
Add a feedback loop in the workflow for test failures after step 4 (e.g., 'If tests fail: review failures, fix, re-run verify') rather than only handling compilation failures.
Include a brief 'decision tree' or rule of thumb inline (e.g., 'Use pure Mockito when no CDI wiring needed; use @QuarkusTest only when testing injection/interceptors') rather than deferring all guidance to the reference.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered' section largely duplicates the description metadata and the 'When to use this skill' section repeats trigger phrases from the description. The constraints section is reasonably tight but could be condensed. The bullet list explaining what the skill covers is informational padding since the actual content lives in the reference file. | 2 / 3 |
Actionability | There are no concrete code examples, no executable commands beyond generic mvnw invocations, and no copy-paste-ready test patterns. All substantive guidance is deferred to the reference file. The skill body describes rather than instructs — it tells Claude to 'read the reference' and 'apply framework-aligned changes' without showing what those changes look like. | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with compilation prerequisites and verification at the end, which is good. However, the steps are abstract ('Apply framework-aligned changes', 'Gather scope and decide target improvements') rather than concrete, and there's no explicit feedback loop for what to do if tests fail after changes. The constraints section does mention stopping on compilation failure, which partially compensates. | 2 / 3 |
Progressive Disclosure | The skill correctly references a single external file (references/421-frameworks-quarkus-testing-unit-tests.md) for detailed content, which is good one-level-deep disclosure. However, since no bundle files were provided, we can't verify the reference exists or is well-structured. The SKILL.md itself is almost entirely a table of contents with no substantive quick-start content — it over-delegates to the reference without providing enough inline value. | 2 / 3 |
Total | 7 / 12 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
ef4eba3
Table of Contents
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.