Testing Inertia with Dusk
Playing
03. Running a Dusk-specific environment file

Episodes

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

Transcript

00:00
We know that when we run end-to-end tests with Dask, this opens up a browser window, pretty much like how we would browse it, click on things, create records in the database, anything that we needed to do. Now because of that, it's not possible to mock things. So as an example, let's say that we had a service that had some sort of secret key attached to it.
00:21
When we go ahead and open this up within our tests, so the browser opens and we click on something, maybe that triggers an API request to a service that we have. Now what we can't do is mock that, or fake that, or get away with not doing that at all. We don't have that much control over what we do because these are being opened in a browser environment. Now to get around that,
00:44
what we need to do is separate out the environment file that we typically use with any of our secret keys in here that we have into a specific Dask environment file. Let's go ahead and take a look at how we do that now. So what I typically do when I start a new project is I take the entire environment file that I'm starting with and I just copy this as the basis of the Dask-specific
01:09
environment file. Let's go ahead and create a .env, but this time a .dask, and then onto the end of this we're going to choose the environment that we want this for. So in our case we're working in a local environment, so I'm going to choose local, but you could choose any value here that you have under the environment setting. For example we could have a CI for continuous integration,
01:32
or we could have a production one, for whatever reason. So we're just going to choose local here, so I'm going to create this .env.dask, so we know it's for Dask, and then .local, and let's go ahead and just paste in the contents of our current env file. Let's go ahead and run the test that we had earlier, so let's say phpArt and pest-dask, and you can see sure enough this still works. But what's
01:54
actually happened here is that will have used that new environment file that we just created, so now we can change over any of the configuration values here specifically for testing. Now the question is how does Dask know how to work with this? If we're opening this up in a browser window, we can't specifically say to our app that we want to use this environment file, because we're opening it
02:18
up in a browser window. What actually happens during the running of Dask tasks is it will copy this file over to an env file, it will back up our env file, and then once the tests have either failed or completed, it will then restore our original env file. Now it's pretty difficult to demonstrate this, but let's give it a go. So I'm going to go and take env.dask.local, and I'm just going to add
02:46
some secret in here. So let's say that this was specific to our Dask environment, and we had another one in here which had a completely different API key. So let's go ahead and say def. So when we run our tests, env will be switched over to env.dask.local, which will be abc, then replaced out into here. Then when our tests finish, it will go back. Just to simulate this
03:12
even further, let's go ahead and open up our example test, and we'll add a pause in here like we did before. So let's add this for three seconds. So let's go and just run our test, and let's keep an eye on our env file here, and we'll see this value switch over. Let's go ahead and run our test here. We should see that switch over to abc. That's been backed up as we can see here, and then
03:34
as you can see it's just been restored. So that is what happens during our tests. Because we are working in a browser environment, remember we can't mock this stuff. We can't specifically tell our browser, oh I want to use that specific env file. It runs like a normal Laravel application, and it will always read from env. So what I would always recommend you do is have a separate env.dask.local
04:01
environment file in case you need to switch over any specific settings inside of here to use different services. For example, the example secret key that we've used here, we might want a different one for our end-to-end tests than we do for our local development. So we could just go through here and configure things completely differently for our dusk tests. Now we'll come back to this a little
04:24
bit later because we're going to look at pushing this to github actions, and once again we're going to need to change over these values or at least set them specifically for that environment. This is a good first step so we can make sure that we tweak this only for our dusk tests. And with that in mind, let's go over to the next episode and talk about our database.

Episode summary

In this episode, we dive into how to create and use a Dusk-specific environment file for your Laravel end-to-end tests. Since Dusk opens up a real browser to interact with your app just like a real user, you can't easily mock out things like API keys or secrets. Instead, you need to provide real (but safe for testing!) values.

You'll see how to copy your main .env file and create a new one like .env.dusk.local that you can tweak just for running Dusk tests. We walk through modifying it with test-specific secrets or API keys, then explain how Dusk actually handles swapping out the environment files behind the scenes—backing up your original and restoring it after the tests run.

To prove it's working, we even add a pause in the test so you can visually see the environment file swap take place in real time. By the end of this episode, you'll know how to keep your end-to-end test environment isolated and avoid running tests with your real API secrets. Up next: handling your test database setup!

Episode discussion

No comments, yet. Be the first!