How commvita is tested
Five thousand backend cases grouped by what a false pass would cost, thirty build checks that refuse untrue claims, guards proven by breaking them, browser runs on a booted platform, security scans on every push, and a release the customer merges.
1 The number, and what it means
At this build the backend test suite holds 295 files and 5,338 test functions, which expand to 5,526 cases. The last recorded run passed all 5,526 with no failures in five minutes. The catalogue that says so is generated from the suite on every build, so a test can’t exist without appearing in it and can’t appear without existing.
The note under the tiles matters as much as the tiles. The result is a snapshot of one run against a named commit, and it becomes stale the moment the code moves. A test with no recorded result reads as not recorded and is never assumed to have passed. Section membership is the one editorial decision, because a filename can’t say what a file is about, and a test file with no section fails the build instead of being dropped.
2 The tests that protect people come first
The catalogue is grouped by what a false pass would cost. The biggest groups are the ones where a wrong answer is a disclosure, a wrong patient or a wrong number on a regulator’s desk.
| Section | Tests | What a false pass would mean |
|---|---|---|
| Reporting, indicators and provenance | 1,091 | A figure that doesn’t state what it covers, a null read as a nought, a period counted twice |
| Incident, safety and risk | 1,041 | A patient-safety incident handled with the wrong response, a duty-of-candour case lost |
| Access control and authorisation | 597 | A disclosure: a role reaching a record it shouldn’t, a commissioning relationship granting access |
| Data spines and reconciliation | 490 | One concept in two stores that disagree, reconciled by matching strings that match nothing |
| Community, portal and engagement | 370 | The patient’s own view of their record wrong, or a proxy seeing what they shouldn’t |
| Jurisdiction configuration and fail-safe | 349 | One country’s rule silently applied in another |
| Clinical record and consultations | 332 | A drug interaction not checked, a prescription written against the wrong person |
Seven more sections cover authentication, board and regulatory records, approvals and e-signature, scheduling and referral, interoperability, platform contracts, and platform administration. The full list with every test’s stated intent is on the platform’s own Architecture screen.
3 Thirty checks that fail the build
Beyond the tests, thirty build checks run on every change and refuse the ones that would make the platform say something untrue. Each exists because of a defect that shipped once, and each is narrow on purpose, because a check that cries wolf gets deleted within a release.
Nothing announces work it didn’t do
A control that touches no data and no transport may not return an outcome word. An endpoint may not report work it didn’t do. A route declared behind a wildcard that can never be reached is refused; one of those was answering a statistics call with a patient lookup.
Registers are measured, never typed
Each register is regenerated from the source and compared. A drift fails the build. A page whose source changed after its help guide was written fails the build. A module in the registry but not the audit, or the other way round, fails the build.
Claims can only get truer
No conformance to a standard nobody read. No permission-matrix domain shown as a control unless a server check enforces it. The measured position of the ontology may not regress. The binding debt may only fall. No silent fallback to England.
Others guard smaller things that still matter: every routed page has a navigation entry and a title; the price is defined wherever it is stated; the retired palette doesn’t reappear; no superseded edition of the data-security toolkit is claimed on a live surface; the build register is never published; and the document served inside the app is the same as the one in the repository, because two copies of one file is how a registry once drifted by 187 entries.
4 Proving a guard guards: mutation testing
A test that passes proves little on its own. It might pass because the code is right, or because the test checks nothing. So for the guards that matter, the team breaks the guard on purpose and confirms the test fails.
The build register records this for each guard: the mutation applied, whether the test fired, and what was done when it didn’t. The record shows 160 builds where guards were mutation-tested, and the entries that matter most are the ones where a mutation survived. A guard tested by removing a whole store rather than the one check it protects turns out to be inert; a prose assertion that matched a phrase turns out to pass on a half-applied change. Each of those got its own test, and then fired. The verdict is read from the test runner’s exit code, never from its printed output, and the tree is checked byte for byte against its checkpoint after every run.
5 In the browser, on a booted platform
The backend suite can’t see a white screen. So the build boots the real API with its seeds, boots the real web application in front of it, and drives a browser through it.
Forty-five browser suites hold 110 tests. One sweeps every route and fails if any page throws, which is how a white screen caused by an endpoint returning one shape while the page expected another was caught and turned into a permanent check. Others walk clinical flows end to end: a mental-health approval, a patient signing into the demonstration portal, the record for a person, the admission feed, the event spine. A reachability gate confirms the demonstration launcher answers before the smoke run is trusted.
6 Security, on every push and every Monday
Security scanning runs on every pull request and push to the main branch, with the heavier jobs also scheduled weekly, and the results are kept as artefacts of the run.
Secrets are scanned on every event. Python and Node dependencies are audited for known vulnerabilities. A software bill of materials is generated for each build. Infrastructure definitions are scanned for misconfiguration. Static analysis runs over the application code. Container images are scanned before release, and that scan is a gate: a failing image doesn’t publish. Licence headers are checked on every file, and the Helm chart is linted and rendered before it can be merged.
The threat model is published on the platform, with the six actors it considers, the score for each, and the mitigations in place against them. It is a demonstrated surface: the scores are the team’s assessment, seeded on the page, and the badge says so. The open gaps it lists are real gaps, and the roadmap tab says which are critical.
7 Release: the customer’s merge is the gate
A release builds both images, scans them, packages the chart with its version, and opens a pull request that bumps the deployment. Production is pull-based: the deployment watches its own repository and applies what has been merged, so commvita never holds a customer’s production credentials, and rolling back is reverting a merge.
That shape is an accepted architecture decision, recorded on the platform with its reasoning. It means the jurisdiction keeps sovereignty over its production environment, and the approval gate for anything reaching patients is a merge by the people who run that environment.
Where it lives in commvita
| Surface | Route | What it shows | Status |
|---|---|---|---|
| Architecture · Testing | /architecture | The catalogue: sections, files, functions, cases, the last recorded run | ● Generated every build |
| Security architecture | /security-architecture | Threat model, controls, gaps, roadmap | ○ Demonstrated |
| Architecture · ADRs | /architecture | Twenty accepted decisions with rationale, including the release model | ● Live register |
| Build checks and workflows | code repository | Thirty checks, tests, browser smoke, security scans, release | ● Live, every change |