unit-test-wiremock-rest-api
giuseppe-trisciuoglio/developer-kit
Unit test REST API integrations with WireMock stubs, request verification, and error simulation.
What is unit-test-wiremock-rest-api?
Provides patterns for testing external REST API integrations using WireMock. Stubs HTTP responses, verifies request details, simulates failures (timeouts, 4xx/5xx errors), and validates client behavior without real network calls. Use when testing service integrations with external APIs or mocking HTTP endpoints.
- Stub REST API responses with configurable status codes, headers, and JSON bodies
- Verify request details including URL, headers, query parameters, and request body
- Simulate failure scenarios: timeouts, 4xx errors, 5xx errors, and malformed responses
- Match requests by URL, headers, and body content with flexible matchers
- Auto-reset stubs between tests using JUnit 5 extension registration
- Prevent port conflicts with dynamic port allocation for parallel test execution
How to install unit-test-wiremock-rest-api
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill unit-test-wiremock-rest-api- WireMock 3.4.1+ added to test dependencies (Maven/Gradle)
- AssertJ for fluent assertions
- JUnit 5 for test framework and extension registration
- Java HTTP client library (RestTemplate, WebClient, HttpClient, etc.)
How to use unit-test-wiremock-rest-api
- 1.Add WireMock and AssertJ to test dependencies in Maven or Gradle
- 2.Register WireMockExtension with @RegisterExtension and dynamicPort() configuration
- 3.Retrieve the dynamic base URL using wireMock.getRuntimeInfo().getHttpBaseUrl()
- 4.Configure your HTTP client to use the WireMock base URL
- 5.Call stubFor() to define request matchers and response stubs before executing tests
- 6.Execute service methods that call the stubbed API
- 7.Assert on returned results using AssertJ
- 8.Call verify() to confirm the client made requests with correct URL, headers, and body
Use cases
- Test a service that calls an external weather API by stubbing responses and verifying correct headers are sent
- Validate error handling when an external payment API returns 5xx errors or timeouts
- Verify request body and headers are correctly formatted when calling a third-party authentication service
- Test retry logic by stubbing an API endpoint to fail initially then succeed
- Ensure client properly handles malformed JSON responses from external APIs
- Backend developers testing service integrations
- QA engineers validating HTTP client behavior
- Teams running parallel test suites requiring isolated mock servers
- Developers building microservices that depend on external REST APIs
unit-test-wiremock-rest-api FAQ
Check URL encoding and header names. Use urlEqualTo() for query parameters instead of urlMatching(). Verify the request matcher exactly matches what the client sends.
Configure connection timeouts in your HTTP client. Use withFixedDelay() in the stub response to simulate timeout scenarios. Ensure WireMock is properly initialized before tests run.
Always use wireMockConfig().dynamicPort() instead of fixed ports. Dynamic ports are automatically assigned and prevent conflicts across parallel test execution.
Yes, but you need to configure WireMock's TLS settings separately. See WireMock documentation for HTTPS stubbing configuration.
Stub at the HTTP client layer for faster, more focused tests. Mocking at higher layers adds overhead. Only mock at service boundaries when testing integration behavior.
Full instructions (SKILL.md)
Source of truth, from giuseppe-trisciuoglio/developer-kit.
name: unit-test-wiremock-rest-api description: Provides patterns for unit testing external REST APIs using WireMock. Stubs API responses, verifies request details, simulates failures (timeouts, 4xx/5xx errors), and validates HTTP client behavior without real network calls. Use when testing service integrations with external APIs or mocking HTTP endpoints. allowed-tools: Read, Write, Bash, Glob, Grep
Unit Testing REST APIs with WireMock
Overview
Patterns for testing external REST API integrations with WireMock: stubbing responses, verifying requests, error scenarios, and fast tests without network dependencies.
When to Use
- Testing services calling external REST APIs
- Stubbing HTTP responses for predictable test behavior
- Testing error scenarios (timeouts, 5xx errors, malformed responses)
- Verifying request details (headers, query params, request body)
Instructions
- Add dependency: WireMock in test scope (Maven/Gradle)
- Register extension:
@RegisterExtension WireMockExtensionwithdynamicPort() - Configure client: Use
wireMock.getRuntimeInfo().getHttpBaseUrl()as base URL - Stub responses:
stubFor()with request matching (URL, headers, body) - Execute and assert: Call service methods, validate results with AssertJ
- Verify requests:
verify()to ensure correct API usage
If stub not matching: Check URL encoding, header names, use urlEqualTo for query params.
If tests hanging: Configure connection timeouts in HTTP client; use withFixedDelay() for timeout simulation.
If port conflicts: Always use wireMockConfig().dynamicPort().
Examples
Maven Dependencies
<dependency>
<groupId>org.wiremock</groupId>
<artifactId>wiremock</artifactId>
<version>3.4.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
Basic Stubbing and Verification
import com.github.tomakehurst.wiremock.junit5.WireMockExtension;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.RegisterExtension;
import static com.github.tomakehurst.wiremock.client.WireMock.*;
import static org.assertj.core.api.Assertions.assertThat;
class ExternalWeatherServiceTest {
@RegisterExtension
static WireMockExtension wireMock = WireMockExtension.newInstance()
.options(wireMockConfig().dynamicPort())
.build();
@Test
void shouldFetchWeatherDataFromExternalApi() {
wireMock.stubFor(get(urlEqualTo("/weather?city=London"))
.withHeader("Accept", containing("application/json"))
.willReturn(aResponse()
.withStatus(200)
.withHeader("Content-Type", "application/json")
.withBody("{\"city\":\"London\",\"temperature\":15,\"condition\":\"Cloudy\"}")));
String baseUrl = wireMock.getRuntimeInfo().getHttpBaseUrl();
WeatherApiClient client = new WeatherApiClient(baseUrl);
WeatherData weather = client.getWeather("London");
assertThat(weather.getCity()).isEqualTo("London");
assertThat(weather.getTemperature()).isEqualTo(15);
wireMock.verify(getRequestedFor(urlEqualTo("/weather?city=London"))
.withHeader("Accept", containing("application/json")));
}
}
See references/advanced-examples.md for error scenarios, body verification, timeout simulation, and stateful testing.
Best Practices
- Dynamic port: Prevents conflicts in parallel test execution
- Verify requests: Ensures correct API usage by the client
- Test errors: Cover timeouts, 4xx, 5xx scenarios
- Focused stubs: One concern per test
- Auto-reset:
@RegisterExtensionresets WireMock between tests - Never call real APIs: Always stub third-party endpoints
Constraints and Warnings
- Dynamic ports required: Fixed ports cause parallel execution conflicts
- HTTPS testing: Configure WireMock TLS settings if testing TLS connections
- Stub precedence: More specific stubs take priority over general ones
- Performance: WireMock adds overhead; mock at client layer for faster tests
- API changes: Keep stubs synchronized with actual API contracts
References
- WireMock Documentation
- WireMock Stubbing Guide
references/advanced-examples.md- Error scenarios, body verification, timeouts
Related skills
More from giuseppe-trisciuoglio/developer-kit and the wider catalog.

