We Stopped Writing Tests After the Fact. Here's What We Do Instead.
Tests written after a feature ships are just documentation. Here's how we made testing parallel with implementation using a dedicated test agent.
We Stopped Writing Tests After the Fact. Here's What We Do Instead.
The Problem
Tests written after a feature ships are really just documentation. The developer knows how it works, writes tests to confirm what they built, and marks the ticket done. Edge cases go untested. User flows that weren't considered during implementation don't get covered.
And the next time someone touches that code, there's no safety net — just the tests that say "the original implementation did this." That's not a test suite. That's a record of what used to work.
What We Learned
The problem isn't that developers don't care about tests. It's that tests are always last. When there's a deadline, "we'll add tests later" is the most common lie in engineering. Everyone knows it when they say it. Nobody has a better answer in the moment.
The only real fix is making tests part of the implementation, not a step after it. And the only way to make that sustainable is tooling.
What You Can Do About It
The test-agent starts writing Playwright E2E test structure at the same time implementation begins. It gets the same ticket context — the acceptance criteria, the user flows, the expected outcomes.
While the db-agent, api-agent, and frontend-agent are doing their work, the test-agent is building the test scaffolding: the page objects, the test cases mapped to acceptance criteria, the assertion patterns. When implementation is done, it fills in the tests against the real UI and runs the full suite.
Failures surface before the ticket moves to Done. Not in the next sprint. Not when someone else touches the code. Before the work is called finished.
Why It Matters
Tests are ready when the feature is ready. Coverage is based on acceptance criteria — the things the ticket said the feature should do — not on what the developer remembered to verify.
When the next engineer touches that code, they have a real safety net. One that reflects how users actually interact with the feature, not just how the original developer thought about it.
At Periscoped, we think the word "done" should mean something — and it doesn't mean anything without tests that prove it.
Enjoyed this? Explore more on testingaiai agentbest practices or get in touch.