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
Run WireMock as a standalone Docker container to mock APIs for integration testing.

zod-validation-utilities
Type-safe validation schemas for APIs, forms, and config with Zod v4 and strong TypeScript inference.

adr-drafting
Create Architecture Decision Records (ADRs) with consistent templates and repository-aware naming.

aws-cdk
AWS CDK TypeScript patterns for defining, validating, and deploying infrastructure as code.

api-review
Review Kubernetes API and CRD design quality for Kelos changes and proposals.

design-cleanup
Remove design-change leftovers and rewrite code as if the new design was always there.