Question

Ok, I know I am going out on a limb making a statement like that, so my question is for everyone to convince me I am wrong. Take this scenario:

I have method A, which calls method B, and they are in different layers.

So I unit test B, which delivers null as a result. So I test that null is returned, and the unit test passes. Nice.

Then I unit test A, which expects an empty string to be returned from B. So I mock the layer B is in, an empty string is return, the test passes. Nice again. (Assume I don’t realize the relationship of A and B, or that maybe two differente people are building these methods)

My concern is that we don’t find the real problem until we test A and B togther, i.e. Integration Testing. Since an integration test provides coverage over the unit test area, it seems like a waste of effort to build all these unit tests that really don’t tell us anything (or very much) meaningful.

Why am I wrong?

Answer 1

Here’s an article on test categorization with some arguments

I won’t mention the benefits of testing as a whole, once we’re just comparing unit tests vs. functional tests:

• Unit testing helps you reduce the scope where to look when there’s an error. – Let’s include classes C, D, E, …, Z in this scenario. If you have only integration test and it fails, where do you start looking? If you don’t have unit tests, you would need to look everywhere inside each of those classes AND the “wiring” between those (which is a narrower scope).If you had unit tests, then you’d just need to check the wiring. In this case, it would also be a bad thing not having some smaller integration tests, like testing A, B, C and D only (so you already know if the “wiring” between those are in fact working).
• With unit tests, you fail faster. This is even more true if you TDD. You probably write your tests after you created all of class A and B. When you run your test, the way A and B works is not as fresh in your mind (maybe you wrote them the week before – hopefully you don’t start testing only when the product is “finished”). You must then remember what you were thinking when you wrote those. Also, unit test are faster, so you’re more likely to run them more frequently (perhaps run them automatically every time you save?)
• Unit tests provide a better documentation how your class should behave. If you’re a “normal programmer”, you probably hate writing documentation. This forces you to write documentation while programming, and forces the documentation to never be obsolete (if it is, your tests fail). And it also helps when you need to change somebody else’s code.

In the ideal world, when a test fails, you won’t need more than 2 minutes to know what to look (with no need of debugging). The idea of having tests of all sizes is just a guideline to achieve this goal, rather than spending hours/days/weeks debugging =).