When people have gotten excited about having so many tests, I've asked them what their plan is when 500 of their 1000 test suddenly stop passing. I've always favored 50 tests I know are meaningful, where any failure is something to respond to, over 500 tests with a bunch of overlap and edge cases I'm not sure matter. But now people aren't even thinking about that, they're just letting the agents make all those decisions.

I think this approach will continue to work for some people and orgs, but others are going to hit walls where their agents can't manage the mountains anymore. It's going to be interesting to see how people and orgs respond when that happens.

▲ CharlieDigital 5 hours ago | parent | next [-]

    > I've asked them what their plan is when 500 of their 1000 test suddenly stop passing

That's not a terrible thing; would indicate that some shared behavior is broken and -- assuming well structured code -- hopefully easy to isolate the behavior.

Bigger problems to me are more practical: 1) large tests waste context both in and out, 2) large volume of tests waste CI cycles which are becoming the bottleneck.

▲

mejutoco 4 hours ago | parent [-]

IMO the solution to too many tests is to encode more things in the type system. If you can encode constraints like the length of an array in the type system you know it is correct if it compiles, and that is one less run-time test to run.

	▲	CharlieDigital 3 hours ago \| parent [-]
		Agree, but this is not a pattern that is emergent from any coding agent I've used; it is only the result of explicit guidance to structure code in specific ways + relying on platform level analyzers. But more specifically, I usually see the explosion of test code in integration tests where there is heavy setup of entity graphs.

▲ StilesCrisis 5 hours ago | parent | prev [-]

Back up to the point where all the tests were passing, of course? Then debug.

	▲	mejutoco 4 hours ago \| parent [-]
		or git bisect until you get the exact commit that introduced it