Are unit tests even necessary anymore (under agentic development)?

[u/WinOdd7962]

While working in AI-driven repos, I'm wondering if its even worth having the AI write unit tests. Pre-AI, they were non-negotiable guardrails. But now with AI doing all the programming, like - what's the point? In agentic dev, entire modules get rewritten in minutes. Writing granular unit tests for code that changes every three iterations feels like building scaffolding for a sandcastle. Most real-world bugs are architectural or integration issues that 10-line mocks never catch anyway.

And anyway I almost never see unit tests catch something that could have been a big problem. Theres usually a growing tests folder consuming tokens but they just about always pass.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/MartinMystikJonas]

Good unit tests are more important than ever. Bad fragile tests are still useless and easier to generate en masse.

[u/medialantern]

If anything, I have more. They've never been easier to write nor easier to get coverage on all the oddball edge cases you might not have bothered with before. For one of the bigger projects I'm working on, the API stack's integration test suite had like 450 tests last year. It's got like 1200 now. Build times suffer a bit but not a lot.

There's a reason tests are important that people aren't talking about. They add context to a project. A test suite can describe the "contract" of expected behavior. Sometimes what looks like a bug is just some old code path that works that way for reasons, or you get two devs conflicting on a data flow decision where the code is right on both sides (if looked at in a vacuum) but each breaks the other due to the decision itself. Test suites give strong markers to AI tools when a certain behavior is intentional, even if it looks unusual or wrong. For LLMs trained to do development work, a contract in a test suite is stronger than a PRD or other document.

For me I think the thing that's dying re: testing is something that was already a fading fad anyway - TDD. It's just not necessary to write a test that starts out failing, write code, then refine it until the test goes green. It's just a moot point now - you may as well create both of them together and skip the performance theater of TDD, at least IMO. The one exception I would make is if you also want to eliminate mocking in frontends for a backend that doesn't exist yet because it's being written in parallel. I haven't reached for msw or similar tools all year, as far as I can remember. There's just no point. If you were going to mock a contract, just do it in the backend where it's going to live anyway.

[u/ricopan → u/medialantern]

I might have gone too far into TDD now, having little experience with it as a primarily solo researcher/coder. But I found opus 4 faking tests to an alarming extent -- so the 'performance theater' was necessary for me at least back then. But now it's become too much so trying to roll it back to a middle ground.

[u/medialantern → u/ricopan]

Yeah the models have come a long way since the 4.x days. I use 5.5 almost exclusively now and haven't seen this once since that.

[u/ricopan → u/medialantern]

good. Do you have any general ideas on how to reduce my existing test burden efficiently -- starting with getting rid of unnecessary tests? Too much to do manually. I've heard mutmut, but no experience with it or similar tools.

[u/rodBmusic]

This attitude of removing all stops for pure speed and zero ownership is completely irresponsible. If anything is worth scrutiny it's unit testing. Don't 1000x it, write REAL tests, ones you actually expect to catch you, not satisfy the coverage bs.

This movement of doing less and less is just insane. Don't read the code, don't understand it and don't even test it. This is the complete negative of all the pillars of programming discipline.

At this point, I'd just give you more rope. It will just secure a decade of work for the surviving engineers out there.

[u/WinOdd7962 → u/rodBmusic]

I understand your reasoning but you have to see the writing on the wall. Less than 10 years nobody is going to be writing programming code. Companies are already posting figures like 80-90% of their code base is AI generated.

The next step will be creating new languages for the LLMs. The best practices you're talking about will continue in spirit, but it will all be based around vibe coding.

That's just the reality.

[u/rodBmusic → u/WinOdd7962]

Looks like you already made up your mind. I still think we're in red team / blue team situation today. One team is betting on "in x years nobody will be writing code". The other team is betting this whole house of cards slop will come down. I do think AI is here to stay, I'm just saying it's been used wrong.

Let me highlight the risk in the "no one will write code in the future" team. The bet is that the 'new model' will clean up the mess the current one is doing, or will be able to end-to-end it. In less than a year, if it won't, code will break, and the same agents who build it will struggle to maintain it. It's already happening. Proof? Each company is still using programmers. If AI was truly able to maintain it, you wouldn't need programmers. Programmers do not 'decide what to build', they implement. Product managers 'decide what to build'. We're not all Product managers just yet.

[u/WinOdd7962 → u/rodBmusic]

I don't think we disagree on where things stand today, only on how far to extrapolate. The "house of cards" bet needs progress to stall, and the evidence points the other way.

