Tests and CI - Gurgant/azurebank-v2 GitHub Wiki
A claim counts here when something checks it on every pull request. This page says what checks what.
What a change must pass
mainrequires a pull request, permits squash only, and has no bypass list.maintakes a merge only when the eleven required checks have passed and CodeQL reports no error and no security alert rated high or critical.- Changes go through pull requests gated by CI tests and CodeQL, with AI review, and I merge each one myself.
The jobs
The README lists them.
| Job | What it checks |
|---|---|
| Backend build + tests | Formatting, a Release build with warnings as errors, a migration for every model change, the API's and the BFF's test suites |
| Backend concurrency proofs | Idempotency, balances and the audit chain under concurrent requests on a real SQL Server |
| Frontend build | Lint, formatting, the generated types against the committed contract, the unit tests, the contract suite against the mock |
| Frontend tests (two checks, one per time zone) | The unit tests again under two time zones that disagree about "today" |
| Real-stack layers | The contract suite, the data layer and Playwright with axe, against the real BFF, API and SQL Server |
| Runtime conformance | Schemathesis against the running API |
| Contract tests (the check is named Bruno collection) | The Bruno collection against the running API |
| Infrastructure | The deployment templates compile and lint clean, the tests of the deployment script and of the PowerShell scripts, a lint of the workflows |
| Demo suite | The demo's browser suite on the stack a deployment runs, with the two restarts of containers it makes |
| Commit messages | The pull request's commit messages, read for a credit line or a mention |
- CodeQL analyses the C#, the TypeScript and the workflows on every pull request.
- Three more jobs run on every pull request and are not among the checks a merge requires: the documentation site, built with every link checked, a count of how much of the hand-written code the tests run, which fails under a floor, and a reading of the prose for American spellings.
- The browser tests run in Chromium only.
- No test count is written here, on purpose: a number in prose goes stale within days. The runs are the source: CI runs.
Why the real backend is in CI
The frontend tests once checked everything against a mock of the API, and the mock was written by reading the server's code. When a test and the mock agree with each other and neither agrees with the server, the tests are green and wrong.
- So one suite of assertions runs twice: against the mock, and against the real API and BFF.
- And one CI job creates its own SQL Server, API and BFF, and runs the real-backend suites against them.
Rules I work by
- A gate on findings compares with
main: "no new alert", never "zero alerts". - Never dismiss a finding to make a number look good.
- Never apply an automated fix without checking it.
- No green without runnable proof.
- A contract change ships as two pull requests: the backend with the regenerated contract, then the UI.
- A test that holds a decision must stay: deleting it reverses the decision.
Read next
- The rules in full: Engineering practices.
- Things that fail silently or ship green, with what goes wrong, why nothing reports it, and what to do: Engineering traps.
- The accessibility checks that run in CI: Accessibility.
- Next page: On Azure.