If your tests are breaking with every code change, you probably haven’t gotten your abstractions right. Runtime complexity is unrelated to how you test, so I’m not sure why you bring it up.

The problem with “ball of mud testing” (or mostly integration tests as you term it) is it’s not possible to write your code test-first, so you have no confidence that your tests or the code you’re testing are valid. I’m also a little puzzled about how you think it’s easier to exercise your edge-cases in your real environment vs. tests. I have coded things where nobody even knew how to get data into the real system to produce edge cases until after the feature was done.