Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
1×
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.

Autoplay

    Mock Your Backend with Cypress

    Brett CassetteBrett Cassette
    cypressCypress
    ^3.1.5

    Using cy.server, cy.route, and cy.wait, we can intercept requests to our real backend, and return known mock responses.

    The pros of using this approach:

    • It's much faster than interacting with the real backend
    • Doesn't need to seed data to the backend
    • Easy control of requests and responses
    • Can mock network delay and failure

    Cons:

    • No guarantee the stubs match the real backend responses
    • Not full end-to-end testing

    Recommended Homework:

    • Mock the route to create a new todo, and reply with a 200
    • Mock the route to edit an existing todo, and reply with a 200
    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: In this example, we're going to talk about mocking the backend. We can discover the reason we need to mock the backend by visiting our real page at localhost:5000. Let's switch over to Chrome.

    Here, we can edit our first to-do. Let's make this Hello, World with a bunch of Zs.

    Now let's return to Cypress, refresh, and we'll see that we have a failing test. That's because we expected this to have the text Hello, World, but it's actually using the real data from our real backend, which we've just changed.

    There are two strategies we can use to address this. One is stubbing all of our network requests. The other is that we can interact with the real backend, but we have to have a database seeding abstraction, as well as a totally isolated testing environment.

    In this lesson, we're just going to talk about the first one, and in later lessons, we'll show how to seed the database. To start, let's tell Cypress simply that we want to begin stubbing network requests.

    To do that, we can call cy.server. By default, this doesn't stub out any requests. They'll all still continue to pass through to the backend, but we do need to call cy.server before we can start mocking routes or spying on them.

    To actually start mocking our routes, we need to know what we need to mock. Let's go back to Cypress and take a look at our XHR request. We see that we perform a GET to api/todos. That's hitting the real backend. Let's mock that out.

    Let's call cy.route to that endpoint, api/todos. By default, this is a GET request.

    Next, we'll return an array of hashes. We can actually see what's in our real backend by looking in db.json.

    Let's go ahead and just copy this out and paste it in. We did expect this not to have so many Zs or any at all, so let's save it.

    Next, we have to cy.wait for this route to load, which means that we have to give it an alias. We can say asPreload and we'll wait for @preload. We'll save it and return.

    Now we can see that we waited for our preload, which returned our mock data and made all our tests pass again. We can also do a deep dive on this request by clicking on the preload, opening our console, and checking our XML HTTP request, where we can see everything like status code, response, body and headers, and we can inspect this to make sure it's what we just sent. It is.