[KronisLV]

> Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there.

Sure, however tests failing after refactoring or removing seemingly unused bits of code will be a great way to figure out when one's assumptions about how everything works are mistaken, or to discover bits of code that one wasn't even aware of.

Along the lines of: "Oh hey, our tests caught that removing this seemingly unused dependency from pom.xml will break PDF export logic, because for some reason it loads classes dynamically and needs that package" or maybe "The tests revealed that our latest refactoring breaks JSON serialization of dates, because while we should be able to use these annotations for our Dtos properly, the underlying framework gets confused because of our serialization library."

The worst cases are where you don't have the tests and things break in ways that might not be immediately obvious. Such codebases will make any attempts at refactoring unsafe and inherently stressful, that's what I meant with brittle - you'll never be able to change anything whilst having confidence that things won't break all over the place.

[marginalia_nu]

To be clear, I'm not saying you shouldn't have tests, but if you change your pom.xml and the code starts blowing up at runtime, your code is still brittle.

Code that isn't brittle wouldn't behave like that.

Tests allows you to catch it early, but with the platonic form of non-brittle code, you wouldn't need to run any other tests than the test that tests the module you just changed.

[KronisLV]

That's a fair point! I guess it's a matter of what's under the hood vs how it appears on the outside. Code that is brittle in obvious ways is still better than code that is brittle in subtle ways and will break later. Code that doesn't have those issues in the first place is the best, of course.