Testing Cookies & Sessions

[00:00:00]
>> There are pieces of this that we could probably pull back into that echo chamber application. That one was still even we got to the point where using commands to simplify the login process. We were seen in the database like things were good, right, like life was pretty sweet, but we were still filling in that form.

[00:00:22]
Like we hid it from ourselves with those commands. If we're watching our tests, we saw it happen, right? And so this comes down to, and is this always the right approach for you? I don't necessarily know it all kind of depends, right? Like the app that I worked on at SendGrid for instance, the way we handle our authentication logic was, if the first FEI request you made, if you got a 403 forbidden then we redirect you to the log in page.

[00:00:51]
It's like a 12 year old app. That point so much infrastructure is built on top of it. So the act of having a mock server that gave you back not 403s, did solve that problem for us. You can argue, did we still have a root problem? Sure, right, but for the purposes of testing some of the stuff in my case, it totally worked.

[00:01:12]
Obviously the login functionality in that echo chamber app basically checks the database for a plain text encoded password and sets a cookie, right? If they have the cookie, when they go to the post page, they're allowed to see it, if they don't have the cookie, they are not allowed to see it.

[00:01:34]
So one of the cases where I think that you can do is simply either request a user from your database, right? And set the cookie where now you can skip the login screen completely. Right, or just set a cookie that were like it's a pencil. They're like gonna post stuff and all of those things, right, you probably need.

[00:01:55]
It all depends on the problem you're trying to solve, right? Whether it needs to be a cookie based on a real user, as it would happen or the ability to just set the cookie yourself but like Cypress does give you the ability to set cookies and get cookies and read their values and stuff along those lines.

[00:02:13]
So here we start off by signing in with the user. And we wanna say that you know, they should be able to log in. So here they signed in. Once they have signed in the path should be the post page, right? Because we know that happened before part.

[00:02:37]
And then this case it is base 64 encoded cookie. We can actually look at the cookie and make sure that what is in the cookie is what we expect, right? So with Cypress you have access to the cookies in this case, right be like okay, when they signed in neat.

[00:02:54]
The other thing that we are kind of able to do as well is if we wanna skip the whole idea of filling out the form, right? You can also just manually set that cookie with whatever the data that you need. Now, depending on what you're doing, right you might have to send a request to a service, right?

[00:03:12]
But if you're marking out all of the API's right that might be a thing that you can do or a lot of times sending that resulting JSON request to like an end to end like to a real server is still faster than visiting a bunch of pages and filling in a bunch of forums, right?

[00:03:28]
So it's simply you fill in that form, and then it sends a fetch request to a server and then you get a cookie set. You could just do that like with a request and not have to go through the rigmarole of filling out the form if you wanna do and just set the cookie and do that in a before each.

[00:03:49]
There, I'm not gonna get all the way into it. There is an accent experimental feature in ciphers is the only reason not gonna dig all the way into it which is sign up session, right. And that gives you the ability to, the same way memorization works or kind of caching functions works.

[00:04:09]
Basically, it'll lets you persist a cookie, local storage and session storage between test runs, right? If we're looking for the same thing, it'll use it over and over again. It is experimental, you do have to turn on a flag. We'll drop a link to the part of the docs about it, so I'm not gonna get all the way into because it could change and all of those kinds of things.

[00:04:31]
But there was a way to save that. But also depending on either, encoding [INAUDIBLE] cookie if you just wanna make sure they don't hit the redirect, right? And then you're gonna mark out all the rest of the data, that will work. If you do need a legit user in order to do stuff, right, it could make sense instead of filling out the forms, we're gonna send the resulting JSON requests And we'll set the cookie like that.

[00:04:53]
And then we'll go through all the pieces that we need to do. The point of the matter is like when you truly need end to end test, you should do end to end tests. When you're just trying to do ancillary stuff about how your UI works for that user is logged in, you've all ready tested that all the login like logic works and account creation stuff.

[00:05:09]
Just getting the pieces you need in place also work as again. Yeah, like there's a compelling part to purity but at the cost of like, no one runs the test suite because it takes six hours. But yeah, I've worked enough big company to know that once to test, we get either a unreliable because too many other things can go down, right?

[00:05:33]
If you need the whole company in a docker container, in order for it to work, it's gonna go down and everyone's going to stop writing tests. And that's the kinda careful balance you need to think about, which is like, cool. Like, what do I really need to do here?

[00:05:46]
So in this case, we can set a cookie, it's just a key value. In this case, encode token all that does is JSON stringify and then base 64 and reverse for decode. So we can set the cookie and now that will be sent in the back and forth responses as well.

[00:06:03]
You can avoid the redirects that is absolutely an option for you to use, right? If the cookie has the username you just wanna make sure it's displayed in page. Set the cookie, make sure username you put in there almost like picture data is displayed on the page. Do you need to go fill out a signup form for that?

[00:06:24]
No. Do you need to go through and see the database? Probably not, right? You're just trying to make sure that what you think. But if you need to access real data and relations and all that kind of stuff and you're testing to see if like, access management works, you either need to probably see the database or do something a little more.

[00:06:40]
All these are various tools to solve different problems. I'm not saying you don't need this one all the time. You do need this other one, I'm saying for different sets of tests, there are different things that you need, and arguably whatever is going to be both getting you the reliability that you seek, with the least cost of time, cuz again, No one's gonna run a six hour test suite, I've been there.

[00:07:04]
As well, and so this is a case where like, you could fire off the request yourself, right? We're here you fire off the request, you get the response. You are then setting the cookie yourself instead of filling in the login form. So this is using a real database data at this point, instead of me putting in some fake stuff up here.

[00:07:23]
So setting your fake is super easy. It's just side by side cookie. Getting the user info from the database and putting the parts that you need into the cookie and doing it yourself also an option, right. That way you can test out different users with different sets of permissions without having to sign in and sign out every single one of them over and over and over again.

[00:07:43]
And like this is a really great candidate for a command, right? We can just put in the user you're looking to go get and it will do the rest of this and Mike could be called, get user what have you, right. And breaking that out into a command yourself and you can kind of just, you can alias this stuff, so on and so forth as well.

[00:08:10]
But yeah, the cookies make it really easy. And you could basically take this application has a real database behind it. We've seen you can see the database have full end to end tests. Or you can stub all this stuff out depending on what you're trying to do, right?

[00:08:26]
You will make sure the right requests are made, like we can see that as well.