Lesson 18.1318.13 Proving the sign-in keeps companies apart

In everyday life. A locksmith who installs a new lock does not just turn the right key and leave. They try the wrong keys, they try the door with the latch held back, and they try it with someone leaning on it. A lock is tested by trying to open it the wrong way.

What you will learn. How to prove companies stay apart: by trying each route you can think of to break it, and by checking that the tests can fail.

Why it matters. One missed route is enough for one company to act as another, and a suite that has never failed gives you no proof it can.

One test run, start to finish. The test suite runs the connector's sign-in checks against both versions, TypeScript and Python. One part of it, the sign-in matrix, tries every route a caller might use to act for another company, and expects each to be stopped:

1. A Cedar Ridge token asks a tool. Expect: Cedar Ridge's answer, never Brightline's.
2. The same token with X-Tenant: org_brightline. Expect: the same as 1.
3. A Brightline handle replayed, meaning sent again, with a Cedar Ridge token. Expect: the handle refused.
4. A staging token at production. Expect: 401.

Then a copy of the connector with one bug planted on purpose runs the same checks. They must fail.

What must these tests try?

Tests for keeping companies apart are tests that try to break it. A test that only checks the right person gets the right answer proves almost nothing, because the danger is the wrong person getting any answer. The whole matrix:

Why must some tests run many times?

The shared-note bug from rule 2 shows up only when one request waits, for example for its data, while another runs and changes the note. If all the requests arrive at the same instant, each may write the note before any of them waits, and the test can pass by luck. So the test for two companies at once sends 200 pairs of requests together, and also spreads them out over a few milliseconds. A test for a timing bug must try many times.

How do you prove the tests work?

A test suite that passes proves nothing until you have seen it fail for the right reason. So the lab plants two bugs, each on its own copy:

• The company read from a header when the header is present.
• The company kept on a shared note, written when each request arrives and read when the tool reads its data, after a wait.

The suite must fail on each. If it passes on a broken connector, the suite is the bug.

What can tests not prove?

Tests try the routes someone thought of. They cannot prove there is no route nobody thought of. So review still reads the code against the rules in 18.11 and 18.12, and looks especially for any new place that reads a company, any new shared note, and any new tool that forgets to take the slip. Field guide F9 is that review's checklist.

At work. OpenCode adds the matrix to scripts/conformance.ts. Both versions pass. On the copy with the header bug, the planted-header check fails. On the copy with the shared note, the parallel check fails within the first few dozen tries. The builder records both failures in ports/ch18.md as proof that the suite can see the bugs.

The operating rule: test that companies stay apart by trying every route to break it, against every version of the connector, run timing tests many times, and prove the tests by planting the bugs they exist to catch.

What Chapter 19 adds: tests that one company can never read, count or even detect another company's rows in the database.

Figure 18.16. The sign-in matrix: every route against both versions, and two planted bugs the suite must catch.