Chapter 3.5.1: Mastering Component Tests
Learn about the value of Component Tests, how to determine when to write them, and their importance in ensuring robust and reliable applications.
Disclaimer: You are reading an early version of the text! The final version of the book will be revised and may contain additional content.
If we write Application Tests first for all of the new features we want to build, is it necessary to write Component Tests too? Although there is no definitive answer to this, I consider a couple of things when thinking about writing a Component Test or not:
Does the component include complicated, non-domain logic (e.g., accordion, tabs)?
Can a Component Test serve as a stepping stone to fulfilling an extensive Application Test?
Is it necessary to ensure a contract between two or more components?
Is the component important enough that a Component Test can help us improve its design?
We should always begin by writing Application Tests when working on a new feature. These tests ensure that the feature works as expected from the user's perspective, and they are a great way to catch regressions as we continue to build and modify the application. We also rely on Application Tests to ensure that various components work together correctly and that the application behaves as expected. However, once we have completed our Application Tests, it may or may not be worthwhile to write Component Tests too. For example, we should write Component Tests for complicated components resembling non-domain logic, such as accordions or tabs. These tests ensure that each component behaves as expected in isolation and can help us catch problems early without relying on less fine-grained and slower Application Tests.
Complicated, non-domain logic
For every application of a certain complexity, we often need complex base components for UI elements like accordions and tabs. Although we also test those complex UI components indirectly via our Application Tests, creating additional Components Tests for those kinds of components makes a lot of sense.
Creating Component Tests for components containing complicated non-domain logic is critical because we typically use those components in many parts of our application. When we change such a component, we want to ensure that those changes do not have unintended effects on other parts of our application. By writing Component Tests for these generic and highly reusable components, we can isolate any issues that arise and fix them without relying on slower Application Tests.
Component Tests as a stepping stone on your way of fulfilling an extensive Application Test
Of course, we should always strive to split more extensive features into multiple tiny pieces and set up our Application Tests accordingly. Yet, there will always be situations where we must write a lot of code to fulfill a particular Application Test for an inherently large feature. In cases like this, creating Application Tests along the way makes a lot of sense to ensure we're on the right path.