What do you mean "exact output rather than behavior"?

If you mean asserting against hardcoded literals, then that is the preferred testing shape in most cases. And for good reason.

If you change production code and a unit test fails, that is useful. Idk why that's silly. If you want to test more complex interaction write a UITest or integration test.

I honestly think we're all living in different worlds. There's probably large differences in capability on a per-language, per-team, per-codebase, per-engineer environment that are producing wildly different perceptions in output quality.

▲

stingraycharles 10 hours ago | parent [-]

It would add tests for exact error messages, for example. It would add tests that the process exited with very specific error codes. Basically tests that I would never ever write myself.

And yes everyone works in different domains. I work at a database vendor myself, so mostly lower-level work.

I’m very happy and successful with LLMs, I just don’t think that these “just move all your tests to your type system!” or “get 100% test coverage” rules are an answer in the long term as we haven’t yet figured out how to do this well.

I personally treat tests as components that need to be well architected, maintained, and adding them risks increasing technical debt and needs to be treated as such.

▲

drooby 10 hours ago | parent [-]

That feels like a pretty uncharitable interpretation of my original comment.

I was describing general strategy, that when applied in concert is more than the sum of its parts.

E.g I mentioned property-based testing, that is another angle at which a test avoids assertions that are too fine grained.

	▲	stingraycharles 8 hours ago \| parent [-]
		Yeah I just don’t consider adding more or better tests as a solution to fragile code, which is the topic of the conversation. I think it has much more to do with overall architecture and design, and as for now, human oversight.