What are Component Harnesses?

[suchona.kani.z]

This creates a dependency on the implementation of the component, which means that our tests must also be adapted if changes are made. This reduces the maintainability of the tests and requires constant adaptation to technical changes in the component library.

This problem and many others are solved by Component Harness!

Before we move on to solving our problems, it is important to explain the terminology. It is an interface that is offered to the developer to interact with the component. The calls to this interface interact in the same way as a user. This intermediate layer decouples the tests from the implementation of the component. A component harness is therefore peru consumer email list a class that allows the developer to map user behavior through an API. This makes the tests less susceptible to changes in the implementation and therefore more maintainable. In addition, more complex functionality of a component can be abstracted in the test.

What do our unit tests currently look like?
First, let's take a look at the current structure of our Karma test. As mentioned, we are using a Datepicker component as an example. First, we just want to test whether our component is displayed with the correct title. To do this, we need the following test code:


At first glance, it is clear that the title is being tested. At second glance, however, the strong connection to the technical implementation of the component becomes clear. In the next test, we increase the complexity and test user input. To do this, we need the following test code:


At this point it becomes clear that the test loses readability and comprehensibility due to its technical nature. When we next revise the test we will ask ourselves a few questions:

Why do we need to look for a Mat-Form field here and not a Mat-Datepicker?
Why do we need to trigger an event after setting the value?
These are just some of the questions. The test should only consist of three steps:

1. the search for the date picker
2. the user entering the date
3. the subsequent checking of the value from the datepicker.
This is achieved by switching to Component Harness.

Conversion of tests to Component Harness
The previous two tests are now switched to Component Harness. We start again with the simple test case that only checks the title. By switching we get the following test code:


It is clear that in this case the datepicker field is actually being searched for. The label can then be checked in this field. This has the advantage that you no longer need to know that the title is rendered as a mat label. In addition, this test is much more robust because it is decoupled from the technical implementation. If the title is no longer rendered as a mat label in the future, this test would still work.

The added value becomes even clearer in the second test case. This is intended to check a user input in the date picker. Without the use of Component Harness, a lot of technical knowledge and functionality was necessary. This is completely eliminated by the changeover:



The complexity that was added by the test setup has completely disappeared. If we were to introduce a new test, we should have no problems understanding the test and making any adjustments. How would we have to adjust the test if there were multiple datepickers? For example, we could use the placeholder set in each datepicker as a reference.