Use when you need to write or improve integration tests for Quarkus — including @QuarkusTest, Dev Services for automatic container provisioning, Testcontainers via QuarkusTestResourceLifecycleManager, WireMock for external HTTP stubs, @QuarkusIntegrationTest for black-box testing against packaged artifacts, REST Assured, data isolation strategies (@TestTransaction vs @BeforeEach cleanup), and Maven Surefire/Failsafe three-tier split (*Test, *IT, *AT). Part of the skills-for-java project
74
67%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/422-frameworks-quarkus-testing-integration-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 a strong skill description that clearly communicates both when to use it and what it covers, with excellent trigger term coverage for Quarkus integration testing scenarios. The description is comprehensive and highly specific, listing concrete technologies and patterns. The only minor note is that it uses second person ('you need to') rather than third person voice, though the 'Use when' framing is a standard pattern from the good examples.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists multiple specific concrete actions and technologies: @QuarkusTest, Dev Services, Testcontainers, WireMock, REST Assured, @TestTransaction, Maven Surefire/Failsafe three-tier split, and more. These are highly specific capabilities. | 3 / 3 |
Completeness | The description explicitly starts with 'Use when you need to write or improve integration tests for Quarkus' (the when clause) and then comprehensively lists what it does across multiple testing concerns. Both what and when are clearly addressed. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a developer would use: 'integration tests', 'Quarkus', '@QuarkusTest', 'Testcontainers', 'WireMock', 'REST Assured', 'Dev Services', '@QuarkusIntegrationTest', 'Surefire/Failsafe', 'data isolation', '@TestTransaction'. These are exactly the terms a Java/Quarkus developer would mention. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — it targets a very specific niche (Quarkus integration testing) with framework-specific annotations and tools. It would be very unlikely to conflict with general Java testing skills or other framework skills due to the Quarkus-specific terminology throughout. | 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 pointer to a reference file, with almost no actionable content in the body itself. While it has reasonable structure and a clear compile/verify workflow, the complete absence of code examples, patterns, or concrete guidance means Claude would need to read the reference file before being able to do anything useful. The 'What is covered' bullet list adds little value beyond what the description already provides.
Suggestions
Add at least 2-3 minimal, executable code examples for the most common patterns (e.g., a basic @QuarkusTest with REST Assured, a QuarkusTestResourceLifecycleManager with WireMock) so the skill is actionable without requiring the reference file.
Replace the 'What is covered' bullet list with a concise quick-start section showing the most common integration test setup, reserving the detailed patterns for the reference.
Add a brief workflow sequence for the test-writing process itself (e.g., 1. Identify test type needed, 2. Choose pattern, 3. Write test, 4. Verify isolation strategy, 5. Run verify) rather than only covering the build-level compile/verify steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered' section is essentially a table of contents that duplicates the description and the reference file's content. The constraints section has some redundancy (e.g., 'MANDATORY' and 'PREREQUISITE' say the same thing). However, it's not excessively verbose and doesn't explain concepts Claude already knows. | 2 / 3 |
Actionability | The skill contains no concrete code examples, no executable commands beyond generic mvnw invocations, and no specific patterns or snippets. All actual guidance is deferred to the reference file. The body describes what topics exist but doesn't instruct Claude how to do anything specific. | 1 / 3 |
Workflow Clarity | There is a clear compile-before/verify-after workflow with explicit safety stops (compilation failure = stop), which is good. However, the actual multi-step process of writing integration tests lacks sequencing, and there are no validation checkpoints for the test-writing process itself — only for the surrounding build steps. | 2 / 3 |
Progressive Disclosure | The skill correctly points to a single reference file for detailed content, which is good one-level-deep disclosure. However, the SKILL.md itself is almost entirely a table of contents with no quick-start content or minimal actionable examples — it's too thin as an overview, making the reader entirely dependent on the reference file. | 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.
1847adc
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.