Testing Workflows with Claude

Claude Code wants to write code. Not tests. Left alone, it will build feature after feature without ever asking "but does it actually work?" Flipping that instinct is your job.

The Testing Problem

Claude Code optimizes for task completion. Tests feel like a separate task, so they get skipped. This is the single most common failure mode in AI-assisted development. Code that looks right, passes the vibe check, then breaks in production because nobody tested the boundaries.

The fix is embarrassingly simple. Bake tests into the prompt.

write a validateEmail function

That gets you untested code. This gets you working code:

write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing

Night and day. Claude Code now has concrete success criteria. It writes the function, writes the tests, runs them, fixes failures. You get verified code instead of plausible code.

Finding the Gaps

Before writing new tests, figure out what is missing. Point Claude Code at a service:

find functions in NotificationsService.swift that are not covered by tests

It cross-references source files with test files, spots which functions have test cases and which are completely naked. No coverage tool needed. Claude Code holds both files in context and reasons about it directly.

Once you know the gaps:

add tests for the notification service

Claude Code matches your existing test style, too. Jest with describe/it blocks? That's what you get. Pytest with fixtures? Same thing. You don't end up with janky tests that look like they were dropped in from a different codebase.

TDD Loops

TDD and Claude Code are a natural fit.

Write the tests first (or have Claude Code write them). The tests define what the code should do. Then Claude Code writes the implementation to make them pass. The writer/reviewer dynamic works here too: have one prompt write tests, a separate prompt write code. The test-writer doesn't know what shortcuts the implementation might take, so the tests stay honest.

Try it

look at src/services/auth.ts and write comprehensive tests for the login function. include tests for: valid credentials, invalid password, locked account, rate limiting, and SQL injection attempts. do NOT write any implementation changes yet.

Wait. Review the tests. Then:

run the tests. fix any failures in the implementation without modifying the tests.

That last part is critical. Claude Code can't just delete a failing test. It has to make the code actually work.

Edge Cases

Humans are terrible at edge cases. We test the happy path, maybe one sad path, and call it a day. Claude Code is genuinely better here because it's seen millions of codebases where those exact edge cases caused bugs.

add test cases for edge conditions in the notification service

Empty strings. Null values. Absurdly long inputs. Special characters. Concurrent access. Timeouts. Claude Code generates tests for all of it.

Subagents help too:

use a subagent to review this code for edge cases

The subagent hasn't seen the implementation process, so it catches assumptions the original prompt baked in. Fresh eyes, every time.

Automate It with CLAUDE.md

If you want tests to happen every time, stop relying on memory. Put it in CLAUDE.md:

## Testing Rules
- Every new function must have corresponding tests
- Run tests after implementation. Do not submit code with failing tests
- Match existing test patterns in the __tests__ directory
- Always test: happy path, error conditions, boundary values, null/empty inputs

Now testing is automatic. Every session, every prompt.

Three Mistakes That Will Burn You

Vague test prompts. "Write tests" gets you shallow tests that assert obvious things and miss real bugs. Be specific about what you want tested.

Not running the tests. Claude Code can write and run tests in the same prompt. Always add "run the tests after implementing." If you can't verify it, don't ship it.

Letting Claude Code edit tests to make them pass. This happens more than you'd expect. It fails a test, decides the test is "wrong," and quietly changes the assertion. Infuriating. Explicitly say the tests are the source of truth. Every time.

In Short

• Include test cases and "run the tests" in your prompts. Best single habit you can build.
• Claude Code finds untested code by cross-referencing source and test files. Use it.
• TDD loops: tests first, implementation second. The tension keeps both honest.
• CLAUDE.md testing rules make it automatic
• Tests are the source of truth. Never let Claude Code modify them to pass.