Embedded Instances

## The habit this question is probing An embedded WireMock instance has to listen somewhere, and the shortest thing to write is a number. A fixture that constructs `new WireMockServer()` with no options takes WireMock's default port; a fixture that writes a number in by hand takes whichever one somebody typed that afternoon. Either way the suite has staked a claim on a **machine-wide resource it does not own**. Nothing inside the test JVM can guarantee that claim: a leftover server from a run that crashed before `stop()` was reached, a local development stack, an unrelated tool, or a second copy of the same fixture is enough to lose it. The failure that follows is the worst kind, because it does not describe the problem. The suite dies during set-up with a bind error, the stack trace names the server rather than the test, and re-running the job sometimes works — which quietly teaches the team that the test is "flaky" rather than that the fixture is wrong. ## What dynamicPort() actually does `wireMockConfig()` builds WireMock's configuration object, and `dynamicPort()` on it says: do not name a port, ask the operating system for a free one. The request is made when `start()` runs, so the sequence is: 1. The fixture builds the configuration and constructs `new WireMockServer(wireMockConfig().dynamicPort())`. 2. `start()` binds, and the operating system hands back a free ephemeral port. 3. Only at that moment does the instance have an address. WireMock has a matching `dynamicHttpsPort()` on the same configuration object, with the same meaning for the HTTPS listener. ## The consequence people miss The port does not exist until start-up. That single fact rules out everything a fixed port made easy: - No constant in the test class can hold the URL. - No property file checked into the repository can hold it either. - Nothing may read the address **before** `start()` has returned. - The code under test cannot point at a hardcoded upstream and still be exercised by this fixture. So the resolved value has to travel from the running instance into the test at run time. In a JUnit 5 test annotated `@WireMockTest`, that is precisely what `WireMockRuntimeInfo` is for: the annotation starts the instance — taking a free port unless you tell it otherwise — and any test method that declares a `WireMockRuntimeInfo` parameter receives the resolved port and base URL. A fixture that constructs the server itself reads the same information back from the instance it started, after `start()`. ## What it forces on the code under test, and why that is good A client that can only talk to a constant address cannot be pointed at a stub at all. So making the port dynamic quietly forces the design most teams want anyway: the upstream base URL becomes a **constructor argument, a builder value or a configuration property** rather than a literal buried in the client. The curling-club ladder client stops containing a fixed `https://ladders.example` and starts taking whatever address it is given. That is the same shape that later lets it be pointed at a staging deployment, a recorded mapping set, or the real service, without touching the client at all. Worth saying out loud in an interview, because it reframes the answer from "avoid a port clash" to "the fixture and the production wiring want the same property". ## Diagnosing the fixed-port failure When you inherit a suite that still names ports, the tell is consistent: - It passes on one machine and fails on another with no difference in test logic. - It fails during set-up, before any assertion has had a chance to run. - The error mentions binding or an address already in use, not a stub or a match. - Leaving a stray process on that number reproduces it on demand, which is the cheapest confirmation available. The fix is mechanical rather than clever: move every fixture to WireMock's `wireMockConfig().dynamicPort()`, then follow the compiler and the failures to every place that assumed the old number — the client's default, a test property, a hand-written URL in an assertion. ## The neighbouring product In MockServer, `ClientAndServer.startClientAndServer()` called with no port argument does the same thing: it takes a free port when the in-process server starts, and the fixture reads the address back from the client it returns. ## What the interviewer is listening for - That you name WireMock's mechanism, `dynamicPort()`, and not just the advice. - That you know the value is unavailable until `start()` has returned. - That you can say how the address reaches the code under test, and what that requires of the client. - That you treat a bind failure as a design defect in the fixture rather than an unlucky run to be retried.