Best Claude Code skills for automated test generation?

Question

So we have this massive release coming up next Thursday for our client in Boston—it is a fintech dashboard with super strict compliance—and our test coverage is sitting at a depressing 34%. I need to get this up to at least 70% before the audit.

Ive been using LLMs for code gen for a couple of years now, mostly just copy-pasting into Copilot or using basic API scripts, but I recently started using the new Claude Code CLI tool. I thought it would be a lifesaver for spinning up Playwright integration tests. But man, I am running into some weird roadblocks with how it navigates my local environment.

My logic was to let Claude Code read the DOM structures directly, run the local dev server, and write the test specs. But it keeps hallucinating selectors that dont exist or getting stuck in loops trying to run the tests and failing. I was thinking maybe I need to define better custom skills or MCP servers for it? Like, has anyone set up a specific skill for Claude Code that lets it inspect the React components better, or maybe a mock data generator skill?

Right now, it just feels like it lacks the context of how our state management works, so it generates tests that pass on static renders but fail completely on actual user flows. I tried writing a custom guide in the CLAUDE.md file to feed it our component directory structure, but it still gets confused.

What are the best custom skills or tool integrations you guys are using specifically to make Claude Code actually good at writing E2E or integration tests without babysitting it every five seconds? I really need to automate this by Monday or Im gonna be pulling all-nighters...

American_Alex · Accepted Answer

Honestly, I was super disappointed with Claude Code for this. The token usage is absolutely brutal when you let it run loops trying to fix Playwright tests, and my API bill spiked instantly. It is just not as good as expected for this kind of agentic workflow, especially on a tight budget. Instead of letting Claude burn through cash, I switched to a much cheaper setup. I use the free Continue Dev VS Code Extension configured with the DeepSeek V3 API which costs pennies compared to Anthropic. To solve the selector issue without paying for agentic loops, I just run playwright codegen locally myself to capture the exact selectors for the main user flows. It takes two minutes and costs zero. Then, I feed those raw recorded traces and my React schema to the cheaper model to clean up and write the assertions. If you need mock data, dont pay for a complex MCP server. Just use a cheap endpoint like Google Gemini 1.5 Flash API to spin up static JSON mocks based on your typescript interfaces. It keeps the context window clean and saves you a ton of money before your Monday deadline.

Mini Moving Manhattan · Answer

Oh man, I ran into this exact same selector loop last month and it was driving me nuts! I managed to fix it and got our coverage up to 80% using a couple of fantastic tricks with Claude Code. Here is how you stop the hallucinations:

First, stop letting it guess selectors and force it to use the Accessibility Tree. I added a simple script that runs Playwright in headless mode and dumps the accessibility tree to a JSON file. Tell Claude to read that file before writing any test. It works amazing because Playwright loves ARIA roles!

Second, use the Model Context Protocol (MCP) to bridge the gap. I configured the official Puppeteer MCP server in my Claude Code setup. This lets Claude actually take screenshots of the local dev server at localhost:3000. When it gets stuck, it can literally see what it is doing!

Lastly, enforce a strict rule in your CLAUDE.md: if a selector is missing, Claude must edit the React component to add a data-testid attribute first, then write the test. No guessing allowed! This totally transformed my workflow. Running it with the Anthropic Claude 3.5 Sonnet API via the CLI is super cost-effective too because it stops wasting tokens on failed test loops!

opmzxmrrue · Answer

^ This. Also, I totally feel your pain with the selector loops. I have been dealing with that stuff for years, and honestly, the trick is to stop relying on the AI to guess the DOM entirely. In my experience, you should look into using some kind of visual testing suite alongside your automation.

Seriously, just pick any decent visual regression tool from a reliable brand like Applitools. It saves you from writing manual selector logic that just breaks when a dev breathes on the code.

Build yourself a dedicated mock server. If the AI doesn't have a stable API to talk to, it will never stop hallucinating broken test states.

Keep your component definitions super lean. I have tried many setups over the years, and honestly, if you prioritize stability over raw speed, you will save yourself those all-nighters. Just grab some reliable hardware like a Logitech MX Master 3S to make your manual intervention phases way less frustrating if you have to jump in. You got this, just stop letting it try to guess the UI!