Work with Document Cookies in Tests with Puppeteer

Tyler Clark
InstructorTyler Clark

Share this video with your friends

Send Tweet
Published 4 years ago
Updated 3 years ago

In this lesson we are going to test that a cookie is saved to the document whenever our login form is submitted. Then we will also learn how to set cookies from within our tests.

Instructor: [00:00] Now, let's say that when our form is submitted, we save a cookie to the page. This cookie will hold the user's inputted first name. Let's write an end-to-end test that checks the document after the form is submitted for this cookie.

[00:12] For simplicity, I've gone ahead and refactored our test to only open one page. This one page will emulate the iPhone 6. Since the saving of this cookie depends on the submission of the form, we'll add this test within the context of the form.

[00:28] We'll write a new describe block here for our login form, and then copy and paste our login form text to inside of it. Next, we'll rename it, and go new text, where we'll check to make the firstname cookie is set.

[00:46] We'll do const cookies equals awaitPage.cookies. Then we're going to get the firstname cookie out of that using the find method, checking on the name and the value of the cookie. Then we're expect that firstname cookie is not undefined.

[01:07] Page.cookies returns an array of an objects for each document cookie. We use the array prototype method find to see if the cookie we set exists. We want to make sure that it's using our Faker-generated content, firstname.

[01:20] Then we test to make sure that we get something back. If we run our test script, we can see that our test fails. It is getting back an undefined. Let's go ahead and implement this. Inside of our app JS file, we're going to add a firstname property to our state object. That'll be a string.

[01:39] Then inside of our handleSubmit, we're going to document.cookie our firstname, and our state.firstname. Next, we'll create a handleInput that will fire on each input to update the state. We'll pass this method on through to our login component as a prop.

[02:06] Then inside of our login component, on our firstname input, we're going to onChange our props.input. Perfect. Now, every time our firstname input box is typed in, it's going to fire this input method. If we save this, and go back to our app JS file, it's going to update our state object.

[02:26] Then every time our submit method is fired, we're going to save a firstname cookie to the page. Now, if we run our test script in our terminal, we'll see that our test passed. Perfect. We are setting our firstname cookie.

[02:44] Now that we know how to test setting cookies to a document, what if an application requires a certain cookie be present before performing any actions, and this cookie was set on a series of previous authorization pages?

[02:57] For example, what if we had an if check that checked the document for a JSON web token before it actually submitted? Now, we're not going to see our success message unless our document includes this JSON web token.

[03:12] Inside of our browser, we can test this out. You can see as I click on this login button, it doesn't show us that success message. Now, our login form test is going to fail. You can see that our test timed out, because the login form submitted, but the success message never showed up.

[03:34] To fix this, we have to go back inside of our app test file, do awaitPage.setCookie. That takes an object with name and value properties. Similar to how we read cookies in our firstname cookie test, we can actually set cookies inside of our Chromium browser that's running the test.

[03:56] In this case, we're going to set a cookie that's actually setting our JSON web token with just some gibberish value. Now, when we run our test, it'll pass. If we run the NPM test script, you can see that we'll step through all of our tests, and it'll pass.

Viktor Soroka
Viktor Soroka
~ 4 years ago

Nice course. One thing I personally did not like is that test at the end of the video is not quite reasonable. Yes, the 'JWT' cookie was set, but if later the check for that cookie will be removed in the source code the test does not react on it in any way. And it is up to the developer to remember and to delete that cookie set in the test code. I this case another test should be written to prove that behaiour I think.