Why should I bother with unit testing if I can just use integration tests?

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 ca

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 =).

Answer 2

Integration tests suffer from a form of combinatorial explosion: Say method A has 5 different ways to behave (different edge cases, etc.), and so has method B. If you test them together, there are now in theory 25 different cases you have to test! Yes, many of them may end up being the same, or can't occur for one reason or another, but basically, the more things you test together, the more impossible it becomes to test all edge cases.

Answer 3

Unit tests aren't about debugging during initial development. They're about design, and they're about adapting to change. My unit tests almost never tell me where a bug is when I'm on my first pass through a hunk of code. My tests warn me when a bug arises six months later because somebody (possibly I myself) tweaked an object whose relationships they didn't fully understand.

Saying unit tests are a waste of time during initial develoment is like complaining that my car gets crappy mileage on its way out of my driveway.

Answer 4

Most of the problem is in the scenario you've posited -- according to your description, all B does is return null. Unit testing something that trivial probably is pretty pointless -- but is is writing the code to start with. If all you need is a null, use null directly and eliminate B completely. If B justifies its existence by really doing something more than return null, then the unit test you've described is incomplete, and you need to test whatever else B is supposed to do.

Answer 5

Another reason that I haven't seen anyone else address: You will not always be the one to maintain the code you write. Let's assume I've written A & B in separate modules, so that each is in a separate jar & has its own maven build file. Let's further assume that A is a Dao method, and B is some sort of Service layer. If I have written even a basic unit test for my Dao (perhaps using test driven development, even!), I have much more confidence that future changes to the database structure & query that may effect my dao are caught early. If, for example, on my team, another developer needs to add columns to a database table that my dao uses, I certainly want them to know right away if doing so will break my dao methods. If they have to wait to build all layers & run an integration test to verify that, they're just wasting precious development time, in my opinion. As a developer, I'd much rather run a 10 second unit test 10 times to fix & test any breaks I find than to run a 2 minute integration build & integration test run multiple times. Obviously, the times vary greatly depending on the size of the project (and your hardware), but those are the kinds of times I'm dealing with on my current project.

Answer 6

Reinforcing(hopefully) Samuel Carrijo's post...

---

When choosing between: 1) unit tests AND a small integration test vs 2) just the integration test you are making a calculated bet. If the integrated component is complex then any failure in the integration test is going to be tricky to figure out to find without unit tests. Sometimes I get it wrong, get a test failure in the integration test and start writing the unit tests without trying to debug. If you bet on not needing unit tests and win, you can save yourself a fair amount of time, and still have confidence in your code, but you don't get the "specification" benefits that unit tests provide to the next guy who has to touch your code.