Testing React Applications Like an Engineer

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

As our React applications grow, so do the challenges of maintaining bug-free code. Crafting a reliable test suite can be a daunting task, often plagued by flakiness and complexity. In this talk, I’ll break down a practical, engineering-first approach to writing tests that actually make development smoother. We’ll dive into the best ways to integrate Playwright with React, ditch outdated testing mindsets, and adopt strategies that ensure your app works as expected—without the headaches. Expect real-world examples, actionable takeaways, and a fresh perspective on testing that might just make you enjoy it.

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

FAQ

Austin Shelby emphasizes the importance of testing as a proactive rather than an afterthought approach. He advocates for testing to be focused on user flows and documenting application functionality clearly and comprehensively.

NASA thoroughly tests every function and line of code of the rover by replicating Mars-like conditions on Earth, including similar soil, extreme temperatures, sounds, and winds.

Austin Shelby believes that in the age of Next.js, the traditional testing pyramid is less relevant. He suggests focusing on user-centric testing rather than strictly adhering to unit, integration, and end-to-end test ratios.

The 'arrange, act, assert' pattern is a structure for writing clear and effective tests. It involves setting up the test conditions (arrange), performing the test actions (act), and verifying the results (assert).

He provides an example of registering a new user in a notes app, demonstrating how to write a simple test using Playwright that verifies successful registration and redirection to the homepage.

User stories help create clear and relatable test cases that communicate the intent of the application’s functionality in a language understandable by both technical and product teams.

Tests serve as documentation by clearly outlining the expected behaviors and functions of the application. If functionality changes, failing tests highlight where issues occur.

Behavior-Driven Development (BDD) encourages using a shared language for writing test scenarios, enabling better communication between technical and product individuals about application functions.

Austin Shelby supports TDD as a tool for solving complex problems. He recommends reproducing bugs locally, fixing them, and using tests as safeguards for confident deployment.

Austin Shelby finds some BDD tools like Cucumber to be gimmicky and suggests focusing on the specificity and clarity of test scenarios instead.

Austin Shelby
Austin Shelby
19 min
17 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Imagine the scenario of working on the Mars rover, emphasizing the importance of thorough testing. Learn to test React applications effectively like an engineer. Focus on user-centric testing over traditional paradigms. Write precise test cases as user stories using BDD for clear communication. Utilize a structured approach with arrange, act, assert steps for clear tests. TDD is valuable for bug diagnosis and solutions, emphasizing efficient bug reproduction and resolution. Annotate tests to reproduce and fix bugs, focusing on user flows and effective bug fixing.

1. Testing React Applications like an Engineer

Short description:

Imagine the scenario of working on the Mars rover, emphasizing the importance of thorough testing. Learn to test React applications effectively like an engineer. Focus on common testing issues and the role of React components in software development.

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.

2. User-Centric Testing with Playwright

Short description:

Focus on user-centric testing over traditional paradigms. Explore testing scenarios with a demo app using Playwright. Write simple tests for user registration and data integrity in the application.

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.

3. Creating Effective Test Cases with BDD

Short description:

Reset database before tests. Write precise test cases as user stories. Use BDD for shared understanding and clear communication. Tests document application functionality and pinpoint issues when changes occur. Be specific in test scenarios to create effective tests.

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.

4. Creating Clear and Structured Test Cases

Short description:

Summarize test steps for clarity. Utilize playwright features for descriptive tests. Share functionality details with product team. Focus on user intent in test cases for clear communication. Use a structured approach: arrange, act, assert for clear and repeatable tests. Verify functionality by testing node order by creation date.

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.

5. Structured Testing with Arrange, Act, Assert

Short description:

Utilize a structured approach with arrange, act, assert steps for clear tests. Verify node order by creation date using custom HTML attributes. Select elements by data test ID for Playwright testing. Annotate test steps for clarity and descriptive naming. Follow a repeatable formula for concise and effective testing.

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.

6. Effective Bug Diagnosis with TDD

Short description:

Run tests for beautiful results. TDD is valuable for software development. Use Mars mission strategy for bug diagnosis. Reproduce bugs locally and use TDD for solutions.

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.

7. Efficient Bug Reproduction and Resolution

Short description:

