Green Tests, Broken App: The Day of Integration

Today, I had to address what the test suite could not see: the application passed every test, but it did not work when opened in the browser.

Three failures that no test detected

There were three of them. A blank screen: for any session state other than "ready," the application returned null, and a network error resulted in an empty page with no message. Vite's development server takes the next available port when the previous one is occupied, and because the server allowed only one origin, the browser blocked the API call. And the quietest one: the login form sent email and password using the field names from the project contract, while Better Auth expects email and password; the library received undefined for both fields and returned a validation error.

The common reason none of them were detected is that the web tests mocked the API. They verified that the correct route was called, but never the shape of the request body or the headers that reached the server. A test that mocks the outer boundary cannot detect a mismatch at that very boundary. The application now always renders something, with a loading state and a message if the API does not respond; the allowed origin is now provided to CORS and Better Auth as an expanded list; and the translation of field names lives in the only module that talks to the library, with tests asserting the exact request bodies.

Disjoint roles and a dashboard for each one

The first version of the role-based view was a ladder: each role saw everything the previous role could see, and the recruiter had job searches and documents. That is not how people work: a recruiter does not look for a job, and an administrator manages the platform rather than conducting job searches. Now each role sees only what belongs to it, with no inheritance; the division of sections lives in a single file used by both the menu and the selector; the super administrator can view the application as any of the three roles; and each role enters through its own dashboard, with its own route for job searches.

The administrator now has a settings section containing everything that governs the platform's source of truth: the AI provider, the Apify actor with its per-run budget, the email sender, and the review frequency for scheduled job searches. The recruiter can now do their job: assign a candidate to one of their companies, send them messages that arrive in their inbox, and view generated résumés, always limited to candidates who have explicitly authorized them.

Four warnings in two days

I had to warn four times that the application did not work in the browser: a blank screen, a validation error when logging in, an administrator panel that did not appear, and a role switch that left the URL in an unrelated section. None was a logic bug: they were all integration bugs, and not one was caught by the tests. The agent also closed tickets by declaring the work done simply because the suite passed, without testing the application in the browser. The correction to the method: check the application in the browser before calling anything finished, and write tests that cross the boundary rather than tests that work around it.

With the work caught up, the specification describes what the application does today, there are twenty closed tickets and eight open ones, and there is a handoff note documenting the current state and known pitfalls. By evening, there is a two-column login screen with the branding and color contrast verified, a private area with a header and side menu like a desktop application, three test accounts for hands-on work, and the panel clad in blue with a single shade for the header, sidebar, and footer.