Post #3033891

I've been rethinking my testing strategy for agentically coded projects (i.e., vibecoded; where I'm not touching the code directly). It's easy to just have it go and make tests, and sometimes poke it or add instructions to make more tests. I haven't seen much value from the result. In part I'm not reading the tests any more than I'm reading the code. But also the tests are _much worse_ to read than the code, tedious and obtuse. Agents (at least in the TypeScript stacks I'm building) love BDD testing. I HATE BDD WITH A FIERY PASSION. It's so, so stupid. I hate it so much. Anyway, there's quite a few things I hate that I'm letting the agents do if they think it's a good idea. I totally enjoy new programming paradigms and figuring out how to map elegant systems to new ideas and all that, but that's not my job in this system. If it's intuitive to the agent that's ok. But while my old opinions are often invalidated, it doesn't mean I can't form better new opinions. And my better new opinion is that BDD still sucks, and these tests the agent makes with no firm instruction are pretty crap. It's kind of okay to make crap tests, because crap tests waste developer time, and I'm very indifferent to the agent's time. But the tests don't seem very valuable. How do I know I know? 1. Writing tests before, after, or long after writing code seems to have no effect on quality. 2. Tests written after code seldom find errors. 3. Code correctness is really high coming from Opus. At least the code you'd unit test. Stuff that would NEED tests when written by a human just... don't need tests. 4. It's not to say there are no issues in the code, but the testing it learned from humans doesn't apply well. 5. Testing doesn't seem to help much with design errors. That is: fragile, poorly abstracted, poorly encapsulated designs. Testing CAN help with these things, but not the testing the agent does on its own. 6. Testing is crappy documentation, for me and the agent. (cont.)