How We Test OneEnv

A tool that promises "nothing goes live silently" has to hold itself to the same standard. OneEnv is tested at four layers — and the layer we trust most is deliberately the one closest to reality.

The test that matters most

The load-bearing E2E spec is the product's whole promise in one run: create an env key, confirm the no-branch guard blocks a direct edit, create a branch, stage the value change, submit it for review, approve and merge as an Owner — and verify the live value reflects the merge. Every run uses a fresh throwaway user and workspace, so nothing depends on (or pollutes) existing data. The integration suite covers the same spine's harder corners deterministically: a conflicting concurrent edit blocking a merge until rebase, a second merged change superseding a stale pending impact, a rejected column removal leaving the service's membership untouched.

Tested at scale, not just at demo size

"Would this hold up at 100+ services" was an architectural guess until we made it an empirical one: a seeded workspace of 150 services × 60 shared keys (9,000 inheritance rows), hammered with concurrent requests measuring p50/p95/p99 latency per route. The pass found a real algorithmic bug — the services list recomputing per-service sync status one query at a time — which was fixed and re-measured, roughly halving its latency. The seed and load harness live in the repo, so the numbers can be reproduced, not just remembered.

We test permission boundaries deliberately, not just the happy path — confirming a plain member is correctly blocked (not just correctly allowed) is where most access-control bugs actually hide. Where a pass turns up something worth fixing, it goes on our roadmap in the open rather than getting quietly patched and forgotten — see the next post for exactly what that list looks like right now.