Your platform standard must rule on test fixtures that force values into hidden fields — what do you weigh, and what seam do you require instead?

This is a standard-setting question, not a technique question. The mechanism is simple and settled; what a lead owns is the decision about who may use it, where, and what the organisation builds instead. ## What you are actually deciding Not "is reaching past visibility acceptable" in the abstract, but three concrete things: 1. **Which code may do it** — fixtures only, or production paths too. 2. **What the declaring type owes in exchange** — whether types are expected to publish construction seams so fixtures do not need the technique. 3. **How wide the boundaries you ship are opened**, and who signs off when one is opened. ## The cost of permitting it broadly - **Refactoring goes quiet.** A member reached by name is invisible to rename and move tooling. The rename succeeds, everything compiles, and the failure appears in a fixture that now writes a field which no longer exists — or, worse, one that still exists and means something else. - **Static analysis loses the graph.** Members with no visible reader look dead; members with no visible writer look constant. Both conclusions are wrong wherever forced access is in play, and the tools cannot tell you which. - **Invariants stop being arguable.** A type's invariant is credible only because its own code is the only writer. Once anything in the process may write any field, "this cannot be inconsistent" becomes a claim nobody can support during an audit. - **Openings outlive their reason.** A boundary opened so one tool could work is open for the whole process, for every later dependency, long after the tool is gone. - **Tests stop testing construction.** A fixture that forces a state never exercises the path that is supposed to produce it, so a bug in that path has no test standing against it. ## The cost of forbidding it outright - **API surface grows.** Types need construction paths for states their ordinary flow never produces, and someone will use those paths in production. - **Third-party types are unreachable.** When the type is not yours, there is no seam to add and the ban simply blocks the test. - **Legacy is expensive.** A codebase already full of forced writes cannot convert in one pass, so an absolute rule produces exemptions that erode it. ## The seams worth requiring | Seam | What it costs | When it is the right answer | |---|---|---| | A construction path visible only inside the declaring unit | a little API surface, invisible to consumers | the default for types you own | | A builder that assembles state and validates once at the end | more code in the type | states with many fields and cross-field rules | | A factory taking a snapshot of persisted state | a shape to keep in step with the type | rehydration-shaped states, which fixtures usually want | | An interface the test substitutes for the collaborator | a level of indirection in production code | when the awkward state is really a collaborator's behaviour | | A forced write, documented and asserted | the whole list above | types you cannot change | ## A standard that survives contact A workable rule has a default, a short exception list and one hard line: - **Default:** reach the state through a path the type publishes, even if that path is scoped to the declaring unit. - **Exception:** a forced write is acceptable against a type you do not own or may not change, confined to fixtures, and required to assert afterwards — through the type's own accessors — that the object reports the state intended. - **Hard line:** never in production code. There the technique defeats invariants the rest of the system is written to trust, and the failure is a corrupted object rather than a red test. - **Boundaries:** an opening is reviewed like any other exposure, granted as narrowly as the runtime allows, and recorded with the reason it exists. ## The signal worth listening to If a team repeatedly has to force a state that is genuinely valid in the domain, the standard has found a design defect, not a testing inconvenience: the type admits states its published construction paths cannot reach. That is worth fixing in the type, because whatever produces that state in production — a persistence layer rehydrating it, an import, a partially completed workflow — is already doing it somehow, and unlike the fixture it has no assertion behind it.