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
10. Navigating between pages

Episodes

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

Transcript

00:00
A key part to an end-to-end test is remembering that what we're doing is testing user flows throughout our application. So what we don't want to really do, we can, is get into the habit
00:13
of hitting a page, performing an action, and saying well that's it. What we ideally want to do is test the critical flows throughout the application. For example, the user should land on the pricing page, see a correct price, then they should be able to click the checkout button or click the sign up button, and they should see, for example, a register modal or a login modal,
00:39
then they should be able to go through to checkout after that. Now we're not doing anything as complex as that just here, you will be able to after you finish the course, but what we're going to do is test clicking a button on the page here, and that will be to create a task. Now that is a pretty critical action on this tasks page, and we'll take a look at a couple of ways that we can
01:00
achieve this, and some of the issues that we might see along the way. Okay, so the first thing is we're going to build the feature out. So down here I'm going to output a button. Now we don't have any link button components in here, but what I'm going to do is I'm going to take the primary button, which is a physical button element, and I'm going to create out a new component in here, and I'm
01:19
going to call this primary link button. We're just going to link through to another page, but of course this button could launch a modal, which for things like that we'll get to a little bit later. Okay, let's paste in what we have here, and I'm going to change this over to a link element, and let's go ahead and make sure we import. So we'll pull this up the top here, and we'll go ahead and make sure we
01:43
import link here from Inertia. When we pass an href through to here, it will be passed through at the moment. It's shouting at us, and I think we'll just get rid of lang of ts in there for now. Okay great, so we've got a element that we can use here. So let's go ahead and output this primary link button, and into here we want to say create task. Now this is just going to be an anchor
02:06
that when we click through it goes to another page. Let's create that out first of all. So let's go over to our task controller, and let's create out a method in here called create, and we'll render a new page out. So inertia and render, and let's render out tasks and create. This will just be the form to create a new task. So let's go and register a route for this. So let's grab this one down here.
02:31
Let's pop create on the end, and we'll reference that create method, and we'll change that over to create. Okay so we can hook this up now and make sure it goes through. So let's say href route and tasks and create, and let's create that element out in here. So we're going to go into our tasks page, create out a create page, and again we'll just take any of these and copy them over. So we'll
02:58
take the dashboard, pop that in there, and let's change this over. So create task, same for our header. We're not going to bother testing but the header's correct. We'll be just doing that as an example, and this in here is going to be a form. Let's check this works in the browser first of all, and sure enough it does. Now what do we do if we want to test the flow of clicking this button
03:22
to go through to this page? Well let's go ahead and put this in our task index test, although you could create out a separate test file for this. We want to make sure it clicks through to create a new task. So as well as going through to that page, we can also make sure we're on the correct path, which is task slash create, and we could even check that there are the correct elements
03:47
on the page as well if we wanted to. So let's go ahead and get started. So let's say this browse, and again bring in our closure here with our browser, and we need a user for this. So let's make sure we've got a user because we know that we need to be authenticated to get this working, and let's say browser login as that user, bring them into
04:15
scope here, and we want to visit. What do we want to visit? This is the kind of point I'm trying to get across. We don't want to visit tasks create because that doesn't tell us anything about the user's journey. It doesn't tell us whether we can actually click on this. We want to visit the tasks page, then we want to click on that link. So what do we want to click on? Well, we can go over and
04:39
change the selector for this. So over in our tasks index, let's do this here. So if we were to reuse the primary link button anywhere else, we wouldn't want to put the dusk selector within that. So we're going to say create task button. So let's take this, and let's say we want to click on that, and let's just run this test just to make sure everything looks good before we start to
05:02
assert anything. So let's filter this down to this test here. Okay, that's failed. Let's just have a look here. So cannot read properties of undefined reading click. Now it looks like, again, we can come over to our test directory and have a look here. It doesn't actually exist on the page. So what is happening here? Well, click link is going to take in the text that we want to click. So it
05:27
will look for text specifically. We know that that is create task. Now, really confusingly, this acts a little bit different to when we press the button earlier with a capitalized text. So if, for example, we would assume we'd need to do create task because in the browser it's visually create task with uppercase, that's still going to fail. Just wait for that, and there we go,
05:50
it still fails. What we now need to do is actually provide create task as lowercase. So a little bit confusing, but once you get used to this stuff, it kind of makes sense. So there we go, we've got a pass on that. But what we don't want to do is use the text. So let's bring that back to create task button. We now want to use click. So we're clicking on a specific selector, which is our dusk
06:12
attribute. Let's run that again and just make sure that passes. And yeah, it's all good. Okay, so what do we want to do now? Well, there's a couple of options that you have here. So you could say the assert path is. So let's say assert path is tasks and slash create. Now we looked at this a little bit earlier when we said that we wanted to wait for pages. So if we run this, let's go ahead and
06:36
see what happens. Now that fails because when we click on this immediately, we're not forwarded over to tasks and create. So what we really want to do here is go ahead and wait for a location. So let's wait for tasks and create. Again, we don't necessarily need to assert that the path is this specific path. We can do if we want to have that assertion in here, but that goes ahead
07:02
and solves the problem. Now, another thing about waiting for a location is that sometimes there's a slight delay. Now let's just say as an example, our tasks create page took a few seconds to load and there was no getting around that we were doing something in the background that meant that this page was just particularly slow. Any of these wait for methods allow you to pass in an amount
07:25
of seconds that you want to wait for. So this is the maximum amount of time. It doesn't mean that this is going to delay your test for the amount of seconds that you give, but it gives you the opportunity to increase the buffer. We could say wait for 20 seconds, for example, as a maximum. That doesn't mean our test is going to take 20 seconds. It means that that's the maximum
07:46
amount of time it's going to wait until it continues and doesn't fail at this point. So usually you can get away with just leaving that as the default, but you can go ahead and adjust it if you need to. Okay, so we assert the path is create, but then we can continue to do things. So now that we know that we're definitely on that page, we can assert that we see in, for
08:07
example, in that header. So let's just remind ourselves what we call that, and that was the authenticated layout header. So we want to make sure that we are seeing that and we want to say create task. I think that's what we added. Let's just have a look. And yeah, it's create task. So there we go. We've created a better flow now where we start on one page, we go through to
08:33
another page, and then we make some more assertions, even if we're on that other page and there's nothing stopping you. Then going ahead and clicking on another link, if you want to, or clicking on something that is provided with some sort of selector in here, and then going ahead and performing more assertions. Obviously what we're creating here is pretty simple, but you
08:52
can chain these on to create the flow that you want to. Like the example I gave at the start of the episode, where you might want to land on a pricing page, see that the correct price is displayed, allow the user to click on that, see that the register modal, type in the details, and then go ahead and be forwarded over to checkout. You can do absolutely anything with navigating through
09:15
pages, just remember waiting for locations. It's probably the most important thing, otherwise you're going to end up having an immediate click, not seeing that this page is the correct page that you want to be on. Just make sure you go ahead and wait for the page to be rendered before you start to perform any other assertions.

Episode summary

In this episode, we dig into how to properly test user navigation between pages in an end-to-end test—something that's key for covering actual user journeys, not just isolated actions. We start by setting up a basic flow: adding a "Create Task" button that takes the user from the tasks list to a task creation page. You'll see how we refactor a standard button into a link, hook up the necessary route, and render the correct page.

Once that's working, we look at the right way to write a browser test for this interaction. Rather than just jumping straight to the target page, our test mimics real user behavior: visit the tasks page, click the button, and then check that the navigation worked as expected. Along the way, we hit some gotchas—like selectors versus link text, and being case-sensitive about those—so you get to see some quick troubleshooting.

A big emphasis is put on waiting for navigation to complete. We'll look at the difference between asserting immediately versus using waitForLocation, and how you can customize how long you're willing to wait for the new page to load. Finally, we round out the episode by making some assertions on our new page and talk through how you can string together more steps to test much more complex user flows—think multi-step registrations or checkouts—by chaining page visits and interactions together. By the end, you'll know why it's so important to test flows, not just static pages, and how to handle navigation reliably in your tests.

Episode discussion

No comments, yet. Be the first!