AiTOnline is a fortnightly Twitch livestream ‘AiT Online’ in which Mark and Richard explore a different testing tool or automation tool. Each stream is followed up by a debrief to share highlights, features and thoughts on what was covered. If you’ve missed any of the streams, you can view them on the AiTOnline YouTube channel.
On the 27th June, we did our second AiTOnline and this time we are exploring React Testing Library (RTL). We’ve used React as the UI framework for our automation playground, Restful Booker Platform, so we were both keen to see what RTL would bring to the party. We already have React tests in the codebase that use Jest and Enyzme, so it was a great opportunity to see how RTL compared.
You can watch the full video or we’ve broken it down into the main sections below.
The GitHub Repo - 4:34 - 9:56
React Testing Library is an open-source tool so you won’t be surprised that you can find it on GitHub. What might surprise you, as it surprised us, is to see that RTL has 100% test coverage! This is a fantastic readme, Kent has put a lot of effort into it. We then walk through the example test to get an insight into how it works.
Whenever exploring tools on GitHub do invest five minutes or so reading the readme, some are better than others, but when there is an example, I encourage you to have to read through an example before diving straight into writing your own.
Watching a File With Jest 12:58 - 15:21
A great tip when working with Jest is to take advantage of the watch keyword which tells Jest to watch the file for changes, and after each change, it will rerun the file. This means you can see your progress in real-time without having to tell Jest to run the test each time.
Writing Our First React Testing Library Test 15:21 - 22:49
We start as we always do when an example is provided, we copy and paste from the example and change sections as we go. There is absolutely nothing wrong from this, that is exactly why people provide examples, to help you get started.
Snapshots 20:20 - 22:49
Snapshots are an approval type that exists within Jest. When you run a Jest test that is utilising the snapshot command it saves the output from the React component as a file, this is your snapshot. Then when you run subsequent tests, Jest compares the output to the snapshot file and reports any differences as a failure, or passes if they are both the same. Approval style assertions are increasing in popularity, it’s certainly something I’d encourage you to explore more.
Reading, Reading and more Reading 25:37 - 28:30
We wanted to create a test that had more complexity, so we decided to focus on some login tests. We chose login as it has login the component. The login component has a username and password field as well as a submit button. So, we intended to create a test that could successfully login. We went back to the example but were stumped as to how it all worked, so back to the docs we go.
We are a bit stumped at this stage, but we decide the best way for it to click is to proceed ahead, write some code and see where it takes us.
Improving Our Product Testability 29:33 - 31:25
We discover that React Testing Library prefers the custom element attribute of ‘data-testid’ as opposed to ‘id’. This is a pattern we’re seeing more and more, as UI frameworks start to autogenerate IDs and classes, especially with the increase in css-in-js. Those autogenerated IDs are a nightmare for automated checks as you need to continuously update the locators. That’s where data-testid comes to the rescue, we can add that to the elements with the React component file and they won’t change. So that’s exactly what we did.
Our Second React Testing Library Test 33:50 - 37:00
We decide to continue iteratively and create a simple test that utilises some more features of React Testing Library. We want to find and read the header text of the login page and assert it’s what we want it to be. The kind of test some people would do with WebDriver is surprisingly easy, and very quick with RTL.
The Penny Drops 35:08 - 35:41
RTLs primary guiding principle is
The more your tests resemble the way your software is used, the more confidence they can give you.
We’ve finally realised what RTL brings to the party, a set of methods that allow us to interact with components just like a browser would. Without touching any of the implementation of the component, which would break the guiding principle.
Our Third React Testing Library Test 38:27 - 59:58
We struggled to complete this test, and I’m not even convinced we end up with what we were hoping for. However, it highlighted areas we’d need to focus on if we were to continue to with RTL. The first being we need to increase our React knowledge to understand the library more and how it works, this would help us understand RTL more and its design. I imagine we could get all this by reading more of the RTL docs. We struggled with Nock and fully understanding what was going on, so we’d need to explore Nock more and maybe even checkout Axios.
However, we are confident we filled in the form and clicked the button though which shows the potential of this framework and already given us lots of ideas for tests we can remove from the UI/WebDriver layer and new tests we can add at the RTL layer due to the rapid execution time.
Lets walk this through 42.56 - 49:00
One of my favourite heuristics when I can’t get a tool or library to walk. We deliberately pause, and slowly walk through our intentions and compare them to what we believe the code is doing. We then even add in some debug information to help us understand what our code is doing. Finally,
Comparison to a Test That uses the implementation 101:32 - 103:15
We take a look at the hotel contact test where you can see we are filling in the room and clicking submit, however, we are using the implemtnation to achieve this test. We are using Component.update() and Component.setState() and Component.instance().submitForm, all this is the implementation of React and goes against the guiding principle of RTL. We can know see how we could rewrite these using RTL. They’d actually be a lot cleaner if we did.
This is a very nice designed library, and clearly very powerful. We’ll be going ahead and rewriting most of our Jest tests in React Testing Library once we’ve spent a bit more time exploring Axios and Nock.
We packed a lot into an hour there but shows the benefit of exploring news tools. We could see after 45minutes that we could get value from this tool and at the end of the hour we have a clear direction we could head in, and what additional areas we need to focus on. If you’re in a context where the product utilises React, you have to check this library out.