3 ms·

I mean, I design my code, I'm just uninterested in distorting the design of the code to make it a little bit easier to write the least valuable kinds of tests (

I mean, I design my code, I'm just uninterested in distorting the design of the code to make it a little bit easier to write the least valuable kinds of tests (you can always unit test some code, it's just a matter of how extreme you want to go in your test harness - I believe it's the test harness that should change to fit the natural design of the code, not the other way around). >If a fault is triggered with an integration test but not with a unit test, that tells you two things: In most cases the interaction between units is far less predictable than the behavior of a given unit. And it's often not obvious which unit is 'broken'. Usually the units are doing what they were intended to do, it's the combination of behaviors that are broken (which yes, means 'the design is broken' - that's usually the harder part than writing the code!). No amount of unit tests will catch that. The integration tests will catch problems units, in contrast (admittedly, not 'accidentally working' cases, but I find it's rare anyone else cares about those).

motorest 2y ago
> 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?

motorest 2y ago

> 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?