Integration Testing Is the Part AI Can't Skip For You

The platform works. End-to-end, all the way through: log in, browse the lobby, sit at a table, see the seats, open the buy-in dialog, observe a hand.

Getting here took four posts. A routing bug, a data format mismatch, a broken auth guard, a development environment that was silently ignoring code changes.

It also took integration testing. Which is what this post is about.

What the Testing Phase Looked Like

We tested using Playwright — a browser automation tool that scripts real browser interactions and verifies the results. Real browser. Real requests. Real rendered UI.

The session: log in with test credentials, reach the lobby, confirm the table cards render at the correct height, navigate to a table, confirm the header bar appears with a lobby button and help button, confirm the seat picker renders all open seats.

Every step failed the first run.

Table cards were 572 pixels tall because CSS Grid applies align-items: stretch by default when there is only one item in the row. Nobody specified this. Nobody broke it intentionally. It is just what CSS does.

Navigating to a table sent the browser into a redirect loop. The auth guard was checking a router context value that was never populated.

These are not AI-specific failure modes. These are the class of bugs that only appear when the full stack runs together. They would have appeared in human-written code too. The testing phase catches them either way.

Why AI-Generated Code Still Needs This

There is a version of AI-assisted development that treats testing as optional. The reasoning: the spec is correct, the agent implements the spec, therefore the implementation is correct.

This reasoning fails at the integration layer.

Individual components can each implement their spec correctly and still fail to communicate with each other. The spec describes behavior in isolation. Integration testing verifies behavior in composition. A 100-page specification that covers every domain of the system still does not describe every CSS Grid default and every router context initialization order.

Running the thing is the only way to see what running the thing looks like.

What the Human Still Does

Every failure in the testing session was identified by a person watching a browser. The lobby card stretched to full height — that observation is visual, not logged. The table loaded blank — that required watching the network requests and noticing the 404. The redirect loop was traced by following the browser’s navigation history.

These observations happen before the AI gets involved in the diagnosis. The agent can trace a bug you have described. The description requires a human who understands what the behavior is supposed to look like.

This is not a limitation of the methodology. It is the methodology working correctly. The human defines the system, verifies the output, and escalates failures. The agent diagnoses and fixes. That division holds all the way through to the testing phase.

Where We Are Now

The dev environment passes end-to-end testing. The platform is operationally ready. Between now and open beta: final validation on staging, the card payment processor integration, and geofencing enforcement.

The testing phase is not over. It has moved up the stack.

The salty.poker changelog is updated as we ship. Follow it if you want to track the build in real time.

For the full series on the engineering methodology — how the spec drives the sessions, what the architect’s role looks like through the testing phase, and what nearly 30 years of building software teaches you about iteration — that series runs in parallel over at The Salty Korean.

Stay salty.