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

So the first thing that we're going to do is go ahead and make our model and we're going to call this task. We'll create a migration, a factory and a seeder alongside of this. I'm going to show you shortly how to run seeders before each of your tests as well. Okay, so all of them have been created. Let's go over to the create tasks table migration

and we'll just fill this in with some really basic data. So we are going to have a string here with the task name. Let's actually call that title and we need this to belong to a specific user. So let's go ahead and set up a foreign ID here, the user ID, and we'll go ahead and constrain that to the users table.

Okay, let's run phpArtisanMigrate and that has been created. And since we're going to be creating tasks within our tests to see if we can actually see them on the page, let's go over to the task factory and fill in a fake title in here. So let's set the title here to fake sentence and let's just say three words.

Okay, so generally when I'm writing end-to-end tests, what I'll do is I won't use any kind of test driven development. What I want is I want all of the features done on the page and I know that they're working. And then from there I can take what I see, translate it to an end-to-end test, and then that's a good way to see if anything's broken when things change.

So obviously because we're using inertia and we can't make a request to this page to actually see the HTML and then assert that something is on the page, it's a good idea to write an end-to-end test for visibility checks like this if they're important. Not all of the tests that we write here are going to be super important,

but we're going to go through, write them anyway, and then you can decide what's important to you through the user flow. Okay, so let's get started then. We'll go ahead and create out a controller in here and let's call this just task controller. We'll just use one controller for everything and over in that task controller, we are going to have a index method to show a list of our tasks.

So what are we going to do here? Well, let's return inertia, render, and we're going to have maybe a tasks index page. And what do we want to pass down here? Well, we want to pass all of the user's tasks in. So let's grab our request out here. Let's take the tasks here.

And for now, at least, let's just grab the user tasks and just pass them in and we won't use any kind of API resource to transform these, but we will change this over. Okay, so over on our user model, let's open this up. We'll need to create out a relationship here. So let's do that now. Tasks, and this is really simple.

It's just a as many and that will be the task like that. Great. Okay, so we haven't got this page created at the moment. So let's head over to resources, JS, and pages, create a directory out in here called tasks, and then we will create out a view component called index for our task index.

Let's go over to our dashboard and just copy the entire template for this over. And let's just write tasks in here and change the title to tasks. And I think that should be about it for now. So let's just empty that out. And let's just write a really quick smoke test for this once we've got our web route set up.

So we'll put this under our author middleware. Let's say route, get, and tasks. And this is going to hook up to our task controller. And that's that index method. We'll give this a name of tasks and index as well. Okay, so we're pretty confident when we come over to that tasks page, we should see tasks in there.

So let's just write a really quick smoke test to check that we can actually see this page. So we'll just say, well, can we see a title with tasks in? So let's go ahead and say dusk make, and let's put this under tasks. It's up to you how you name these. What I tend to do is break them up into the action I'm taking.

So for this set of tests, we're just going to be looking at an index. So I'm going to call this task index test, but you can give these any name you want and organize them in any way that you want. So let's open up our task index test and let's say it and let's say shows the tasks page.

So what do we need to do? Well, we just need to hit the tasks page and assert that we see tasks. We'll dive into this a little bit more in detail about how we can look inside of specific elements. We're not specifically worried about that in this test because it's very simple, but it will give you the knowledge that you need to go on and look specifically inside of places within your page.

OK, let's go ahead and run this test. So PHP artisan and pest dusk. And let's go ahead and run our task index test. OK, that fails. It's pretty obvious because at the moment we need to be authenticated for this. So obviously within this test, we would need a user.

Let's go ahead and say user factory. That's the wrong one. Let's pull in the correct user here and say factory and create. We don't care who it is. We just want to make sure that we can see this. Let's bring that into scope. And we already know how to do this. We looked at it earlier.

We want to log in as that user, then hit the tasks page. Let's run that again. And sure enough, it passes. So we know that we can see inside of here. We'll come back to this a little bit later to look at looking inside elements to actually assert things within them.

But for now, let's go over to that list of tasks test. So over in our index under our tasks, let's go ahead and just list through all of our tasks within here. So let's start out with a kind of wrapper here and we'll say if the tasks has a length. So if we actually have any tasks, then we're going to iterate through them in here

and actually we'll create a separate component for this just to keep things nice and tidy. So let's create a directory in here called tasks and we'll call this task item. OK, so inside of our task item, we are just going to dump out the task title. And up here, we'll go ahead and define our props, which is just going to be a task object

that should just dump out the title of our task. In here now, what we can do is output the task item. And we can do a V4 task in tasks and we can key that by the task ID and we can pass the task in as a prop and that should get rented out.

So let's go and make sure that we're actually pulling in our defined props here because we're passing that through. So tasks and that's going to be an array of items and we should now over in the task list, see a list of tasks as long as we have some. Now, we don't have any at the moment.

So what I'm going to do is manually create these out in the database for now. And then of course, we will see them in our test properly. So let's hook this up and just say task one. And we'll go ahead and duplicate this down, say task two.

And I think that'll be enough now just to test this out. Okay, great. So we can see a list of our tasks, pretty straightforward. How do we translate this to our Dusk tests though? Let's head over to our task index test and we'll create our new test.

So it sees a list or shows a list of tasks. We're going to do exactly the same thing. We're going to browse to a particular page. So to create out our closure in here, into here,

