3 ms·

GIVEN a function that returns one or zero, which is fully unit tested. GIVEN a function that divides one number by another, which is fully unit tested. WHEN I

GIVEN a function that returns one or zero, which is fully unit tested. GIVEN a function that divides one number by another, which is fully unit tested. WHEN I integrate both functions together. THEN I should get back a number. This is why you need integration tests. Interaction of fully tested units does not guarantee that they can be integrated together in arbitrary ways without the possibility of bugs being introduced from the integration. The above example integ test would reveal a DivideByZero error. This is a super simplistic integration of two simple functions, now imagine a massive enterprise system and how many bugs could be due to the integration of its parts alone, even if individually each part is one hundred percent correct and bug free.

iainmerrick 9y ago
That's what I was about to say too! But you said it better. :) Unit tests are for standalone modules. Integration tests are for apps. It's definitely good to factor stuff out into modules where you can, but ultimately you'll still want to check that everything works when it's all hooked up together. I guess the alternate approach would be writing "mocks" for the submodules, so the higher-level app can be treated as a module itself, and unit tested rather than integration tested. I've found that to be difficult and error-prone compared to integration testing (or normal unit testing for that matter) -- as you say, unexpected interactions between modules can easily fall through the cracks.
matt_sales 9y ago
you're missing a unit test case for your division function -- the case of 0. That test will reveal the function's domain is non-zero numbers. And you know this because you got the fast feedback from your unit test. No integration test using 0 necessary unless you want to test the failure scenario. BTW, nobody is saying not to use integration tests. But unit tests are faster, more stable, and easier to maintain and execute.
- AstralStorm 9y ago
  Hmm? The division function actually works as defined by throwing a floating point exception, returning one of infinities or other well defined behaviour It's the test of the user of the function that is incomplete.
skybrian 9y ago
Of course, but the point of the original article is that if the given functions work properly in isolation, it won't feel like writing an integration test. It's just an ordinary test.

iainmerrick 9y ago

That's what I was about to say too! But you said it better. :) Unit tests are for standalone modules. Integration tests are for apps. It's definitely good to factor stuff out into modules where you can, but ultimately you'll still want to check that everything works when it's all hooked up together. I guess the alternate approach would be writing "mocks" for the submodules, so the higher-level app can be treated as a module itself, and unit tested rather than integration tested. I've found that to be difficult and error-prone compared to integration testing (or normal unit testing for that matter) -- as you say, unexpected interactions between modules can easily fall through the cracks.

matt_sales 9y ago

you're missing a unit test case for your division function -- the case of 0. That test will reveal the function's domain is non-zero numbers. And you know this because you got the fast feedback from your unit test. No integration test using 0 necessary unless you want to test the failure scenario. BTW, nobody is saying not to use integration tests. But unit tests are faster, more stable, and easier to maintain and execute.

AstralStorm 9y ago
Hmm? The division function actually works as defined by throwing a floating point exception, returning one of infinities or other well defined behaviour It's the test of the user of the function that is incomplete.

skybrian 9y ago

Of course, but the point of the original article is that if the given functions work properly in isolation, it won't feel like writing an integration test. It's just an ordinary test.