←back to thread

413 points martinald | 4 comments | | HN request time: 0s | source
Show context
Volundr ◴[] No.46205257[source]
FTA

> I've had Claude Code write an entire unit/integration test suite in a few hours (300+ tests) for a fairly complex internal tool. This would take me, or many developers I know and respect, days to write by hand.

I have no problem believing that Claude generated 300 passing tests. I have a very hard time believing those tests were all well thought out, consise, actually testing the desired behavior while communicating to the next person or agent how the system under test is supposed to work. I'd give very good odds at least some of those tests are subtly testing themselves (ex mocking a function, calling said function, then asserting the mock was called). Many of them are probably also testing implementation details that were never intended to be part of the contract.

I'm not anti-AI, I use it regularly, but all of these articles about how crazy productive it is skip over the crazy amount of supervision it needs. Yes, it can spit out code fast, but unless your prepared to spend a significant chunk of that 'saved" time CAREFULLY (more carefully than with a human) reviewing code, you've accepted a big drop in quality.

replies(7): >>46205349 #>>46205526 #>>46205624 #>>46206683 #>>46206705 #>>46208955 #>>46214506 #
jf22 ◴[] No.46205624[source]
> you've accepted a big drop in quality.

Right, but you do it in a 10th of the time.

replies(2): >>46205955 #>>46206771 #
1. bagacrap ◴[] No.46206771[source]
I mean, just say you view unit testing as nothing more than a checkbox.
replies(1): >>46207181 #
2. jf22 ◴[] No.46207181[source]
I don't know why you'd think that.

200 decent unit tests are better than zero unit tests.

replies(1): >>46209757 #
3. welshwelsh ◴[] No.46209757[source]
The main benefit of writing tests is that is forces the developer to think about what they just wrote and what it is supposed to do. I often will find bugs while writing tests.

I've worked on projects with 2,000+ unit tests that are essentially useless, often fail when nothing is wrong, and rarely detect actual bugs. It is absolutely worse than having 0 tests. This is common when developers write tests to satisfy code coverage metrics, instead of in an effort to make sure their code works properly.

replies(1): >>46210712 #
4. jf22 ◴[] No.46210712{3}[source]
Look, you tell the LLMs what kind of tests you want and judge the quality before committing.

If you're letting the LLM create useless test that's on you.

I think you're reading these comments in bad faith as if I'm letting the LLM add slop to satisfy a metric.

No, I'm using an LLM to write good tests that I will personally approve as usefull, and other people will review too, before merging into master.