Refactoring: Changing Structure Without Changing Behaviour · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.

Tidying code without breaking it

Computing · Software Engineering · ages 19-21
Name ______________________   Date ____________

  1. Which check should you run before editing and after each small refactoring step?

    • Only the compiler's syntax check
    • Only the code's line count
    • The relevant automated tests

  2. Which must be preserved during a refactoring?

    • Returned values and effects
    • The order of private helper definitions
    • The internal arrangement of helper functions

  3. Replacing a whole block in one edit automatically rules out refactoring, even if all observable behaviour is preserved.

    Circle one:   True   False

  4. You will rename and move a class. Which plan makes failures easier to locate?

    • Rename and move together, then update imports
    • Move the class, leave its existing uses in place, then test
    • Separate the changes, update uses and imports, and check each

  5. A billing function reads input, computes a bill and prints it. Which extraction plan best supports preserving its behaviour?

    • Extract the bill and revise its rounding
    • Extract one job, preserve its inputs and effects, then test
    • Extract printing and check just the returned total

  6. A previously passing check fails after one extraction. What is a useful next action?

    • Update the expectation to match the extracted code
    • Investigate the failure; undo the latest edit if needed
    • Finish extracting the remaining jobs before inspecting this failure

  7. Passing tests after every refactoring step prove that behaviour is unchanged for all inputs and effects.

    Circle one:   True   False

  8. A teammate combines a bug fix with helper extraction and labels the whole change refactoring. How should the review distinguish the work?

    • Separate the intended behaviour change from the restructuring
    • Review the extracted helpers and leave the bug fix implicit
    • Use the passing old tests to review the combined change as restructuring
LightMySky · lightmysky.comW1-mt_HHZufOyTg4-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Tidying code without breaking it W1-mt_HHZufOyTg4-s1

  1. The relevant automated tests · Relevant tests compare tested behaviour before and after the edit. A pass is evidence for those checks, not proof of full equivalence.
  2. Returned values and effects · Refactoring preserves observable behaviour. Private helper definitions may be reordered or rearranged while preserving that behaviour and promised public import paths.
  3. False · Edit size alone does not decide the classification. Small steps make behaviour-preserving changes easier to check.
  4. Separate the changes, update uses and imports, and check each · Separate checks help identify which change introduced a problem. Either rename-first or move-first can work.
  5. Extract one job, preserve its inputs and effects, then test · Extract one job while preserving what it receives, returns and does. Check before extracting the next job.
  6. Investigate the failure; undo the latest edit if needed · Inspect the failure before continuing. Undoing the small edit can restore the baseline while you find its cause.
  7. False · Passing tests establish their checks. Untested inputs, effects or weak assertions can leave a behaviour change undetected.
  8. Separate the intended behaviour change from the restructuring · The bug fix intentionally changes behaviour. The extraction should preserve behaviour and can be reviewed separately.
Worksheet · LightMySky