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

is that this button label could change at some point in the future. Now what that is going to do is just immediately break our tests. Remember, we're not posting down to an endpoint, we are physically pressing a button, and we've had to label this in the way that it's rendered within the browser.

The CSS selector that we've used with the tailwind has gone ahead and uppercased this, so we've had to specify it here. What happens if that class is removed and this becomes normal case? Well then, in that case, our test will fail as well.

So what we want to do is, from the start, make sure that we are writing tests that are not too brittle and sensitive to UI changes. Now the first thing that we're going to talk about before we fix this issue here, is the fact that we've used hash selectors here.

Now for this specific example within the Breeze starter kit, we've had to use a hash to signify that this is an ID. If we head over to the register page and take a look at the input for the name, for example, you can see that it doesn't actually contain a name on here like we would usually add.

Now it's probably a good idea to always include these, but if you do have a name attribute on any of your inputs, you do not need to use a hash selector or a class selector to try and identify them. Let's go through each of these and update it.

So let's go down to the email address. We'll add a name in here of email. Let's go down here to the password and we'll do the same here. So we'll set a name of password.

And last but not least, we'll do the same for the password confirmation. So we'll set a name here of password confirmation. Now, as long as we do have a name associated with our inputs, we can get rid of the hash selector here and this will automatically look this up by name.

Let's go ahead and run this test and see what happens. So let's run this register test. And sure enough, we should get green. So that's passed in exactly the same way.

Now, just be careful with this because, for example, if we just went over to our name input and got rid of name, what's going to happen here is if we do use name and we don't have an attribute on that field, it's going to go ahead and fail because it's not going to be able to locate that selector.

So you can see here, if we just go up here, no such element and the element is within the body and it's an element called name. So it's not been able to find that input. So let's go back over and change this because I typically always include a name on my input,

even if I don't need to, for example, because we're working with view here, everything is already attached to the form at the top of the page just here. So everything's getting linked up and then posted through. OK, so let's work on the most important one.

And that is this register button. And we're going to look at dusk specific selectors. So there's a couple of ways that you can approach this. So let's find that register button and let's go ahead and have a look here.

So there's a couple of ways that we could do this. We could assign an ID to it. So if we were to assign the ID of register to this or register button, probably be a better idea. What we could do is easily target that within our register test. So when we use this press method, this will take in the button name, whatever it is, it will resolve that.

So it will look for that element within here. And this could be anything. So in our case, we could do hash register button. Let's go ahead and run our test. And as long as I can find that we get green. So that's one option. But specifically, I want to talk about dusk selectors.

And there is a trade off here. So a dusk selector looks like this. Let's go to our register page. Basically, it's just an attribute on any of the elements that you have on the page. It could be on a single div that you want to target and look inside. It could be on a dropdown trigger, could be on a button for a form. It could be an element name.

So it could be we could attach these to the name, the email, the password. And this basically allows us to very conveniently give names to our elements to identify them within our texts. And as long as these don't change, which they shouldn't, then you're always going to have the same name. So in our case, I'm going to call this register button. So it's pretty much the same thing as adding an ID.

What we can do within our test now is rather than target this by a hash, we can target this by an app symbol. So we're basically creating a unique name for this element, which is probably not going to change even if the text inside of this changes. So it now doesn't matter what text is in here or how it looks on the page. And that's going to go ahead and pick that button up for us. It's going to find that selector and it's going to pass.

Now, as I said, there's a tradeoff here, and that is what you're doing is within your actual code, you're polluting your elements with this dusk attribute. Now, the amount of times that someone's going to be looking at the source of your page and see these, we don't really care about that. So when I say polluting, I just mean it's adding some extra things specifically for our test that we wouldn't normally need.

So I prefer this method because it allows me to easily look at the source code. It allows me to, when I'm actually on the page itself, go ahead. And when I'm writing my tests, inspect any particular element I need and say, oh, yeah, that's called register button. Then I can hop straight over to my test and identify it properly.

So I really like this method, but obviously it's not going to be for anyone. So you can decide how you want to target these elements. You will agree, though, that it's a lot better than having that uppercase register text in there based on how this is styled out in the browser. That means now that if this changes at all, so register now, for example, it's not going to go ahead and break our tests.