A unit test needs a 60-line setup block and its class takes eleven constructor parameters — what is that telling you about the design?

### Test pain is a measurement, not a chore The practice at issue is usually called **listening to the tests**: treating difficulty in writing or maintaining a test as data about the production design rather than as an inconvenience of testing. It matters in emergent design because the arrangement block is where the cost of a structure shows up first. A test is the earliest independent client of the unit; it has to build whatever the unit demands, with no framework wiring to hide the bill. So a long setup and a wide constructor are one observation stated twice: **this unit is coupled to that many things.** Sixty lines of arrangement do not mean the test is bad. They mean the design asks for sixty lines of context before it will do anything. ### The common signals and what each one reports | What hurts in the test | What the production code is telling you | | --- | --- | | Long arrangement, many collaborators built | The unit depends on too many things; responsibilities are clumped | | Several collaborators always constructed together | Those collaborators are one missing concept | | The test reaches through one object to set up another | The unit reaches too; the dependency is transitive and hidden | | You must assert on internals to see the effect | The behaviour has no observable outcome; the interface is wrong | | A combinatorial blow-up of cases | One unit is making several independent decisions | | Setup grows every time any feature is added | The unit is a hub everything must be threaded through | ### The wrong responses Almost every wrong answer here consists of making the *test* more comfortable while leaving the design exactly as it was: * a shared setup helper that builds the eleven collaborators once for the whole file — now the coupling is real and invisible, and one change to it ripples through every case; * a builder whose only job is to hide the width of the constructor; * standing in for every collaborator so nothing has to be built — the count of stand-ins is itself the measurement, and hiding it discards the signal; * declaring the class "just wiring, framework requires it" when nothing about the framework required eleven parameters. The right response puts the change in the production code, and emergent design says exactly when to make it: in the restructuring beat, with the suite green. ### A worked example In a marketplace bidding engine, `BidAcceptor` accumulates eleven constructor parameters — auction store, bid store, clock, fee schedule, currency converter, audit writer, notifier, rate limiter, fraud score client, feature flags, metrics. Its unit test needs 63 lines before it can assert that a bid 40 cents above the leader wins. Reading the clumps: the clock, the close time and the extend window always appear together and are only ever used to answer "is this bid in time" — that is an auction-clock concept. The audit writer, the notifier and the metrics recorder are always used *after* an outcome is decided — that is one outcome-publication role, and the acceptor should return an outcome rather than perform three side effects. The fee schedule and the currency converter are only used to price the bid — a pricing collaborator. After those three extractions the acceptor takes four parameters, its test arranges in nine lines, and the three new units have their own small tests. Nothing was designed up front: the clumps were visible only because eleven parameters had accumulated one test at a time. ### Why the interviewer asks Because it separates two attitudes. One treats tests as an obligation that gets more expensive as the system grows, so the answer is better test infrastructure. The other treats the cost curve of the tests as the cheapest available reading on the design, and answers by changing the design. The second attitude is what makes emergent design work at all: without it, the signals arrive and get absorbed by helpers. ### Caveats worth voicing Not every long setup is a design defect. Genuinely stateful domains need real fixtures, and a test at a coarser level legitimately arranges more than a unit test does. The signal is *the trend and the clumping*, not the raw line count: setup that grows monotonically, or the same group of collaborators appearing together in every case, is the part that reports coupling. And the response is always a small restructuring under a green suite — you do not stop delivering to redesign, because the whole point is that this correction is cheap when taken early.