we'll get our browser instance that we can use to hit the page. Again, we're going to need a user to be authenticated here. So we can just pull over the user factory here and go ahead and use that user, bring that into scope.

And we want to visit the tasks page. So let's say visit the task page. And of course, we need to be signed in. So let's say login as that user. We want to visit the tasks page and we want to make sure that within here,

we can see all of them tasks. And that's a little bit more trickier than it sounds. We don't have methods within Dusk that allow us to easily do this. So that's why I wanted to cover this in a separate episode.

Let's go ahead and run our test here and we'll filter this down specifically to this test. And sure enough, it passes. Okay. So we now need to figure out how we're actually going to work out whether we can see these on the page. And the first thing to do is obviously see these in the database

or at least create them with a factory. Okay, so let's use our task factory to go ahead and create out a few tasks on the page. So let's go ahead and create these out and let's go ahead and create three out here. We'll do this for that user. So they actually belong to that user

because remember, we should be able to see them within that user's account. And once again, let's go ahead and bring these into scope within here so we can perform some assertions. Now, what do we want to do here? Do we want to say assert C and then task get 0 or something like that and then title?

That probably would work. I'm going to show you a much easier way to deal with lists of things, but let's just run this for now. And obviously that hasn't worked just because we need a relationship over in our task model. So let's go ahead and open that up and just create out a user relationship in here.

We'll say this belongs to a user. Okay, let's run that test again and it could pass. And yeah, it does. Now what we could do instead is we can specifically target a group of elements by their name. What I mean by that, and this is a much easier way and clearer way to do things,

we're going to go ahead and create our local variable here just called elements. And from our browser, we can use the elements method and pass in a common selector between a bunch of elements. Now, what could that common selector be? Well, it could be the dusk attribute feature that we've already looked at.

So what we could do is we could open up our task item and for this we could say dusk and we could just call this task item or let's call this task item without a hyphen. So we've got a task item in here. Over in our test now, what we can do is use at task item. That's going to give us three elements. Then what we can do is start to assert that we have the correct count.

So remember that with the assert C, what we're doing is we are checking that there are technically three because we could do an assertion for each one. But what we can do now is make our tests a little bit clearer. So we can start to use any of the test expectations so we could say expect elements to have count of three. So for me, at least that's a lot clearer. Let's go ahead and just run this and make sure it's all good.

And yeah, there we go. We've got one assertion passed. It does have three. Now the question is, what actually is this? What are we getting back when we use browser elements? Well, let's just dive into this really quickly. So we've got this resolver all on a selector. Let's open this up and have a look. So what it's doing is it's using the driver behind the scenes,

which we know is our Chrome driver. And it's using this find elements method, which is within the PHP WebDriver library. And then it's going ahead and finding these by the selector. So basically just plucking out a list of elements. And as we can see here already, I don't think this is typed, but we can see that this is pretty much going to return an array to us.

So let's just die dump on elements and just check this out and we'll have a look here. OK, great. So this has obviously three elements. It's zero index. So we end up with two as the last one. And this is a remote web element. Now, this remote web element contains a bunch of stuff.

So it's really useful to dive into this stuff so we can actually really get into these elements and see what we can do with them. And if we open this up and just take a look at a list of the methods we've got here, we've got click. We've got all of these things that we can use to interact or get the information about them, get text. We can use any of this stuff. Now, behind the scenes, Laravel Dusk will handle most of this for us.

And most of the time we won't need to interact this deeply with these elements. But we have done this so we can do something like this elements to have count. What we can now do, though, is we can go through each of these elements and assert that they all have a specific content or we can do it the other way around. So we could do something like tasks each create our closure in here.

So we're going over each of the tasks that we have into there. We're going to get a task like this and we basically want to use the browser to continue to assert that we see this on the page. So kind of like what we did before. But now we're iterating through. And what that means, well, let's go ahead and do this first and then I'll show you why this is useful.

So let's go ahead and bring browser into scope. And we're going to say assert C and we're going to say task title. So we want to make sure we see all three that we're iterating through on the page. Let's run that test again and let's make sure that passes. And sure enough, it does.

Now, why is this method better than what we've done before? Well, basically, if we were to change the amount of elements that we had here, so maybe we wanted to see a list of five elements on the page and we changed our factory to generate five elements. If we were ignoring all of this and doing things like this, assert C and tasks get zero title,

duplicating this down and then saying assert C task one title and doing it again for element two and so on and so forth. I think you get the idea. First of all, it's a little bit messy. It's not as flexible. So if we were to change that from three to five, we would then have to add two more assertions onto this list. So as well as doing things like this, it's also a lot more flexible because now we're just iterating through the tasks that we've created

and we're checking that that text is on the page. So for very basic things like we looked at up here, assert C that we have a tasks title, which we're going to go ahead and dive into in a little bit more detail later. We should really for lists of items,

go ahead and grab them up either by a selector or a dusk attribute as our selector and then going ahead and asserting that we have the right amount. And in this case, obviously that can change. So we would have to change that over to five if we were to generate five elements. But this in particular is a lot more flexible.

We don't need to adjust our tests based on how many tasks are on the page. Okay, let's change this back to three because that's pretty much all we need to get that working. And let's just go ahead and run all of our tests on the dusk just to make sure everything looks good. And there we go.