Which WireMock artifact do you declare to run an embedded stub server in a Java test?

## What "embedded" means here An **embedded** WireMock instance runs inside the test JVM itself. There is no separate process to launch, no image to pull, and no port published by anything other than your own test: the suite constructs the server, starts it, points the code under test at it, and stops it again when the test is done. For a client that reads a curling-club ladder — `GET /ladders/tayside-a/standings`, returning the rinks in finishing order — that means the entire fixture is ordinary Java sitting on the test classpath. Which is exactly why the very first question is *which artifact do I declare*, and why an interviewer treats a confident, correct answer as a signal that you have actually done this rather than copied a snippet. ## The coordinate to declare The aggregate artifact is `org.wiremock:wiremock`. It is still the coordinate WireMock's own documentation leads with, and it exists precisely so that a single dependency line gives you everything you need: the server, the static `stubFor(...)` DSL, and the JUnit integrations. The Maven **group** is `org.wiremock`. That is worth committing to memory on its own, because the artifact many people still type from muscle memory belongs to a group that no longer publishes it. ## The WireMock 4 module set WireMock 4 is modularised. Alongside the aggregate it publishes a set of narrower modules: - `wiremock-core` — the server, the matching engine and the data model, with no test-framework glue at all. - `wiremock-junit4` — the `WireMockRule` integration for JUnit 4 suites. - `wiremock-junit5` — the `@WireMockTest` annotation and `WireMockExtension`. - `wiremock-jetty` — the HTTP server implementation the core binds a port through. - `wiremock-httpclient-apache5` — the HTTP client implementation used when WireMock itself makes outbound calls. - `wiremock-standalone` — a shaded uber-jar, built to be launched as its own process. The point to hold on to is that **the modular set is an alternative, not a replacement**. Nobody is pushed off `org.wiremock:wiremock`; the modules exist for teams that want to pin a narrow surface — a shared test harness, for example, that drives the server programmatically and never touches a JUnit annotation, and therefore has no business forcing a JUnit integration onto every consumer. ## Artifacts that are not the one you want | artifact | what it is | embed it? | |---|---|---| | `org.wiremock:wiremock` | the aggregate, still the primary coordinate | yes | | `wiremock-core` + `wiremock-junit5` | the narrow modular pair | yes, when you want to pin | | `wiremock-standalone` | shaded uber-jar for a separate process | no | | `wiremock-jre8` | an artifact from the previous major line | it does not exist any more | `wiremock-standalone` deserves a sentence of its own. It is a legitimate artifact and it is not discouraged — it is simply for a different hosting shape. It shades its dependencies so that it can be launched as a self-contained process, which is the opposite of what you want on a test classpath, where a shaded copy of a library your application already brings is a source of confusing run-time behaviour rather than a clean build error. `wiremock-jre8` is the trap. It was published for a Java 8 baseline on the previous major line, and it is gone. WireMock 4's baseline is Java 17, so a separate JRE-8 build has nothing left to be. ## What the dependency actually buys you Once the artifact is on the test classpath there are two ways to get a running instance, and both are this subject's material: 1. Construct the server yourself — `new WireMockServer(wireMockConfig().dynamicPort())`, then `start()` and `stop()` around your tests. 2. Let the JUnit integration do it — `@WireMockTest` from `wiremock-junit5`, which starts and stops an instance for you and hands the test a `WireMockRuntimeInfo` carrying the resolved port and base URL. Either way the stub itself is written with the same WireMock DSL: `stubFor(get(urlPathEqualTo("/ladders/tayside-a/standings")).willReturn(aResponse().withStatus(200).withBody("[]")))`. ## The comparison worth knowing In MockServer the equivalent in-process entry point ships in `mockserver-netty` and is reached through `ClientAndServer.startClientAndServer()`, which starts a server in the current JVM and returns a client bound to it. ## What the interviewer is checking - That you can name the aggregate coordinate and its group, rather than reciting a stale one from memory. - That you can say why `wiremock-standalone` is the wrong dependency to embed, and what it is actually for. - That you treat the modules as an option you may take, not as a migration you are obliged to perform. None of that is trivia. A build file that still names `wiremock-jre8` will not resolve at all, and a build file that embeds `wiremock-standalone` will resolve happily and then misbehave at run time in ways that look nothing like a dependency problem.