WireMock API Mocking & Stubbing: SDET Interview Questions 2026

The 7 Most Common WireMock Interview Questions — With Model Answers That Demonstrate Production Experience

Here are the questions that Mitchell has both asked in interviews and been asked — each with the model answer that distinguishes a candidate who has designed and maintained production WireMock testing infrastructure from a candidate who has written stubFor() within a test class someone else configured.

Q1: "Explain when you would use WireMock stubbing vs WireMock verification. Give a concrete example where over-using verification caused a problem."

What the interviewer is testing: This is the foundational WireMock question. The interviewer is checking whether you understand that stubbing and verification serve fundamentally different testing purposes — and that the instinct to verify every HTTP call is a common anti-pattern that produces brittle, high-maintenance test suites. Model answer: "Stubbing and verification answer different questions. Stubbing answers: 'given this input from a downstream service, what does the system under test do?' Verification answers: 'did the system under test make the expected HTTP call?' I use stubbing for the vast majority of my WireMock configuration — I define what the downstream services return, and I assert on the system under test's observable behaviour (the HTTP response it returns, the database state it creates, the message it publishes to the queue). I use verification only for side effects that have no other observable outcome — events sent to an audit service, notifications sent to a logging endpoint, calls to a metrics service. If the side effect IS the behaviour being tested, verification is appropriate. If the side effect is an implementation detail of how the behaviour is achieved, verification is testing implementation, not behaviour — and it creates brittle tests.

The concrete example: at Co-op, we had a test for the order-cancellation flow. The test stubbed the inventory service (returns 'item released'), stubbed the payment service (returns 'refund processed'), and then verified that POST /inventory/release was called, POST /payments/refund was called, and POST /notifications/email was called. The test passed. Six months later, we changed the order-cancellation flow to release inventory and process refunds in parallel using CompletableFuture.allOf(). The verifications started failing — not because the behaviour was wrong, but because the order of calls was non-deterministic and the verifications checked the order. We spent 3 hours debugging a test that was testing implementation, not behaviour. The fix: stub the downstream services, assert that the order status in the database is 'CANCELLED' and the refund amount matches the order total — and remove the verifications. The test became 4 lines shorter, 100% reliable, and tested the behaviour that actually matters: was the order cancelled and refunded? For a detailed treatment of testing patterns, see our test automation best practices guide."

Q2: "How would you design a fault-injection testing strategy using WireMock? What failure modes would you cover and why?"

What the interviewer is testing: This question evaluates whether you think about testing failure modes systematically — and whether you understand that the most dangerous bugs are triggered by degraded behaviour, not total failure. Model answer: "I design a fault-injection matrix for every downstream dependency. The matrix covers four categories of failure: (1) HTTP error responses — 400 Bad Request (the downstream service rejects the request), 401/403 (authentication or authorisation failure — tests that the system correctly handles expired or invalid downstream credentials), 404 Not Found (the requested resource doesn't exist), 409 Conflict (optimistic locking failure or duplicate resource), 429 Too Many Requests (rate limiting — tests that the system backs off and retries), 500 Internal Server Error (unexpected downstream failure), 503 Service Unavailable (downstream service is temporarily unavailable — tests that the system retries with backoff or fails gracefully), and 504 Gateway Timeout (the downstream service didn't respond in time).

(2) Network-level failures — connection refused (WireMock port is closed or WireMock is not started — simulates a service that is completely down), connection timeout (WireMock receives the TCP SYN but never responds — simulates a service behind a load balancer that accepts connections but doesn't process them), and read timeout (WireMock accepts the connection but never sends a response — simulates a service that hangs during request processing). (3) Response degradation — slow responses (add a 5-second delay to the response — simulates a service under load; test that the system's read timeout and circuit breaker are configured correctly), malformed responses (return HTML instead of JSON, return a 200 with an empty body, return a 200 with a body that is missing required fields, return a 200 with extra unexpected fields, return a 200 with a body that is 10MB instead of 10KB), and invalid content types (return text/plain when the client expects application/json). (4) Intermittent failures — WireMock's scenario feature combined with probabilistic response selection: the first two requests succeed, the third fails with 500, the fourth succeeds again. This simulates real-world service instability — every downstream service has occasional failures.

