00:00 Alright, I want to talk about mocking. And I'm not just talking about being nice to people and not mocking them. No, this is something else. So, mocking is basically you take the real thing and you swap it out for something that's fake. Let's figure out why that would

00:15 be. So, we'll use an example. Let's say that I'm building a store where you can buy really cute plush koalas. And I need to test to make sure that the checkout process works. That's probably the most important part of the whole thing is that the checkout process will work.

00:31 And so, I write my test, my automated test. And I say, okay, add three koalas to the cart and then hit checkout. Oh, I'm here on my, you know, payments. I need to, like, fill my credit card. So, I look at my credit card and I type in all the numbers and I put that

00:46 into my test. And every time I run that test, I'm buying three koalas. And I'm getting those things shipped to me. And I'm getting a closet full of koalas. There's a good thing and a bad thing about that. One good thing, I've got a closet full of koalas. How fun would that be? But the bad thing is my bank account is emptying. Like, you can see, here's my

01:05 bank account. Here's my closet full of koalas. And look, they're changing. This is not a good thing. So, we need to mock out some stuff. Sometimes you cannot use the real thing. We've already done this in previous workshops where we're sending emails with Resend and we don't want to hit the actual API because we don't want to have to pay every time we're doing

01:24 our development and testing out these emails. Or we've got the GitHub API and we don't want to be able to, or not be able to continue working just because the GitHub API falls over for an hour or two or something. And so, we are already mocking stuff. So, there's

01:41 actually not a lot to this exercise because we've already learned about creating those mocks in a previous workshop. But, there is a challenge here where we have our server process that's running over here and our playwright process that's running over here and it's

01:58 hitting that server. They're separate processes. So, the server over here that knows about the emails that are being mocked out and stuff can't communicate over to the playwright process that needs to be able to read the emails to proceed with the test. So, that's the thing that we're going to be solving in this exercise is how to communicate between the mocks that

02:17 are running as a part of our server and the tests that are running separate. So, we've got this onboarding test and here it's just going through the onboarding flow. If I scooch this over we can see first we click on login, then we click on create an account, we fill

02:35 in the email and we hit submit and then it's checking for our email. And that email right now we just log it to the terminal output. And so, there's no way for playwright to get access to that. And so, your job is to make it so that playwright can access that and

02:50 that's what we're doing in this exercise. So, once it gets access to that it actually goes to the URL, the verify URL and then it's able to fill out the whole process. So, other than the process of saving to disk and reading from disk and what you were going to be doing

03:09 to communicate across these process boundaries, there's not a lot of new learnings here. So, you can feel free to try and write this test yourself if you want to from scratch. But yeah, it's just pretty typical playwright test. The most important part of this is how

03:24 to communicate between these processes for this mocking. One important thing I want to just call out is that whenever you make a fake version of something during testing, you're losing confidence. You're poking a hole in the ship and you've got to patch that up before you start taking on water. There are definitely merits to mocking, but you've

03:43 got to do this judiciously. Otherwise, you'll just be testing your implementation which is a really, really bad place to be in. So, there's a bit of a fine line, but this is definitely one of those things that we want to have mocked and so we're going to be doing that in this exercise. So, have a good time with this one. Like I said, it's going to

04:03 be pretty quick, but I think that it's a really important topic and you're going to be continuing to work through this mocking stuff. I should also mention that playwright does have the capability of mocking out the network and it has actually really, really

04:19 cool things that you can do with mocking out network calls. The reason we're not using that is because in the Epic stack and in the Epic apps that we build, most of our requests that we want to actually mock are going to be server side anyway. And so, we're not going

04:37 to be actually making or using playwrights request interception APIs. Feel free to look those up if you ever need to integrate with a third party that you have to do it a client side integration or something. But for the most part, you're just going to be doing those

04:53 integration server side and so we'll use MSW on the server and it works great. However, if you did ever want to test like what happens if my server doesn't respond, then that's certainly something that you could do via the playwright APIs for that. Okay, I think that's everything you need to know for this very quick exercise. Have a good time and

05:12 we'll see you when you're done.