In WireMock, which four Fault values can withFault() take, and what does each do?

## Four constants, and no fifth WireMock's fault injection is a single enum, `Fault`, passed to `withFault(...)` on the response builder. The enum's members are `EMPTY_RESPONSE`, `CONNECTION_RESET_BY_PEER`, `MALFORMED_RESPONSE_CHUNK` and `RANDOM_DATA_THEN_CLOSE`. That is the complete list. It is worth stating flatly, because this is one of the places where confident memory invents members that do not exist — a timeout fault, a slow-response fault, a refused-connection fault. None of those are in the enum, and reaching for one in an interview or a code review is an immediate tell. A fault is used *instead of* a status code, not alongside one. A stub reads `stubFor(post(urlEqualTo("/auctions/v1/lots/48/bids")).willReturn(aResponse().withFault(Fault.CONNECTION_RESET_BY_PEER)))`; there is no `withStatus(...)` in that chain, because nothing resembling a normal reply is going to be written. ## What each one does on the wire The four are not interchangeable. They fail a client at different depths: - `EMPTY_RESPONSE` — the connection is closed with nothing written. The client never sees a status line, so it fails at the socket and IO layer. - `CONNECTION_RESET_BY_PEER` — the connection is reset rather than closed cleanly. Clients typically surface this as a distinct reset error, and some retry policies treat a reset differently from a clean close. - `MALFORMED_RESPONSE_CHUNK` — an OK status header is written first, then garbage, then the connection closes. The client accepts the response line and then fails part-way through reading the body. - `RANDOM_DATA_THEN_CLOSE` — random bytes are written with no valid status line at all, then the connection closes. The client's HTTP parser rejects the stream before there is anything to accept. The useful split is between the two that give the client nothing to parse (`EMPTY_RESPONSE`, `CONNECTION_RESET_BY_PEER`) and the two that give it something invalid to parse (`MALFORMED_RESPONSE_CHUNK`, `RANDOM_DATA_THEN_CLOSE`). ## Why a fault is not a status, a delay or a timeout Three confusions are common enough to be worth naming: 1. **A fault is not a status code.** WireMock's `Fault.EMPTY_RESPONSE` is not a 204 and not an empty 200. A 204 is a complete, valid reply with a status line, headers, and an intact connection; the client gets a response object it can inspect. `EMPTY_RESPONSE` gives it nothing at all. 2. **A fault is not a delay.** Nothing in the `Fault` enum makes a response slow. WireMock's delay controls are a separate family of methods and belong to a different discussion; injecting a fault fails a request, it does not stall one. 3. **A fault is not a client timeout.** A dropped or reset connection usually fails fast. If the behaviour you actually need to test is a client that waits and gives up, a fault is the wrong tool. ## Choosing between the four for a cattle-auction stub | what you want to test | the WireMock constant | |---|---| | the client's socket and IO error path | `Fault.EMPTY_RESPONSE` | | a reset seen distinctly from a clean close | `Fault.CONNECTION_RESET_BY_PEER` | | a body parser that must survive truncation | `Fault.MALFORMED_RESPONSE_CHUNK` | | a parser given a stream that is not HTTP | `Fault.RANDOM_DATA_THEN_CLOSE` | If the bid client under test wraps every downstream call in a single catch-all, all four will look identical in your assertions, and that is a signal about the client rather than about WireMock. Faults become useful precisely when the client distinguishes between "could not reach the ring service", "got an unreadable answer" and "got a bad status". ## Keeping the attribution straight The hard part of this topic is not the four names; it is remembering whose they are. WireMock spells its control as a decoration on the reply builder, `aResponse().withFault(...)`. MockServer, by contrast, does not have a fault enum at all — it models the same territory as a separate action, `error(...)`, carrying `withDropConnection(Boolean)` on `HttpError`. Because a fault and an error action are shaped differently, a stub cannot be ported from one server to the other by renaming a method. So write and review these sentences with the product attached. Three habits keep a claim checkable: - name the product in the sentence itself, not once per paragraph; - say how many values there are, because a list that has drifted is easiest to spot by its count; - name the enum as well as the constant — `Fault.EMPTY_RESPONSE`, never a bare `EMPTY_RESPONSE`. A final practical note: because a fault replaces the reply, a stub carrying one is easy to lose track of in a large mapping set. Give it an obvious path — a dedicated lot number in the cattle-auction scenario — so that a reader scanning the stubs can see which endpoint has been deliberately made hostile and which is merely misconfigured.