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
06. Diving straight into end-to-end 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 go all in and start to create our test for our registration flow. This is probably the only thing that we're going to do within the Breeze starter kit,
00:08
then we're going to start to work on some of our own functionality and some more interactive elements. But let's just use the register page to get used to writing tests with Dusk. Okay so how do we create a new test within Dusk? Well we can use phpArtisan Dusk make and then we can just give the name of the test. Let's go ahead and say auth and register test and let's
00:31
go through and build this out. Okay so let's open up that register test and you can see that already the scaffolding has been given for us with this browse. We don't have to type this out every single time and it gives us an example a search from just in here as well. Okay so let's just create the best case scenario. We're not going to do too much around here and I personally avoid
00:52
testing stuff like validation. You can very easily do that with feature tests so you don't end up with too much within your end-to-end tests and create brittle tests. Okay so it can register an account. Okay so what do we need to do here? Well we want to be unauthenticated but at the end we want to check that we are authenticated once we've successfully filled this out. So where do
01:16
we want to visit? Well I can't remember so really simply I'm just going to open up my browser and just take a look at the page that I want to be on. That is slash register. So let's go to the register page and now we're faced with working out how we fill in these inputs. Remember we're not posting this data down we're physically filling this input on the page. So let's go ahead and try
01:39
and work this out. So let's use the type method and you can see here that this takes in the field that we want to type in and the value. So what is the field? Well this is just a selector on the page so let's go ahead and open up register.vue and let's look for the name field down here and see what we've got. So this is just called name. It has an id of name so we can very easily use that.
02:02
So let's go ahead and just say name like that. There are lots of different ways that we can do this and reference these and we're going to be looking at that a little bit later but let's go ahead and just fill these in for now. So what do we want to type in? It can be absolutely anything so let's say type Mabel. Let's just take a look at this. So let's go and capture a screenshot
02:22
of this. So let's take a screenshot and we're going to call this register and that will bring us into our screenshot directory which we haven't looked at yet but this is incredibly useful for capturing a moment of time while you're writing your test to see what's going on. Okay let's go ahead and run these tests so let's say php artisan pest and dusk and we'll just go ahead and run
02:45
all of our tests here. Okay so that did pass we're not actually doing anything specifically but let's go over to our screenshots directory and you can see that we've got a register.png file in here and yeah sure enough you can see that that data has now been filled in. Great so really now all we need to do is just work down to the next field, the field after that and the field
03:05
after that and then we need to press that register button. So how do we do this? Well we just continue in Laravel fashion chaining on what we want to do. So let's type into the email field the email that we want to register with so let's say maybellicocourse.com and let's go ahead and type in a password. I'm guessing that is just called password but we can verify that and let's
03:28
just put the password as the text password and now we need the confirmation which I'm not sure about so in this case we just go straight over to there and start to look for it and it's just password underscore confirmation so we can take that and type into that as well. So let's say password confirmation and of course we will match that up to the password before or what I tend to do is
03:51
actually assign this so if it changes I only need to change it in one place. Kind of makes sense. Okay so now that we've done that we know that all of these fields as per the name that we saw in the screenshot have been filled out. Now what do we need to do? Well we need to press on a button. We don't want to post down like I mentioned before we're actually physically pressing on a button here so
04:12
we use press. We give the name or the selector of the button. So with this press let's just take a look at this because what we can do is provide the string that's within the button so this helps us as well. So if we even just open up the browser we know that this is register. Now there's a couple of problems with this if you had another button which had the same name or didn't even have a
04:36
label then you wouldn't be able to do this. So what we could do is just take a look at this so let's look for that register button and you can see yeah there's no identifying features about this. It's a really neat way that we can go ahead and identify these. I'm going to leave that until a little bit later so we can sort of solidify it in one lesson but let's go just go ahead and pass
04:56
in the register text for now and see what happens. Okay so let's just run this test so we're going to be running these a lot so let's go into our browser test go into auth and run our register test and let's just see what happens and as long as we don't get an error we can sort of assume it's worked. Okay so we do have an error so unable to locate button register. So why would that be?
05:19
Probably because, and this is another tricky part about end-to-end tests, this is actually in upper case. Now it's not within our code so if you actually look at it it is just a normal case button with a capital R but the styles for this behind this primary button element make this upper case but that means that within the browser as we see this on the page it needs to be identified as
05:45
an upper case thing. So it's basically whatever you see within the browser needs to be the case within your test. Now that's a pretty annoying and like I said we're going to look at a much better way to specifically target elements but let's go ahead and run this again and see the difference. Okay great so you can see now that has passed. Now we don't have any assertions here we're just
06:05
registering an account but now that we've done that we can start to add in some assertions. So let's go ahead and assert that we are authenticated. So we can just do that or we can say that assert that we're authenticated as a specific user but since we're in a registration flow we can't do that so let's just add this assertion in run this test and see what happens.
06:28
Okay so you can see that this has failed now let's go up and have a look here so failed asserting that an array is not empty. What does this mean? Well that doesn't necessarily mean that the registration process has failed it might just mean that we need to add some sort of delay onto this or wait till we're redirected to another location. Now anytime a dusk test fails if we just
06:54
have a look here in the screenshots directory as well as any manual screenshots that we've taken which I'm going to delete we also have at the point of failure which is incredibly useful we can click on this and we can see what's going on here. Now what's actually happening here is we're checking the authenticated users array basically what has been cast to an array for the specific
07:18
details and at the moment it's empty which means we're not authenticated. That's not very useful but in these circumstances it's a really good idea to think about the actual user flow that you're going through. When I press register over in the browser what do I expect to happen? Do I expect to just be instantly authenticated and be logged in? Well probably not I expect to be redirected over
07:42
to a specific page and then I can see that I'm logged in so we need to think when we're writing these tests as if we were actually going through the flow ourselves. So let's go ahead and register out an account we're pretty much going to replicate the test that we're writing here so let's go ahead and fill in all of these fields and let's hit register and what's happened here?
08:02
Well we've been redirected over to the dashboard so that's probably a good place to start here to assert that we are on a particular path so we can say assert path is for example there are a bunch of these which will pretty much do the same thing with some differences but we're just going to do this and say assert path is dashboard then we're going to assert that we're authenticated.
08:28
Now this might not work let's go ahead and run it and see and then I'll show you another way that we can get around these tricky scenarios so let's just wait for this and yeah it's still failed and it's probably that yeah we're not redirected just yet. So that brings us on to another really important part about writing end-to-end tests and that is waiting for things to happen so we have to
08:49
wait for things before we assert them. We don't when we're writing unit tests or feature tests because we pretty much get the data back instantly and obviously the nature of our code when we hit an end point and then get the data back means it's going to wait for that response to come back and then it's going to create the assertion whereas here what we're doing is we're just
09:09
working within a browser there are going to be delays so what we're going to do instead is we're not necessarily going to assert the path is we can do that if you want to make sure that we're on a specific location but we are going to wait for a location so we can wait for elements we can wait for text we can wait for pretty much anything let's just make sure we wait until we're on the
09:32
dashboard to then go ahead and assert that we're on the dashboard which is kind of pointless because by waiting for this location we've already assumed that we do eventually land on it we can add the assertion in anyway but now we should be authenticated let's go ahead and run this test for one final time and we should get green. So I appreciate this is probably quite a
09:54
lot to digest there are lots of things going on here particularly if you're new to Dask or writing end-to-end tests and we've just looked at a really brief overview which throughout the course we're going to be tidying up and looking at much easier ways that we can do these things but really the key to writing good end-to-end tests is to think about this as if you were actually in the browser
10:13
well I'll go ahead and enter my details then I hit register but I need to wait till I'm redirected to the dashboard before I start checking the path and before I start checking if I'm authenticated or not if in doubt go back to the browser go through the flow yourself and then go ahead and write the test in as much detail by waiting for things as you can.

