Try out Cypress Studio
The Studio feature makes e2e test writing faster and easier than it's ever been before.
We've made it to the last lesson in this module — hurray! And I have a feeling you're really going to like this lesson because Cypress has gone and done what developers for years have wished was possible with testing: it's made it possible to show an e2e how it should conduct a test.
This Cypress Studio feature is still in experimental mode at the time I'm writing this, but hopefully, it will be out of experimental mode in the not too distant future.
For this lesson, we'll enable Cypress Studio and learn how to show Cypress what we'd like it to test instead of having to write all the test code ourselves. It's pretty cool and speeds up test writing time by leaps and bounds.
Enable the experimental Cypress Studio in our app#
As I said, Cypress Studio is not fully out of beta mode yet, so in order to take advantage of it, we'll need to add a special flag in our app.
cypress.json file where we added the
baseUrl variable a few lessons ago, and add the following line to our file.
With this line of
"experimentalStudio": true;, we're ready to start using Cypress Studio. Easy enough to enable it, right?
Test a user can add products to checkout#
The first step, just as it was for our other e2e tests, begins with determining what we want to test and making a test file for that particular flow.
For this test, another important functionality in Hardware Handler is that a user should be able to add products to the checkout when they go the My Products page. Let's get to it.
Make a new
Inside of the
integrations/ folder, make a new file named
add_products_to_checkout_spec.js. This is where we'll tell Cypress Studio to write our new test adding items to the checkout.
Right after creating this file, we'll set up a
describe block to contain our test. Keep the initial
describe simple. Our test will drill down into the details soon enough.
Mock our data and API calls for the department and product APIs
Before we can show Cypress how we want it to test, we need to set up a few mocks and some data for it to use whenever the test runs.
If you look at our actual
<ProductList> component, you'll see that when the component loads, it needs data from the
departmentApi and from the
productApi — so we'll need to mock data for both of those to serve up for this test.
We already have the mocked department data we need from our last lesson, so it's a matter of just importing that mock. Create a
beforeEach where we'll set up these mocks.
Right inside of the
describe, make a
beforeEach, and we'll start it off very similar to the one we did in our last lesson for the
Just like before,
cy.visit will bring us to the landing page of Hardware Handler, and then the combination of
cy.fixture will ensure that any HTTP calls made to the department API's
getAllDepartments function will be intercepted and the mocked data in our
department_data.json file will be returned in its stead.
Next, we must create data and a mock for the product API's
getAllProducts HTTP call.
Add a new mock to our
product_mocks.js file inside of the
support/service_mocks/ folder and add a new function named
getAllProducts is a
GET request, its setup is practically identical to the
addNewProduct mock call we already defined above it, but it doesn't even need to accept any arguments beyond a
response and a
Here's how that API call mock should look.
Create mocked product data
Our new product mock needs some product data to supply when it's called, so once more, we'll open up our
fixtures/ folder where our
department_data.json lives and create a new file named
This file will hold an array of mocked product data, and each
product object will have the following properties: