If you've ever had to write tests for jobs, you're going to love this. I have a job here, UploadVideo, and it's responsible for taking the given videoPath and uploading to Vimeo, the video hosting service. Let me briefly take you through the logic. First of all, if the file doesn't exist or is empty, then we release this job back onto the queue and try it again a minute later. Keep that in mind. If the video does not exist, we release back onto the queue. Then we tell Vimeo that we intend to perform an upload. If the response comes back and we learn that the approach is incorrect, there's nothing

Then we tell Vimeo that we intend to perform an upload. If the response comes back and we learn that the approach is incorrect, there's nothing we can do to make it work, so we're just going to delete the job off the queue and end early. Then we gradually upload the video to Vimeo using the TUS technique outlined in the API documentation. Once that's complete, we're going to verify that the upload worked. However, if in verifying the Upload Length is not equal to the Upload Offset, that would indicate that something's gone wrong. So that being the case, we fail with Video Upload Failed to Complete like so, and we

indicate that something's gone wrong. So that being the case, we fail with Video Upload Failed to Complete like so, and we finish there. So to summarise, there are four possible states our job could find itself in. One is that the job went fine, everything worked, happy days. But it could also be released back onto the queue, it could have been deleted, or it could have failed outright. Have you ever tried to test for those three circumstances, failed, deleted, released? Historically it's been incredibly annoying. Like here's my test for checking that the job is released back onto the queue if the

Historically it's been incredibly annoying. Like here's my test for checking that the job is released back onto the queue if the video file is not available. I create the job, I pass in a file I know does not exist, and I handle it. Logically, I know that this is correct, but how do I actually make the test pass? Perhaps I do something like job, reach for the underlying job in the queue, I know there's an isReleased method, let's run it. I will get a failure, called to a member function isReleased on null, because we're not actually dealing with a real queue here, we're just handling the job directly. Laravel 11 comes to the rescue because there is finally a way to handle these three scenarios.

dealing with a real queue here, we're just handling the job directly. Laravel 11 comes to the rescue because there is finally a way to handle these three scenarios gracefully. Basically, when we create a new instance of the job in our test, we can chain on a withFakeQueueInteractions method like so. Then we handle the job as normal, and now we have access to some assertions, such as assertReleased, assertDeleted, and assertFailed. Let's use assertReleased for example. AssertRelease now, add a minute to match what we have inside our job. And then let's run it.

AssertRelease now, add a minute to match what we have inside our job. And then let's run it. And now it passes. Let's take a look at another example. We want to check that the job is deleted if the approach is not TUS. So I'm using HTTP::fake in order to actually return an incorrect response. Logically, I know it's correct, but at the moment if I run this, nothing's actually happening. However, I can chain on that new with fakeQueueInteractions method, and now instead of assertReleased, I can use assertDeleted. Run it.

of assertReleased, I can use assertDeleted. Run it. And it passes. And then finally, we have it fails if the job upload verification fails. I've done everything else correctly. I've stubbed out a fake sequence of HTTP requests to Vimeo. I create my job. I handle it. Well, again, let's say with fake queue interactions, and now I can say assertFailed. Run it.

Well, again, let's say with fake queue interactions, and now I can say assertFailed. Run it. And it passes. This is such a welcome addition to the framework, because historically, testing these edge cases in jobs has been gross. You've either had to build your own mocks or fakes, or even worse, ignore the problem entirely and just hope everything works in production. But now with this super simple withFakeQueueInteractions method, you have all of the insights you need to make sure that your jobs work exactly as expected in your tests. Well there we go.

you need to make sure that your jobs work exactly as expected in your tests. Well there we go. That is Laravel 11 in a nutshell, and I'm sure you'd agree, there are so many exciting things to dive into. Feel free to come back to these videos whenever you want to remind yourself of what's on offer. And remember, if you're starting a project from fresh, then you get to enjoy that slim line framework, removing all of the junk and allowing you to get to building what you want quicker than ever before. But even if you're just upgrading from Laravel 10, and remember, you don't need to change your structure at all to do that, you're still going to benefit from so many features that

But even if you're just upgrading from Laravel 10, and remember, you don't need to change your structure at all to do that, you're still going to benefit from so many features that Laravel 11 brings to the table. If this series went a little over your head and you need more support learning Laravel, be sure to check out Jeffrey's 30 Days to Learn Laravel course right now on Laracasts so that you can get up to speed with what I believe is the greatest framework on earth. I'll see you soon.