Episode summary

In this episode, we dive right into creating our first end-to-end (E2E) test with Laravel Dusk, focusing on the user registration flow using the Breeze starter kit. We'll only stick with Breeze for this initial experience and will later expand to building our own functionality.

First, you'll see how to generate a Dusk test using php artisan dusk:make and explore the auto-generated test class. We talk about focusing on the "happy path" (best-case scenario) and intentionally skip things like validation, since those are better off tested with feature tests to keep your E2E suite from getting brittle.

Next, we start filling out the registration form like a real user would: typing into input fields, mimicking button clicks, and running our test to see if it works. A cool tip in here is using Dusk's screenshot feature to visually confirm what your test is doing at any step.

Along the way, we run into some bumps—like not being able to find the Register button because of how the text appears on the page (turns out, case-sensitivity matters!). We fix the selector and talk about best practices for targeting elements in your tests (with improvements coming in later episodes).

Once we've got things filling correctly, we take a look at asserting that the user is authenticated and correctly redirected. This introduces one of the key concepts in E2E tests: waiting. Unlike unit or feature tests where everything happens instantly, browser-based E2E tests need to patiently wait for navigation, redirects, or elements to appear, and we show how to do just that.

The episode wraps with a reminder that E2E testing is about thinking like your users and replicating their actions as closely as possible, always checking your assumptions by manually running through the process yourself if things get confusing. As we go further in the course, we’ll keep refining and improving our test code!

Episode discussion

No comments, yet. Be the first!