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
05. Authenticating for tests

Episodes

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

Transcript

00:00
Let's turn this example test into something a bit more useful, and we're going to talk about authenticating, which is probably the majority of the time you are going to be acting as a logged in user. Okay, so we'll go ahead and just rename this test. So let's go ahead and rename this to, let's call this dashboard test, and we'll go ahead and make sure that we can hit our dashboard and see the user's name. Okay, so let's say it can see the dashboard. We'll just keep this super simple, and I'm just going to change this over to it instead of test, but you can go ahead and use any of the functions you want.
00:36
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.
01:16
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.
01:54
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.
02:35
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.
03:05
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.
03:29
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.
03:55
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.
04:21
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.
04:50
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.

Episode summary

In this episode, we take a basic test and turn it into a more realistic example by focusing on authenticating users—because let’s be honest, most of our testing is for logged-in users! We start by renaming our test to something more purposeful, like a dashboard test, and set out to check if the logged-in user’s name actually appears on the dashboard screen.

Next, we go over how authentication works in end-to-end (E2E) tests compared to more traditional feature tests in Laravel. Instead of using actingAs, we use loginAs inside our browser automation, which handles the browser-based login process for us. We walk through updating the Vue dashboard component to actually show the current user’s name (making the test meaningful!), and do a manual registration in the app to make sure everything's wired up end-to-end.

The episode then highlights the differences in APIs for feature tests versus E2E tests: instead of sending HTTP requests, browser tests interact with the interface like a real user would—clicking buttons, visiting pages, and so on. We write a simple assertion to confirm that the authenticated user’s name is shown with a “Hey, UserName!” message.

There's a quick chat about test brittleness—like depending on specific text that might change—and why that's something to watch for as you write more robust tests. Then, we finish up by running the test (success!) and using the browse option to visually see what’s happening in the browser, which can be a lifesaver when diagnosing sticky test issues. We’ll rely on this visual debugging trick more as the course continues!

All in all, this episode is all about getting a realistic, authenticated workflow set up for E2E browser tests and seeing how to actually interact with a real app as a real user would.

Episode discussion

No comments, yet. Be the first!