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

Already subscribed? Sign In

Autoplay

    Handle Page Requests in Tests with Puppeteer

    Tyler ClarkTyler Clark

    In this lesson, we are going to fetch the Star Wars api from a React lifecycle method. Then inside of our tests we will intercept the request and abort it. Finally we'll test that our error message works as intended.

    reactReact
    puppeteerPuppeteer
    jestJest
    javascriptJavaScript
    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
    Transcript

    Transcript

    Instructor: 00:00 Inside of our application, we're going to do async componentDidMount, const data equals await fetch, the Star Wars API URL. Then we'll unwrap that promise, and set our Star Wars property to our data. We'll add that to our state object.

    00:16 Then inside of our HTML, let's add an h3 with a data property of Star Wars. Then we'll do this.state.StarWars.url, receive Star Wars data, if not, then something went wrong. Puppeteer gives us the ability to intercept requests made on a page.

    00:37 Not only can we write tasks that check the content of our h3 with successful requests, but we can intercept the request and force the failure. This way, we can test our UI on both successful requests and unsuccessful ones.

    00:51 Inside of our tests, we going to add a page.setRequestInterception to true. We'll do page.onRequest, intercept the request with an if check on that request to make sure the URL includes swampy. Then we're going to abort this request. If not, then we'll continue it on.

    01:15 This setRequestInterception is basically a flag that enables us to access each request made by the page. Once a request is intercepted, the request can be aborted with a particular error code. We could cause a failure, or we can intercept, then continue after checking some conditional logic.

    01:34 Now, let's go ahead and run a test checks this h3 content. We'll do test, fails to fetch Star Wars endpoint. We'll do const h3 equals await page.eval, our data attribute, Star Wars. We'll grab the inner HTML out of it, and then expect h3 to be receive Star Wars data.

    02:00 As we can see in our running app, as soon as the page loads, it goes out and fetches the Star Wars API. When it receives the data, our h3 text changes to received Star Wars data. Let's throw a .only on this test, and we're only testing this one, then save it, and run our npm test.

    02:19 That test is failing. It looks like it's getting the something went wrong text, instead of our received Star Wars data that we put to test. This goes to show that our request interception logic that we wrote is working as intended.

    02:38 On each request, we filter out the one that includes the swampy string and abort it. Everything else, we let continue on. Our failed request text should actually be, "Something went wrong." Now, let's remove this only, and skip our console and exceptions tests, because they will fail with the failed fetch request.

    03:01 Run our test in debug mode this time, so we can actually see the h3. If we notice, that something went wrong text stays the same the whole time. All of our tests pass, which means that we successfully aborted the Star Wars request.

    03:19 It's also worth noting that, when intercepting requests, we can control what headers are sent, what error codes are returned, and return custom body responses.

    Discuss

    Discuss