How commvita is tested
Six thousand backend cases grouped by what a false pass would cost, thirty-eight build checks that refuse untrue claims, guards proven before they ship, 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 326 files and 5,979 test functions, which expand to 6,031 cases. The last recorded run passed all 6,031 with no failures, in just under seven minutes. The snapshot says which commit it ran at, and whether the working tree was clean when it ran. At this build it says the tree wasn’t. 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 |
|---|---|---|
| Incident, safety and risk | 1,191 | A patient-safety incident handled with the wrong response, a duty-of-candour case lost |
| Reporting, indicators and provenance | 1,129 | A figure that doesn’t state what it covers, a null read as a nought, a period counted twice |
| Access control and authorisation | 619 | A disclosure: a role reaching a record it shouldn’t, a commissioning relationship granting access |
| Data spines and reconciliation | 534 | One concept in two stores that disagree, reconciled by matching strings that match nothing |
| Community, portal and engagement | 409 | The patient’s own view of their record wrong, or a proxy seeing what they shouldn’t |
| Jurisdiction configuration and fail-safe | 365 | 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-eight checks that fail the build
Beyond the tests, thirty-eight 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.
Eight were added in the build merged on 20 September, and each came from a defect found the same day. One holds a withdrawn jurisdiction off the landing page and out of every menu. One stops the competitive register showing an openEHR tile as progress toward a native implementation. One keeps a subject-access request’s open-or-closed vocabulary the same in the API and the page that reads it. One executes the team absence diary’s real code because the front end has no unit-test runner, and says so in its own header. The others hold the risk register’s shape, the sidebar’s route-to-domain map, a supplier register that was supplied and not read, and a one-way ratchet that stops a competitive rating on a page that fetches nothing from being counted as measured.
4 A guard is proven before it ships
A test that passes proves little on its own. It might pass because the code is right, or because the test checks nothing. So every guard that matters is proven to fire before it ships, and the proof is recorded against the build that added it.
The build record shows 177 builds where that proof was done, and the entries worth reading are the ones where a guard turned out to be inert and had to be replaced with one that fires. How the proof is run is part of how commvita is built and stays private. What it means for a buyer is that a green run is a run in which the guards have each been shown to catch the thing they guard.
5 In the browser, on a booted platform
The backend suite can’t see a white screen, and the front end has no unit-test runner: the platform measures that about itself and says so. 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.
Fifty-six browser suites hold 137 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. Three gates run before the smoke is trusted: the demonstration launcher answers, every demonstration person links to a record, and every named-person key resolves. A separate job builds both container images, runs the API image once to prove every pinned file is present, and boots it against a database until it answers.
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. 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 deployment package is checked 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 reference page: the platform’s own banner says it reads nothing from the platform by design, because its subject is the software and not a store, and the scores are the team’s assessment. 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 the images, scans them, packages the deployment with its version, and opens a pull request that bumps it. 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 |