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
13. Testing validation errors

Episodes

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

Transcript

00:00
End-to-end tests are probably not best suited for validation. We can do that by just sending a request down to our store method within our controller and asserting that we get a session flashed with the error message. But I'm going to show you how to do this now just in case you need to for any reason
00:15
and then we're going to look at a way to make our test as less flaky as possible. So if the validation message changes our tests don't break. There's a couple of ways to do this so let's dive in. Okay so let's go ahead and create our new test for our task store.
00:30
So let's say it fails if a title is not provided or whatever you want to say. And let's go ahead and start to send a request down. So let's say browse, create our closure in here with our browser. And let's go ahead and bring in a user here because we know that we need to be logged in.
00:50
Let's go ahead and create out a user in here bring them into the scope of this closure and let's go and make a request. So let's say browser and we need to be logged in. So let's say log in as user.
01:05
Now we're going to go ahead and visit a specific page that is going to be our task create page which is tasks slash create. Just while we're here let's talk about what we've been doing so far. We've been saying something like tasks and create.
01:20
Whether you're writing normal feature tests or end-to-end tests it's probably always a good idea to rather than provide the url use the root helper with the name of the root that you've given. Again that means if your urls change then your tests are less likely to break.
01:39
Okay so we're going to go ahead and visit that page and what are we going to do? Well we're just going to immediately press the submit button. So let's just find out what that's called create task button. So let's go ahead and press that button immediately
01:52
and why don't we just run this test just to make sure everything is good so far and then we'll go ahead and assert this. So let's say php artisan pest and dusk filter and let's go ahead and run this test. Okay that passed with no assertions.
02:07
What is the assertion going to be? Well it's that we just see a piece of text. Now I don't know what that is at the moment so let's go ahead and click create task. Now at the moment we've got the required attribute on this field
02:18
so what we're going to do is just get rid of that for now. Again you probably wouldn't write end-to-end tests for this unless you didn't have that required attribute in there otherwise you'd write a feature test to post through.
02:30
But let's go ahead and just get rid of that for now. So let's get rid of this required attribute and let's have a look. Okay so we've got a error message the title field is required. Of course also in some circumstances you'll want to show a validation message.
02:43
For example if you were checking that a username was available and you were sending a request down to check this we might look at that later. So what do we need to do here to test this? Well we want to wait for some text.
02:56
We don't want to see some text because we know that we're sending a request down and this is potentially going to take even a couple of seconds. So we want to wait for some text which technically creates our assertion and the text is the title field is required.
03:12
Now at the moment this test isn't great because the validation text could change at any point which is going to break our test even though technically it should have passed. So we'll look at that in just a second then I'll show you the other method that we can use to test this.
03:26
Okay let's go ahead and run that test again and of course this passes. Okay let's look at the first way that we can improve this and that is the text that we have just here and how we can get around this being very static.
03:41
And that is using a language file. So if you wanted to the first thing to do would be to go ahead and publish your language files. So let's say lang and publish. What that's going to do is create out a lang directory in here with our validation messages.
03:57
For required we could go ahead and change this over now. I'm not going to change it but even if you did once we've done this update your test will still pass. So this is the attribute field is required.
04:08
So how can we make this a little bit better? Well directly within our test kind of like what we've done for our root we can reference the language helper to go ahead and output this message. Then even if it changes within that single source of truth
04:22
within our language directory it's still going to work. So to output a language value we use double underscore that's the function name and then we just reference the validations. This is validation and required.
04:35
Now because this contains an attribute placeholder just in here what we need to do is we need to provide this in as the second argument here. So attribute as the key is the name of the thing that we want to change over and we know that this is title this is what we're testing for.
04:54
So this will build up the string that we previously just pasted in. Let's go ahead and run our test again and not publish our language files again. Let's run our test again and see what happens here and you can see it still passes. But now if you are using validation let's go ahead and change this over.
05:10
Please fill in the and then let's get rid of field is required and we should get a pass because we're now referencing our language files. So that is one way that you can do it but I appreciate that not everyone is going to be using language files.
05:29
So how else can we test that this works? Well what we could do is go over to create and regardless of what our input error is we could just make sure that this appears. On here if we just take a look at the input error component
05:45
this will only show this if we have a message a validation message come through. So what can we do? Well we could either go ahead and take the component itself and add a dusk attribute to this or probably more appropriately we could add a dusk attribute specifically to this input error
06:07
and that will pass the attribute down and apply it to the overall wrapper we have inside of here. So we could say something like title error or title let's make this a little bit more descriptive validation error. Now we can take this and we can say something like this
06:23
so let's just comment this one out and keep it there for reference and we're going to say wait for and we're going to pass in that selector which is just at title validation error. So now regardless of what is in there for example you might be using custom validation
06:38
messages within a form request or something this is still going to work. Okay let's go ahead and run the test again and we should get green because that element is now there we know that that element itself provides the validation message.
06:52
So what I mean now is that if we go over to our task controller for example let's actually change this over to a form request so let's go ahead and make a request out here and call this task store request we'll switch this over and refactor it and just make sure that our tests still pass.
07:08
So let's go ahead and grab our validation errors just here and or our validation rules let's go ahead and change this over to request validated and let's go over to our form request set authorize to true since we are not working with any authorization rules here
07:26
and let's go ahead and pass the rules back into there. That's still going to work so let's run our test again and yep sure enough we get green but now we can change this over to pretty much anything we want. So let's go ahead and apply a custom message specifically to this title
07:44
so let's say title.required and let's say you need to enter a title so something completely different so now that we are checking specifically the presence of the actual validation error we don't care what the text inside of it is we just want to know that it is shown. So let's go ahead and run our test here and we should still get green.
08:08
So there are a couple of methods that you can use to test for validation within your end-to-end tests not always appropriate because we can create our separate test to just post down to that and make sure that the section has that key in there for the validation message but sometimes in some cases you will want to go ahead and test for validation.

Episode summary

In this episode, we dive into testing validation errors in our end-to-end tests. While feature or unit tests are usually better for validation logic, sometimes you just need to check validation behavior through an actual browser flow. We'll walk through how to do that, step-by-step.

First, we create a test that checks if the app fails whenever a required field (like a task title) isn't provided. We mock a logged-in user, visit the create page, and immediately hit the submit button with missing input. When the validation error shows up, we assert its presence.

But what about when validation messages change? Hardcoding error messages is fragile because any text change breaks your test. So we explore two ways to make tests more reliable:

  1. Use language helpers: Instead of hardcoding error strings, reference the Laravel language files directly in your test. So if the validation message string changes in the source, your test still stays in sync.
  2. Detect error components: Instead of checking the text, assert that a specific validation error component exists in the DOM. For this, we add a custom Dusk attribute to the validation error display. The test then just waits for that element, regardless of what text it displays—perfect if you use custom validation messages.

We finish up by showing how this approach continues to work even if you switch validation to a dedicated form request or customize your error messages. The idea: focus on the presence of validation feedback, not its exact wording. That way, your tests are less brittle and easier to maintain!

Episode discussion

No comments, yet. Be the first!