Front End Testing: Presentation Components

Recently we were asked for our thoughts on how we approach front end testing. This is, of course, a vast topic that's difficult to cover completely but this series will demonstrate some of the ideas and principles that guide our decisions when testing on the front end. We'll be using React in our examples as this is where most of our experience applies but the underlying fundamentals of why we choose certain tactics should apply in most front end environments.

Too simple to test?

This is the first in the series and covers the specific question: "Do you test purely presentational components with no conditional logic?"

Short answer: Yes. Even presentation components that simply render values? Yes.

There are a few reasons for this:

1. There's more that can go wrong than one might think.

2. The presentation may change in a way that would benefit from testing.

3. The component may end up with behavior.

   
   

To demonstrate we'll take this Task rendering component. Its purpose is to render the task within a To Do list.

On the surface the component is quite simple. Just take the text of the task and render it. Why this simple component exists comes down to design decisions. For now, let's presume it was a just a decision made by the developer. Here's the test:

This is a simple test that's pretty tempting to argue against having. So, let's have a look at the reasons I like to have this test.

Reason 1: There's more that can go wrong than one might think

Even simple presentation components can have errors sneak in. Here's a pretty common one:

In this case, our simple test saved us from an inadvertent typo. I'd guess that I'm not the only one to end up with a similar typo in my components and am sometimes lucky enough to catch it during manual inspection but a quick automated test can catch this before even loading the browser.

Reason 2: Presentation changes

Frequently components will end up with some level of presentation decision that does require a test. In our example, we've now decided that we'd like to strike through the text of completed items. This requires logic within the component which is still strictly presentation, but it comes with branching code. This needs to be tested somewhere and the Task component seems as good a place as any for now. Here's the updated test:

And the associated code change:

Had the previous test not existed we could have simply created the test now. Indeed, I would have. I find, however, that it's much smoother for my personal workflow to be able to jump right into an existing set of tests no matter how small. Had it not existed I'd create the new test file with the first test and committed that to the repository prior to adding my new tests and functionality.

Reason 3: Behavior changes

It's not uncommon for presentation components to suddenly need to react to user input. Let's say we've decided to allow users to change the completion status of a task by clicking on it. Here are the tests and associated code changes:

Once again, it is simpler to add on to existing tests than bootstrap a new one. Starting from a non-empty test is much more enjoyable at this moment.

Conclusion

These are the reasons I believe there's value in writing tests for even the simplest of presentation components. If a single simple test were costly to write and run then perhaps I'd delay the creation of the test until there was some logic as shown in the last 2 examples. In practice these simple tests have very low cost in initial writing, maintenance, and run time. In many projects I have a template script that for creating new components which also generates the boilerplate for the test. This brings down the cost of initial writing even lower.