Preventing LLM unit test spam<br>Mark Larah · Jul 8, 2026<br>Preventing LLM unit test spam

I don’t want to read, or ship, thousands of lines of LLM-written unit test spam.

By default, LLMs will correctly test every codepath and achieve 100% coverage.<br>And it will happily churn out hundreds of brittle tests to do so.

(LLM-written granular unit-test assertions remind me more of snapshot<br>tests than actual tests.)

As a human, I simply can’t review that many tests! Realistically, I suspect it<br>drives folks to do this:

Homer shipping yet another vibe-coded PR with 100s of tests

#Keep a high test-to-coverage ratio

Prefer fewer tests that each cover more logic.

❌ Bad

def test_event_initial_status_is_pending_review():<br>event = create_event(name='Taco Tuesday', location="Taco Bell", host=123)<br>assert event.status == 'PENDING_REVIEW'

def test_event_initial_attendees_includes_host():<br>event = create_event(name='Taco Tuesday', location="Taco Bell", host=123)<br>assert event.attendees == ['Homer S.']<br>✅ Good

def test_create_event_basic():<br>event = create_event(name='Taco Tuesday', location="Taco Bell", host=123)

# events are reviewed before being published<br>assert event.status == 'PENDING_REVIEW'

# attendee list should automatically include the host<br>assert event.attendees == ['Homer S.']

#Testing at the edges

I’ll refer to a classic KCD blog post for guidance here:

Write tests. Not too many. Mostly integration.

~ https://kentcdodds.com/blog/write-tests

In short, tell your agent to read that post and “test at the edges” of the<br>system. Avoid many granular unit tests and avoid mocking (where possible).

As much as possible, write integration-style tests that send real inputs and<br>assert real world behavior or output. This applies to:

CLI inputs and output

Files written to disk

(Stubbed out) network requests made

For testing React UIs: using React Testing Library to “click on buttons” etc

Note : I say “integration-style” because I don’t think you should need to<br>spin up actual services with docker or set up sandboxes. Many libraries and<br>services ultimately do simple i/o that can either be stubbed out in-process<br>(e.g. network<br>requests),<br>or for testing filesystem operations, using temporary<br>directories.

Testing at the edges is great. The main selling point is usually that because<br>tests are less coupled to “helper functions”, they are less brittle and can<br>don’t have to change when restructuring or swapping out internal logic.

But another benefit is: less test code overall 🙂<br>Mark Larah leads API infrastructure at Yelp and is a member of the GraphQL TSC. Based in Austin, TX. Ramen and dark chocolate snob.<br>Edit this post on GitHub

Comments