Testing is an extremely important aspect of the software development lifecycle. Without it, how can we ensure that the code works as we’d expect given a set of requirements? You’ve probably heard about a few different kinds of tests: unit, integration, and functional. For the purposes of this post, we won’t be discussing functional testing here, as it’s somewhat disjointed (and layered upon) integration and unit testing.

During my time as a professional, I’ve encountered situations where I want to use both integration and unit. The software I write has the requirements based around what the user wants to see out of the software (i.e. user-driven requirements). As such, integration and functional testing are tests I primarily focus on since we need to ensure that we meet the requirements set by the user - what happens internally doesn’t matter to them.

Despite this however, there are situations where I will write out unit tests for myself, as I may need to be specific with the inputs and outputs, as well as the data type(s) of the input(s) and output(s). I like to think of these tests for the software that I (currently, at the time of writing) am working on as “integrity checks” for myself.

Unit vs Integration

Think of one as isolating different parts of the code and testing them, whereas the other looks at the interaction of different parts and doesn’t care how the different parts handle them.

---

Unit Testing is testing individual components within the code in a “whitebox” manner.

The software is generally broken up into “pieces” (or components), and these “pieces” are individually inspected and tested. Generally, these are functions, methods, or even classes and are defined by the person writing the tests. These tests can include testing for a proper output data type, proper output data value (or values), or throw the proper error given an input.

There’s a few advantages of opting for unit tests:

• Detecting defects (i.e. data types/structures) is easier than integration testing and are typically detected early on.
• These tests do not require other parts of the test (i.e. the “inner workings”) to be completed in order to complete the test.
• Unit tests are relatively straight-forward to maintain and can be re-usable.

Now looking at the other side of the coin (disadvantages):

• These tests generally don’t determine if your code can run with external dependencies.
• System-wide issues could go undetected.
• Does not check the behavior between two parts of the system.

---

Integration Testing is testing the software together in a group generally in a “blackbox” manner.

That is, the software isn’t broken down into its individual components, but rather code is written to look at how these individual components behave with one another and within the system.

There’s a few advantages with integration testing:

• Allows for a wide testing coverage within the system.
• Bugs regarding interaction between individual components are identified at this level.
• One additional step for reliability within the system.

But of course, integration testing does have it’s drawbacks:

• Running tests could be very slow.
• These tests often have a large scope and could encompass many components across one or more modules.
• Reliance upon internal and external dependencies is a must.

The diagram below gives a general idea on how integration testing and unit testing differ:

Note that I’m intentionally leaving out the different kinds of integration testing (top-bottom, bottom-up, and sandwich) explainations - this may (or may not) be covered in a different blog post.

Conclusion

So when you’re developing, what should you select as your de-facto testing type? My answer is neither - both unit and integration testing compliment one another. As the programmer, you know how much time you have on your hands as well as the requirements for the software, so it’s a judgement call.

---

If this post has helped you at all, I’d love to hear about it! Tweet at me or shoot me a DM: [@WxBDM](https://twitter.com/WxBDM.