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
59
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, comprehensive, and well-differentiated. It lists concrete Quarkus testing techniques, provides explicit trigger scenarios, and even disambiguates from a related skill for framework-agnostic Java testing. The only minor concern is verbosity, but the density of useful information justifies the length.
| 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 @131-java-testing-unit-testing for non-Quarkus Java. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would say: 'unit tests', 'Quarkus', '@QuarkusTest', 'Mockito', '@InjectMock', '@InjectSpy', '@ParameterizedTest', '@CsvSource', '@MethodSource', 'QuarkusTestProfile', 'REST Assured'. Also includes explicit trigger phrases like 'Add or improve unit tests in a Quarkus project'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — narrowly scoped to Quarkus-specific testing patterns and explicitly differentiates itself from framework-agnostic Java testing by pointing to a separate skill. The Quarkus-specific annotations and tools create a clear niche. | 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 table of contents pointing to an external reference file, with almost no actionable content in the body itself. While the workflow structure and constraints are reasonable, the complete absence of code examples for any of the seven testing patterns listed makes it largely unusable without the reference file. The skill would benefit significantly from inline quick-start examples for at least the most common patterns (pure Mockito test, @QuarkusTest with @InjectMock).
Suggestions
Add at least 2-3 concrete, executable code examples inline — e.g., a minimal @ExtendWith(MockitoExtension.class) test and a @QuarkusTest with @InjectMock test — so the skill is actionable without reading the reference file.
Consolidate the redundant constraint bullets (MANDATORY, PREREQUISITE, SAFETY, BLOCKING CONDITION) into a single clear statement like 'Run ./mvnw compile before changes; stop if it fails.'
Add a feedback loop to the workflow for test failures: what to check, how to diagnose, and when to roll back changes.
Remove the 'What is covered' bullet list which duplicates the description and 'When to use' sections; replace it with a quick-start example that demonstrates the primary pattern.
| 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 somewhat verbose with redundant emphasis (MANDATORY, PREREQUISITE, SAFETY, BLOCKING CONDITION all say roughly the same thing). However, it's not egregiously padded and avoids explaining basic concepts. | 2 / 3 |
Actionability | The skill contains zero executable code examples, no concrete commands beyond generic mvnw invocations, and delegates all actual guidance to an external reference file. There are no copy-paste ready patterns for any of the testing approaches mentioned (Mockito, InjectMock, InjectSpy, REST Assured, ParameterizedTest, etc.). | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with compilation prerequisite and verification at the end, which is good. However, the steps are generic ('apply framework-aligned changes', 'gather scope') rather than specific to the testing domain, and there's no explicit feedback loop for what to do if tests fail after refactoring. | 2 / 3 |
Progressive Disclosure | The skill references a single external file for detailed guidance, which is appropriate one-level-deep disclosure. However, since no bundle files were provided, we cannot verify the reference exists or contains adequate content. The SKILL.md itself is too thin — it should contain at minimum a quick-start example or key patterns inline rather than deferring everything to the reference. | 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.
3fa5789
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.