# Claude Code Testing Tips: Write-Test Loops, TDD, and TESTING.md > Claude Code tips for verification: close the write-test loop, Playwright vs /chrome, double-check every claim, TDD, interactive PR reviews, and TESTING.md. Source: https://camnangai.com/en/for/developers/claude-code-tips-testing-and-verification Published: 2026-10-24 If you want Claude Code to run a task without you hovering over it, you have to give it a way to check its own results: write the code, run it, read the output, and repeat. This is part five of a series that walks through all 50 **Claude Code tips** in YK Sugi's [claude-code-tips](https://github.com/ykdojo/claude-code-tips) repo. It groups five tips about [verification](https://camnangai.com/en/for/developers/why-code-verification-matters-in-the-age-of-ai): numbers 9, 26, 34, 24, and 48. They run from Claude checking its own code to you reviewing a large body of code without reading every line. The more work you hand to Claude, the more your verification step decides whether you can trust what comes back. ## Why do autonomous tasks need a write-test loop? Because without a way to check, Claude can't tell whether it is done. The repo's example: you are working on Claude Code itself and notice `/compact` suddenly returns a 400 error. The classic tool for finding the exact commit that caused it is `git bisect`, and you can let Claude Code run the bisect itself, as long as it has a way to test each commit. For things with an interactive terminal interface, like Claude Code, the way to test is tmux: start a tmux session, send commands into it, capture the output, and compare it with what you expect. This checks whether `/context` works: ```bash tmux kill-session -t test-session 2>/dev/null tmux new-session -d -s test-session tmux send-keys -t test-session 'claude' Enter sleep 2 tmux send-keys -t test-session '/context' Enter sleep 1 tmux capture-pane -t test-session -p ``` With a test like that in hand, Claude Code runs `git bisect` and tests each commit automatically until it finds the one that broke things. It is also a reminder that software engineering skills still matter: if you know `git bisect`, that knowledge is just as valuable when working with AI, applied in a new way. The more common case is simply writing tests: let Claude write the code, then let it write tests for that code, run them, and fix what it can. It doesn't always go in the right direction and you still need to supervise, but it handles a surprising amount on its own. ## Playwright MCP or /chrome for testing web apps? For most tasks that aren't visually intensive, Playwright MCP generally works better than Claude's native browser integration (through `/chrome`). Chrome DevTools MCP is a third option the repo author hasn't tried. The main difference is how each tool "sees" a page: | Criterion | Playwright MCP | Native Chrome integration (`/chrome`) | | ------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | How it reads a page | The accessibility tree, as structured data | Screenshots and clicks by coordinates | | Speed, reliability | More reliable | Slow, sometimes clicks random things | | Context cost | Heavy, though 200k is usually enough for a few tasks | Depends on how many screenshots it takes | | Use it when | Most web testing | You need a logged-in state (it runs in your own browser profile) or must click by position on screen | That is why the author keeps the native Chrome integration off by default and only turns it on through the `ch` alias (part one) when it is actually needed. Even with native Chrome, you can tell Claude to use accessibility-tree references instead of coordinates. This is from the author's `CLAUDE.md`: ```markdown # Claude for Chrome - Use `read_page` to get element refs from the accessibility tree - Use `find` to locate elements by description - Click/interact using `ref`, not coordinates - NEVER take screenshots unless explicitly requested by the user ``` The native integration also has two reported issues: it doesn't always pick the local browser (issue #74667), and it can't be enabled from a Remote Control session, such as when you are working from your phone (issue #74671). To address both, the author built [Browser Bridge](https://github.com/ykdojo/browser-bridge), an open-source alternative. If MCP is new to you, [what is MCP](https://camnangai.com/en/knowledge/what-is-mcp) explains it from the start. ## What if your test environment is hard to set up? Get creative about closing the loop, and let Claude Code do the legwork. First example: while working on the Python library Daft (which has a Rust backend), the author needed to test a locally built version on Google Colab, but building a Python library with Rust directly on Colab barely works. The fix was to build the wheel locally and upload it to Colab by hand. While waiting for the wheel to build, monkey patching (swapping in behavior at runtime) worked well in the short term. Second example: something needed testing on Windows, with no Windows machine available. The repo's CI was failing because of Rust issues on Windows, and there was no way to try it locally. The approach was one draft PR with all the changes, plus a second draft PR with the same changes and Windows CI enabled on non-main branches, then testing directly on that new branch. Claude Code created the PRs and adjusted the workflow on instruction. In both examples a human designed the testing strategy, and the execution was a back-and-forth with Claude Code. This is where your experience pays off most. ## What are the ways to verify Claude's output? More than you might expect, and they work best combined. For code there are four main ones: have Claude write tests and check that they look reasonable; read the code in the Claude Code UI as it is being written; use a visual Git client like GitHub Desktop to scan changes quickly (in the author's words, "not a perfect product, but it's good enough"); and have Claude open a draft PR, checking the content before turning it into a real one. The remaining one is making Claude check its own work. When it hands you a result, say from a round of research, ask "are you sure about this? Can you double check?" The repo author's favorite prompt, and to me one of the most worth copying in the whole series: > double check everything, every single claim in what you produced and at the end make a table of what you were able to verify The table at the end is the valuable part: it forces Claude to separate what it verified from what it didn't, instead of answering with a blanket "everything looks good". ## How does TDD work with Claude Code? The more code you write, the easier it is to make mistakes, and tests matter more as the codebase grows. Some people say AI can't test its own work, but it turns out it can, much like the human brain: when you write tests, you think about the same problem from a different angle, and the same goes for AI. Test-Driven Development (TDD) fits Claude Code in four steps: 1. Write the tests first. 2. Make sure they fail. 3. Commit the tests. 4. Write the code until they pass. Writing failing tests first and committing them before the implementation creates a clear contract for what the code should do. Claude has a concrete target to hit, and you verify the implementation by running the tests. If you want to be extra sure, read the tests yourself to make sure they don't do anything silly like always returning `true`. The article on how [TDD amplifies AI success](https://camnangai.com/en/for/developers/tdd-amplifies-ai-success) goes deeper on this approach. ## What does an interactive PR review look like? Ask Claude Code to pull the PR details with `gh`, then review it however you like: a general pass, or file by file, step by step. You set the pace, the level of detail, and the complexity. Sometimes you only want the overall structure; sometimes you want it to run the tests too. Claude Code acts as a reviewer you can talk to rather than a one-shot machine. Some AI tools are good at one-shot reviews (including the latest GPT models), but with Claude Code you can ask follow-ups, dig into the parts you doubt, and skip the parts that don't matter. ## What is reviewing code through a TESTING.md? When you have to review a lot of code, whether Claude Code's output, a teammate's PR, or an external PR, the hard part is building a mental model of what is going on and knowing whether it is correct. Reading the code is one way and writing tests is another, but there is a way one level above both: have Claude Code test everything in that code thoroughly, write up how it tested and verified it in a `TESTING.md` file, and review that document instead of the code. Tune the format until it reads well for you: too long, ask for shorter; too short, ask for more; jargon you don't follow, ask it to explain or simplify. The repo's real `TESTING.md` started with the review of one external PR, where Claude Code reproduced a bug on a real Windows runner in GitHub Actions, verified the fix, and summarized everything it tested. It is now a running log with a section per review, newest first. Tracked in git that way, it gives you a record of how everything was tested; when someone asks "how do you know it works?", you point them at the file. I see this as the natural next step for anyone already reviewing PRs with AI: you move from reading diffs to reading evidence. ## Where should you start with verification? Start with the "double check every single claim" prompt and its verification table, since it applies to code and research alike, today. Once that is a habit, move to TDD for the code that matters, and use `TESTING.md` for PRs too big to read the whole diff. ## References - [45+ Claude Code Tips: From Basics to Advanced — YK Sugi](https://github.com/ykdojo/claude-code-tips) - [Use Claude Code with Chrome — Claude Code Docs](https://code.claude.com/docs/en/chrome) - [Best practices for Claude Code — Claude Code Docs](https://code.claude.com/docs/en/best-practices) - [Playwright MCP — Microsoft](https://github.com/microsoft/playwright-mcp)