There is no test team behind Giant Context, so the build has to do that job. Three suites carry most of it. One checks that the logic works, one checks that the whole flow holds against a real database, and one checks that the right people, and only the right people, can reach each endpoint.
Each checks exactly one thing and never the thing another one checks. No test lives in two of them, and the separation is what makes a red build readable.
The first suite tests logic in isolation. A function, a component, a piece of pure behaviour, with no database and nothing else running. Nothing has to be stood up and nothing torn down, so the suite finishes in seconds and can run on every save, which catches a regression in the minute it is written rather than the hour it is later debugged.
Each unit test answers one question. Given this input, does this code return the right output. When one goes red, a function regressed, and the search stops there.
The second suite tests the whole flow. A real request goes into the running server, through the real routing and the real handlers, out to a real database, and the result is checked against what should have happened.
It stands up actual infrastructure for every run, a live server talking to a live Postgres, which costs seconds where a unit test costs milliseconds. What it buys is the class of failure unit tests cannot see. A function can be correct in isolation and still be handed the wrong input, called in the wrong order, or wired to a route that never reaches it. Unit tests never look past the function, so the seams between correct pieces go unchecked, and the seams are where a system this size actually breaks.
When it goes red, something between two working pieces stopped fitting.
The third suite tests access control, and most codebases never build one.
The most expensive bug a multitenant platform can have is one tenant reaching another tenant's data, and it is the bug ordinary tests are worst at catching, because it does not look like a bug. It is a valid request, correctly formed, from the wrong person. The logic works. The flow holds. The only thing wrong is who is asking, and neither of the other two suites is looking at that.
Every protected route already declares the permission it requires, so a generator reads those declarations alongside the table of which role holds which permission, and writes a test for every route and every role. Hundreds of routes with several roles apiece is a matrix nobody keeps current by hand, and the day a person falls behind is the day a permission changes with nothing watching.
Because the coverage comes from the permission rules rather than being kept in step with them, it cannot fall out of step. A new protected route is tested before anyone writes a test for it.
The three suites are held apart by the build rather than by discipline. Each has its own place in the tree, its own configuration and its own job in the pipeline. Each configuration takes in only its own files and shuts out the others, so a test file belongs to exactly one suite and there is no way for it to belong to two.
Working alone, what that separation gives me is a fast read on what broke. If unit is red, a function regressed. If integration is red, a flow came apart. If access control is red, a permission boundary moved. The suite that fails names the kind of failure, so the search starts already narrowed to one layer. Running every check against everything would be slower and would tell me less, because a failure that could have come from anywhere gives no direction to look in.
Unit | Integration | RBAC | |
|---|---|---|---|
What it checks | Logic in isolation | The whole flow, end to end | Who can reach each route |
Database | None | Real Postgres | Real Postgres |
Speed | Milliseconds, in parallel | Seconds, one at a time | Seconds, one at a time |
Written by | By hand | By hand | Generated from the route permissions |
What this buys is the ability to put a multitenant platform in front of real businesses and trust it between deploys. The logic is checked, the flows are checked, and the access rules are checked on every change, the last of them generated from the same source the platform is built from. The rigour a team would supply by hand comes from the build instead, which is the only way one person has it at all.
It matters more as the platform gets more autonomous. A system that drafts and publishes and acts without anyone watching each step is only as sound as what stands behind it, and the suite that stays trustworthy longest is the one nobody has to remember to update.
Remote, Pacific time, full-time or contract. Get in touch.