Bestandsverhalten und Regression prüfen

Characterization & Regression Checks

When legacy code lacks reliable tests, refactoring blind risks breaking subtle edge cases that users or downstream systems depend on. Build a targeted safety net that records what the code actually does before changing how it is structured.

1. Characterization Tests (Michael Feathers)

A characterization test documents actual current behavior, even when that behavior looks idiosyncratic:

1. Invoke the unit through its stable boundary (public function, service method, HTTP handler or CLI runner) using representative inputs.
2. Observe the actual output, state changes and side effects produced by the current implementation.
3. Assert those exact outcomes in the test suite so any unintended deviation during refactoring fails immediately.
4. Cover the critical matrix:
   • Typical happy-path inputs.
   • Empty, null, undefined, zero and boundary-length inputs.
   • Malformed inputs, validation failures and thrown error types/messages.
   • Ordering, rounding, timezone, locale and duplicate-item behavior.

If a characterization test uncovers an obvious bug, do not silently alter the behavior during a structural refactoring. Mark the test clearly, record the finding, and confirm with the product analyst or a reviewer/tester whether fixing it is in scope.

2. Golden Master / Approval Testing

For complex outputs (large JSON payloads, rendered HTML/templates, SQL query builders, financial calculation tables or report exports):

• Capture deterministic baseline outputs (Golden Masters) across a curated set of input fixtures before touching the implementation.
• Normalize non-deterministic fields (timestamps, random UUIDs, unordered set keys) via injected clocks/ID generators or deterministic serializers rather than weakening assertions.
• Compare the refactored implementation's outputs byte-for-byte or structure-for-structure against the baseline after each refactoring step.

3. Testing Behavior, Not Implementation Details

Tests written for refactoring must survive internal restructuring:

• Assert at stable boundaries: test public module contracts, HTTP/IPC responses, persisted records and emitted domain events — not private helper calls or internal call counts.
• Avoid over-mocking internal collaborators: if a test mocks every internal class you plan to merge or split, the test will break on every refactoring step while proving nothing about real integration. Mock only true external boundaries (third-party APIs, payment gateways, clock, filesystem).
• Check side-effect parity: verify that database writes, cache invalidations, emitted events and log/error codes still occur in the expected order and transaction scope.

4. Verification Cadence & Handoff

• Run the characterization suite before the first structural edit (confirming it passes against unmodified code) and after every step.
• Combine characterization tests with the project's existing typecheck, linter and build pipeline.
• At handoff, report what characterization checks were added, which invariants were verified, and any areas that could not be exercised automatically.