Unit Or Integration? Simply Explained For Automation Newbies

by TestFortExpert on 12/8/2014

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.

Quick checklist

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.

Finish!

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!

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries