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
19. When you don’t need Dusk

Episodes

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

Transcript

00:00
There are quite a few circumstances where using Laravel Dusk just doesn't make sense. We've already touched on them throughout the course but let's take a look at an actual example of this. We'll go ahead and add authorization rules to our destroy and our update method. At the moment anyone can pass in an id of a task whether it belongs to them or not and that will be either
00:22
deleted or updated. So at the moment we obviously have a security concern and we want to write a test for this. Okay let's build the functionality out for this first. So we're going to go ahead and use a policy here. So let's make a policy for our task. So we'll call this task policy. Let's head over to that task policy and fill in the authorization actions for both of these.
00:45
So to go ahead and destroy a task what do we need here? Let's bring the user in here which will always get passed in when we use this and let's bring in the task that we are trying to destroy. All we want to do for this and for the majority of authorization is just check that the user id matches the task user id that's been assigned and that will basically just tell us whether we're
01:08
allowed to delete it or not and we can pretty much just copy and paste this down for our update functionality as well. Okay so now that we've got this policy let's go ahead and add this into here. Now there's a couple of ways that we could do this. We can either create a form request for this or we could use the gate facade here to authorize this. I'm going to go ahead and create a form
01:27
request because this is just typically what I would do and it generally makes things a little bit cleaner. So let's go ahead and make out a request called task destroy request and let's do another one for update request and we don't have one there already so let's do that as well. So task update request and let's go ahead and just swap these over immediately. So this will be
01:51
task update request and we don't have any request in here because we don't need one but I always find that using a request a form request actually helps here anyway just in case we need it later. So let's go ahead and say task destroy request bring that in and we don't need to use that but we can go ahead and authorize directly in here. So with authorize we can just
02:12
say this user since we're already in a request we can access the currently authenticated user and we'll say can destroy and we want to pass in the task that's within this request which comes from root model binding. We can copy this over and do the same thing for our task update request so we can just go ahead and pop that in there but just change over the action just inside of here.
02:35
So we should now not be able to go ahead and delete a task that doesn't belong to us. Let's just start to write an end-to-end test for this we're not going to end up creating an end-to-end test for this because it just doesn't make sense but I'm going to go through the flow of this so you can kind of understand why it doesn't make sense for this kind of thing.
02:54
Okay let's go ahead and make out a test then so let's say in fact we could probably do this for the task destroy test that we've already got here so let's go ahead and just work on this one but we won't end up using this test. So let's say it cannot delete a task if it does not belong to us something like that what would we need to do? Well we would need to go ahead and create our
03:18
user so let's use the user factory here create our user let's bring in browse just so we don't need to copy and paste this because we're going to try and be as quick as possible in demonstrating this so we want to log in as the user visit the task index. Now the first issue that we have with writing end-to-end tests for actions like this is the user will never see
03:44
tasks that don't belong to them if we head over to the browser I'm never going to see in this list within the app tasks that don't belong to me and we you could even write a test for that on your task index test so because of that what we're going to have to do is set this app up in a way that visually we see the completely wrong thing now the problem with that is that we can't do that
04:06
so if we head over to our task controller under our index method this is only showing tasks for that user so actually we can't really without any kind of hacking of this build this test out with an end-to-end test what we would have to do is go in and actually modify our code for this test to go ahead and work which obviously we're not going to do because we're just testing out what
04:31
we actually have already written so really at this point we can't go ahead and create our test for this because even if we create some tasks that go ahead and assign the task to a different user we can't display them in the browser so we're sort of stuck here so what do we do instead well let's get rid of this entire test we go ahead and create a feature test for this and if you are new to
04:53
testing I'm going to go ahead and show you how to do that now so let's go ahead and create our test for this so let's say pest test controllers and task controller test we'll just keep this as one overall controller test so let's go over to task controller test and this looks pretty similar but now we are actually sending a request down like a get post patch delete request whatever we need to
05:13
do so now we can say it cannot delete tasks that do not belong to us and we can go ahead and set this up pretty much in the same way so we can go and say user factory and create and then we can go ahead and send a delete request down to a specific root which we can still use our root helper here let's say tasks and destroy we need to pass a task in here so we basically need a task that belongs
05:43
to another user so let's go ahead and create that out now with our factory we'll say task factory and create but we want this to be for a completely different user so we can just pass in a new user factory instance in here and that's created a task that doesn't belong to this user what we can do now is slightly change this around so let's change this to acting as so let's say acting as that's
06:04
completely different from login as because the mechanisms are completely different when we send what is effectively just an api request to this page so we're going to act as this user and then we're going to go ahead and send a delete request down so we can just take that in here rather than using this when we're using pest we have these helper functions that map up really nicely
06:24
then we can go ahead and say assert forbidden and that should pass so let's go ahead and run this one in isolation this is going to be a completely different way of running this we can just use pest on its own to do this so let's go ahead and filter that down and yeah sure enough it passes but of course over in our task controller if we didn't have this form request in here which
06:49
authorizes this then our test is going to fail great okay so let's just fill out one more test here just for clarity and that will be to update and it will pretty much be exactly the same thing so cannot update tasks that don't belong to us we do exactly the same thing we have a user who's performing this action we create a task that doesn't belong to us but this time we go through
07:11
two tasks update we actually let's see what we used here so if we go to update we used a patch here so let's go over and change that to patch we pass the task in but now we are going to pass the title that we want to update to so let's just say new title and again we're going to assert forbidden so with our pest test now we can run this and we can either go into a specific directory so let's
07:36
go into our controllers directory and let's go ahead and find that task controller test both of them pass they're a lot faster and of course this is a lot more appropriate so the general advice I would go with is always try to write feature tests but if you have any interactions on the page or you want to test the user flowing through your application for example clicking create task let's
08:01
say that is a critical action and we need to know that clicking this button goes through to this page we can't do that with a feature test necessarily you can do but it depends on how you have things set up if you want to test the flow between things end-to-end tests are really good as well as that things like this we couldn't use a feature test to test this toggle functionality and we couldn't
08:25
use a feature test to check when this is updated when we hit the enter key it actually updates something so go ahead and try to write a feature test first they're faster they will give you faster feedback and then if you have any critical flows or interactions that you can't use with feature tests then go ahead and reach for end-to-end tests

Episode summary

In this episode, we dive into situations where using Laravel Dusk (or end-to-end browser tests in general) just isn't the best option—especially when it comes to testing things like authorization rules.

To get hands-on, we start by setting up proper authorization for updating and deleting tasks in our app, making sure that only the rightful owner of a task can modify or remove it. We use Laravel policies and form requests to handle the authorization logic cleanly.

Next, we try to write a Dusk test to confirm that a user can't delete or update someone else's tasks. But we quickly hit a roadblock: there's no way for a user to even see tasks they don't own in the UI, making an end-to-end test for this scenario both pointless and awkward to set up. We'd basically have to hack the app just for the test to work, which is a big red flag.

Instead, we ditch Dusk for this use case and write straightforward feature tests instead. These tests directly send HTTP requests as different users and confirm that forbidden actions are properly blocked. They're faster, more reliable, and fit this scenario perfectly.

The takeaway: always try to start with feature tests—they're quick and cover most backend logic elegantly. Reach for Dusk only when you need to verify frontend flows (like users clicking buttons or navigating pages), not backend restrictions that aren't even visible in the interface.

Episode discussion

No comments, yet. Be the first!