00:00 All right, so for us to be able to be logged in and create a connection, we're going to be creating users. We need to have a user to be logged in as. And for us to be able to create a connection, we need to create a connection with a GitHub user that does exist and that our mock will respond to. So there are a couple of things we're going to need to do as part of our setup.

00:19 First of all, let's get a GitHub user with await insert GitHub user from our mock. Now we'll add it to the list of users that our mock can respond with. And then we're going to need a new user with await insert new user. This is going to come from our DBUtils.

00:38 And the reason we're using the DBUtils instead of calling Prisma directly is because the DBUtils will keep track of all the users that are inserted during the course of forever, the process. And it exports this inserted users set.

00:55 That's just going to be a set of all of the IDs that are users that are inserted so that we can delete those users when our test is done. So between every test that is run, we can clear out the users from the database

01:10 so that test users don't get kind of split between all of these different or accessible between all these different tests. So it's all part of the cleanup process. So we also want to do the same for our GitHub users as well. So let's come up here and we'll add an after each from vTest.

01:28 That's an async function and async arrow function. Here we go. And we'll just await delete GitHub users to get rid of the GitHub users from our mock. And then we'll do a similar thing after each.

01:46 After each, there we go. And this is also going to be async. And here we're going to await prisma.user. And let's bring in Prisma properly. Here we go, .user delete many.

02:02 And the many users we want to delete are where their ID is inside one of those inserted users in that set. And then we can say inserted users, your job is done here. Let's clear out that set of inserted users.

02:21 So that way, we can create users, both GitHub users and our own database users, and then get rid of them between all the tests. So now, no matter what we do, after the tests are over, we delete those users and we don't have to worry about those users leaking out. Okay, great.

02:39 So that takes care of the setup and cleanup of our users. Now we also need to create a session. Now deleting the user is going to delete session, so we don't have to worry about cleanup for that one. But to be logged in, a user does have to have a session. So we'll say prisma.session.create.

02:57 And we'll create a session for this user where the data is user ID, new user.ID. And the expiration date is get expiration date from our utils there. Okay, awesome. So now we need to get this request to be authenticated.

03:16 And so we need to update our setup request to accept some optional parameters. So we'll default this to an empty object. We want a session ID and a code. The code is how our mock identifies different users. So the code is going to be important here.

03:32 And then the session ID is going to be the ID that we want to commit to our cookie. So the session ID will be a string. It's optional. And the code, also optional, will be a string. And the code is going to default to this faker thing.

03:47 So if you don't provide one, then we'll just, you know, create a GitHub user on the fly with providing a random code. And then the session ID, if that's provided, then we need to get the cookie session from our session storage and set that session ID.

04:05 So let's get our cookie session from await session storage dot get session. And then if the session ID is provided, then we'll say cookie session dot set session key.

04:24 This is all coming from our experience with the auth stuff. And there's our session ID right there. Okay, great. So now we're almost there. We just need to make sure that this cookie session cookie appears in the cookie header for our request. Now we can't just do that because we have another cookie there already.

04:43 So cookies are actually joined by a semicolon character. So if I say join semicolon, now I can have multiple cookies. And I can say convert set cookie to cookie and await the session storage commit session. And of course, we can make a variable out of that and all that stuff. But that should work.

05:02 So that gets our request to be authenticated because now we'll have a cookie that should be kind of familiar with what we've done before with our playwright test. It's kind of similar. The whole idea is just to simulate that authenticated request.

05:16 So with that now, we need to pass the session ID. It's our session dot ID. We're selecting too much here. So let's select ID true. There we go.

05:30 And then we also want to provide the code, which is going to come from our GitHub user dot code right here. And with that now, we can save this. And we should actually pass. Yeah, we're in a passing state now because our settings profile connections is where

05:49 we end up going. But we have a very important part of this. And that is that we actually are creating a user. So let's make sure that that or creating a connection to the user. So let's go and say Prisma dot connection dot find first, where the user ID matches

06:08 the new user ID and the provider ID matches the GitHub user profile ID. And that is going to give us our connection. So then we can console log the connection, save that and boom, we've got our connection.

06:27 So to assert on this, we don't really know a whole lot about the information in here. So it's pretty much sufficient to say that if the connection exists at all, then that's a passing test. So we can expect the connection to be truthy and that'll be enough. There we go. Cool.

06:46 Now, I want to show you what happens if this fails for some reason. So what if we say, yay or yahoo, whatever. So this fails. This is not going to be a very helpful error message at all. So instead, we're going to say connection was not created or some helpful error message

07:05 that will certainly be a lot more helpful than this. Now, of course, we do have the code frame and everything that is quite helpful. But I think having a more useful error message is quite handy. And so the second argument to expect is how you do that. It's nice.

07:19 So let's restore this to its former passing glory, new user.id, and our test should be passing. Whew. Okay. That's quite a bit there. So let's talk about the different pieces that we did here.

07:32 So first we needed to have a GitHub user that the user would authenticate to and a new user that would be the authenticated user. And then we need to create this session so that user can be logged in.

07:46 Then we made sure to take care of some cleanup up here so that we don't have a user in both the GitHub variety and our own that persists beyond the scope of this one test. So then we updated the setup request so that it can authenticate our request using the

08:06 same mechanisms that our application uses for authentication, which is just a session ID in a cookie. And then we had to set up our cookie header so that it has all of the cookies that we need. So including both the connection as well as the cookie session, our off session.

08:25 And so with that, we were able to get to the right place where the user's logged in. And so we get sent over to the connections page. And then we're also verifying that the connection was actually created. And that is taking care of doing an authenticated request to our loader.