Skip to content
cccskills
FreePublished on GitHub

writing-springboot-tests

Use when writing or adding tests for Spring Boot code at a service's edges: HTTP clients that call other services (WireMock: 4xx and 5xx responses, timeouts, retries), Kafka or RabbitMQ listeners (redelivery, poison messages, dead-letter topics), events published to other services, or full-API tests against real databases with Testcontainers; also when a Boot 4 test needs the right imports, slices or container wiring. Supplies verified Boot 4.1 templates and the framework traps that make such tests pass without proving anything. Not for reviewing existing tests (see code-reviewer) or Boot 3 to 4 test migration (see springboot-migration).

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80 stars(GitHub 80 + cccskills 0)

Run score Not tested

See how to install

Files included (14)

  • SKILL.md5.9 KB
  • assets/api-integration-test.java5.1 KB
  • assets/event-publication-test.java6.2 KB
  • assets/http-client-wiremock-test.java6.9 KB
  • assets/message-listener-test.java6.6 KB
  • assets/personas-db.java1.8 KB
  • assets/personas-jwt.java2.3 KB
  • assets/personas-oidc.java2.9 KB
  • assets/pitest-plugin.xml1.2 KB
  • assets/repository-slice-test.java2.6 KB
  • assets/route-access-test.java4.4 KB
  • assets/service-unit-test.java5.4 KB
  • assets/testcontainers-configuration.java2.4 KB
  • assets/webmvc-slice-test.java4.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Writing Spring Boot Tests

Use this for tests where the framework, not the logic, decides whether the test proves anything: calls and messages between services, retries, timeouts, transactions, and Boot 4 test wiring. For plain unit tests you need nothing here beyond the three rules.

Rules

  1. Cases come from the contract, clause by clause. Every sentence of the Javadoc, the provider's API documentation, or an agreed message format is a case: units and formats (cents or decimals, field names), status codes with a special meaning (a 409 that means "already done"), headers, time limits, delivery promises (once only, after commit, poison messages dead-lettered). Call the code the way its callers do, with their values, so conversions run.
  2. Run the real thing at the edge. Real HTTP (WireMock), the real broker and database (Testcontainers), real transactions. A mocked client, template, or transaction manager can't show timeouts, retries, redelivery, or publish-after-commit. Timeout tests use the production timeout value. Build the client the way production does (its bean, or its builder settings) and point it at the stub. If the client can't be pointed elsewhere, make its base URL or endpoint configurable: that improves the design. If it has no timeout at all, report that as a finding instead of skipping the test. AWS SDK clients count: see traps.md.
  3. Show each test failing once, and treat a failing test as a finding. Break the guarded line and watch the test go red (PIT for classes with logic). If a test fails on the current code, report it with the contract clause; never weaken the assertion.
  4. Test through what the code does, not its internals. Assert on results, stored rows, sent messages, and calls to other services. Don't widen a method's visibility, or add a getter, counter or flag that only a test uses: UnusedCodeTests fails on a method only tests call. Changing the code for a test is right when it also improves the design, such as taking a Clock or a client through the constructor instead of creating it.

Before writing

Read ../code-reviewer/references/testing/traps.md: the Boot 4.1 / Framework 7 / Spring Kafka 4 traps found by running these templates (@Retryable behind an interface proxy, @RestClientTest ignoring timeouts, Apache HttpClient retrying 503, blocked partitions, corrupted dead letters, single-batch topic reads), and the Testcontainers and test-data traps.

Imports, starters and PIT: ../code-reviewer/references/testing/boot4-test-toolkit.md.

Templates

Verified on Spring Boot 4.1.1 with Postgres 18, Kafka 4.1 and WireMock 3.13. Take the mechanics (annotations, wiring, stubbing, polling) from them; take the cases from rule 1, not from the template.

