In WireMock, what do the mappings/ and __files/ directories hold for a museum ticketing stub set?
answer
- definitions in one, bodies in the other
- matcher plus canned response per file
- bodyFileName resolves under __files/
- inline body means no file at all
- nothing in WireMock ever retires a file
basics
~20 sIn WireMock, mappings/ holds the JSON stub definitions, each a request matcher plus a canned response. WireMock's __files/ holds the response bodies those definitions name with bodyFileName. Both directories only ever grow: nothing in the server retires a file.
solid answer
~50 sA WireMock stub set on disk is two directories. WireMock's `mappings/` holds JSON stub definitions — each one a request matcher, such as a `GET` on `/exhibitions/SUMMER-26/sessions`, paired with the canned response to return. `__files/` holds the response bodies; a definition points at one with `bodyFileName`, and WireMock resolves that path relative to `__files/`. A WireMock body can instead be inlined in the definition with `body`, in which case nothing lands in `__files/` at all. The pair sprawls because it only ever grows: every recorded session, every new error case and every one-off experiment adds files, and neither the server nor the build ever retires one. A body file that no mapping references any more is invisible — nothing reads it and nothing warns. Mountebank keeps the equivalent persisted state under the directory given to `--datadir`.
code
json · 13 lines{
"name": "summer-exhibition-sessions-ok",
"request": {
"method": "GET",
"urlPath": "/exhibitions/SUMMER-26/sessions"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"bodyFileName": "exhibitions/summer-26-sessions.json"
},
"metadata": { "owner": "ticketing-squad", "case": "happy path" }
}go deeper
Be ready to say which directory holds what: mappings/ for stub definitions, __files/ for response bodies, linked by bodyFileName. Interviewers ask this to check you have actually opened a WireMock stub set.
Explain the two ways a definition carries a body, why the reference is one-directional, and why several definitions can legitimately share a single file under __files/.
Talk about the growth curve: recordings and one-off experiments add files that nothing retires, orphaned bodies are invisible to the server, and a scan across mappings/ is the only way to find them.
Own the question of when a large catalogue becomes a liability. Argue that the threshold is confidence, not file count, and that naming and owner metadata are what keep deletion possible at all.
## Two directories, two jobs A WireMock stub set on disk is a pair of directories that live side by side. - WireMock's `mappings/` holds **stub definitions**. Each JSON file describes what to match — a method and a URL, plus optional headers, query parameters or body conditions — and what to send back: a status, headers and a body. - WireMock's `__files/` holds **response bodies**, as ordinary files. A JSON payload, an XML document, an image, a PDF: whatever a stub needs to return that is too big or too awkward to sit inside the definition. For a museum ticketing API, the WireMock definition `mappings/summer-exhibition-sessions-ok.json` might match `GET /exhibitions/SUMMER-26/sessions` and answer `200`, while the actual list of session times lives in `__files/exhibitions/summer-26-sessions.json`. One file says *when to answer*, the other says *what to answer with*. The names are not arbitrary. WireMock looks for stub definitions under `mappings/` and body files under `__files/`, and the double underscore keeps the body store sorted and visually distinct from the definitions beside it. ## How a definition finds its body A definition can carry its response body in one of two ways. - **Inline**, with a WireMock `body` or `jsonBody` value inside the response block, in which case nothing lands in `__files/` at all. Good for a short error payload, painful for anything with structure. - **By reference**, with WireMock's `bodyFileName`, whose value is a path resolved relative to `__files/`, so `"bodyFileName": "exhibitions/summer-26-sessions.json"` reads `__files/exhibitions/summer-26-sessions.json`. From the Java DSL the same choice is `withBody(` for the inline form and `withBodyFile(` for the referenced one; in WireMock, `withBodyFile(` is the HTTP body-file setter, and the path it takes is again relative to `__files/`. The reference is one-directional. The definition names the file; the file has no idea which definitions point at it, and several definitions may point at the same one. ## Why the pair only ever grows Sprawl is not a defect in the format. It is the natural consequence of a store with no retirement mechanism. - Every new test case that needs a different answer adds a definition, and usually a body file with it. - Every recording session writes a fresh batch of both, named after whatever the recorder saw. - Every one-off experiment — a `503` for the ticket-issue path, a lapsed membership, a sold-out session — leaves files behind after the branch merges. - Nothing deletes. The server does not expire a mapping, the build does not fail on an unused one, and no test asserts that the catalogue is smaller than it was. - Nobody feels able to delete either, because a definition's file name rarely says which suite depends on it. A museum ticketing set that started at six definitions is at four hundred a year later, and every individual step along the way was entirely reasonable. ## The orphan nobody sees The most persistent sprawl is on WireMock's `__files/` side. Delete a definition and its body file stays behind: nothing loads it, nothing warns about it, and no admin call reports it. It is a file in your repository with no reader and no owner. Two habits keep that manageable: - When you delete a WireMock definition, look up the file its `bodyFileName` named — and check that no other definition names it too. - Scan periodically for body files that no remaining definition references. It is a text search across WireMock's `mappings/`, and it is the only thing that finds them. ## What to check when the directory gets big - Count both directories: a WireMock `__files/` much larger than its `mappings/` usually means orphans have accumulated. - Look for near-duplicate definitions matching the same path with slightly different bodies — the classic sign of two teams solving the same problem twice. - Look for WireMock definitions with no `name` and no `metadata`; an unnamed stub is one nobody can claim later. - Ask what would happen if you deleted a given file. If the honest answer is *nobody knows*, that is the real state of the catalogue. That last question is the point. A large WireMock `mappings/` directory is not a problem in itself — a mature museum ticketing suite legitimately needs a lot of canned answers. It becomes a problem the moment the set is larger than anyone's confidence about it, because from then on every file is kept by default and the directory can only grow.
- In WireMock, when would you inline a response body instead of putting it under __files/?When the body is small and reading it beside the matcher helps — a short error payload such as `{"error":"session_sold_out"}` on the ticket-issue path. Anything with real structure, like a full session listing, belongs in `__files/` and is referenced with `bodyFileName`, because a large body inlined in the definition makes the matcher impossible to read and the diff impossible to review.
- How would you find WireMock body files under __files/ that no mapping references any more?Search every definition under `mappings/` for its `bodyFileName` values, build the set of referenced paths, and subtract it from the files actually present under `__files/`. Nothing in the server does this for you: an unreferenced body is never loaded, never warned about and never listed by any admin call, so it survives indefinitely unless a scan like this finds it.
Think of the museum's own prop store: a mappings file is the catalogue card saying which scene needs a prop, and __files holds the props themselves. Every new production adds a card and a prop, and nobody is ever assigned to clear the shelf.
saying these in an interview costs you the question
- Thinking __files/ holds stub definitions too
- Assuming bodyFileName is a path relative to mappings/
- Believing WireMock warns about unreferenced body files
- Expecting a body file to be removed with its definition
- Treating a large mappings/ directory as automatically wrong