A characterization test records the observable behavior of an existing system for selected inputs and compares later executions with that accepted baseline. It establishes consistency with recorded behavior, not the correctness of every behavior the original system contains.
The baseline is also called a reference snapshot or golden master. Its evidential value depends on which observations were captured, how they were approved, and whether the comparison can detect differences that matter.
Establish the observation boundary
A test begins with a known input and relevant starting state. The observable result can include a report, response, file, database change, error, or external action. Capturing only the screen leaves other effects outside the test.
Take a transaction that displays success, updates a balance, and sends a downstream message. A screenshot comparison observes the display. It does not establish the balance update or the message. Those effects need their own captured observations if they form part of the required behavior.
Starting state matters because equal inputs applied to different states can legitimately produce different results. Configuration and business dates can also affect output. A baseline without those conditions is difficult to reproduce and easy to misinterpret.
Approval defines the expected behavior
Snapshot testing separates capturing output from accepting it. Someone with appropriate knowledge must decide whether the captured behavior is a requirement, a tolerated defect, an intentional exception, or an observation still needing explanation.
An existing defect does not become correct because it appears consistently. If a rounding rule is wrong, preserving the old output and correcting the rule are different objectives. The test must record which objective governs the change.
This is particularly important when documentation is missing. The running application provides evidence of what occurs. It does not alone establish why it occurs or whether the organization still requires it. Operator knowledge, records, and independently checked examples help interpret the observation.
Comparison rules are part of the test
A comparator needs a correspondence rule: which records or fields represent the same business object on each side. Position in a file is not interchangeable with business identity when output order changes.
Normalization removes differences declared irrelevant to the comparison. Replacing a generated timestamp can make a stable comparison possible when the timestamp has no business role. Removing a settlement date because it causes differences erases information that could determine whether a transaction is timely.
Numerical tolerance has the same boundary. A permitted difference must follow from the required calculation or representation, rather than being increased until the test passes. Dataframe comparison tools expose matching and tolerance options; those options require an acceptance decision.
Test the comparator
A passing result is useful only if the configured comparison detects the errors it is meant to reject. Introducing a known material difference tests that property. Altering a customer identifier, removing a record, or changing a significant amount should produce the expected discrepancy.
This checks the comparison mechanism as well as the replacement application. A permissive normalization rule can otherwise produce a reassuring pass for both correct and incorrect output.
Differences need classification. A defect, an approved behavior change, a mismatched starting condition, and a comparison-tool limitation require different responses. Automatically replacing the baseline with the latest output removes that distinction.
Scope follows the selected cases
Characterization tests are strongest where a stable observable contract can be recovered and compared. They provide bounded evidence for the scenarios, states, and effects included in the suite. They do not establish unobserved seasonal paths, arbitrary concurrency, or every possible input.
Critical normal cases, exception paths, and infrequent operations expand that coverage when selected deliberately. External effects must remain controlled so that replay does not duplicate real business work.
The result is an executable record of accepted behavior with an explicit observation boundary. It supports maintenance and replacement because a change produces an inspectable difference, while the decision about whether that difference is acceptable remains visible.