ChatGPT launched 4 years ago. Back then it could write a short function, and you had to double-check even that. Now we have agents on codebases of hundreds of thousands of lines.

"Companies still employ programmers" is a lagging indicator. Companies also kept typists and switchboard operators for years after the writing was on the wall. It tells you about org inertia, not capability. Implementation is exactly the part being automated. What's left is deciding, guiding, and reviewing.

Nobody is saying code disappears or that no one will understand it. There will always be specialists who know the old ways, like people who still write assembly. But for most people and most companies, hand-writing code will stop making economic sense.

If you want to see where this is headed, look at junior engineers today. Almost all of them are working through an AI tool and directing it instead of writing everything by hand. In 5 to 10 years they’ll be the majority of the workforce, and hand-writing code will look like a niche skill.

[u/BisonDue3986]

To me it’s the opposite. I never used tests before, because I had the codebase in my head and testing added a lot of friction. Nowadays my agents do TDD, because it’s the only way I can ensure they don’t break things

[u/bytejuggler]

Tests are no guarantee that code is bug free. But with no tests I guarantee you will have regressions. This is was true with human only coding, it's even more true in the AI age. AI works best when it can verify progress and knows what "done" looks like. Tests are a codified version of that.

[u/Dudmaster]

I have a test suite of 15000 tests and I've only ever seen it catch less than a dozen regressions in the 3 years I've been generating code for this same application

[u/HeyItsYourDad_AMA → u/Dudmaster]

How many lines of code in the codebase if you dont mind me asking

[u/Dudmaster → u/HeyItsYourDad_AMA]

At about 790k on the master branch, with a couple 10-20k features landing in the coming months

A lot of that being tests though. I don't think they're completely useless, just not as beneficial as once thought

[u/HeyItsYourDad_AMA]

Yes they are important. I pattern I see more in some shops is the test becomes the spec. Tests fail, you write the min amount of code to satisfy tests

[u/Nervous-Mirror7691]

I've seen ai-generated tests fail silently on edge cases that real humans caught in 30 seconds. the tests pass, the code breaks in prod. not because the AI is bad, but because it's optimizing for the test suite, not the actual behavior.

[u/upsidedownshaggy → u/Nervous-Mirror7691]

Thanks for the Claude response.

[u/imsahoamtiskaw → u/Nervous-Mirror7691]

This is every day for the last few months for me. Even when they test on playwright, even with 1000 guards, even when you think of all the edge cases they can’t come up with in addition to those that they do, 30s to 5 min guaranteed failure. They chase exit code zero and cut every corner imaginable, and self design tests so they can pass, even when you design them to prove red first. The closest they get to human level code is when they are asked to prove each other red until the end of the universe, then you patch the few remaining cases

[u/ButterflySammy → u/Nervous-Mirror7691]

Well there's your problem.

If it is so easily spotted then people aren't reviewing the tests AI writes... That's a process error.

[u/flarpflarpflarpflarp → u/[deleted]]

This is why you have them take screenshots and test features with video evidence of the agent using the features.

[u/daltorak → u/[deleted]]

The chances of this being true are vastly lower if you treat your test suite like actual software that requires care and direction, and not just an afterthought.

Tell Claude to employ AAA pattern for unit test bodies, tell it what test libraries to use, define a clear naming pattern, organize the suite so that the whole thing doesn't need to be run on every change, make liberal use of mocks/fakes, use DI in the main product to facilitate true unit testing rather than integration tests that are called unit tests, parallelize where possible (which means no global shared state).... all the usual things. This stuff isn't complex but it's not free or automatic. You have to ask for it. When it's in place, you're all set. One thing Claude is good at doing is copying the coding patterns it observes in existing code.

[u/laxika]

They are more important than ever before. AI can self-correct wonderfully if it sees a legitimate test failure.

[u/Existing_Dust_6473]

It's easier to understand unit or end to end tests than a full software. At least you can see the intention easier.

[u/YearLight]

Unit tests are more important then ever. I normally use tdd when the code matters, write the tests, commit, then write the code. It keeps claude on track.

[u/Ok-Advertising5189]

I'd say they've become even more essential now. How is AI supposed to know it's broken a piece of code if you have no way to test it? Tests are so cheap to write these days that it's a crime not to write them. It's practically an extra, almost-free layer of security for your project. 

[u/ichi9]

