323-frameworks-spring-boot-testing-acceptance-tests
Use when you need to implement acceptance tests from a Gherkin .feature file for Spring Boot applications — including finding scenarios tagged @acceptance, implementing happy path tests with TestRestTemplate, @SpringBootTest, Testcontainers with @ServiceConnection for DB/Kafka, and WireMock for external REST stubs. Requires .feature file in context. This should trigger for requests such as Review Java code for Spring Boot acceptance tests; Apply best practices for Spring Boot acceptance tests in Java code. 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/323-frameworks-spring-boot-testing-acceptance-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, well-crafted description that clearly defines a narrow, specific niche — implementing acceptance tests from Gherkin feature files for Spring Boot applications using a defined technology stack. It includes explicit trigger guidance with both a 'Use when' clause and example trigger phrases, and the technical specificity makes it highly distinguishable from other skills. Minor note: it uses second-person 'you' in the opening ('when you need to'), but this is borderline and doesn't significantly harm clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: finding scenarios tagged @acceptance, implementing happy path tests with TestRestTemplate, @SpringBootTest, Testcontainers with @ServiceConnection for DB/Kafka, and WireMock for external REST stubs. Very detailed and actionable. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement acceptance tests from Gherkin feature files with specific technologies) and 'when' (explicit 'Use when' clause at the start, plus 'This should trigger for requests such as...' with concrete examples). Also states a prerequisite: 'Requires .feature file in context.' | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms: 'Gherkin', '.feature file', 'Spring Boot', 'acceptance tests', 'TestRestTemplate', 'Testcontainers', 'WireMock', 'Kafka', 'Java code', '@acceptance'. These are terms a developer would naturally use when requesting this kind of work. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche: Spring Boot acceptance tests from Gherkin .feature files with a specific tech stack (TestRestTemplate, Testcontainers, WireMock). Very unlikely to conflict with generic Java testing or other Spring Boot skills due to the precise combination of technologies and the Gherkin trigger. | 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 provides reasonable structure and workflow sequencing but critically lacks concrete, executable examples — no sample test class, no code snippets showing the patterns it describes. It reads more like a table of contents for the reference file than a standalone skill. The bullet list of covered topics is informative but verbose for what it delivers, and the actual actionable guidance is entirely deferred to an external reference that wasn't provided for evaluation.
Suggestions
Add at least one complete, executable example test class showing @SpringBootTest + TestRestTemplate + Testcontainers + WireMock wired together, mapping a sample Gherkin scenario to a Java test method.
Replace the generic workflow steps ('Apply framework-aligned changes') with specific, concrete instructions — e.g., 'Create a test class annotated with @SpringBootTest(webEnvironment = RANDOM_PORT), add @Container fields for each Testcontainer, wire WireMock stubs in @BeforeEach'.
Trim the 'What is covered' bullet list to remove items Claude already knows (e.g., what TestRestTemplate or Testcontainers do) and focus on project-specific conventions and non-obvious patterns.
Add an explicit feedback loop in the workflow for when tests fail — e.g., 'If tests fail: read the failure output, check WireMock stub mappings and container logs, fix, and re-run verify'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered' bullet list is somewhat verbose and explains things Claude already knows (e.g., what TestRestTemplate does, what Testcontainers is for). The constraints section repeats the preconditions already stated above. Could be tightened significantly. | 2 / 3 |
Actionability | There are no concrete code examples, no executable snippets, no sample test class, and no copy-paste ready commands beyond generic 'mvn compile'. The skill describes what to do abstractly but delegates all concrete guidance to an external reference file that wasn't provided. | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with compilation precondition and verification steps, which is good. However, the steps are generic ('apply framework-aligned changes') rather than specific, and the feedback loop for test failures is implicit rather than explicit. | 2 / 3 |
Progressive Disclosure | The skill references a single detailed reference file with a clear path, which is good structure. However, since no bundle files were provided, we can't verify the reference exists. The main skill body is too thin — it offloads almost all actionable content to the reference, making the SKILL.md itself not very useful standalone. | 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.
- Repository
- jabrena/cursor-rules-java
- Commit
762cb86
- Reviewed
Table of Contents
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.