E2E Testing Register Flow
In this lesson, we will learn how to test the register flow with Playwright.
We will write similar E2E tests for the register flow as we did for the login flow. Let us not worry about the basic tests that mirror the login flow tests. We will focus on the tests that are specific to the register flow.
So, just copy the below code and paste it into the register.spec.ts
file inside the e2e
folder.
How to test the register flow?
Let us first see how the flow works:
- Go to the home page.
- Click on the
Register
link. - Fill in the form with the required details.
- Click on the
Register
button. - You will be redirected to the dashboard page.
The issue might not be evident in the above flow. But, if you try to register with an already registered email, you will see an error message. So, we would need a way to register with a unique email every time we run the test.
This is one of the known issues with E2E testing. Determinism is hard to achieve in E2E tests with such scenarios. By determinism, we mean that the test and the flow should be predictable and consistent every time we run the test.
We greatly recommend you read Determinism: E2E Test Defects Determinism!, this is part of a React course from Stefano Magni and Jaga Santagostino. It also, helped us better understand the issues with E2E testing. Though their course uses Cypress, the concepts are the same.
So, what are our options to achieve determinism in this scenario?
-
Delete the user after the test: In our case, we can do this easily as we have access to the database which is also fast (locally). But, this is not always possible.
-
Use a unique email every time: In our case, we can also do this easily. We can use a random email every time we run the test. This is a good option if you do not have access to the database or if deleting the user is not an option.
Again, we use a local Supabase database, so both the above options are feasible for us. We will go with the second option as it is more generic and can be used in most scenarios. In a real-world scenario, you might have to evaluate more options to achieve determinism.
In our case, we use email and password for registration. But, your application could be using just third-party authentication like Google, Facebook, etc. In such cases, you might not have control over the email. In such cases, you might have to use a different approach to achieve determinism. One solution could be to create dummy accounts in the third-party service and use them for testing. That means you will have to manage these dummy accounts and delete them after the test.
Let us see how we can use a random email every time we run the test.
In the above code, we generate a random number and append it to the email every time we run the test. This way, we ensure that the email is unique every time we run the test. Of course, this is not a foolproof method, but it works for our case, and also we have control over the database.
Note how we now use exact: true
for the Password
label. This is because the Password
label is a substring of the Confirm Password
label. So, we need to be more specific in this case.
Run the tests and they should pass. Let us also test the case where we try to register with an already registered email.
Run the tests and they should pass. We have now successfully tested the register flow. We have also seen how to handle the issue of determinism in E2E tests.
Next, we have a bonus section, where we will discuss how to handle the cases where we test post-authentication flows. This is a common scenario in most applications. So, it is important to know how to handle such cases.
At this point, our code should match the code in the branch 6-e2e-register-flow
.
Last updated on
Building Register Page
In this lesson, we will build the register page with a form that allows users to enter an email, a password, and a password confirmation.
Bonus: Saving Auth State
We E2E tested the core flow of login and register. But to test the other protected parts of the application, we need to be authenticated.