A Refactor With No Behaviour Change Breaks 34 Tests

Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.

The brief you were given

Extracting a pricing calculation out of a service and calling it from the same place changes nothing a user can observe. It breaks 34 tests.

The trap — the fix that looks like good design and is not

Updating the 34 mocks to match the new call sequence. It takes an afternoon, the suite goes green, the refactor lands, and the process appears to have worked exactly as intended. The suite has simply been re-pinned to the new implementation, so the next structural change costs another afternoon, and the one after that costs another. Nothing about this is visible as a problem, because the cost is paid as a small tax on every future change rather than as a single failure — and the observable outcome is that the team gradually stops refactoring, without anyone deciding to.

Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.