robinsamways.ca · Verification Practice
$ No CI, and That's a Deliberate Choice — Not a Gap
How this site actually gets verified before shipping: Playwright for browser-driven UI checks, FastAPI's TestClient for API-level testing, and — deliberately — real external calls when the thing under test is an integration itself, rather than mocking away the exact behavior being verified. There's no CI or persistent, automatically-triggered test suite yet.
That absence is a stated trade-off, not something quietly left out and hoped nobody would ask. For a solo project at this scale, the actual practice is: run the real suite manually before every archive checkpoint, verify drift against the spec directly, and be upfront that automation hasn't been added yet rather than implying more automation exists than actually does.
Playwright -> real browser-driven UI checks
FastAPI TestClient -> API-level testing
real external calls -> when testing an integration itself, not a mock of it
no CI / no persistent suite -> deliberate, stated trade-off at this scaleThe fix
Not a bug fix — a documented practice. The honesty is the point: being upfront about what doesn't exist yet, and why that's a deliberate choice rather than a gap being hidden, is itself part of the verification discipline being described.
Why this matters
This demonstrates a real, separately-evaluated skill — thinking about testing and verification strategy, not just shipping features — using this site's own actual practice as the worked example instead of a hypothetical. Overclaiming automation that doesn't exist would be less credible than plainly explaining why it doesn't, yet.