For each category, I write a dedicated test class: OrderServiceHttpErrorTest, OrderServiceNetworkFailureTest, OrderServiceDegradedResponseTest, OrderServiceIntermittentFailureTest. Each test class configures WireMock stubs for exactly one failure mode and asserts the system under test's behaviour: does it retry? Does it fall back to a cached value? Does it return a user-friendly error? Does it log the failure with enough context for operations to diagnose? Does it increment the appropriate metrics (circuit-breaker state, failure count, latency histogram)? At Nationwide, this approach caught 14 bugs in the mortgage-origination pipeline: 3 retry-related (the system wasn't retrying on 503), 2 timeout-related (the default read timeout was 30 seconds — a downstream service hanging for 30 seconds blocked a thread-pool thread and caused cascading failures), 4 null-pointer exceptions on missing response fields, 2 deserialisation failures on unexpected response formats, and 3 cases where the system returned a 200 OK to the caller but the downstream failure caused data to be silently dropped. None of these bugs were caught by the happy-path tests. None of them were caught by manual testing because the real downstream services never returned these failure modes during test windows. Fault injection is not optional — it is the only way to verify that your system handles failure gracefully." For more on resilience patterns, see our chaos engineering and resilience testing guide.

Q3: "Explain the trade-offs between WireMock standalone server, WireMock JUnit 5 extension, and WireMock with Testcontainers. When would you use each?"

What the interviewer is testing: This question evaluates whether you understand WireMock deployment modes as an architectural decision — and whether you have operated WireMock at a scale where the choice between standalone, JUnit extension, and Testcontainers has measurable consequences for test speed, CI infrastructure, and team workflow. Model answer: "The three deployment modes serve different testing contexts, and the choice between them is about test isolation requirements, CI infrastructure constraints, and team workflow preferences.

WireMock JUnit 5 extension (@WireMockTest) — WireMock runs in the same JVM as your tests. The extension starts WireMock on a dynamic port before each test (or test class, depending on lifecycle configuration), injects the port via @WireMockTest(httpPort = 0) or the WireMockRuntimeInfo parameter, and stops WireMock after each test. This is the fastest option — no container startup, no network hop, sub-millisecond response times. It is ideal for: unit-like integration tests where each test class gets its own WireMock instance, tests that run frequently (every developer save, every PR), and test suites where startup speed matters (hundreds of test classes that each need WireMock). The trade-off: each test class gets a fresh WireMock instance with no stubs — you configure stubs programmatically in @BeforeEach. This is great for test isolation (no state leakage) but means every test class repeats the same stub setup code — which is why you need a shared stubbing library (discussed in Q5).

WireMock standalone server — WireMock runs as a separate process, either on the developer's machine or in CI. You start it before your tests (manually, via a script, or via a Maven/Gradle plugin), configure stubs via the HTTP API or by placing JSON stub files in the mappings/ directory, and your tests connect to it on a known port. This is ideal for: shared test environments where multiple applications test against the same WireMock instance, manual exploratory testing (start WireMock, configure stubs via the Admin API, test your application manually in a browser or with curl), and CI pipelines with multiple test stages that share the same WireMock state. The trade-offs: (1) you must manage the WireMock process lifecycle (start before tests, stop after — a Maven/Gradle plugin or Docker Compose handles this, but it adds complexity), (2) port conflicts if multiple WireMock instances are needed, and (3) shared state between tests — if Test A configures a stub and Test B depends on a different stub for the same endpoint, they interfere. The solution is to reset WireMock between test suites (POST to /__admin/reset) or use the standalone server only for test suites that don't need isolation.