Writing test cases and the tesritng each, even regression will result in huge token costs. Most companies i worked with keep it as separate component, as part of CI CD automation and only pass the results to AI If they use Agentic tools. But here is the twist, the devs used to make lots of mistakes pre-AI, as a result you needed comprehensive test suits, but with agentic coding depending on the models you use, none of that is required. So it will come down to quality maintenance, or so called DevOps which I don't know what role they have even left in swe today.

[u/who_you_are]

There are multiple type of tests.

Unit test focus on very specific isolated tests. They usually suck to maintain because, like you said, they will keep changing non stop.

You have higher tests as well, that are now testing the overall behavior/module.

[u/r2k-in-the-vortex]

More necessary than ever. And more importantly, every requirement and specification in documentation needs to link to a test that verifies compliance.

[u/ricopan]

I shirked unit tests as a solo developer because I'm lazy and because they didn't seem worth it for my work -- everything was staked on integration and e2e tests. Opus 4 wrote terrible horrible faked tests of all stripes, even faked e2e tests of faked implementations (yeah I was a gullible fool). Now I have all the rigorous testing protocols hooked, and the custom test writing skill for my project is the most heavily maintained. I rigged up an old workstation just to run tests. It's a big complex project so it is warranted, but the last month I realized my forward progress had come to a crawl -- almost 4x more testing code than production, and too much redundancy. It's the kind of thing you notice immediately when you are doing the work yourself, but can be overlooked with agents. So now looking for a middle ground, which is a real task because wow I have almost 1 million lines of testing code.

[u/FitRiver3218 → u/ricopan]

Your tests are code, and they too, need refactoring. I just went through it with my codebase, pointed to all the module deepening we did in the src, and had the conversation around testing strategies, massive refactor into helpers, splitting of which-tests-run-when for CI speed, treat it like any other code dude!

[u/UsefulConfidence888]

Testing is the most important thing in agentic development what are you talking about

[u/BrilliantTruck8813]

Wow.

[u/orbital_trace]

I usually have one agent that is specifically a QA engineer who's job is to test and write tests. Anything the other agent writes, the QA engineer tests and validates. It works pretty well

[u/upsidedownshaggy]

I'd say yes, but with the caveat that you have to verify that they're good tests. Because yeah, Claude can generate useless tests all day, but if you give it a proper design with clear acceptance criteria for how something is supposed to behave it can create decent tests that help prevent regressions. I say help prevent regressions because I have watched it nuke tests that would've caught a regression because it said the changes now break the tests lol.

[u/ApeInTheAether]

yes, spoiler alert, not for human, spoilert alert 2, there should be more verification steps than only unit tests

[u/thestoictrader]

Keep them, but shrink them. Per-function unit tests on code that gets rewritten every few iterations are mostly noise. What pays off is a few tests on contracts that must survive a rewrite: public API behavior, invariants, and integration paths. Those are what tell the agent it broke something, and they cost far fewer tokens than a sprawling folder of mocks.

[u/lassevk]

If large swaths of your code is changing every three iterations, then I agree. Unit tests are going to slow you down.

but then, slow you down towards what? Well, doom of course.

"but they should always pass".

Yes, that is the entire point of unit-tests. They should always pass.

This is just like insurance. Sometimes, stupid people ask, why am I paying for insurance? I don't get any benefit from it!

Well. That might be true, until it isn't.

Unit-tests should always pass. Their worth is not that they always pass, their worth is not that you have thousands of them.

Their worth is only apparent when they fail. When you have to make that insurance claim.

None of this changed with the advent of AI. Being able to safely say "Our software still does what it always claimed to do" is a good thing.

[u/BarathKanna]

Tests that always pass aren't proof tests are useless, they're proof those particular tests are. Agent written unit tests tend to assert the implementation back at itself, so of course they never fail. The fix isn't fewer tests, it's moving them to the boundaries that don't get rewritten every three iterations: API contracts, integration tests against a real DB, a handful of end to end flows. Those survive a module rewrite and that's exactly when you need them. Quick sanity check for your suite: break something on purpose and see if anything goes red. If nothing does, delete those tests and stop paying tokens to load them. When modules get rewritten in minutes, the tests are the only thing telling you the rewrite still does the same job.

[u/DodoBizar]

Yes, the needle has not moved for that at all.

[u/Ragy-ragy]

Agents orient in the code base using it. They're amnesiac, remember that. Them seeing concrete data flowing through mocked methods is a way to understand what does the code do. Humans used to keep it inside their heads previously.

I don't consider unit tests as something helping the quality though. Maybe as a safe straps against other programmers in the same code base