Look at how simple and readable our test has become! 🤩

When writing harness tests, we heavily work with async/await . Therefore, one of the first things we should always do is to put the async keyword in front of our callback.

The loader allows us to load the harness objects. In our case, we are interested in the harness for the radio button with the “Dead” label. Once we got a hold of the harness, we can use its API to call the check method. The check method is self-explaining and internally knows how to check the checkbox — we no more need to lookup implementation details of mat-radio-button .

The same goes for the table. We only have one table on our page, therefore it’s enough to ask the loader for the MatTableHarness without specifying a selector. After we got a hold of the MatTableharness we can use the getRows function to get the number of rows.

Notice that we didn’t call fixture.detectChanges() nor fixture.whenStable() . The material component harness takes care of stabilizing the fixture once we interact with a component. This is amazing and makes our test less error-prone.

Another amazing benefit is the readability of our test. Take a look at the following two examples, what do you think? Which tests are easier to read? The classic tests or the harness test? Which one contain less boiler code?