Testing React Applications Like an Engineer

Imagine the following scenario. You are an engineer working at NASA, and for the past few years you have worked on the perseverance Mars rover. And finally it's time. It's on the way to Mars and everything is going well. It lands successfully, but then there's an unexpected error. What can you do? You can't just fly to Mars and fix it, well, because it's one of the most expensive Well, because it's 140 million miles away. So what do you do? Exactly for these cases, every single function and every single line of code in the rover had to be thoroughly tested. And NASA engineers are one of the best testers in the world. They replicated the scenarios that can happen in Mars in earth. They created a little playground with similar soil that is in Mars and exposed the rover to extreme temperature, sounds and winds. And we can use these same techniques when we are testing our software.

And that is what I want to help you do today. I want to help you to test React applications like an engineer. My name is Austin Shelby, and I'm a freelance software engineer from Finland. Some of you may know me from my YouTube videos where I teach programming. I'm also the founder of MandoFlow, the best way to learn Mandarin Chinese online by turning your favorite YouTube videos into personalized language learning lessons. So when I talk about testing, I want to focus on four main issues that most developers have, starting with that testing is seen as an afterthought.

Now, if you have learned anything about testing, you have surely come across a picture that looks something like this, the famous test pyramid. It shows the optimal ratio of end to end integration and unit tests that you should have in your application. Or maybe you have seen an image like this. Or maybe this one. Now, it seems like everyone has their own opinion of the perfect ratio. But I think in the age of Next.js, it doesn't matter that much because most of the code that we write nowadays looks something like this. Now, React components in its simplest form are just a function of your state. But let's take a look at this single unit, a single React component. Here we are getting the authenticated user, which checks the request cookie and fetches the session based on it. If there is a user, it will redirect it into the profile. This redirect function throws a special Next.js error. And we're also rendering the register form. So this single unit is doing quite a lot of things.

So should we write a unit test to it? I don't think it matters. And honestly, I would forget about the unit integration and end to end paradigm. And rather focus on the user because most applications have one of two goals. Either to get the user to sign up or make them do a purchase.

Now, let me show you the demo application that I created for this talk. We can use this to explore different scenarios and how to test them with Playwright. So in the notes app, I can create a new user. Let's just call it Austin. And add some password. Once we register, it redirects us to the home page and gives us a nice welcome message. We can also create some notes. Like A, B, and C. And we can see that they're being ordered by their creation time.

Now, let's use the registration as an example on how to write a simple test with Playwright. We're going to import test and expect from Playwright, and then we're going to write the test first. We're going to go to the register page. Then we're going to select the username input by the label username and password. Then we're going to fill in the data. Test user and password 123. And then we're going to press enter. Then we're going to perform two assertions. First, that the page should be on the home page and that we have the welcome message. Welcome test user. But there's one more thing missing. These tests are touching the database and we want each test to be started from a clean slate.

So before each test, we want to reset the database. And if we run this test, we get the following report. All of the steps pass successfully. But often writing test cases is more difficult than writing the test. And a great way to think about it is this. Right now it says works, which is not very precise. I think we can do a lot better than that. A great test case should read like a beautifully written user story.

Let's think about the registration case. If we write a user story, it would go something like this. As a new visitor to the Notes app, I want to register for an account using a registration form so that I can start publishing notes. This is something that a product person would write, for example. Now as engineers, we would be more comfortable with something like behavior-driven development. In BDD, we're using a shared language that both technical and product people can understand. And we can communicate about the different functions of our application.

Tests are the best way to document the functionality of your application. If the application somehow changes, the tests fail and we can tell exactly where something went wrong. But a lot of BDD tools like Cucumber are a little bit gimmicky. So I don't recommend using them. But what we can learn from BDD is how specific they are when they write the test scenarios. Let me give you an example. For the registration, we can write something like this. Given I am an unauthenticated user, when I navigate to the register page, and I enter test user into the username field, and I enter password 123 into the password field, and I press enter, then I should be registered successfully and I should be redirected to the home page.

Now this is very precise. We can write a very nice test based on this. But it's quite long. Let's summarize it into a single paragraph. Register user with valid credentials and redirect to home page. Let's go back to our test and rewrite it like this.

Next, we can use a very good playwright feature, test step, to annotate our test with different descriptive steps. So for the first step, given I am an unauthenticated user in the register page, and I enter valid credentials and press enter, then I should be registered successfully and redirected to the home page. Like I said earlier, a well-written test should read like beautifully written prose. And it will look something like this in the test report. And these reports are a great way to share functionality with product people.

If they want to find out, for example, in which page should the application redirect after a successful registration, they can just look at the test steps and find out it should redirect to the home page. This is the best way to document the functionality of your application. So think of the intent of your user stories. What does the user want to achieve? And communicate that in a language that both product and technical people are able to understand it. And annotate your tests using it so they come more clear. But we don't only want our test cases to be clear, we also want our test to be very clear.

And we can do this by using some structure. We want all of our tests to be so clear that we can find out what is happening at a quick glance. And we want to use a repeatable formula that we can use over and over again for every single test we write. And the pattern that I want to teach you is called arrange, act, assert. Here's how it works. In the arrange step, we do stuff like reset the database, seed some test data and set up authenticated sessions. In the act step, we do stuff such as navigate to the target page, interact with different elements on the page, such as input fields and buttons, and submit forms. In the assert step, we select different elements from the page, assert the correct state, and even check the URL that is correct.