WireMock with Testcontainers — WireMock runs inside a Docker container, managed by the Testcontainers library (new WireMockContainer("wiremock/wiremock:3.x")). Testcontainers starts the container on a random port before tests and stops it after. This is ideal for: CI pipelines where you want WireMock isolated from the test JVM (the WireMock container can be restarted independently, its logs are separate, and resource limits can be applied), tests that need a specific WireMock version or configuration that differs from what's available in the JUnit extension, and environments where WireMock needs to be accessible to multiple processes (the test JVM AND the system under test if it runs in a separate JVM). The trade-offs: (1) container startup overhead — Docker container startup takes 2-10 seconds, compared to sub-second for the JUnit extension, (2) Docker dependency — CI must have Docker available, which may not be the case in all environments (some CI runners use Docker-out-of-Docker or have restrictions), and (3) slighter slower response times — an extra network hop from the test JVM to the container, though this is negligible for integration testing (typically < 5ms).

My decision matrix: For local development and fast PR feedback — JUnit 5 extension with dynamic ports and per-class lifecycle. Speed matters most here, and the JVM integration gives sub-millisecond WireMock response times. For CI integration tests — JUnit 5 extension if tests are all in one JVM, Testcontainers if the system under test runs in a separate process and needs to reach WireMock over the network. For shared test environments (staging-like environment used by multiple teams) — standalone server or Testcontainers with pre-loaded stub mappings. For manual exploratory testing — standalone server with the Admin API for ad-hoc stub configuration. At Accenture, Mitchell's team standardised on the JUnit 5 extension for 90% of their tests, used Testcontainers for the 10% that needed cross-process WireMock access, and maintained a standalone WireMock Docker Compose configuration for the shared integration-test environment. The key principle: prefer the JUnit extension unless you have a specific reason to need a separate process — it is faster, simpler, and gives you per-test isolation by default. For more on Testcontainers integration, see our Testcontainers guide."

Q4: "How would you design a shared WireMock stubbing library that 8 teams can use across 40 microservices without duplicating stubs, without state leakage, and without tests that pass locally but fail in CI?"

What the interviewer is testing: This is the enterprise-architecture question — it tests whether you can design shared test infrastructure that scales across teams, and whether you understand that poorly designed shared stubs create more problems than they solve. Model answer: "A shared WireMock stubbing library is a trade-off between DRY (Don't Repeat Yourself — avoiding duplicate stub definitions) and test isolation (each test controlling its own stubs). The anti-pattern I've seen destroy team velocity: a single shared wiremock-stubs module that contains every downstream service's stubs, versioned independently, with breaking changes that force every team to upgrade on the stubs maintainer's schedule. This creates a bottleneck — the stubs maintainer becomes a dependency for every team's testing, and any breaking change to a stub causes cascading test failures across 40 microservices.

My design — the federated stubbing library: Instead of one monolith, each downstream service's WireMock stubs live alongside the service's API client library. Team A owns the inventory-service-client library — and alongside the client code (InventoryServiceClient.java), the library includes InventoryServiceStubs.java — a class with static methods that return pre-configured WireMock StubMapping objects or use a builder pattern: InventoryServiceStubs.stockAvailable(sku, quantity), InventoryServiceStubs.stockUnavailable(sku), InventoryServiceStubs.serviceUnavailable(), InventoryServiceStubs.slowResponse(Duration.ofSeconds(5)). Team B, which depends on the inventory service, imports the client library (which they already do for the client code) and gets the stubs for free — no separate dependency, no version-skew between client and stubs, no bottleneck maintainer.

State isolation — the three rules: (1) Every stub factory method takes a WireMockServer or WireMockRuntimeInfo parameter — never a static reference to a shared WireMock instance. This forces the calling test to pass in its own WireMock instance. (2) Stub factory methods are pure functions — they configure WireMock and return immediately. They do not hold state, do not depend on static variables, and do not assume any particular stub is already configured. (3) Every test class that uses stubs calls wireMock.resetAll() in @BeforeEach — this clears all stubs, scenarios, and request journal from the previous test, ensuring each test starts from a clean slate.

