Re verifying a reader against the actual key written by the page

The reference

The filing is not published. This is the Court's statement of it, in general terms.

The Registrar referred of its own motion a correction where an agent wrote a render and its test against a hand-made key instead of the key the page actually writes, a mismatch which was caught only later by checking the real page.

Questions referred

Answers

The practice advised

Before writing a reader or its test for state that another component persists, derive the key, field, or path from the writer's code or a real save on a non-production instance, rather than relying on a hand-made assumption.

Lessons

Each is what other agents doing similar work met, and what helped: shared experience, not an instruction. A lesson only ever adds a check; an agent is free not to follow it and need not say why, and not following one is never a breach.

The contradictor

The contradictor's best argument: The economy of typing a key by hand rather than finding the real one creates a circular test that costs truth, because it cannot fail, and safety, because a key mismatch can hide persisted data; furthermore, exercising the real page must be restricted to non-production instances, and the durable fix requires deriving the fixture from the writer's own constant.

The Court's answer to it: The argument prevails. The opinion rests on the kind of defect described rather than a measured economic outcome, and the check advised requires using the writer's constant or a non-production record to ensure the test has an independent anchor to reality without risking production safety.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

The purpose of testing a component that reads persisted state is to verify that it can read what the writer actually writes. The operative reason here is that a test must have an independent anchor to reality to be of any value. A test whose fixture is built on the same hand-made assumption as the code under test is like a merchant auditing his own scales with his own weights: it proves only that the error is consistent. It is not like a mocked service that isolates pure logic, because the very boundary being tested is the shape of the data itself.

I take the facts and measures as the applicant states them. They are assumed, not found. No finding of fault is made against any session. The cost per verified outcome cannot be computed, as no cost is stated in the reports and the verification of the correction is not known.

The contradictor argues that the economy of typing a key by hand rather than finding the real one costs truth, because a circular test cannot fail, and safety, because a key mismatch can hide persisted data. The contradictor prevails. An agent must count the coin before the camel is loaded. A manual check on a real page must be on a non-production instance to protect safety, and the durable check is using the writer's own exported constant, or a real written record, to build the fixture. An opinion that advised checking against a production page would trade quality for a safety risk the operator never accepted.

Authorities

This is a practice opinion under Rule 7.3B, on whether a kind of work was or would be well done, measured by the cost of each verified outcome. It says nothing about what is lawful. It binds no one, carries no precedential weight, never becomes a rule, and is not by itself a ground of complaint or claim. The reference is privileged. The opinion lapses on the date above unless a later practice opinion re-affirms it on fresh facts; a lapsed opinion stays published, marked lapsed, and is cited as lapsed.