Testing Inertia with Dusk
This episode is for members only

Sign up to access "Testing Inertia with Dusk" right now.

Get started
Already a member? Sign in to continue
Playing
04. Use a different database

Episodes

0%
Your progress
  • Total: 2h 53m
  • Played: 0m
  • Remaining: 2h 53m
Join or sign in to track your progress

Transcript

00:00
Before we talk about how we're going to set our database up to work with Laravel Dask, let's first of all talk about how we would do this with our unit or our feature test. We'll run a demo of this and then we'll look at the difference between our feature and unit and our browser test. Okay, so usually when I go ahead and first start up a Laravel project,
00:19
the first thing I'll do is come over to phpunit.xml and I'll go ahead and uncomment these two lines Now essentially what this will do, so when we run any feature or unit tests, it will switch over the database connection to use SQLite and the database that it will actually use is an in-memory database. Now this makes our tests incredibly fast.
00:39
It means we don't have to set up a separate database within say MySQL to go ahead and run our tests on and it also means that we keep our test data like our cedars, any of the factory data that we create away from the database that we're working with when we're developing locally. So if we just go ahead and run tests on its own now to run our feature and unit test,
01:00
that's now going to go ahead and use that SQLite database and it's going to be incredibly fast and it's not going to go ahead and create out any fake data within our database or roll it back so we won't lose anything locally. So that is probably the best way to go ahead and set the tests up locally and of course you could switch this over to MySQL and then create out a completely
01:21
separate database for testing but generally using SQLite is a good idea. Now the question is can we do this for Laravel Dusk and unfortunately the answer is no. Let's think about why. Now again what we're doing here is we're opening up these tests in a browser like we would be browsing. Because of that we cannot use an in-memory database because we're not executing this
01:45
within our code itself we're running this within a browser environment. So we could still use SQLite there's nothing wrong with doing that but we would have to have a physical database for this data to go into. Now at the moment the way that things are set up inside of our tests if we were for example to in our example test here go ahead and create a record out in the database just here. So let's
02:10
say that we created out a user in the database just here. Where would that user be created? Well the answer is it would be created in our database because over in our environment file even our Dusk local environment file our database credentials are exactly the same. So because we can't use an in-memory database and we don't really want to use the database that we
02:35
are working with what do we do? Well we go ahead and set up a completely different database and we can do this still within MySQL. Now what I wouldn't recommend is changing over the database connection that you use so the actual software that you use under your database. So I wouldn't recommend changing this specifically to SQLite. Now there's a good reason for that is that end-to-end tests
03:01
are tests that you would actually do manually yourself but you want code set up to do for you. So you basically want your environment to be more or less the same as what you would see as a user. So we really want to keep this as a MySQL database but we want to go ahead and create up a separate database for our testing. Let's go ahead and do that then we'll go ahead and run our tests and
03:26
we'll see what happens and we'll also talk about running database migrations as well. So what I generally do is just end off the current database that I'm working with locally or in production and I go ahead and just end on testing. So let's take this and we'll go ahead and create a new database out. So let's create a new database here called myapp underscore testing and this is now
03:51
our testing database. Okay so we don't have any migrations in here at the moment so now that we have changed that over what's going to happen to our test? Well at the moment we're not doing anything within our test to actually create anything so why don't we just create our user in here using our user factory and just see where this data goes and what happens. Okay so I'm
04:12
going to get rid of this pause here because we don't really need that anymore and let's go ahead and run this test. So let's say php artisan pest dusk. Okay so as we pretty much gathered would happen this goes ahead and fails so you can see here that we don't have a users table under the database that we've just chosen and remember we've configured this in our specific dusk environment.
04:34
So what do we do? Well let's head over to pest and this is slightly different if you want to use php unit but it's not too much trouble to configure it's pretty similar. What do we want to do here? Well we want to go ahead and uncomment this line to use database migrations. What this will do is for every browser test that we run it will migrate our database for us so this is pretty much like
04:58
well it is the trait that you would use within your test case class when you're working with php unit. Either way we're now using this let's go ahead and run our test again and we'll see what happens. Okay great so it passed this time and if we just take a look at our testing database you can see evidence of this here when we have the migrations table that's been created. Now you'll
05:19
notice that in here we're not left with them tables everything has been rolled back again to start fresh each time and we'll be diving into the behavior of this and another trait that we can use a little bit later when we get to it. Okay so so far we have got dusk up and running we're using a completely different environment file so we can configure our tests specifically within that
05:42
environment we know that that's copied over to env when this runs in the browser and we now also have a completely separate database that our data is going to be put into for our dusk test which makes everything now completely isolated away from as if we were viewing this in our browser and we now have a pretty nice environment set up to start writing some tests.

Episode summary

In this episode, we dive into setting up a separate database for our Laravel Dusk browser tests. First, we take a look at how unit and feature tests typically use an in-memory SQLite database to make tests run super fast and keep test data from polluting our local development database. We see how simple it is to do this by tweaking the phpunit.xml file and using the default in-memory settings.

But when it comes to Laravel Dusk—which actually opens up a real browser to simulate users interacting with the app—we hit a snag: Dusk can't use that speedy in-memory SQLite DB because browser-based requests are made outside of PHP's process. Instead, Dusk needs to read and write data to a physical database. We walk through why it's not a great idea to just use the same MySQL database you use for your day-to-day development: your tests would mix with your real data, creating a mess.

To solve this, we create a brand-new database just for Dusk tests (like myapp_testing). We set the connection details in a dedicated Dusk environment file, and then update our test setup to run migrations before each test. That way, we always have a fresh database structure that gets cleaned up after the tests are done. By the end of the episode, Dusk is up and running with a totally isolated database, so you can confidently write your browser tests without risking your local data or worrying about leftovers. This sets a solid foundation to continue building even more robust Dusk tests in the next lessons!

Episode discussion

No comments, yet. Be the first!