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

Okay, so how do we do this? Well, the first thing that we need to actually check if the user is authenticated is a user that we can actually log in as. Now, if you have worked with feature tests before in Laravel, you'll know that we have an acting as method where we can pass the user in, and then we can go ahead and maybe send a get request to a specific room. Now, because we're working with Dask, it pretty much works in the same way. We just have a method name change. So what do we do here? Well, we could either do this inside of the browse function, or we could go ahead and use any of the variables within this closure here that we want to use.

So let's go ahead and just get rid of this, and we'll just start from scratch here. So we're saying this browser we're browsing to, so we're opening up our browser, which is what this browse does, and then using that browser instance, what are we going to do? Well, we're going to log in as, so this is slightly different to acting as, but it works pretty much in the same way. But remember that because we're in a browser, there needs to be a mechanism in place for us to actually authenticate within the browser and login as handles that for us. So we can just go ahead and pass in the user that we have here, and we should be good. So that should log the user in.

Now with npm run dev running, because remember, if we make any changes, make an assertion here, and it's not being compiled, we're not going to see that, and obviously our test is going to fail. We're going to head over to the dashboard.vue component, and let's just output the user's name over here. So let's just say, hey, and then we'll go ahead and use page, props, auth, and user, and we'll grab the user's name. So let's go over and just register out an account here, just so we can actually see this for ourselves, and then we'll go ahead and create the end-to-end test. Okay, great. So yeah, sure enough, we see, hey, Alex on the dashboard, and we can now transfer that over to an end-to-end test.

So we want to log in as user. Now what we want to do is visit a particular page. So the API between our feature tests and our end-to-end tests are completely different, because we're not sending a GET request to this, because it's already open in the browser. We don't have the concept of really making a GET request or a POST request here. We're visiting and then taking an action. So if we, for example, were submitting a form with an end-to-end test, we wouldn't POST through anywhere. We would click on a form's submit button.

So it just takes a little bit of a while to get used to the different terminology here where we're working with end-to-end tests. Okay, let's go ahead and visit the dashboard. And what do we want to do? Well, let's just use a simple assertion here that we assert that we see, hey, and then the user's name. Now we can talk about the brittleness of end-to-end tests, and this does relate to feature tests as well.

We don't really want to be writing tests like the test that we've written here. We want to make these as open as possible to change. Hey is a string that we've included in here, but could change very easily, and this would then go ahead and interfere with our test. Let's do this anyway, but we'll bear that in mind as we're writing our test. And I'm going to show you some tips that we can use to get around brittle tests when we're end-to-end testing.

Okay, so we're going to say user and name, and we can go ahead and specifically create a name out here as well if we want to be a bit more specific. Okay, let's go ahead and run this test and see what happens. So let's say PHP artisan pest dusk, and while we're doing this, let's go ahead and specifically hit the file that we're actually working with here. So this is the dashboard test. So let's run that specifically.

Okay, so as you can see, we get green here. Just while we're here, let's go ahead and open this up with the browse mode enabled just so we can see this working, and we'll see what's going on behind the scenes here. Now that didn't actually work, so let's go ahead and just get rid of that and go ahead and put this before the filter. So let's say browse and then the name of the test file. I think it matters which order this is in, and there we go. You can see that was pretty quick. The first test that we ran was a little bit slow, probably because of caching or something like that.

But now we're about two seconds, which isn't too bad. Now that was incredibly quick where we use the browse option. We don't really need to for this, but what you'll find is occasionally when you're writing tests, end-to-end tests, you're going to get to a point where you get stuck at some interactions and using browse will help you diagnose what is actually happening within the browser. And we'll be using that frequently throughout the course to see what's going on.