We still have a few more tests to write in the tasks page. Let's write them now.
Delete a task
Here we need to:
- Add a new task
- Verify that the task was created in the
Pending tasks table
- Mark the task as completed
- Verify that the task was added in the
Completed tasks table
- Click on the delete icon
- Verify that the task is removed from both tables
Here we can see that all the steps until step 4 are the same as those in the test should be able to mark a task as completed. So let's extract that logic into a POM.
Let's add the tests for deleting a task now.
All the tests should be passing.
Adding tests for starring and un-starring
We can add the tests for starring and un-starring a task now.
For starring the a task:
- Add a new task
- Click the star icon
- Star icon should be highlighted
- The starred task should come up on top of the pending tasks
For un-starring a task:
- Add a new task
- Star the task
- Click on the star icon again
- Star icon should not be highlighted
Note that we are using this the same steps for starring the tasks in un-starring the task, so we can extract it to the POM. We should be able to understand when to extract a logic to a POM and when to write the tests in the spec file from these examples.
Let's execute the tests now.
Now we might see an issue. The tests dealing with starring tasks might fail in some runs and pass in others. Such a test is termed a flaky test. Let's see what is causing the test to fail.
Debugging flakiness
The error is thrown at poms/tasks.ts:59 which is
We are checking that the first element in the table is the starred element which is a valid test case. What is causing the test to fail is because of the parallelism which is enabled by default in Playwright. We have two tests dealing with the starring of tasks. When both of them are executed in parallel, there can occur a race condition which puts the starred task in another test on top. It is not recommended to run all the tests serially, even though it can solve this issue.
The best way to solve this would be to group the two inter-dependent tests into another describe block and configure that describe block to run tests in serial.
In this enhancement, we grouped the tests for starring the tests into a single named describe block and configured them to run serially so that the race condition is avoided. This approach is more optimized because we're not losing the speed provided by parallelism in all the tests just to avoid a race condition in a few tests.
Let's re-run the tests.
Now we can observe that the tests dealing with starring a task is executing one after the other. All the tests are passing as well.
Adding tests which verify multiple users - Multi-page tests
Now let's dive into some of the unique features Playwright provides us. For testing the feature where we assign a task to a different user, we need to:
- Verify that the task is visible under the
Pending Tasks section to the current user as the creator
- Verify that the task is visible to the assigned user under the
Pending Tasks section as the assignee
Here we are dealing with two different dashboards. We can only test the dashboard for a different user if we logout and login again. How do we avoid that? In a normal browser, the most sensible way would be to open a new Incognito or In-Private window and login there as a new user.
We can do the same in Playwright by initializing a new browser and a page context. Before we move on with our implementation, we have to make a minor change to the createTaskAndVerify POM method for tasks. Currently we have hardcoded the assignee as Oliver Smith. We need to make a change to that so that the method assigns any user we pass in.
Now let's write the test for dealing with multiple user logins.
In the above code, we have added in a new test should create a new task with a different user as the assignee which deals with the logic to sign in as multiple users. Here apart from the default page fixture we get from the test, we also initialize a new browser context and page for logging in as a separate user. Note that we have passed in an empty storageState into the browser context. This is because we have configured this test group with a global storageState in the playwright.config.ts file (Refer section: Adding tests for tasks and global setup).
This configures Playwright to restore the storageState in all the tests under the group whenever a new browser context is defined. So we have to manually define an empty storageState to prevent our application from being logged in before our tests begin in a new page. An empty storageState means:
- Empty cookies
- Empty origins. This also empties the local storage.
Let's run these tests now.
Great! All tests are passing. Let's commit these changes now.