Now, let's use this guideline to write a test. Let's start with the homepage. Here we can see three different nodes, and if we can look at the dates, we can see that they are ordered in descending order. So let's write the test that verifies this functionality. We're going to start by giving it a descriptive name, list nodes in descending order by creation date. Now, for the arrange step, we want to set the stage, and we do this by seeding some data into the database. We're going to put there three different nodes, third, second, and first, which are all created on different dates. Next, we move on to the act step, and here we just go to the homepage. That's it. Now, the most crucial, the assert step. How can we assert that the nodes are in the correct order?

Let's take a look at the application again. We have the three nodes, and we need to check that the content is what we expect. But how can we select them? In the registration form, it was easy because we could just select inputs by their label. But in the homepage, the nodes, they don't have any label. So how do we select them? Well, Playwright provides a great solution by using some custom HTML attributes. Let me show you. So this is the React component for the node, and I want you to pay attention to the link component. Here, we are rendering the content, and this is the element that we want to select in our Playwright test, and we can identify this element by using a custom HTML attribute data test ID, and we can give it any descriptive name that we want. Here, we give it node content, and then in our Playwright test, we will select all elements by the test ID node content, and then we're going to do four assertions. We're going to check that there are three nodes and that the contents are third, second, and first. Next, we can annotate each step, arrange, act, and assert, so they are more descriptive. First, given there are three nodes, when I visit the homepage, then I see the nodes in descending order by creation date.

If we run the test, we see a beautiful test result. And the last point that I want to drive home, which is probably the most controversial, is that TDD often feels like a waste of time, but I actually disagree. I absolutely love test-driven development. Let me explain why. Let's go back to the Mars mission. So the engineers at NASA were very smart. They didn't just create one rover, they created two, and they are the exact copies of each other. One of them they sent to Mars, but the other one they kept in Earth, and that's for a very good reason. Imagine a scenario where something goes wrong in the Mars. For example, the rover cannot climb up a hill. So what's the problem? Maybe the hill is too steep, maybe the soil is too sandy so the tires cannot grip, or maybe the battery is drained. Well, the way they can figure out what's the actual problem is by reproducing the scenario on Earth and then trying to figure out the solution. And we can use this exact same strategy when we are testing software. Let me show you. Imagine in the notes app one day you get a bug report. One user managed to create the same note twice, which is very strange. So you take a look in the database, and you look at the created at date, and you can see it's almost the same. There's only one second between them, so it looks like that the user managed to submit the form twice, which shouldn't happen. So this might be a bug. So let's use TDD to figure it out what is going on. So I want you to think like an engineer. First, we want to reproduce this bug locally, and then we want to use TDD to guide us towards a solution. We can fix it and deploy it with confidence as we have the test as a safeguard. So let's get started. So let's think about the three steps, arrange, act, and assert. What do we need to have for this test? First, we need to have an authenticated session. Second, we need to be in the profile page. Then we need to select the input by the label note, and then we need to write some text and submit it twice. Then we need to assert if there are one or two notes created. All right, let's start working on it.

So first, we're going to call it authenticated user can create a new note. The first arranged step, we need to create an authenticated session. During the registration form, we just enter the username and password and submit the form, and this way we can create an authenticated session. But that is quite slow and we have to fiddle around on the UI. We are programmers, so we are very lazy, so we want to automate this. Why not just manually insert the user and the session into the database and then attach the session token into the cookie? We can do this with Playwright very easily.

For each test, Playwright gives us context, which we can use to attach cookies. We integrate user and sign in function. We create the user and the session, and then we're going to use the context from Playwright to add a cookie with our session token. This way, we can create a user and an authenticated session very quickly. Let's move on to the next steps. We go to the profile page, get the input by the label note, enter Wow, press enter, and then do two assertions. We assert that there's one note with the text Wow. We run it, and everything works.

Let's annotate the test a little bit better and try to reproduce the bug by adding some steps. Given I am an authenticated user in the profile page and I write a new note Wow and press enter twice, then I should see one new note with the content Wow. We run the test, and it fails. We should have only one note, but we actually have two. So we managed to find the bug. Now, let's fix it.

Now, let's move on to the next step. Let's annotate the test a little bit better and try to reproduce the bug. Let's add some steps. Given I am an authenticated user in the profile page and I write a new note Wow and press enter twice. And here we press the enter key twice. Then I should see one new note with the content Wow. We run the test, and it fails. We should have only one note, but we actually have two. So we managed to find the bug. Now, let's fix it.

This is the form that we use to create new notes. And I want you to pay attention to the submit button. While the form is submitting, we're just changing the text. We are not actually disabling the button. So let's fix it by disabling the button when the form is submitting. Now when we run the test, it all works great.

So here are the main takeaways I want you to take away. Whenever you're writing tests, forget about the end to end integration and unit paradigm. Rather, focus on the user and what are the most crucial user flows for your business. Next, write clear test cases using a language that both product and technical people can understand. This is the best place to document your application's functionality. Third, structure your test with the arrange, act, assert format so they can be easily written and anyone can understand them. And lastly, use TDD as a tool to solve complex problems. First, reproduce the bug locally. Then fix it and deploy the change with confidence. Thank you so much for listening. I had a great time making this and hope you learned something new. If you have any questions or you just want to connect, here are all my links in social media. Alright, please enjoy the rest of the conference and thank you again.