Think about it, what have we learned at this point? Well, we've realized that Breeze is just an artisan command. That's it. It's a command that copies over some existing stubs to your project and then updates your package.json file. And that's it. So we've learned that this package should be used at the beginning of your project. Right after you run php artisan new project. And the reason is because, have a look here. In your routes file, notice it's copying that routes stub over to your main routes file. It's not merging it with what you currently have, it's replacing it entirely. So you want to use Breeze at the beginning of your project.

It's not merging it with what you currently have, it's replacing it entirely. So you want to use Breeze at the beginning of your project. But yeah, other than that, there's nothing else to Breeze. At least in terms of the package. The core of what it does exists in all of these stubs that are copied over to your project, that you will then have full ownership over. So with that in mind, let's go over to, we've set up a brand new project here. I'm going to initialize Git so we can review everything that's copied into the project. So we'll say initial install. Alright, and then let's pull it in. composer require Breeze. And then finally, php artisan Breeze:install.

Alright, and then let's pull it in. composer require Breeze. And then finally, php artisan breeze:install. So now when we run this, actually real quick while we're here, let's install our node dependencies. There we go. But anyways, if I do a git status, we can see everything that changed as a result of running that breeze:install command. So I thought we'd start with basic registration. Let's open this in my editor. Now if I go into tests/Feature, you'll see that as part of Breeze install, it adds a series of tests. So if we're starting with registration, let's have a look at how this was constructed. Okay, testRegistrationScreenCanBeRendered. And yeah, this is often a good first test to write.

Okay, test registration screen can be rendered. And yeah, this is often a good first test to write. So we're making sure we do have a route that responds to /register, and we are asserting that the response is a 200. So there's no 500 that gets thrown along the way. Alright, let's give it a run. Now I can run this directly in phpStorm. I already have that wired up. It's going to fail because we haven't yet set up the database. But otherwise, you could do it from the terminal by saying phpunit or vendor/bin/phpunit. And let's filter the tests down to only the ones that match this name. So we give that a run. And of course, yeah, it's going to fail in this case because I haven't yet set up the database.

And let's filter the tests down to only the ones that match this name. So we give that a run. And of course, yeah, it's going to fail in this case because I haven't yet set up the database. Let's have a look here. If I run git status again, did it update the environment? No, it didn't, which means in this case, it's going to use the name of the project, which I just so happen to call Breeze for simplicity, as you see there. But yeah, if I had called it my project, then this would automatically be set to that. Anyways, Breeze is fine. So let's go ahead and I'll just do this inline here. CREATE DATABASE Breeze; OK, exit out. I'll run php artisan migrate. There we go. Anyways, if we switch back to our registration test,

OK, exit out. I'll run php artisan migrate. There we go. Anyways, if we switch back to our RegistrationTest, and then notice that we're using the RefreshDatabase trait, and that will automatically determine should we use database migrations or transactions. So if we have a look at phpunit.xml, you can set your testing specific environment variables here. And notice these are commented out. So if you'd like, you could set your connection to use an SQLite database in memory. This can often be a good way to go, especially for smaller projects. It'll be much faster. The downside is now your tests are using a database connection and configuration that's a little different from your actual project.

It'll be much faster. The downside is now your tests are using a database connection and configuration that's a little different from your actual project. So if your actual project uses MySQL, but your tests use SQLite, you can sometimes run into issues there. Anyways, it's a tradeoff between speed and a little more assurance that your tests are using the exact same database configuration as your production environment. But anyways, if I were to comment this out and stick with that, it is going to be super fast. Now in our case, why don't we stick with the default connection, which is MySQL, but I will use a database name. And real quick, notice db_database. Let's have a look here.

but I will use a database name. And real quick, notice db_database. Let's have a look here. Okay, so our default connection is MySQL. And if you scroll down to your connections, here is the default one we're using here. So notice it's figuring out the database name through that environment variable. So it's saying, look in your environment for something with that key and use it. And if you didn't find anything at all, then just set it to forge. So why don't we go to phpunit.xml and say, no, I'm not using an SQLite database in memory. We'll call this breeze_testing. And now our test database is separate from our local database, which is good.

We'll call this breeze testing. And now our test database is separate from our local database, which is good. Okay, so let's give it a shot. I'm going to give this a run. But if you think about it, it's going to squawk again. It's going to say, okay, well, now you want it to use a different database. And that one doesn't exist. Fair enough. Let's do it again. Create database. All right. Now we could manually run our migrations for the testing environment or the refresh database trait is going to do that automatically. So let's give this yet another run.

or the refresh database trait is going to do that automatically. So let's give this yet another run. There we go. It passes. So when we make a GET request to /register, assert that the status is 200. All right. The tests tell us it works. Now let's make sure it works in real life, which of course it does. But for the visual, we run it. We go to the registration page and it works. Okay, so let's have a look. If I go to route/web, you'll remember that the php artisan breeze:install command

Okay, so let's have a look. If I go to routes/web.php, you'll remember that the php artisan breeze:install command updates your routes/web.php file. And if we were to take a look at the diff there, here's what you started with and here's the sections it added. Okay, so let's see. It adds a landing page for your dashboard, and then it requires this auth.php file. Now if we open this up, here it is. And this is all added by Breeze.

Now if we open this up, here it is. And this is all added by Breeze. So notice this is where it registers that endpoint. So for example, if I were to comment that out and run the test again, of course it's going to fail. You're going to get a 405. Okay. Let's have a look here. RegisteredUserController, which really at first sight, that's kind of an odd name. Why not RegisterUserController?

that's kind of an odd name. Why not register UserController? Let's see. Are there other things here? No. Yeah, my instinct, it doesn't really matter, but my instinct would be register UserController or even RegistrationController, maybe. All right. So that will hit a create method, and it loads this view, which again, you are in charge of. If we come back, where is it? Yeah, it adds or copies this directory over.

If we come back, where is it? Yeah, it adds or copies this directory over. So if we were to take a look at auth/register, there it is, and you'll see it here. So you're in control of everything. So a lot of our learning for this series will be in how things like this are constructed. If you're new to Laravel, you're going to see a bunch of things that don't look familiar. Look, x-label, what else?

that don't look familiar. Look, x-label, what else? x-slot, x-guest layout, what are these things? And why do they not resemble the typical HTML elements you're familiar with? And in fact, in the past, you might have been used to Laravel using this extends keyword and then sections, which are still in the framework and used all over the place, but we don't see those anywhere. We see this kind of custom tag type system.

and then of course writing would be writing your own code. So with that in mind, in the next lesson, I think we need to start learning about Laravel's Blade components.