Now, you surely know that Laravel offers a few different ways to deal with authentication scaffolding. But one thing I do like about Breeze is how every step of the way, you are in charge of the code. As we learned in the first or second episode, Breeze will copy those stubs to your project. So this then allows you to tweak them how you see fit. For example, once again, let's have a look at the registration test that it copies over. If I give it a run, it's passing. Let's have a look here. TestRegistrationScreenCanBeRendered. Fine. TestNewUsersCanRegister. Okay, so notice here, it's not loading a page and filling out the form. It's basically cutting through to the endpoint for that form. So if we submit a POST request to /register, and we send through the attributes that you would normally provide to that form, well, once that submission is complete, you should

if we submit a POST request to /register, and we send through the attributes that you would normally provide to that form, well, once that submission is complete, you should now be authenticated, and you should be redirected to the dashboard represented here. It's going back. And of course, that passes. So again, we have control over this. So if we take a look at RegisteredUserController, here's that store method. It validates the request, it creates the user, it signs them in, it dispatches an event, and then it redirects the user. Which means, for example, if we were to create the user, but not sign them in, well, we give that test a run, and of course, it's going to fail. Okay. But now, what about when we need to make changes or adjustments? For example, if we go to our routes/web.php file, we'll go down to the auth routes that Breeze copies over. Have

what about when we need to make changes or adjustments? For example, if we go to our routes/web.php file, we'll go down to the auth routes that Breeze copies over. Have a look right here. So we're saying, if you visit the register page, load this controller and the create action. But it also applies the guest middleware. So what this basically means is, if you are authenticated, it's going to redirect you to the dashboard. Or in other words, if you're signed in, you don't need to see the register page. So let's just send you to your dashboard. And if you're curious about that, the middleware is called guest. You can always go to your Http\Kernel. And if you scroll down to the very bottom, here's all of your keyed route middleware. And you'll see one right here. That guest key points to redirectIfAuthenticated. So if we take a look at that, here is the middleware. And

all of your keyed route middleware. And you'll see one right here. That guest key points to redirect if authenticated. So if we take a look at that, here is the middleware. And have a look right here. If the user is signed in, redirect them to their dashboard. That's all that middleware does. Otherwise, continue on to the next layer of the union, so to speak. That's how I think of middleware. I think of it as layers leading to the core of your application. And at any point, one of these layers, or middleware, has the opportunity to change it up, to redirect somewhere, to add something to the session, or to the headers, or things like that. Anyways, if I switch back, one thing we will notice, let's go back to the routes file, is we have no test to ensure that that guest middleware is applied. So for example, if I were to just remove this, and then from the terminal run php artisan

to the routes file, is we have no test to ensure that that guest middleware is applied. So for example, if I were to just remove this, and then from the terminal run php artisan test, or just phpunit on your project would work as well, you'll see everything still passes. So maybe you want to tweak this. You want to test for that. All right, well, you are in charge of this code, so it's really easy to extend. It's almost like you're now collaborating with the Laravel team, which is cool. So let's add a new one. Test, and what should we say here? What are we trying to say? Well, we're testing that authenticated users don't see the registration page. So how about authenticated users cannot register, of course. Okay, well, we have some existing code that we can have a look at. So why don't we just copy this over, and then tweak it. How about given we are signed in, if I visit

of course. Okay, well, we have some existing code that we can have a look at. So why don't we just copy this over, and then tweak it. How about given we are signed in, if I visit this registration page, then I'm going to assert that we are redirected to the dashboard. That's basically what we're doing here. Okay, let's go ahead and use a UserFactory. Create a User in our database, and then our test helpers offer this method called be, which effectively sets the authenticated user for the test. So create a User, set them as the authenticated user, try to access that registration page, and if we did everything correctly, they should be redirected to the dashboard. We give it a run, and it fails. Okay, so now we have a way to ensure that if you're signed in, you can't access that registration page. We'll go back here and return that middleware like we originally had, and now if I run that