This is secret unit testing tip #4. Want more? Watch the webinar.
Many people who start out writing tests get hung out the semantic difference. What is a unit? When does a unit test cross the border to integration land? Is it a narrow border or a wide plateau between them?
For me, it’s never been about the type of the test. It’s about its purpose.
Integration tests are great for knowing that the components in your application work together correctly. That’s their big advantage over unit tests. However, they also have a couple of disadvantages:
- They are slow.
- They require big setups (databases, services, etc.)
- When a test fails, fixing and debugging takes a lot of time (see the first two points).
Unit tests are the answers to the disadvantages of integration tests:
- They are quick. This means you can run them all the time, many times a day, and see how the code behaves.
- They require minimal setup (just for the unit, everything else is isolated)
- When a test fails, fixing and debugging take a very short time (because it’s focused on just part of the code, has simple setup and is quick)
Unit tests are about immediate and effective feedback. Immediate feedback means you don’t waste time waiting for the answer. Effective feedback means that the tests pinpoint the failure, and since they are short and readable, there’s even a shorter distance between failure and fix.
Do you need both kinds of tests? Yes. You want to get the benefits of both types of tests.
Which are more effective? Depending on what problem you’re trying to solve, obviously. Integration tests confirm your app is ok, while unit tests add the ability to pin-point problems and fix them quickly.
Which are easier to write and run? Generally unit tests, because of the complex setup issues that are usually required for integration tests.
So stop the debating, and start writing tests.