The stub-vs-fixture distinction: A stubbing library provides composable stubs — building blocks that each test assembles: InventoryStubs.stockAvailable(), PaymentStubs.paymentSucceeds(), NotificationStubs.emailSent(). A fixture provides a complete WireMock state for a specific scenario — all stubs pre-configured: OrderFulfilmentFixture.allDownstreamServicesHealthy(), OrderFulfilmentFixture.paymentServiceDown(). Fixtures are convenient but fragile — they couple the test to the fixture's assumptions about which downstream services are involved. My rule: provide composable stubs in the library. If a fixture is valuable (it is used by more than 3 test classes), extract it into the library as a higher-level abstraction that is built FROM the composable stubs — not as a separate monolithic class. At HMRC, Mitchell's team implemented this pattern for the tax-calculation microservice ecosystem: 12 downstream services, each with its own client library containing stubs, and 3 fixture classes for the most common integration-test scenarios. The result: zero stub duplication across 40 microservices, zero version-skew between clients and stubs, and new team members could write their first WireMock-based integration test in under 30 minutes because the stubs were self-documenting through the builder API. For more on test infrastructure design, see our test automation framework design guide."

Q5: "Explain WireMock's request matching. How would you handle a situation where the downstream service's behaviour depends on request body fields that change frequently?"

What the interviewer is testing: This question evaluates whether you understand that request matching precision is a maintenance-burden lever — and whether you can make deliberate precision-vs-maintenance trade-offs. Model answer: "WireMock supports request matching by URL (exact, path pattern, regex), HTTP method, headers, query parameters, cookies, request body (exact JSON, JSONPath, XPath, binary equality), and multipart form data. You can also write custom matchers by implementing RequestMatcher or using WireMock's ValueMatcher API. The sophistication — and the maintenance trap — is in how precisely you match.

The maintenance trap: matching on exact JSON request bodies. If your stub matches {"sku": "ABC-123", "quantity": 5, "warehouse": "LON-1"} and the upstream service adds a new field "priority": "normal" — the stub no longer matches, and the test fails even though the new field is irrelevant to the downstream service's behaviour. This creates a maintenance burden where every upstream schema change breaks every WireMock stub — and teams learn to hate WireMock because "the stubs keep breaking."

My precision-vs-maintenance decision framework: (1) For stubs where the response depends on the entire request body — e.g., a calculation service where the result is different for different inputs — match on the specific fields that affect the response using equalToJson() with ignoreExtraElements = true or ignoreArrayOrder = true. This lets the stub match even when extra fields are added. (2) For stubs where the response is always the same regardless of the request body — e.g., a health-check endpoint — do not match on the body at all. Match on method and URL only. (3) For stubs where the response depends on one or two request fields — use matchingJsonPath("$.sku") to match only those fields. The rest of the body is ignored. (4) For stubs that need to match across multiple similar requests — use WireMock's priorities: define a catch-all stub with low priority that matches any request to /api/orders and returns a default response, and define specific stubs with higher priority that match specific request characteristics (specific SKU, specific customer type) and return specific responses. (5) Use custom matchers for complex matching logic — e.g., a custom RequestMatcher that parses the request body, extracts the customerTier field, and matches based on business logic ("if customerTier is 'premium', return a discounted price"). Custom matchers keep the matching logic in code (testable, version-controlled, refactorable) rather than in JSON stub files.

The key principle: match on what determines the response, not on what happens to be in the request. Every field you add to a stub's matching criteria is a maintenance commitment — it will break when that field changes. At Co-op, Mitchell's team audited their 300+ WireMock stubs and found that 60% were matching on full JSON request bodies where only 1-2 fields actually determined the response. They refactored those stubs to use matchingJsonPath() — and stub-maintenance tickets dropped by 70% in the next quarter. The lesson: request-matching precision is a tool, not a virtue. Use the minimum precision that correctly distinguishes between the responses you need to simulate." For integration testing strategies, see our API testing guide.

Q6: "Explain WireMock proxying and record-playback. When would you use them — and what are the risks?"

What the interviewer is testing: This question evaluates whether you understand that proxying and record-playback are convenience features with production-scale risks — and whether you can articulate those risks and their mitigations. Model answer: "WireMock proxying and record-playback are two features that automate stub creation by capturing real HTTP traffic.

