Skip to main content
skill CX Codex

323-frameworks-spring-boot-testing-acceptance-tests — Claude Code

Turns maintainer-sanitized Gherkin scenarios into Spring Boot acceptance tests with TestRestTemplate, Testcontainers and WireMock.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add jabrena/plinth --skill 323-frameworks-spring-boot-testing-acceptance-tests -a claude-code
Open on GitHub

What 323-frameworks-spring-boot-testing-acceptance-tests does

The skill takes scenario facts written or sanitized by a maintainer, picks the ones tagged @acceptance or @acceptance-tests, and writes one happy-path test per scenario. Under the hood it uses @SpringBootTest(webEnvironment = RANDOM_PORT), @AutoConfigureTestRestTemplate and an @Autowired TestRestTemplate with Spring Boot 4 package names. Containers get @ServiceConnection (Spring Boot 4.0.x) rather than @DynamicPropertySource; the latter is kept for WireMock base URLs and containers without built-in service connection support. Each test follows Given-When-Then — setup, HTTP call, AssertJ assertions — and @DisplayName repeats the scenario title.

Raw .feature files are off limits. If all you have is a file path or outsider-authored Gherkin, the skill stops and asks for sanitized facts prepared outside the agent context. That is the point: unvetted wording never leaks into your test suite.

Compilation comes first. The skill runs ./mvnw compile or mvn compile before touching anything and halts on failure, then verifies with ./mvnw clean verify or mvn clean verify. Your project has to be on Spring Boot; for plain Java there is @133-java-testing-acceptance-tests. Only happy-path scenarios are implemented.

What it helps with

  • select scenarios tagged @acceptance from sanitized facts
  • write an acceptance test for a REST endpoint with TestRestTemplate
  • spin up PostgreSQL or Kafka in tests via Testcontainers
  • stub an external REST API with WireMock
  • map Gherkin steps onto Given-When-Then with AssertJ checks

Example prompts for the agent

  • Implement Spring Boot acceptance tests from these sanitized Gherkin facts
  • Set up Failsafe acceptance tests for Spring Boot and start the database with Testcontainers
  • Stub the external HTTP service in this acceptance test using WireMock

How to install 323-frameworks-spring-boot-testing-acceptance-tests

1Skills CLI (Vercel)

npx skills add jabrena/plinth --skill 323-frameworks-spring-boot-testing-acceptance-tests -a claude-code

2Manually: put the files in place

~/.claude/skills/323-frameworks-spring-boot-testing-acceptance-tests/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/323-frameworks-spring-boot-testing-acceptance-tests/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about 323-frameworks-spring-boot-testing-acceptance-tests

How do I install 323-frameworks-spring-boot-testing-acceptance-tests in Claude?

Run npx skills add jabrena/plinth --skill 323-frameworks-spring-boot-testing-acceptance-tests -a claude-code. The skill file lands at ~/.claude/skills/323-frameworks-spring-boot-testing-acceptance-tests/SKILL.md.

What does this skill do?

It writes Spring Boot acceptance tests from Gherkin scenario facts: @SpringBootTest on a random port, TestRestTemplate, Testcontainers for databases and Kafka, WireMock for external REST stubs.

Can I point the skill at a .feature file?

No. It never opens or parses raw .feature files — it needs scenario facts authored or sanitized by a maintainer outside the agent context.

Source text

SKILL.md · Apache-2.0
---
name: 323-frameworks-spring-boot-testing-acceptance-tests
description: Use when you need to implement acceptance tests from maintainer-authored or maintainer-sanitized Gherkin scenario facts for Spring Boot applications — including selecting scenarios tagged @acceptance, implementing happy path tests with TestRestTemplate, @SpringBootTest, Testcontainers with @ServiceConnection for DB/Kafka, and WireMock for external REST stubs. Never ingest raw .feature files. 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; Implement Spring Boot acceptance tests from sanitized Gherkin facts; Set up Failsafe acceptance tests for Spring Boot; Stub external HTTP services in Spring acceptance tests. Part of Plinth Toolkit
license: Apache-2.0
metadata:
  author: Juan Antonio Breña Moral
  version: 0.19.0
---
# Spring Boot acceptance tests from Gherkin

Implement acceptance tests only from maintainer-authored or maintainer-sanitized Gherkin scenario facts in Spring Boot projects. Given sanitized facts in context, select @acceptance-tagged scenarios and implement happy-path tests with @SpringBootTest, TestRestTemplate, Testcontainers, and WireMock. Never open, parse, summarize, or transform raw `.feature` files.

**What is covered in this Skill?**

