> I mean, I design my code, I'm just uninterested in (...) the design of the code (...) to write (...) tests You're just admitting you're the root cause of the

> I mean, I design my code, I'm just uninterested in (...) the design of the code (...) to write (...) tests You're just admitting you're the root cause of these problems, and basic testing strategies play no role in that failure. > In most cases the interaction between units is far less predictable than the behavior of a given unit. Irrelevant. You write tests to verify how units of code should respond to specific input values, because your units of code will for a fact handle those sets of input values in Production and you want to prove they can and will handle them. > And it's often not obvious which unit is 'broken'. It is, if you know what you're doing. That's why unit tests matter, because they prevent you from hand-waving over the problems you're creating for yourself. You need to think through what are the preconditions and post-conditions of each unit of code, add checks, and make sure your unit of codes comply with those. These errors can only be a mystery if you have no idea what are these preconditions and post-conditions, enforce none, test none, and just allow failures to cascade and errors to be swallowed without having any idea of what's going on and where the problem starts and finishes. > No amount of unit tests will catch that. This is simply wrong. Consider for example null reference exceptions. Do you think it's impossible to tell with tests where a null reference is passed where it shouldn't?