Now if a user can't register or log into their account, we have a really big problem, which means we should really ensure that these things work for our application. So with that in mind, I'd like to write some browser tests for our forms. Now, just as we learned in the testing episode, we're gonna leverage pests browser testing support. So in the browser testing documentation, if I scroll down, we can require it.

So in the browser testing documentation, if I scroll down, we can require it. I'll bring up a terminal, paste that in, and while that's doing its thing, notice we can run our tests like the normal way, we can open a browser with debug and we can navigate, which opens a browser, uh, behind the scenes using the visit function. Okay? All right, that's done. So now let's go into our test directory and get started.

Okay? All right, that's done. So now let's go into our test directory and get started. I'm gonna rename feature two browser, and within pest PHP, let's also update to use that folder. Cool. So now within our browser test, why don't we rename this to register test? Okay. It registers AA user. Alright, so let's say if I were to visit the register page and I fill the name with John Doe and then we fill the email,

and I fill the name with John Doe and then we fill the email, I'm just gonna do it all exactly the way you would do in, uh, manually within a browser. Password, password, 1, 2, 3, you know, something like that. And then if I click, uh, let's see what it's called, Create accounts. So we can either use the label or an ID or a data dash test attribute. Either one works. Okay, so now what do we expect to happen?

or a data dash test attribute. Either one works. Okay, so now what do we expect to happen? Well, I would assert that the path is the homepage. We are redirected to the homepage. Okay, maybe this will fail, maybe it won't. Let's give it a run. This time I'm gonna do it directly from my editor, command T Oh, awesome. It passes. Very cool. So yeah, just keep in mind if we were to, for example, in registered user controller, try

So yeah, just keep in mind if we were to, for example, in registered user controller, try to redirect somewhere else. If I run that test again, of course it's going to fail, right? And yeah, we can scroll up and see. Yeah, we thought we'd be redirected there, but actually we got the homepage. Okay, so this is pretty good. Next, why don't we say they should be logged in.

Okay, so this is pretty good. Next, why don't we say they should be logged in. So I can say this assert authenticated, right? Run it again. We're signed in. Once again, if we skipped that step or we wrapped this in something that didn't work the way we would expect it to, in this case, all hard code, false. Well now they're not gonna be logged in, right? So it's going to fail right here. So we are confirming our hypotheses, right?

So it's going to fail right here. So we are confirming our hypotheses, right? Let's come back as part of registering a user. Um, they are redirected here. They are authenticated. And why don't we also expect that, uh, we have a, a relevant user in the database so we could sayer database has. So you could say, look in the user's table and expect that we have a user. So we could do that. Another option is you could grab the

and expect that we have a user. So we could do that. Another option is you could grab the authenticated user and you could say to match array, and you could say, well, I expect that user to have a name of John Doe give it a run and it passes. Uh, let's do another one. I expect the email. So we're, we're literally just fetching the user from the database, uh, the authenticated user, and we're making sure that their attributes match, uh, what we pass here.

and we're making sure that their attributes match, uh, what we pass here. Give it a run. It works. You get the idea. Okay, let's do another one. Let's duplicate this. And this will be our login test. All right? It logs in a user. All right, so this time we will visit login. And to log in, you need to give us an email and a password. The form will have a button of sign in. Now, once again, it's possible you'll have a sign in link

The form will have a button of sign in. Now, once again, it's possible you'll have a sign in link in multiple parts of your page. So if you expect it to click this button, it's possible, it won't, it'll click something in the navigation link. So in these situations, it can be helpful to add a data test link and you could say log in or sign in. I don't like mixing those up, but you could say, uh, log in button. And now we can target that directly without relying on a

but you could say, uh, log in button. And now we can target that directly without relying on a piece of text that could change in the future. So if we did that, we could say, um, click and then I can use the at symbol, which translates to something like this, right? But instead I can just say at symbol and then it will expand to what you saw there. Alright? Fill in an email, fill in a password and assert that.

Alright? Fill in an email, fill in a password and assert that. Well, let's go to sessions controller. Upon successful authentication, it takes us back to the homepage and we can say assert path is homepage. We should be logged in and yeah, so this is going to fail. If you think about it, let's give it a run and see if you can figure out why Command T and it's gonna take a few seconds because it's waiting to figure out if this is gonna work.

and it's gonna take a few seconds because it's waiting to figure out if this is gonna work. No, no, no. Fails, right? So if you want to pause and try to ask yourself why didn't this work? Okay, the answer is, well, you're trying to log in a user with a fresh database, but there is no user that matches, uh, those credentials. Remember, for every test we refresh the db, so our user's table is literally empty.

Remember, for every test we refresh the db, so our user's table is literally empty. So let's do the assert, um, or the A or the arrange, what is it? It's the three A's arrange, act, and assert. So we're gonna do the arrange portion. So let's say user factory Create. Now let's hard code the password. So once again, the password is going to be, uh, what do we have here?

So once again, the password is going to be, uh, what do we have here? Password, 1, 2, 3. Well, now if we try to log in as this user with that same password, then this time it will work because we do have a valid user in the database. Perfect. Okay, what about, uh, it logs in a user. How about it logs out a user? So at this point we should say create a user, set them as the authenticated user.

So at this point we should say create a user, set them as the authenticated user. So I could say off log in, or you can also say this acting as, which is basically the same thing. Um, acting as assuming we are authenticated as this user. Then if I visit the homepage and I click the button that says log out, then I should be signed out, right? So assert not, I'm trying to remember what it is not.

I should be signed out, right? So assert not, I'm trying to remember what it is not. Uh, is it un is it guest? There it is. Then at that point, we should just be a guest. All right, so let's check our nav bar. We will have a log out button. Once again, you can add data test if you need to there. Uh, let's give it a shot. I will run the test. Yep, we are signed in. We visit the homepage. It literally clicked the button that you see right here

Yep, we are signed in. We visit the homepage. It literally clicked the button that you see right here that made a post request here. The sessions controller logged the user out, it redirected them home. And now, um, we're, we're a guest. It's working. Awesome. So yet again, I just wanna remind you, this protects you because if at some point you accidentally screw something up, like you, you commented this out or deleted and you didn't even realize you did so well, now if I run

up, like you, you commented this out or deleted and you didn't even realize you did so well, now if I run that test again, uh, of course it's going to fail. Hey, this was supposed to lock the user out, but it didn't do that. So take a look. All right, so now we have just some initial tests to get us going. This one registers a user, this one logs in. And remember, we're slightly cutting corners here just to save time in real life.

And remember, we're slightly cutting corners here just to save time in real life. Don't just test the happy path. Test the unhappy path. So it requires an email address. You could say it requires a valid email address and then write a test to ensure that if one is not provided, then something's not gonna work. So let's do um, John, 1, 2, 3. What happens in that case? We should see a validation error, right?

What happens in that case? We should see a validation error, right? Let's give it a shot. Let's just try this one out. Before I click, I'm gonna call debug. So I can view this in the browser. We'll give it a run and yep, you can see it filled out these fields. If I click create account, yeah, notice we get some browser support. Uh, so this isn't our server side validation,

notice we get some browser support. Uh, so this isn't our server side validation, this is the client side validation taking effect. So if I bring this back, if we click create accounts, I'm going to assert that the path is still that register page. Give it a run and whoops, one more time. There we go. You get the idea, right? You wanna make sure you test both the happy path but also the unhappy paths.

You wanna make sure you test both the happy path but also the unhappy paths. Okay? So that's generally, um, some testing here. I would probably do more in real life, but this is enough to get us going. So in the next episode, let's move on to flash messaging and also a little bit of Alpine Chas.