All right, let's return to the registration page from the last episode, and we'll have a look at this test here. I want you to notice that at no point do we actually interact with the register page. Instead, we immediately start at the post endpoint. So if I hit the endpoint to register a User, and I provide this data, then you should be authenticated. But again, notice how I never actually said, go to the register page, and type into this form, and press the register button. In fact, we sort of bypass the front end entirely. Which means, if I were to go to that register page, and yeah, here's that email section, let's comment that out. So now, we're not even asking for an email input, even though it's required. But, if we run the test, it still passes, because once again, we never actually interact with the page. So you can see how that might be a problem, and you have to decide, when is it okay to bypass the page? When am I specifically focused on testing

once again, we never actually interact with the page. So you can see how that might be a problem, and you have to decide, when is it okay to bypass the page? When am I specifically focused on testing the endpoint? And on the other hand, when am I focused on ensuring that the user's interaction with my system works the way I expect? I'll give you another example. Let's bring back the email, and here's that little test we wrote that asserts that we have session errors. Now, it is true on that registration page, right down here at the, where is it? Where are you? Here it is. This is where, it's a Blade component for showing validation errors. But again, if I were to remove that entirely, if validation fails during registration, the user will not be notified at all. There shouldn't be an ounce of feedback. And yet, the test that ensures a validation error is thrown still passes, because we do have validation errors in the session, we just never rendered them in the

There shouldn't be an ounce of feedback. And yet, the test that ensures a validation error is thrown still passes, because we do have validation errors in the session, we just never rendered them in the view. So in these cases, you might consider writing feature tests that work with an actual browser, or that interact with a browser in the same way that a user would. And luckily, Laravel has a first-party tool to help with this very thing. So let's give it a shot. composer require laravel/dusk. All right. Next, as part of that, we should have a new dusk command. Yeah, here's your namespace here. You probably won't need to use too many of these, but to get started, let's run dusk install. All right, we're ready to go. So now I can create a new test by saying dusk make, and why don't we reproduce that registration test so you can see for yourself. All right, if I switch back in my sidebar, you'll now find a new browser section here. And a bunch of directories, you can ignore.

reproduce that registration test so you can see for yourself. All right, if I switch back in my sidebar, you'll now find a new browser section here. And a bunch of directories, you can ignore most of them. Here's a directory for screenshots if your tests fail. Here's a directory for console about logs, if you need those. And then you have an example test, which I'm going to delete. And then the RegistrationTest that we just created. Okay, so let's just have a quick look. Browse. Okay, that sounds like we're opening a browser. And then we visit a home page, and then we expect to see Laravel. So again, notice it's a little bit different. Let's give it a run. php artisan dusk. And it passes. Okay, so it feels the same, but there's something different going on here. You didn't see it, but behind the scenes, a phantom browser is being open. And if you saw references to ChromeDriver being installed just a minute ago,

going on here. You didn't see it, but behind the scenes, a phantom browser is being open. And if you saw references to ChromeDriver being installed just a minute ago, that's what's going on here. So it's behind the scenes, but it's still taking place. So if I instead wanted it to say, uh, food, uh, say, foobar, or something like that, well, of course, it's going to fail, because at no point is foobar displayed on the welcome page that you see here, the standard Laravel splash page. Okay, so now, again, just for fun, let's reproduce what we had here in this feature test. And then we'll talk about the differences. And actually, we'll do this one test new users can register. Okay, switch back. And I'll say testRegisterNewUser. Okay. So we're going to open up a browser. And then once that browser is open, what do you want to do? Well, in this case,

Okay, switch back. And I'll say testRegisterNewUser. Okay. So we're going to open up a browser. And then once that browser is open, what do you want to do? Well, in this case, let's visit the register page. Or by the way, if you want to reference a named route, you could use visitRoute instead. So visit the named route. And then let's type into the input with a name of name. And we'll just do john doe. And then we're going to look for an input with the name of email, and we'll type john@example.com. And then two more, we're going to have password, myPassword123. And then copy that. And this will be passwordConfirmation. So yeah, I'm just grabbing those inputs from this form, email, password, and passwordConfirmation. Okay, so if I were to switch back, before we submit this form, let's just grab a quick screenshot. So we can see what's going on here. And I'll give it a name for the file. Alright, we give this a run.

on a browser, I expect that the route is now the dashboard, because at this point, you've signed up, you've been redirected, and you should now be on your dashboard. And why don't we add one more assertAuthenticated. So notice, the API is very similar. But again, the difference is we're interacting with an actual page, we're interacting with JavaScript, and everything hooked up to that maybe a confirmation modal shows maybe, maybe some kind of alert displays. With this style of testing, you get that interaction, and you can work with it. Whereas with a standard feature test, that never interacts with the page that never loads any JavaScript, you're getting something a little different. And by the way, that doesn't mean you shouldn't write these tests. I write countless tests like this, because often it's exactly what you need. This path here that skips the front end entirely is

that doesn't mean you shouldn't write these tests. I write countless tests like this, because often it's exactly what you need. This path here that skips the front end entirely is going to be so much faster than a companion test that opens a browser and fills out a form and waits for a modal to display. That version is always going to be significantly longer. And we'll have a look at that in a minute. Anyways, let's give this test a run. And I think it's going to pass. And it does. But now real quick, a little tip. If you're working along, and we run the test again, it's now going to fail. Yeah, the User is not authenticated. So can you think about it? Why did this test fail? The answer is because we already had a User registered in our system. So when we try to register a new John Doe, that triggered the validation. So it sounds like we need a way to say, reset or rerun my database migrations before

registered in our system. So when we try to register a new John Doe, that triggered the validation. So it sounds like we need a way to say, reset or rerun my database migrations before the tests. And we can do that by saying, use database migrations, like so. And you'll find that imported here. So now before each test, Laravel is basically going to rerun your migrations. And when it does that, any past state or table records will, of course, be removed. So now, no matter how many times I run this, everything's going to pass. Green. Green. But again, notice, for that simple test, that took two and a half seconds, versus, let's do this one here. phpunit, tests, feature, RegistrationTest. So a single browser test took two and a half seconds, whereas all of our non-browser registration tests ran in about a half second. And if we want to find, let's just narrow this down completely. Let's only run that single test. Okay, so that one ran