Writing tests for the user registration page
Let's continue with our project by automating the registration page. We are already familiar with how to find a locator and write the tests for a page which we will use here.
The steps required to automate the registration process would be.
- Go to the login page
- Click on the
Register Now link
- Enter the name
- Enter the email
- Enter the password
- Confirm the password
- Click on the
Register button
- In the login page, enter the email
- Enter the password
- Click on the
Login button
- Confirm the username in navbar
- Confirm the
LogOut button in navbar
So let's write the tests for this scenario.
Now execute this test. Great! This passes.
But try executing this again. It will fail with the error stating the Email has already been taken.
Using faker to generate random data
Lets modify the test to use faker. Faker creates randomized values for real-world entities which resemble their original counter-parts. Using faker solves the issue of the same email being used again for the registration process. For this add faker into our Playwright project.
Now lets use faker to generate the user credentials.
Now the tests should pass in all the runs.
Introducing POMs
If we observe the test for register, we see that the last five steps are the same as the steps in the login spec. We should try and uphold the Do not Repeat Yourself (DRY) convention as much as possible. This is where Page Objects Models come into play. Lets extract the logic for the login spec into a POM.
For this create a new directory called poms and add a login.ts file in it.
Now extract the logic for the login operation into the login.ts file.
Now lets create an instance of this class in the register.spec.ts file.We will have to pass in the page context during the object instantiation since fixtures are not accessible outside test files.
We can also replace the steps in login.spec.ts with our new POM as well.
The need for fixtures
We have successfully avoided code repetition. POMs can be used to extract out any repeating logic specific to a page. The only downside is that the fixtures aren't accessible in the POMs by default. In cases such as the code above, where the number of fixtures used is less in number, it is fine to instantiate a new POM object by passing in the required fixtures. What about the case where a POM requires 4 or 5 fixtures for their proper working? We will have to pass them in during each use of the POM which is not very "DRY".
These are the cases where POMs as fixtures make a lot of sense. Let's convert the POM above into a fixture and see the difference.
Start by creating a fixtures directory and adding an index file.
Lets convert the POM into a fixture.
Now import the extended test from the fixtures in our tests and use the POM as a fixture.
Now let's see if the tests are running as expected
Excellent, the tests are working as expected but with a much cleaner code. To summarize, if we have a page specific logic repeating in multiple places, we can create a Page Object Model for the page and extract the logic there. Since POMs do not have access to the test fixtures, we have to pass them in during the object instantiation. To avoid this process and make the code look cleaner, we can convert the POMs into fixtures from where we can use them without repeating the instantiation process.
Let's commit these changes.
