Transcript

In this video, learn how to isolate test state by adding another real-world, happy path end-to-end test with Cypress to the demo application. After watching this video, you will be able to prevent sharing persisted end-to-end test state and manage setup code for your own happy path tests.

You will also:

  • learn the dangers of saving persisted state between different tests
  • run specific tests with it.only
  • clear text inputs with the Cypress clear command
  • write explicit assertions with the Cypress should command
00:00
(playful music)
00:04
Welcome back to Test Double's intro course
00:06
on end-to-end testing with Cypress.
00:09
In the last couple of videos,
00:10
you learned about and wrote your first real-world,
00:14
happy path test.
00:15
You also interacted with forms
00:17
via the click and type commands
00:19
and used other kinds of selectors to find elements
00:23
with the get command.
00:24
In this video, you will get more practice
00:27
with real-world tests by adding another happy path test.
00:31
In the process, you will learn the downsides
00:34
to sharing persisted state between tests,
00:37
how to only run specific tests with it.only,
00:40
how to clear text inputs with the clear command,
00:44
and how to make explicit assertions with the should command.
00:48
Boot up the back-end server Cypress environment,
00:51
front-end dev server, and Cypress itself.
00:54
Also, ensure you're running
00:56
the tasks.spec.js file in Cypress.
01:00
We covered the user scenario of creating a task
01:03
in the previous video.
01:04
After creating a task,
01:06
a user will likely want to update details about the task.
01:10
That sounds like a great candidate for a real-world,
01:13
happy path test.
01:15
Every time the back-end test server boots up,
01:18
it clears the database so you have a blank slate.
01:21
So, there aren't any existing tasks to update.
01:24
You might be tempted to put this new test
01:27
after the create task test,
01:29
and reuse the previously created task for this new test.
01:33
That would work,
01:34
but raises other issues that could lead to flaky tests.
01:38
Sharing state between tests
01:39
where one test initializes the state is awkward
01:43
and there are no guarantees that future versions of Cypress
01:46
will run tests within a file in the same order every time.
01:50
Ideally, each test should be responsible
01:53
for managing its own state,
01:54
so it can be run in isolation from other tests.
01:58
So, this new test needs to first create a task
02:01
before it updates the task.
02:03
Add this new test below the create task test.
02:07
Instead of calling it directly,
02:09
you call an only method on it.
02:12
This will make Cypress only run this test
02:15
so you don't have to wait on other tests to finish.
02:18
Copy the code from the create task test
02:21
and paste it into this new test.
02:24
Now, let's make a few tweaks to make it more obvious
02:27
this is setup code and to simplify the setup.
02:31
Add a comment explaining what this chunk of code is doing.
02:35
Remove the new lines to group the code together.
02:38
Remove changing the status and setting the estimate for now,
02:42
since they're not really relevant for data setup.
02:45
Just leave the verification that the task was created
02:49
to make sure we're back on the project page.
02:52
We don't care if it's in the column we expect
02:54
because we already tested that in the previous test.
02:58
Save the file and verify the test creates the task.
03:02
Next, add a new section of code below this data setup block
03:06
to test updating the task.
03:08
Add a comment to specify what this block of code does
03:12
and create a new title variable
03:13
with an updated, unique title for the task.
03:17
Click on the task card on the project board.
03:21
Select the title input by the name attribute
03:23
and type in the new title.
03:26
Notice you use a new command called clear
03:28
in the command chain.
03:30
The clear command clears out whatever text
03:32
is currently typed into the input.
03:35
If you leave out the clear command, then by default,
03:38
Cypress would append the new title to the previous title.
03:42
Next, click on the Save button.
03:45
Verify the success message is displayed.
03:48
And finally, verify the new task title is present
03:51
and the old task title is not present on the project page.
03:55
You use the trusty contains command
03:58
to check for both titles,
03:59
but you use a new command called should.
04:02
The should command lets you write explicit assertions
04:05
similar to other testing frameworks.
04:08
It takes a string argument
04:10
that can represent different kinds of assertions
04:12
based on assertions from the Chai assertion library.
04:16
In this case, you pass in the assertion not exist
04:19
to verify that an element containing the old task title
04:23
does not exist in the dom.
04:25
Follow this link to reference
04:27
other assertions you can use in Cypress.
04:30
Save the file.
04:32
The test should rerun, creating the task, updating its title,
04:35
and verifying the updated task exists on the board.
04:40
Make sure to change it.only back to just it as well,
04:43
so other tests can run again.
04:45
Let's recap what you accomplished.
04:48
You learned the downsides to sharing state between tests.
04:52
You ran only a specific test with it.only.
04:55
You cleared a text input with the clear command.
04:59
And you made your first explicit assertion
05:01
with the should command.
05:03
In the next video, you will learn about the DRY principle,
05:06
learn how duplication affects tests,
05:09
and clean up some duplication
05:11
in the existing Yams test suite.
05:13
(playful music)

« Start at the beginning

‹ End-to-end Testing with Cypress Series: 04 Happy Path Tests

End-to-end Testing with Cypress Series: 06 DRY (Don't Repeat Yourself) ›

Jeremy Fairbank

Hash An icon of a hash sign Code Name
Agent 0029
Location An icon of a map marker Location
Maui, HI