Authenticate user to create a new note quickly with Playwright. Use context for adding cookies. Create user, session, and cookie for authentication. Reproduce bug by adding steps and fix 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.

8. Improving Test Annotation and Bug Fixing

Short description:

Annotate test to reproduce and fix bugs. Fix form submission issue for new notes. Key takeaways: focus on user flows, write clear test cases, structure tests effectively, and use TDD for complex problems.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Testing Web Applications with Playwright
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Watch video: Testing Web Applications with Playwright
Testing web applications with Playwright, a reliable end-to-end testing tool. Playwright offers fast execution, powerful tooling, and support for multiple languages. It provides precise selectors, web-first assertions, and code generation for easy testing. Playwright also offers features like live debugging, tracing, and running tests on CI. The future of Playwright aims to make testing easy and fun, with a focus on creating frustration-free web experiences.
Full-Circle Testing With Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Everyone Can Easily Write Tests
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.
Tiny Tests, Large Results
TestJS Summit 2022TestJS Summit 2022
21 min
Tiny Tests, Large Results
Automated atomic tests are a great way to improve UI tests by making them less brittle and faster. The tests focus on testing a single feature or component and have minimal UI interactions. The Talk explores examples of automated atomic tests and their implementation on web applications. It also discusses the analysis of atomic tests, login tests, and working with JSON Web Tokens for authentication and authorization. The Talk concludes by highlighting the use of UI and web requests in automated atomic testing.
We May Not Need Component Testing
Vue.js Live 2024Vue.js Live 2024
26 min
We May Not Need Component Testing
Component testing is a gray area between integration and unit testing. The demo app focuses on the cart component and writing test cases for Playwright component test and VTest. The first cart test encounters a bug with the invisible method in View Test.
Testing Mail Service With Playwright
TestJS Summit 2022TestJS Summit 2022
17 min
Testing Mail Service With Playwright
Top Content
Watch video: Testing Mail Service With Playwright
This Talk discusses how to test mail service with Playwright, covering e-mail verification, reset password user journey, and more. It explores the use of third-party providers for reliable e-mail delivery and demonstrates how Playwright can help perform checks on e-mail content. The Talk also introduces the concept of a fake SMTP server and showcases how fixtures can be used to access the SMTP server and perform assertions on the HTML body of emails. Playwright's HTML rendering feature allows for interaction with email content as if it were a regular web page. It highlights the ability to render HTML from API calls, perform assertions on the rendered page, and exclude dynamically generated data from visual regression tests.

Workshops on related topic

Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Building out a meaningful test suite that's not all E2E
TestJS Summit 2023TestJS Summit 2023
89 min
Building out a meaningful test suite that's not all E2E
Workshop
David Burns
David Burns
We're all taught to follow the Testing Pyramid but the reality is that we build out the Testing Christmas Tree. In this workshop, David will talk you through how to break down projects and put the tests where they need to be. By the end of the workshop you will be able to update your projects so that anyone and everyone can start contributing and truly living up to "Quality is everyone job".
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.
Live e2e test debugging for a distributed serverless application
TestJS Summit 2021TestJS Summit 2021
146 min
Live e2e test debugging for a distributed serverless application
Workshop
Serkan Ozal
Oguzhan Ozdemir
2 authors
In this workshop, we will be building a testing environment for a pre-built application, then we will write and automate end-to-end tests for our serverless application. And in the final step, we will demonstrate how easy it is to understand the root cause of an erroneous test using distributed testing and how to debug it in our CI/CD pipeline with Thundra Foresight.

Table of contents:
- How to set up and test your cloud infrastructure
- How to write and automate end-to-end tests for your serverless workloads
- How to debug, trace, and troubleshot test failures with Thundra Foresight in your CI/CD pipelines
Uniform Browser Automation Infrastructure
TestJS Summit - January, 2021TestJS Summit - January, 2021
127 min
Uniform Browser Automation Infrastructure
Workshop
Ivan Krutov
Ivan Krutov
In this workshop, I will show you how to quickly deploy and use browser automation infrastructure with Moon solution. We will start deploying everything on your workstation and will soon be able to run Selenium, Playwright and Puppeteer tests in parallel in the same cluster. Then I will demonstrate how to easily deliver the same experience for your team using a remote cluster in the cloud platform.