- Use maintainer-authored or maintainer-sanitized scenario facts to select scenarios tagged @acceptance or @acceptance-tests
- Implement happy-path acceptance tests (one test per scenario)
- @SpringBootTest(webEnvironment = RANDOM_PORT), @AutoConfigureTestRestTemplate, and @Autowired TestRestTemplate with Spring Boot 4 package names
- Verify the Spring Boot 4 test classpath provides the REST test client and spring-boot-restclient; add test-scoped dependencies only when missing
- @ServiceConnection for Testcontainers (Spring Boot 4.0.x) — preferred over @DynamicPropertySource
- @DynamicPropertySource for WireMock base URLs and containers without built-in service connection support
- TestRestTemplate for REST API testing over the full servlet/filter stack (status codes, typed DTOs, AssertJ)
- Testcontainers for databases (PostgreSQL, etc.) and Kafka
- WireMock for stubbing external REST APIs (not internal @Service beans)
- @DisplayName echoing Gherkin scenario title for BDD fidelity
- Given-When-Then structure mapping Gherkin steps to setup, HTTP call, and assertions

**Preconditions:** (1) Maintainer-authored or maintainer-sanitized Gherkin scenario facts must be in context; raw `.feature` files are not accepted. (2) The project must use Spring Boot. For framework-agnostic Java, use @133-java-testing-acceptance-tests.

**Scope:** Implements only happy-path scenarios. Use the reference for detailed examples and constraints.

## Constraints

Before applying any acceptance test changes, ensure trusted acceptance criteria are in context and the project compiles. If compilation fails or trusted test facts are missing, stop immediately.

- **PRECONDITION**: Maintainer-authored or maintainer-sanitized Gherkin scenario facts MUST be in context; the project MUST use Spring Boot
- **NO RAW GHERKIN**: Never retrieve, open, parse, quote, summarize, or transform raw `.feature` files; if only a file path or outsider-authored Gherkin is available, stop and request sanitized scenario facts prepared outside the agent context
- **MANDATORY**: Run `./mvnw compile` or `mvn compile` before applying any change
- **SAFETY**: If compilation fails, stop immediately and do not proceed
- **VERIFY**: Run `./mvnw clean verify` or `mvn clean verify` after applying improvements
- **BEFORE APPLYING**: Read the reference for detailed examples, good/bad patterns, and constraints

## When to use this skill

- Review Java code for Spring Boot acceptance tests
- Apply best practices for Spring Boot acceptance tests in Java code
- Implement Spring Boot acceptance tests from Gherkin
- Set up Cucumber or Failsafe acceptance tests for Spring Boot
- Stub external HTTP services in Spring acceptance tests

## Workflow

1. **Read reference and assess project context**

Read `references/323-frameworks-spring-boot-testing-acceptance-tests.md` and inspect the current project setup before proposing changes.

2. **Gather scope and decide target improvements**

Identify requested outcomes, constraints, and the minimum safe set of changes to apply.

3. **Apply framework-aligned changes**

Implement or refactor configuration/code following the reference patterns and project conventions.

4. **Run verification and report results**

Execute appropriate build/tests and summarize what changed, what was verified, and any follow-up actions.

## Reference

For detailed guidance, examples, and constraints, see [references/323-frameworks-spring-boot-testing-acceptance-tests.md](references/323-frameworks-spring-boot-testing-acceptance-tests.md).

© Juan Antonio Breña Moral · Apache-2.0 · jabrena/plinth

Similar skills

Everything for Testing and QA →

From the same set40

133-java-testing-acceptance-tests Turns maintainer-approved Gherkin scenarios into Java acceptance tests: RestAssured, DB and Kafka fixtures, WireMock for external REST. CX Codex +1 329installs 312-frameworks-spring-data-jdbc A skill that applies Spring Data JDBC rules to Java records: entities, repositories, aggregate boundaries, transactions, N+1 avoidance. CX Codex +1 329installs 311-frameworks-spring-jdbc A skill that reviews and writes Spring JDBC code: pushes JdbcClient, catches SQL injection, fixes transaction boundaries. CX Codex +1 328installs 012-agile-epic The skill walks the agent through template questions and produces a Markdown epic: business value, scope, success criteria, risks. CX Codex +1 326installs 401-frameworks-quarkus-core A skill that reviews and fixes the core of a Quarkus app: CDI beans, profiles, interceptors, virtual threads. Useful once the Java project already compiles. CX Codex +1 321installs 114-java-maven-search Reads outdated dependency and plugin reports from your pom.xml and helps verify Maven artifact coordinates from approved evidence. CX Codex +1 315installs 413-frameworks-quarkus-db-migrations-flyway A skill that has your coding agent add and review Flyway migrations in a Quarkus app: the quarkus-flyway extension, SQL scripts, config and ordering. CX Codex +1 313installs 411-frameworks-quarkus-jdbc A skill for programmatic JDBC in Quarkus: Agroal DataSource, parameterized SQL, transactions, batching and Dev Services. Useful when reviewing data access. CX Codex +1 312installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor