What is the difference between Unit and Component Testing?
And why you should care.
I am becoming a big fan of component testing. With component testing, you test in earlier stages of the development process, and instead of testing an entire application (or a big chunk), you test smaller parts of the application. From a Shift Left perspective, this is a significant development.
I often explain it as testing the “Lego blocks” of the application.
Those Legos are the building blocks developers write to build the application from the ground up. And each Lego comes equipped with one or more unit tests. But sometimes, we want component tests for the same Legos too. And this might seem not very clear. And because of this grey-ish area, I often asked the following questions:
- What is the difference between a unit test and a component test?
- Who is responsible for writing component tests?
- If we use component tests, do we need unit tests?
So let’s dive in and clarify the subject once and for all (hopefully 🙂).
What is the difference between a unit test and a component test?
A unit can be anything. It can be a function or a subroutine, and it can even be a component as long as it can be tested as the smallest isolated piece of source code which serves a specific function. So when we speak of unit testing a function or a subroutine, it is clear what we mean. But when it involves units for Front-end elements, things get blurry. Let’s focus on unit testing for Front-end components.
A unit is an unexposed component.
A unit can be a component, but if it is, it is an unexposed component. This means it is used as a technical unit within the application and does not require specific business requirements to do what it must. It should not have any dependencies. A unit can be a visual element, but often it is not.
A component is exposed.
A component is exposed and probably has dependencies. Often a component exists of multiple units. For example, a subscription form with input fields, buttons, and styling can be a component.
