Whenever there’s a talk about test automation, everybody seems to talk about unit tests. But then they want you to run integration tests, too. What’s the difference between the two and why would you want to write them? Read on to find out.
Start digging here
At a closer look at the two test types, there’s seemingly no clear distinction. Most people tend to describe a unit test as the one that tests just one class. However, a unit can just as well consist of many related classes with the same purpose. Others even suggest that unit tests are the ones that are fast, etc.
Integration tests aim to check if several units can work well together in a team. People are usually afraid to write these as they think they’ll need to test all the system through.
For those who don’t like writing tests for UI, there are two options: to get a testing framework making UI testing easy, or to start testing right one level below your UI. The first way will make sure the UI is integrated correctly with the system, and the other way will let you isolate your UI from design and allow for improving your system design. To be brief, there’s one general rule: integration testing raises your confidence while unit testing improves your design.
As you can now see, it’s possible to include as many classes as you wish in your test, including even some external services, and call it whatever the current trend tells you to.
Unit tests explained
If you agree with the opinion that laziness drives progress, you’ll like the idea of unit tests. The thing is when writing unit tests you’ll want to be very lazy, because you’ll need to make sure you’re writing code as little as possible. Next, you also need to become overly sensitive to the code that’s not absolutely required to write in order to test this of that piece of functionality. Once you adopt this way of thinking and let it guide you through the test writing, you’ll find that the code gets easier to use, improve, fix and even understand. The basic idea of how this happens is the smaller tests you write, the smaller classes being tested you get.
Since each unit test only covers a small piece of functionality, it also gives you the benefit of knowing which system’s part exactly doesn’t work, when it breaks.
Integration tests explained
All devs usually write unit tests while newbies tend to create integration tests without even knowing about it. Besides, despite common disbelief, these are sometimes written more easily. All you need to do is just to follow a user story so that a new user could read your test and know what exactly happens there. And if you also name the class and methods of the test according to the features under test, they’ll even have no need to look at your test code to understand it.
Unit tests’ characteristics:
- They drive your design by helping you separate individual responsibilities into classes focused on implementing a single thing, and they can be easily replaced.
- More or less, they guarantee that separate units work as you expect, but don’t guarantee the whole system’s fine work. However, since they focus on implementation details but not on the system’s behavior and this can sometimes lead to false positives.
- They are very easy to maintain. Since each unit test only covers a small piece of functionality, you’ll know immediately which system’s part needs fixing if a test fails.
- With some effort they can document some small pieces of your app workflow.
Integration tests’ characteristics:
- They can’t drive your design.
- They check whether the system works well as a whole, regardless of implementation.
- They are hard in maintenance. It’s better to ensure your functionality is covered by unit tests in case your integration test fails to prevent yourself from a debugging session.
- They document the system’s main features and demonstrate the user actions along with their output end-to-end.
Congrats! Now you’re not a newbie anymore. At least not in automation. At least not in the integration vs. unit issue. Happy learning and automation!