SoapUI

## The arrangement in one sentence SoapUI's defining arrangement is that **the request set is derived, not authored**. You point the tool at a machine-readable description of a service, and a request for each declared operation comes into existence without anyone typing a call by hand. Everything else follows from that single relationship: the description is **upstream**, the request set is **downstream**, and the direction of that arrow never reverses. A person may edit a generated request afterwards, but nobody decides *which* requests exist — the document does. The description document itself — its format, its parts, and the contract-first code generation people do off it — is a separate subject belonging to the SOAP/WSDL material. What matters here is only the relationship: one document, many requests, generated in one direction. ## Why derivation changes the character of the request set - **Coverage stops being a matter of diligence.** Every declared operation gets a request because the generator walked the document, not because a tester remembered it existed. Nobody has to keep a mental list of the calls a service supports. - **Shape is not a matter of taste.** The skeleton of each call — its name, the fields it expects — comes from the same authority for everyone on the team, so two engineers generating from the same document get the same starting point. - **Onboarding collapses to reading one document.** A newcomer does not learn the interface from a colleague's saved calls; they learn it from the thing that generated them. - **Absence becomes informative.** An operation that never appears in the generated set was never declared in the description — which is itself a finding worth raising. - **The unit of change moves upstream.** When the interface changes, the correct response is to change the description and re-derive, not to hand-patch a dozen saved calls. ## The cost: drift between a saved artefact and a moving interface Generation happens once, at a moment in time. After that the requests are **saved artefacts**: they do not re-derive themselves, and they do not notice that the service moved. The drift lifecycle is worth being able to narrate: 1. A description is published and the request set is generated from it. 2. The service evolves; an operation is renamed, added, or its expected fields change. 3. The saved requests keep the **old** shape. Nothing is broken loudly — they simply describe an interface that is no longer the one being published. 4. Someone regenerates. Everything added by hand downstream of generation — a tuned value, a comment, a deliberate edge case — is now at risk of being replaced by a fresh skeleton. 5. So the discipline is to know which local edits you cannot afford to lose, and to keep them somewhere regeneration does not own. That fourth step is the one candidates miss. The value of derivation is that the document decides; the price of derivation is that anything you add after the document has decided lives on borrowed time. ## Typed by hand versus derived from a description | Aspect | Typed by hand | Derived from a description | |---|---|---| | Where the operation list comes from | Someone's memory, or prose docs | The published machine-readable description | | Coverage of declared operations | Whatever the author got round to | Complete by construction, at generation time | | Cost of an interface change | Hunt down and edit each affected call | Republish the description, re-derive | | Typical failure mode | A call that was never written at all | A stale call nobody regenerated | | Risk to local customisation | None — you wrote every character | Regeneration can overwrite hand edits | ## What the arrangement does not give you Derivation is evidence about **agreement with a document**, never about a running system. Two things in particular do not follow from it: - It does not prove the deployed service behaves the way its description says. A description can be aspirational, stale, or simply wrong, and the generated requests will faithfully reproduce that error. - It does not replace the checks you attach to a request. Generation gives you a call to make; deciding what a good answer looks like is still a human judgement. ## How to answer this in an interview Lead with the direction of the arrow: the description is upstream of the requests, so coverage and shape are properties of the document rather than of the person. Then name the price in the same breath — staleness and the fate of hand edits at regeneration time — because a candidate who names only the benefit sounds like they have read about the tool rather than lived with it.