Evil Unit Testing (2019)
I haven&#x27;t experienced that problem. I&#x27;ve experienced the problem everyone else seems to have, too: Too many unit tests makes things brittle over time. One small change breaks a bunch of stuff in some mechanical way. Perhaps a required parameter got added to a function, or perhaps a class got too big and needed to be split up. Either way, you sometimes end up with a slew of tests that don&#x27;t compile.<p>Testing at a higher level <i>should</i> help, because the tests are more coupled to the behavior and less coupled to the implementation details. To the extent that you&#x27;ve achieved that, tests breaking due to a change shouldn&#x27;t be spurious, because the breakage is due to a legitimate change in behavior that needs to be accounted for in the tests&#x27; expectations.<p>Wild guess: The difference in experience here can be explained by the first three words of the article. A contractor who isn&#x27;t sticking around on any one project for long isn&#x27;t going to see consequences of their design decisions when they take many years to incubate. And a contractor who&#x27;s seen this at &quot;no less than six different companies&quot; probably hasn&#x27;t been a long-timer at many of them. Unit testing has only been <i>de rigueur</i> for 20 years, tops, so, even assuming those were the only six companies, I think it&#x27;s safe to assume a maximum of 3 years per company. Subtract a year or two from the incubation time because it&#x27;ll take a while to comprehensively revamp a test suite. A lot of Shakespeare&#x27;s plays seem to end on a happier note, too, if you always leave the theatre right after the third or fourth act.