While refactoring production code under a green suite, may you edit the tests in the same step?

## Why one side has to be frozen A refactoring makes a claim: structure changed, observable behaviour did not. The suite is what tests that claim, and a test only has authority over code it was not written against. The moment you edit an assertion in the same step as the production code it guards, the two changes can cancel: you alter behaviour by accident, alter the expectation to match, and the run comes back green. Nothing lied — you simply removed the observer and the observed at the same time. So the discipline is a simple alternation. During the refactor step, **production code is the variable and test code is the constant**. If the test code has to move, invert it: test code becomes the variable and production code the constant, and you verify the tests still pass against the unchanged implementation before touching structure again. ## The three cases people conflate **1. A test broke because the refactoring changed behaviour.** This is the net doing its job. Undo the move; do not touch the test. **2. A test broke because it was coupled to structure rather than behaviour** — it named a helper you renamed, counted calls to a collaborator you merged, or reached into an intermediate object you dissolved. Nothing about the system's observable behaviour changed, but the test cannot compile or cannot pass. This is where discipline earns its keep. The tempting move is to fix the assertion in place, mid-refactoring, which puts you in the cancelling state above. The disciplined move is: return to green, change the test alone so that it expresses the behaviour rather than the shape, confirm it passes against the untouched implementation, commit that, then resume the restructuring. **3. A test needs to exist that does not yet.** Adding a test is a different hat entirely. If you discover mid-refactor that the region is thinly covered, stop, add the test against current behaviour, watch it pass, and then continue. Writing that test after the restructuring means you are pinning whatever the code does now — including any drift you just introduced. ## The rename exception, and why it is not one A tool-driven rename that propagates a new name into test files does touch test source. It is still safe, because it changes no expectation: the same call is made, the same value is compared, only the identifier differs, and the change is applied mechanically rather than judged case by case. The distinguishing question is always *did any assertion's meaning change?* If a human decided what an expected value should now be, that is an edit to the oracle. If a tool substituted a token everywhere at once, it is not. ## Worked example An airline seat-map service exposes `cabinView(flightId)`. You want to split the sprawling builder into an availability part and a pricing part. Forty-seven tests cover the region; forty-four assert on the returned cabin view, three assert that the builder called an internal `resolveBlockedSeats` helper a specific number of times. The extraction is behaviour-preserving, and the forty-four stay green. The three break — not because behaviour drifted, but because they were written against the call structure. If you rewrite those three assertions while the extraction is half-applied, you no longer know whether the forty-four went green because behaviour survived or because you were lucky. Instead: undo the extraction, rewrite the three tests to assert on blocked seats appearing in the returned view, run them against the original implementation, commit, and only then redo the extraction. Now the extraction is guarded by forty-seven behaviour-level tests, and the fact that they all stay green means something. ## The smell of the rule being broken A change set where production and test files move together in a restructuring commit is the visible symptom, and the review question that catches it is simply "which assertions changed, and why?" A refactoring commit should be able to answer "none". If the answer is a list, the commit is a behaviour change wearing a refactoring's label, and its green suite proves nothing about the behaviour that was preserved. The deeper point is that discipline here is not ceremony: it is what makes the green run *informative*. A suite you are willing to edit whenever it disagrees with you is not an oracle; it is a transcript of your intentions.