00:00 I really don't like having third parties be tied into how I develop my software, both for development as well as testing, for a couple of reasons. If their servers go down, then we're stuck, we can't develop our software. If my network connection is slow or non-existent, then I'm stuck, can't develop my software.

00:21 If I have to pay for access to their APIs, then yeah, I'm paying out the nose. I really like to mock out all of my third-party stuff, and that applies with GitHub authentication or third-party auth in general as well.

00:36 What we need to do is, during development and testing, we need to simulate an environment that kind of simulates the way that the real thing would work in development. Normally, I like to just use MSW and it has all the mocks, and so any fetch requests

00:53 will get intercepted by MSW, and my application is totally unaware that this is happening. Unfortunately, the way that this works is I call into RemixAuth and it's going to say, oh, okay, you need to go to GitHub. So as soon as I click on this, I'm going to go over to GitHub, and I can't mock anything over there. That's a different URL entirely.

01:14 So we need to prevent going to GitHub, which, unfortunately, does mean that we need to change our source just a little bit. We just add an if statement that says, if we're in this situation, then don't call RemixAuthAuthenticator, but instead we'll simulate what RemixAuth and GitHub would have done without us.

01:32 Now, I think it's also useful for you to know that once that code and that state come back from GitHub, then RemixAuth is going to take that and start making calls, requests, to the GitHub API, as we saw earlier. And so those need to be mocked, and there's no new learnings necessarily out of that.

01:53 And so Kelly, the coworker, actually put that mock together for you, and I thought it would be useful for you to get a little tour of how those mocks work. So those are all set up for you. We've got these GitHub handlers in our MSW mocks.

02:08 And the way that this is going to work is we actually have a file that is gitignored. We have .local. in our gitignore. That will save all of the GitHub users that you create. So as you need to make new GitHub users or whatever, those will be persisted on disk.

02:28 And so that way, restarting the server and everything will continue to work. And so we have this createGitHubUser. This all is going to happen kind of behind the scenes for you. We've got a mechanism for getting the GitHub user that will be useful when we get into testing. And then we have this insertGitHubUser, which we're going to use to, during our seed script, we're going to say,

02:50 oh, I want to have Cody connected to a GitHub user so I can use loginWithGitHub with Cody. And so we'll insert a GitHub user that will actually save the GitHub user that is created to disk so that you can interact with that user going forward. And every time you start up the app, you can just hit loginWithGitHub,

03:10 and boom, there's Cody right there is authenticated. So then we also have this, the way that this works is the token that, or the code that is used is going to be the kind of unique identifier for all these users.

03:28 You can dive into this code to get a little bit closer look at how exactly that works. But for every code that you have or that you create yourself, we'll create a new GitHub user for that code. And so you can just say, hey, go straight to this URL. It has a code specified. And if there's a user already there, then you'll log in as that user.

03:48 If there's not, then it'll create a new user for you. And then you can log in as that one. So that can be kind of handy if you need to like test out, OK, I need these different cases. We'll create these users and then test those users out. We also have this pass-through GitHub, which will be handy for you. So if the GitHub client ID starts with mock underscore,

04:09 and then that will, basically, there's no way that that's a valid GitHub client ID. And so we're going to go ahead and mock. Otherwise, then we can pass through to GitHub. So this way, you can test out the actual flow, which would be quite useful as you're making changes and stuff. You're like, oh, I want to test out the real flow.

04:30 I don't want to go through these MSW mocks. Well, you just give it a proper GitHub client ID and then rerun your server and it will actually skip all of these mocks. So it'll just say, oh, we're passing through. Just pass through, send it off to GitHub, do the regular request and all of that stuff will just work.

04:49 We'll also pass through GitHub if we're both not prefixed with mock and not testing. If you're testing or prefixed with mock, then we're not going to pass through because I don't want to pass through in a testing environment. So in any case, that's the basic way that it works. The most important thing for you to know

05:09 is that we need to have our client ID prefixed with mock and then these mock HTTP handlers will get called. So what you're going to do in this exercise is actually not as complicated as all this maybe sounds. So first, you're going to update your environment variables to have a mock prefix for the GitHub client ID.

05:29 And then you're going to go to the route that handles this button click and you're going to check if I'm in a mock environment. So if that GitHub client ID starts with mock, then instead of calling remix-auth, because that's going to send me over to GitHub, instead of doing that, we're going to create our own URL

05:47 that matches the callback URL that GitHub would have made for us. And we'll provide a code and some state. And we also have to set a cookie for that that kind of relies on some of the way that remix-auth for GitHub works. And so we're going to create that cookie and commit that session to our connection session.

06:10 And then we'll send the user over there and the rest of our code will pick up as if we'd actually gone through GitHub. So not a lot of changes that need to happen here, but it is a little bit funny because you don't typically make changes to your source code to facilitate testing and development. But this is definitely one of those cases where it's worthwhile.

06:28 And I think that you should have the guidance that you need and the knowledge that you need here as well. Feel free to delete this file and create it yourself if you want some practice on building mocks like this. But this is all just pretty typical MSW stuff.

06:45 So I think that is everything that you need to be successful. So go forth and have a good time.