So, because we have Jetstream installed, if we actually go to our project structure and head to the Tests directory, under the Features subdirectory, you'll note we already have a load of test files. And if you chose to use PHPUnit, then these will be PHPUnit classes. In our case, they are pest tests. But yeah, you can see we already have a bunch of tests. And that's a great way to ensure that the test suite is actually up and running and that it works correctly. So, tell you what, let's go straight into our terminal and we'll run php artisan test. All right, we seem to have tests passing. That's really nice. However, if we jump into TablePlus, I have a sneaky suspicion that if we load our forum database and take a look through here, yeah, sure enough, it's deleted all of our data that we set up in the Seeder. Our test suite is using the same database.

our forum database and take a look through here, yeah, sure enough, it's deleted all of our data that we set up in the Cedar. Our test suite is using the same database connection as our actual local environment. So, anytime you run a test, well, all of your local data is going to be deleted. That means the first task we need to tackle is altering the database that our test runner uses. In order to get this configured, let's jump into the phpunit.xml file, which is at the root of our project directory. And we can scroll down to this phpNode here. Now, anything inside of this phpNode is going to override the specific variables inside the .env file only when executing tests. So, as we declared in the first episode, we're using MySQL with a database called forum. And if we take another look at the phpunit.xml file, currently there is no variable overriding database connections.

in the first episode, we're using MySQL with a database called forum. And if we take another look at the phpunit.xml file, currently there is no variable overriding database connections. However, you'll see that by default, Laravel has these two commented outlines, which we can uncomment if we just want something to get up and running with quickly. So, in this case, we're saying set the DB connection not to MySQL, but to SQLite. And use the SQLite in-memory database. So, don't store anything on a file, but use an in-memory database whenever you're executing these tests. That allows for a very fast database connection. So, if we jump back into our terminal and run php artisan test, everything should work as it did before. However, we're now using a different database connection to what we use in production. In production and in local testing, we're using MySQL. But for our automated tests, we're

However, we're now using a different database connection to what we use in production. In production and in local testing, we're using MySQL. But for our automated tests, we're going to be using SQLite. For 99% of the time, that's not going to cause any problems. But there may be edge cases where SQLite handles things differently to MySQL. And that can cause false positives or false negatives in your test. So, I think it's important, certainly in larger projects, to use the same database connection and just use two separate database instances. So, let's go ahead and update phpunit.xml to use MySQL. For the database connection, I can just remove this because the default in .env is MySQL, so there's no need to override anything there. And let's set the DB_DATABASE to forum_test. Okay, what happens now if you run php artisan test? Well, you can see everything fails. And it fails

anything there. And let's set the db_database to forum_test. Okay, what happens now if you run php artisan test? Well, you can see everything fails. And it fails because the test suite will not create the database for you. So, SQLite, it doesn't matter because it's in memory. But MySQL, you're going to have to create that database yourself. I'll jump into TablePlus. I'll head to the database picker up here. I'll create a new one called forum_test. And let's click okay. Now, we can go back and we can run php artisan migrate:fresh --seed in order to refill our real forum database. So, here we are. We have our users back. We have our posts back. And we have our comments back. But if we run php artisan test again, well, yeah, it all runs as we'd expect. But in TablePlus, well, now it's not. So, that's how you can set up two different databases, one for testing and one for actual.

test again, well, yeah, it all runs as we'd expect. But in TablePlus, well, now it's not So, that's how you can set up two different databases, one for testing and one for actual development work. You want to do that as soon as possible. Once you've done it, you don't even have to think about it again. Now, it may be too early to even start thinking about this. But while our tests are very simple and plain and basic, and I know there are no problems, I want to actually try out parallel testing so that as our test suite grows, we can switch over to parallel testing as and when it makes sense. So, I'm going to run php artisan test and I'll drop in the -P flag to make it run in parallel. And there we go. You can see that it did run successfully. We skip a few tests because there are features in Jetstream that we're not using. But I would imagine now in TablePlus, if we refresh and

You can see that it did run successfully. We skip a few tests because there are features in Jetstream that we're not using. But I would imagine now in TablePlus, if we refresh and we open the database picker, note that we actually have eight forum test databases. And that's because Laravel sets up a new database for each core on your computer, each process that is going to be used by the parallel runner. So, that looks like it's working correctly. We know that we have a working base, which has parallel testing. I just want to organize my test suite. See, notice that under the feature directory, we have all of these Jetstream tests, which is brilliant. The reason Jetstream publishes these is that if we edit the actions that Jetstream ships with, well, we can also update the tests at the same time. But this is a lot of junk, a lot of filler inside the root of the feature directory. And thanks

that Jetstream ships with, well, we can also update the tests at the same time. But this is a lot of junk, a lot of filler inside the root of the feature directory. And thanks to the fact that we're using pest, there are no namespaces. So, I'm going to go in and just create a simple directory called Jetstream. And I will drag and drop all of these tests into the Jetstream directory like so. So, that's from php artisan test once more. And hopefully, everything will still pass. Yeah, but we've now nicely namespaced everything under the Jetstream directory. Okay, the last thing I want to do is ensure that I'm actually able to run tests using phpStorm. And that test was ignored. Let's find one that won't be ignored, maybe authentication.test. And yeah, everything's working inside phpStorm. I've got that set up to command T to run any test when I hover over it. So, I think this

be ignored, maybe authentication test. And yeah, everything's working inside phpStorm. I've got that set up to command T to run any test when I hover over it. So, I think this puts us in a pretty good place. I can execute the test from the terminal. I can add the --parallel flag and that works. We're using the same type of database for development and running tests. So, we're going to avoid any edge case issues with that. I've segregated the Jetstream tests. Anything else? There is one more thing I'd like to do. If we jump into the pest.php file on line 17, you can see it uses the BaseTestCase and the RefreshDatabase trait. Now, if you're using PHPUnit, this will all be declared inside this TestCase class here, the abstract class, but we're using Pest. So, I'll continue to do that. All I want to do is switch out RefreshDatabase with lazilyRefreshDatabase. This simply

case class here, the abstract class, but we're using pests. So, I'll continue to do that. All I want to do is switch out refresh database with lazily refresh database. This simply means that it will only migrate the database. It will only roll back and roll forward all of your migrations and data if the test touches the database. So, this can have a little bit of a speed impact on how fast your tests run, particularly when you're using MySQL, for example, instead of an in-memory SQLite database. Let's just make sure this works. A test and we'll use parallel here. And yeah, sure enough, everything still works correctly. So, with that done, I think we're ready to start writing tests to build out our very first feature an index of forum posts. See you in the next episode.

an index of forum posts. See you in the next episode.