EdgeTemplate
Outbound HTTP client: request, 4xx, 5xx, retries, timeout, unusable answersassets/http-client-wiremock-test.java
Message listener: state change, redelivery, poison and non-JSON messagesassets/message-listener-test.java
Event other services consume: after commit, never on rollbackassets/event-publication-test.java
The whole service over HTTP, other services stubbedassets/api-integration-test.java
Secured routes: signing in as a named user through the app's own role mapping (session OIDC login, JWT bearer, or database users); who may call each routeassets/personas-oidc.java, assets/personas-jwt.java or assets/personas-db.java; assets/route-access-test.java
Web slice, persistence slice, service unit testassets/webmvc-slice-test.java, assets/repository-slice-test.java, assets/service-unit-test.java
Shared containers; PITassets/testcontainers-configuration.java, assets/pitest-plugin.xml

Secured routes

Spring's test logins skip the app's own role mapping. oidcLogin().authorities(...), jwt().authorities(...) and user(...).roles(...) hand the test a finished role. A test that signs in this way passes even when the code that turns the provider's claims, or the stored user, into roles is broken. Sign in through a persona instead, so that code runs:

.with(oidcLogin().authorities(new SimpleGrantedAuthority("ROLE_ADMIN")))  // the role mapping never runs
.with(personas.as("admin"))                                                // the app's mapping produces the role

Copy the helper that matches how the app signs users in: personas-oidc.java for an OIDC login kept in a server-side session, personas-jwt.java for JWT bearer tokens, or personas-db.java for users loaded by a UserDetailsService. A persona is the claims the provider sends, or the username of a seeded user. The helper needs the app's mapper, JwtAuthenticationConverter or UserDetailsService as a bean.

route-access-test.java lists who may call each route. It calls every route as every persona and with no login, and it fails when a route is missing from the list. It checks roles, not records. Whether one user can read another user's data needs a test with two users. A request on a random port can't sign in through a persona, so test secured routes through @AutoConfigureMockMvc.

Report

List the tests added (behavior and level), how each was shown to fail, tests that fail on the current code with the contract clause they rely on, and contract clauses left untested.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Adds a new application module to this Spring Modulith project with the package layout the ModuleBoundariesTests gate expects, and a module-scoped integration test. Use when the user asks for a new module, bounded context, or feature area that doesn't belong in an existing module.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

Use when asked to review, check or diagnose Spring Boot code: a pull request, diff, module or file before it merges; a slow endpoint or query (N+1, unbounded reads, JPA and Hibernate performance); security, JSpecify null-safety, architecture boundaries or Boot 4 migration risks in existing code; or whether the tests would catch real bugs, proving each finding by running it. Not for Kotlin-only code, non-Spring frameworks, or generic review advice without code context.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

Use when starting a new Spring Boot project or service: scaffolding or bootstrapping a backend, REST API, microservice or modular monolith; choosing how to structure it (layered, package-by-module, modular monolith, tomato, DDD-hexagonal); selecting Spring Boot 4 features; generating the base project with progen or Spring Initializr; or applying the bundled templates and references in this skill. Not for migrating existing projects or for isolated JPA/repository work without broader project-creation context.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

Writes a Flyway database migration for this project following the team's rules for naming, editing and renaming, so migrations from different developers don't collide and deployed databases stay valid. Use whenever a change needs a new table, column, index or data fix, or the user mentions a schema change or migration.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

Use when a team wants every developer's coding agent (Claude Code or Codex) to follow the same rules on a Maven Spring Boot 4 repository: setting up AGENTS.md, guardrails, shared agent settings, or build and CI checks that agents must pass before code merges. It adds ./mvnw verify gates that fail on null-safety bugs (NullAway with JSpecify), module-boundary breaches (Spring Modulith), unknown or deprecated Boot property keys, Spring mistakes that compile (ArchUnit) and unformatted code, Claude Code hooks that run those gates before a turn ends, and a CI workflow.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

Use when upgrading an existing Spring Boot application, for example from Boot 3.x to Boot 4 or to the latest Spring Boot and Java: dependency transitions and starter renames, test annotations such as @MockBean to @MockitoBean, Jackson 3 issues, Spring Modulith 2 or Testcontainers 2 upgrades, code that stops compiling after a version bump, or planning a phased migration. Not for greenfield project creation or isolated repository design.

The English summary is being prepared. Showing the original description.

a-pavithraa/springboot-skills-marketplace80Updated Oct 27, 2026

See all skills by a-pavithraa

Report a problem with this skill