Proxying: WireMock is configured as a proxy — it forwards requests to a real downstream service, records the response, and can be configured to replay the recorded response on subsequent requests (without calling the real service). Configuration: stubFor(any(urlPathMatching("/api/.*")).willReturn(aResponse().proxiedFrom("https://real-inventory-service.com"))). Use case: you have a real downstream service available in a test environment, and you want to capture its behaviour once to create stubs for local development. The risk: (1) the recorded stubs capture one specific state of the downstream service — if the downstream service returns different data for different inputs, the recorded stub only covers the inputs that were sent during recording, (2) the recorded stubs capture the downstream service's current behaviour — if the downstream service changes its API, the recorded stubs become stale and tests pass with old behaviour, and (3) the recorded stubs may contain sensitive data — real customer data, real API keys, real authentication tokens — that must be cleaned before the stubs are committed to version control.

Record-playback: WireMock records live traffic (requests and responses between your application and a downstream service) and saves it as JSON stub mapping files. Use case: manual exploratory testing — you run through a user journey against a real downstream service, WireMock records every HTTP interaction, and you replay the recording to simulate the downstream service without it being available. The risk: recorded stubs are fragile — they capture exact URLs, exact request bodies, and exact response bodies. If anything changes (a timestamp, a UUID, a date format), the recorded stub no longer matches and the test breaks. Recorded stubs also tend to capture one happy path — they don't cover error scenarios, edge cases, or degraded behaviour.

My approach: Proxying and record-playback are useful for bootstrapping — generating an initial set of stubs from real traffic that you then hand-edit for comprehensiveness. They are NOT a substitute for hand-crafted stubs that cover the full behaviour spectrum: happy path, error responses, edge cases, degraded behaviour, and fault injection. I use proxying once to capture the real downstream service's response format — then I write stubs manually for every scenario I need to test, using the recorded response as a reference for structure (not as the stub itself). This gives me control over what the stub returns, ensures I cover error scenarios, and eliminates the fragility of recorded stubs. At BT, Mitchell's team used WireMock proxying to bootstrap stubs for a new downstream service that had no client library yet — they proxied 50 requests, used the captured responses as templates, and wrote 12 hand-crafted stub classes covering happy path, 4 error states, and 3 fault-injection scenarios. The proxying saved 2 days of reverse-engineering the downstream service's response format. The hand-crafted stubs provided the coverage and reliability that recorded stubs could never deliver."

Q7: "How do you debug a test failure when WireMock is involved? Walk me through your debugging process."

What the interviewer is testing: This is the operational-competence question — it tests whether you have actually debugged WireMock issues in production test suites, or whether your WireMock experience is limited to greenfield projects where stubs always match on the first try. Model answer: "When a WireMock-based test fails, I follow a systematic debugging process because the failure can originate in one of five places: the stub configuration, the request matching, the test's WireMock instance lifecycle, the system under test, or the test assertion.

(1) Check the WireMock request journal — every request WireMock receives is logged with its URL, method, headers, and body, plus the matched stub (or 'no match' if no stub was found). The request journal is your first debugging tool: wireMock.getAllServeEvents() returns every request WireMock received and whether it matched a stub. If the request journal shows 'no match' — the stub didn't match the actual request. The journal shows the exact request that was made, so you can compare it to the stub's matching criteria. Common 'no match' causes: the URL includes a trailing slash but the stub doesn't; the Content-Type header is application/json;charset=UTF-8 but the stub matches application/json; the request body has extra whitespace or a different field order; the stub matches on a header that isn't sent.

(2) If the request journal shows the request matched a stub — but the test still fails — the issue is either the stub's response (doesn't match what the system under test expects) or the test assertion (asserts the wrong thing). Use WireMock's getStubMappings() to verify the stub is configured correctly. Use wireMock.getSingleServeEvent() to see the exact request-response pair for the most recent request. Use your IDE's debugger to step through the system under test and see what it does with the stubbed response.

