This next new addition relates to the tests that you will write. So you'll see that I've set up two projects, one in Laravel 5.4 and I've pulled up ExampleTest, and then another one in Laravel 5.5 where I've pulled up the same file. And you'll see that they're a little different. Let's see why. If I switch back to my 5.4 implementation, yeah, you're going to see these two different traits included out of the box. So DatabaseMigrations and DatabaseTransactions. These are the ways that we set up and we prepare our database for the test that takes place. Because without it, well, imagine you have a test that seeds a database table with a record. And that way, when you perform a query, you return that record, right? Well, when you're done with that test, you need to clear the database. You need to remove all of the test prep that you've done, right? These two options are the ways that we traditionally do it in Laravel. You can either

you need to clear the database. You need to remove all of the test prep that you've done, right? These two options are the ways that we traditionally do it in Laravel. You can either use database transactions. And the way this works is when you run your test, it prepares a transaction, it triggers your test, and then when you're finished, it rolls everything back. So it's sort of like it never fully commits the database operation. That can be useful. But then you also have database migrations. So the way this one works, let's just take a look. Database migrations. Okay, so what it will do is it triggers php artisan migrate, and then before the application is destroyed, it rolls everything back. So that achieves a similar result, just in a different way. With this option, we migrate our database, we run our test, and then we roll everything back, and that effectively undoes any changes that we made. Okay, but you know what? This is useful,

With this option, we migrate our database, we run our test, and then we roll everything back, and that effectively undoes any changes that we made. Okay, but you know what? This is useful, but I think for newcomers, it's actually pretty confusing. Because you're trying to get started, and you're thinking, well, which one of these am I supposed to use? And the answer is, you're not supposed to use either of them. You can pick the one. Neither one is better or worse. All right, well, in Laravel 5.5, I think this is streamlined quite a bit. So this is what you'll get if I switch over to our Laravel 5.5 implementation. So now we have this new trait, RefreshDatabase, and think of that as a new trait that kind of encompasses either operation. It'll do it automatically. Now, an important thing to know, don't worry if you're upgrading, you will still have database migrations available, and of course, database transactions. So those have

do it automatically. Now, an important thing to know, don't worry if you're upgrading, you will still have database migrations available, and of course, database transactions. So those have not been deprecated or removed. Your code is still going to work. But moving forward, you can use RefreshDatabase instead. And you know what? I think this is just a cleaner way to go about it. When you say, use database transactions, it's not immediately clear what that does. But now if we say, RefreshDatabase, we immediately understand what that will do. Okay, so how does it know if we want to use database transactions or migrations? Well, let's take a look. Here's that trait. All right, so now here, this is where it determines, well, should we use migrations or transactions? So take a look. Are we using an InMemory database? So what that's going to do is read your database connection default, and it's going to see if you set that.

use migrations or transactions? So take a look. Are we using an inMemory database? So what that's going to do is read your database connection default, and it's going to see if you set that to memory. So you could do this in phpunit.xml, and if we were to scroll down, yeah, you could say, DB_DATABASE. And if you set that to memory, yeah, this is a unique way to specify that for SQLite, you want to use a database in memory. And the benefit to this approach is it's really, really fast. So if you have this set in your testing environment, Laravel is going to pick up on that. And then it's going to go, okay, you mean to use an inMemory database. So I will refresh inMemory database. So what that's going to do is it will run migrate, to build up all of your tables. And even though that might seem time consuming, because it's a database in memory, that's actually going to be incredibly fast. Okay. So that's all you need to know. If you're using a

tables. And even though that might seem time consuming, because it's a database in memory, that's actually going to be incredibly fast. Okay. So that's all you need to know. If you're using a database in memory, this trait will detect that and automatically run php artisan migrate for you. However, if you're not using a database in memory, it's going to use this approach. So let's take a look at that. Refresh test database. Okay. So what this is going to do is it will run php artisan migrate:fresh. And what that will do, it'll drop all of your tables and then do a fresh run of php artisan migrate. But notice we are doing this check to ensure that the operation only happens once. It's not going to do that for every single test. It'll only do it for the very first one. And then below it, we're going to use database transactions here, where we begin a transaction. And then like before, before the application is destroyed, we roll everything.

first one. And then below it, we're going to use database transactions here, where we begin a transaction. And then like before, before the application is destroyed, we roll everything back so that we don't, we never commit anything fully. And that's it. That's all you need to know. So in Laravel 5.5, you will now use refreshDatabase by default rather than database migrations or database transactions. And this new trait will encompass either one. It's going to figure it out automatically so that you don't have to be responsible for deciding which one is more appropriate. It'll just do it for you. Very useful. So now if I were to say, well, given I have a User, then when I submit this JSON request or something along those lines, yeah, because we're using this trait, it'll make sure that once the test has completed, we remove this User entirely. Now, because phpunit.xml, we specified that we're using an SQLite database in memory,

using this trait, it'll make sure that once the test has completed, we remove this User entirely. Now, because phpunit.xml, we specified that we're using an SQLite database in memory, it'll take care of that by just running a full php artisan migrate before the test. However, if we don't have that and we're using an actual test specific database, yeah, it will initially run php artisan migrate just to make sure you haven't added any migrations. And sometimes that will happen where you've added migrations, but you forgot to run them on your test database. So then everything fails and you have to do it manually. But now it'll do that for you the very first time. And then from that point forward, it'll leverage database transactions, which is incredibly fast. All right. And that's all you need to know about this one.