Characterisation tests

Characterisation tests are written against code you did not write and do not fully understand. Instead of asserting what the system should do, they record what it does: feed known inputs, capture the outputs, and freeze them as the expected result. When you refactor, migrate or replace that code, the tests tell you whether behaviour changed. They characterise the system rather than specify it.

Typical forms include golden-master tests over reports or invoices, recorded API request and response pairs replayed against the new service, and database snapshot comparisons after a batch job. AI tooling helps here: it can generate hundreds of input cases from production logs and draft the harness around a legacy function far faster than a person would.

They are not unit tests of correctness. A characterisation test will happily enshrine a bug, such as a rounding error in GST calculation, because that is what the system does. That is deliberate: you first make the old behaviour visible, then decide which behaviours to keep and which to fix, and change the test when you change the intent.

• CTO / Head of Engineering: they are the only way to refactor an undocumented system with confidence; without them every change is a guess.
• CFO: they reduce the risk of a modernization producing different invoices, payroll or ledger totals than the system it replaces.
• Compliance officer: recorded behaviour becomes evidence that the new system reproduces the approved calculation logic.
• Operations head: they catch the edge cases that staff rely on but nobody wrote down, before go-live rather than after.

Legacy code rarely has tests, and its authors are often gone. Modernizing it without a safety net means discovering behaviour changes in production, usually via an angry customer or a wrong month-end figure. Characterisation tests exist to make the current behaviour explicit and machine-checkable before anyone touches the code. The trade-off is effort and a false sense of completeness: the tests only cover the inputs you thought to record, so they must be drawn from real production data, and they need to be revisited when a bug is intentionally fixed.

• Recording a year of invoice inputs and outputs from a manufacturer's ERP before migrating its pricing and GST logic to a new service.
• Replaying captured API traffic from a bank's core lending system against the new API layer to confirm identical responses.
• Snapshotting a university's fee-calculation results across every programme and category before re-platforming the fee module.
• Pinning a logistics firm's driver-settlement batch job output while its stored procedures are rewritten as application code.
• Capturing a hospital billing module's outputs across insurer schemes before the module is replaced.

Technique / practiceA testing practice that engineers apply during modernization, increasingly with AI-generated cases. Eazyware makes it the first step of every Legacy-to-AI Modernization engagement so that later phases can be measured against pinned behaviour.

Eazyware service that covers it: Legacy-to-AI Modernization Program. Starting prices are on the pricing page.