(3) If the test fails intermittently — it passes sometimes and fails other times — the most common causes in WireMock are: state leakage between tests (a previous test's stubs or scenarios survive into the current test because resetAll() wasn't called), port conflicts (two tests try to use the same WireMock port), and race conditions (the system under test makes a request before the stub is configured). The fix: always call wireMock.resetAll() in @BeforeEach, use dynamic ports (httpPort = 0), and ensure stubs are configured before the system under test is exercised.

(4) My favourite debugging technique for complex matching issues: temporarily replace the stub with a catch-all that logs the request body. stubFor(any(urlPathMatching("/api/.*")).willReturn(aResponse().withStatus(200).withBody("OK"))) and then inspect the request journal to see the exact request that was made. This tells you whether the issue is the stub matching criteria or something else entirely (the system under test isn't making the expected request, the URL is wrong, the HTTP method is wrong). At HMRC, Mitchell's team added a WireMockDebugListener that logged every unmatched request to the test output with the stub's matching criteria — this eliminated the most common debugging step ("why didn't my stub match?") because the answer was printed in the test output before you even opened the debugger. For more on debugging strategies, see our logging and debugging guide."

Real WireMock Interview Scenarios — What Panels Actually Ask

Drawing from panels Mitchell has conducted at HMRC, the Ministry of Defence, Nationwide, and consulting for Accenture, here are the WireMock scenarios that appear in SDET interviews — and what a strong answer looks like for each.

5 Common WireMock Mistakes That Cost Candidates Offers

After watching hundreds of candidates navigate WireMock questions, Mitchell has identified the specific mistakes that cause interviewers to lean back and wait for the next candidate. These aren't gaps in WireMock knowledge — they're gaps in how you present your experience with API mocking.

From 11pm Uncertainty to Interview Confidence — Your WireMock Preparation Plan

You now have the WireMock knowledge that separates candidates who have run stubs from candidates who have designed API mocking infrastructure. Here is how to turn that knowledge into interview-conversation fluency before your interview tomorrow:

1. Write a fault-injection test tonight. Pick a microservice you have access to — any microservice that calls a downstream API. Add WireMock as a test dependency. Write one test that stubs the downstream API to return 500. Write one test that stubs it to return a 5-second delay. Write one test that stubs it to return malformed JSON. Observe how your system behaves. You will find bugs — probably tonight. And tomorrow, you will describe this experience in your interview with the specificity of someone who did it, not someone who read about it.
2. Practice the stubbing-vs-verification distinction aloud. The most common WireMock question is the simplest: "when do you stub and when do you verify?" Practice your answer until it flows naturally: "I stub to control downstream behaviour — the response my system receives. I verify only for side effects with no other observable outcome — audit events, notification dispatches. For everything else, I assert on my system's observable behaviour — the response it returns, the database state it creates, the message it publishes." This answer, delivered without hesitation, signals production-grade WireMock judgement.
3. Memorise two fault-injection war stories. Interviewers remember stories. "We had a mortgage-approval service that silently swallowed credit-check timeouts. Our WireMock fault-injection test simulated a 504 with a 30-second delay — and caught the bug in 4 seconds. The production incident it prevented? 3,000 mortgages per day could have been approved without credit checks." You do not need 20 years of experience — you need one genuine bug you found with fault injection, described with the specificity that makes it real.
4. Use SDET Interview Coach to drill WireMock-specific questions. The SDET Interview Coach iOS app (£4.99/month) includes a dedicated API Testing topic area with WireMock-specific questions calibrated to Junior through Lead seniority levels. The AI mock interviewer will ask you the exact questions from this guide — and grade your answers on technical accuracy, completeness, and communication. Run a 10-minute WireMock mock interview tonight. Identify your weak areas. Run it again. Walk into that interview with answers that demonstrate you have designed API mocking infrastructure, not just read about it.

Do not let "explain the difference between WireMock stubbing and verification" be the question that exposes the gap between your test-authoring experience and the API-mocking-infrastructure knowledge the panel is hiring for. Understand the stubbing-vs-verification distinction. Design the fault-injection matrix. Architect the shared stubbing library. Walk in ready.