Okay, let me focus your attention on tests for a moment. So I'm going to open up the exampleTest.php that's included with Laravel. And let's just do an example validation test. So a Post requires a title. So let's imagine we're doing a POST request. We want JSON in response to posts. But I'm not going to give it a title. Well in that case I would expect a status code of 422, right? Okay, so let's go ahead and run that. And sure enough, we expected a 422, but we got a 200.

Okay, so let's go ahead and run that. And sure enough, we expected a 422, but we got a 200. Okay, let's take a look at our routing. So I'm going to go to my routes/web.php file. I have a basic resource in place and a PostController. And you can see I have an empty store method here. So now at this point, we want to validate the request to be specific that a title is in fact required. Okay, so if I run that again, now we do get green. All right, so that's a basic validation test.

At some point, an exception could be thrown. Something went wrong. Now when this happens, the way Laravel handles exceptions automatically for you can actually confuse you. So anyways, let's run this. We do it again. And now, yeah, so we expected a 422, but we got a 500. But you'll notice we don't have any help here. All right, thanks for the 500, but why exactly did we get that?

But you'll notice we don't have any help here. All right, thanks for the 500, but why exactly did we get that? So in these situations, you have a couple choices. When you're debugging alone, you can call the dump method. So basically the way it works is when you make your request, you're going to get a response object in return or in response. And that will be an instance of TestResponse. So you can always filter through all of these assertions to see what you need. Anyways, so what you could say is on the response,

to see what you need. Anyways, so what you could say is on the response, go ahead and dump all of the contents of the response. And that should contain the exception that was thrown. So if I give this another run, yeah, now we can see at the very least, all right, something went wrong. We had an exception in HostController on line 11. And now at the very least, you have a little more debugging ammunition.

And now at the very least, you have a little more debugging ammunition. Now, another option, if we bring this back, would be to disable exception handling. And this is what's new in Laravel 5.5. Now, if you've watched many videos at Laracasts, this is something that I've implemented on my own. I learned it from Adam Wathan, who added a little anonymous class to assist with this, but now it's part of core Laravel 5.5.

who added a little anonymous class to assist with this, but now it's part of core Laravel 5.5. So I could say this without exception handling. So by default, Laravel handles exceptions and converts them into the proper responses. But yeah, once again, sometimes you don't want that to be converted. You actually wanna see the exception that was thrown. So now if I disable exception handling, yeah, you're gonna see something totally different.

So now if I disable exception handling, yeah, you're gonna see something totally different. So once again, before we run it, all we get is a 500 with no information. But if we disable exception handling, and even if this is only a temporary thing you do, sometimes you want it permanent, and then sometimes you're just debugging and you add it there temporarily. Anyways, once you add it in,

and you add it there temporarily. Anyways, once you add it in, now it doesn't get turned into the status code. We can actually immediately spit out the exception that just took place. And now once again, you have your full trace where you can figure out what went wrong. So now in this case, yep, PostController, we can see some random bit of code we ran ended up throwing an exception.

we can see some random bit of code we ran ended up throwing an exception. So we fix that or we catch it. We do whatever we need to. And then once we run it again, well, if we run it, you'll see that now we get a ValidationException. So this is the thing to keep in mind. Sometimes you will want to add this only temporarily while you're working through an error that you see.

Sometimes you will want to add this only temporarily while you're working through an error that you see. But in this particular case, we're seeing a validation exception because we immediately threw the exception. When in reality, at this point, we do want Laravel to convert that exception to the proper response, which would be a 422. So if we get rid of that now and run it, we're back to green. So yeah, in Laravel 5.5,

So if we get rid of that now and run it, we're back to green. So yeah, in Laravel 5.5, you have without exception handling. You can also turn it off and then maybe somewhere down the line in your method, you could turn it back on by saying with exception handling. You can find all of these within the interactsWithExceptionHandling trait on your TestCase. So you'll see right here,

on your test case. So you'll see right here, if you want to see what's going on. So when we disable it, yeah, so we basically take the ExceptionHandler instance that's bound in Laravel's container and we've replaced it with this anonymous class where we automatically throw the exception right away. And that's it. Now, of course, like I said, you can turn it off,

So in closing, if you ever come across these situations where the response from your test isn't giving you enough feedback and you really need to drill down further, maybe consider disabling exception handling entirely. And again, this would also be true if you're specifically testing for an exception to be found but in the actual project, Laravel catches that exception and then it turns it into a redirect or something.

Laravel catches that exception and then it turns it into a redirect or something. If you really want to assert against that exception, disable exception handling, and then you could use a php assertion like expectException or something like that. Anyways, try to commit this to memory, play around with it, and then I promise when you're writing tests, you'll come across good use cases for this.