2 ms·

> This works fine if the difficult part of your software is in nicely abstracted boxes, but in my experience the content of the boxes is usually fairly trivial:

> This works fine if the difficult part of your software is in nicely abstracted boxes, but in my experience the content of the boxes is usually fairly trivial: you can write a huge number of tests for them, but they're rarely where problems occur. That's perfectly fine. It's also the basis of the whole test pyramid concept. One of the main reasons why you have some problems caught in integration tests instead of unit tests is that developers introduced bugs by failing to characterize how some components actually work and thus fail to design both the units of code and the tests that go along with them. This is not a problem caused by unit tests. This is a problem caused by developers failing to design and implement components, which consequently means they failed to add relevant tests. > The integration and interaction are where you get by far the most value out of testing (...) It's perfectly fine to think like that. The test pyramid concept exists for a reason. However, when looking at failures you need to understand their root causes. If a fault is triggered with an integration test but not with a unit test, that tells you two things: - one or more unit of code is broken, - your unit tests fail to cover a very predictable failure mode. Each of these items by themselves reflect a fundamental failure in the way developers implemented their test strategy. > Unit tests are the last tests that should be added to any system (...) This take is fundamentally wrong, to the point that your software design process needs to be completely and fundamentally broken to believe it's reasonable that unit tests can be added post-facto after skipping the whole design process.

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

rcxdude 2y ago

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?