4,300 tests, written by an AI: how they were planned, run and enforced

If an AI writes your code, your tests are the only thing standing between "it compiles" and "it's right". So in ParkEase, tests weren't a phase at the end. They were the contract the generated code had to meet.

By the end: 3,246 unit tests and 1,080 integration tests, plus browser end-to-end suites. Here's how they came to exist, and how they were kept honest.

The build phase of the workflow is test-driven development: write the failing test, watch it fail, write the code, watch it pass. That order matters more with an AI than with a person. An agent writing tests after the code tends to write tests that describe what the code does, bugs included. A test written first describes what the code should do.

ParkEase was built as 22 tasks, and each one has an entry in a test registry: what will be tested, at which level, and why. That file reached 2,357 lines. It's what made "is this feature tested?" a lookup instead of an opinion, and it's updated as part of shipping, not afterwards.

Integration tests run against a real PostgreSQL 18 with PostGIS in a throwaway container. No mocked database.

A mock is a second implementation of your database written by the same author, AI or human, with the same assumptions. ParkEase's most important rules live in the database itself: overlapping bookings are refused by an exclusion constraint, the ledger must balance. You can't test those against a mock that doesn't have them.

Four integration suites are mandatory on every change:

Plus stress tests: 100 drivers racing for 10 slots must produce exactly 10 bookings and 90 clean conflicts, no server errors, p95 under 2 seconds.

Two lessons became rules after they let defects through:

The web and admin apps get Playwright end-to-end runs at phone and desktop sizes, with an accessibility scan on every page.

The last gate before any pull request: lint, typecheck, every unit suite, the four mandatory integration suites, a dependency audit and a secret scan, run locally, with the output pasted into the PR. "CI will catch it" isn't a reason to open early.

Fixtures can lie. The first deploy found three bugs that every test agreed with, because the test fixtures and the code shared the same wrong assumption about the API. The fix was making tests use the real response shapes, imported from the shared contracts instead of hand-written.

No phone, no test. The end-to-end mobile flows were written but need a real Android device to run. That gap is logged, not hidden.

Next: harvesting. How every mistake, review finding and deferred idea became a written row somewhere, and the hook that won't let a task finish until it does.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code. Code: https://github.com/Deonkar/parkease