wiremock-standalone-docker
Provides patterns and configurations for running WireMock as a standalone Docker container. Generates mock HTTP endpoints, creates stub mappings for testing, validates integration scenarios, and simulates error conditions. Use when you need to mock APIs, create a mock server, stub external services, simulate third-party APIs, or fake API responses for integration testing.

zod-validation-utilities
Creates reusable Zod v4 schemas, validates API payloads, forms, and configuration input, transforms and coerces data safely, and handles validation errors with strong type inference for TypeScript applications. Use when designing validation layers, parsing `z.string()`, `z.object()`, or `z.email()` schemas, or implementing runtime type-safe data validation.

adr-drafting
Creates new Architecture Decision Record (ADR) documents for significant architectural changes using a consistent template and repository-aware naming and storage guidance. Use when a user or agent decides on an architectural change, needs to document technical rationale, or wants to add a new ADR to the project history.

aws-cdk
Provides AWS CDK TypeScript patterns for defining, validating, and deploying AWS infrastructure as code. Use when creating CDK apps, stacks, and reusable constructs, modeling serverless or VPC-based architectures, applying IAM and encryption defaults, or testing and reviewing `cdk synth`, `cdk diff`, and `cdk deploy` changes. Triggers include "aws cdk typescript", "create cdk app", "cdk stack", "cdk construct", "cdk deploy", and "cdk test".

gluestack-ui-v4:components
Component usage patterns for gluestack-ui v4 - covers component selection, props vs className, compound patterns, icons, and provider setup.

gmgn-cooking
Create and launch meme coins on Solana, BSC, and Base launchpads via bonding curve fair launch.