So, let's go ahead and run php artisan test and see what damage we've caused with our slug updates. Oh, not bad. Six failed. Let's take a look through. So, in the StoreTest, redirecting, obviously, we've changed the logic of the redirect, but we haven't changed our test. Not a problem. The update test for a Comment, exactly the same thing. The same for the update test for redirect, the same again.

The update test for a Comment, exactly the same thing. The same for the update test for redirect, the same again. It's all the same thing. It's basically the fact that we've updated the logic in the front end, but we never updated our tests. It's not that the logic is broken, it's that our tests now show old logic instead of new logic. So, let's work through these. We have the CommentController destroy test. Let's find the failing tests here.

We have the CommentController destroy test. Let's find the failing tests here. Here's the show page. We assert the redirect here, but we actually want to go to comment, post, and then we want the show root method. So, let's run it again. Now we have one failing test. Come down here. Again, we assert a redirect, but we should be asserting a redirect to comment, post, show root, and once again, we want to pass in this little page parameter, like so, into

Again, we assert a redirect, but we should be asserting a redirect to comment, post, show, root, and once again, we want to pass in this little page parameter, like so, into an array. Get rid of that. Hopefully, those tests now pass. Yes, they do. On to the next failing file. So, I think the store test had some failures. Yep, it redirects to the post page had a failure. So, instead of checking that, we want to check for post, show, root, and we can get rid of

Yep, it redirects to the post page had a failure. So, instead of checking that, we want to check for post, show, root, and we can get rid of this root here. Let's rerun those tests. Now passing. Update test. And two failing ones again. This should be fairly straightforward, basically the same as last time. So, assert a redirect to comment, post, show, root, and then we'll get rid of the root helper. And we have the redirect check as well, again, with the page.

So, assert a redirect to Comment, Post, show root, and then we'll get rid of the root helper. And we have the redirect check as well, again, with the page. So, let's get rid of that. And then we'll get rid of the root helper and we'll say Comment, Post, show root, and rerun the tests. Nice. Let's rerun all the tests, php artisan test, if I can spell. And I think we still have one failing here. PostController store test. All right.

PostController store test. All right. So, PostController store test. Let's find out which one fails. Once again, it's the redirect. And we're actually wanting to go to post latest first. And we can get rid of this. And then we can just chain that show route method onto the end. Rerun. And now everything should be passing.

Rerun. And now everything should be passing. Let's double check. Boom. Awesome. So, we're back at a clean slate. The tests are passing. I would actually guess that if we go into the web file and we now remove this optional parameter, and then we run the tests again, everything will... Oh, no.

parameter, and then we run the tests again, everything will... Oh, no. We have a few failures here. Let's take a look. So, missing required parameter in the show test for a PostController. So, let's go to the show test. It can show a Post. Okay. Yeah. So, when we're generating post show routes in our test, then it's failing.

Yeah. So, when we're generating postShowRoute in our test, then it's failing. So, here, instead of doing that, we can say postShowRoute. And we can do the same thing underneath. So, here, we'll say postShowRoute. And then here on the bottom, we want to do the same thing. So, postShowRoute, like so. Those tests now pass. Let's rerun the whole test suite again. Nice.

Let's rerun the whole test suite again. Nice. So, we've removed that optional parameter, meaning that every single show root URL will always include the title as a slug. One step closer to exactly what we want. Now, we never actually added tests for any of the functionality. So, one thing we need to test is this show root method on the Post model. And we also need to test the redirect that we've introduced on the show endpoint. We'll start with the model. So, if we go to the PostTest, we can add a test down here.

We'll start with the model. So, if we go to the post test, we can add a test down here. So, let's say it. And we want to test that it can generate a route to the show page. So, how do we do this? Well, let's create a Post, first of all. PostFactory. We'll call create. And then down here, we can say expect post show route to be. And we'll manually use the route helper to confirm that they're the same here.

And then down here, we can say expect post.show root to be. And we'll manually use the route helper to confirm that they're the same here. So, we're going to go to post.show. And we pass in the post to start with. Then we pass in string slug post title. All right, run that. And it passes. But we also want to check that it can generate additional parameters, or query parameters, we'll call it, on the show root. So, we'll test that functionality next.

or query parameters, we'll call it, on the show root. So, we'll test that functionality next. I can copy and paste the majority of this. But then what I want to assert is that if I add, say, page equals 2, then the toBe endpoint is going to be that root, but with an added page parameter as well. So, page equals 2. And when we run that test, you can see it still passes. Just to make sure that it's not passing for a reason other than the fact that it works,

Just to make sure that it's not passing for a reason other than the fact that it works, if I remove this and then rerun that test, you can see that it fails because the two strings are no longer equal. But if I add it back in, everything should work as we know it does. So, that's our show root test. We need to check our show test as well on the PostController. So, here's our show test. And what do we want to say? It will redirect if the slug is incorrect.

And what do we want to say? It will redirect if the slug is incorrect. So, let's open up our test closure. And inside here, we want a post. So, we'll create a post. And let's make the title something very obvious, like Hello World. That'll make it nice and easy to understand what the slug should be. And I'm going to make a GET request. And I have to do this manually, right? So, I'll make a GET request to the root post.show,

And I have to do this manually, right? So, I'll make a GET request to the post.show, passing in the post, passing in the slug that we want to go to. So, in this case, I'm going to say foobar. And then I'd assert a redirect because we've gone to the wrong root. And I'd assert a redirect to the post show root, right? So, let's run that test. And yeah, you can see that it passes. But if I'd put Hello World here instead, which is the correct format, then there would be no redirect.

But if I'd put Hello World here instead, which is the correct format, then there would be no redirect. And you can see that is the case. There is actually a little bit of functionality that isn't tested here. And that's the fact that we've made use of request path instead of just comparing the URLs, so that any query parameters are passed on to the regenerated root. That should be pretty simple to implement. I could say page is two here. And then in the show root, I can pass pages two as well.

I could say page is two here. And then in the show route, I can pass pages two as well to check that that query parameter has been passed along. And the test passes. So, very simple to actually add the test for this functionality. And I think it is important you add this test because it will allow us to refactor down the line as we see fit. I think it's too early to abstract this to anything other than what it currently is. But if we were to reuse this in other places, we might want this as some form of middleware.

But if we were to reuse this in other places, we might want this as some form of middleware to take it out of the controller and allow us to place it on different routes. For now, I think it's absolutely fine there. We use it in one route. No need to abstract too early. But the fact that we have our test in place means that we are covered should we want to change it down the line. Let's just run the entirety of our test suite once again to make sure everything's happy.

Let's just run the entirety of our test suite once again to make sure everything's happy. It absolutely is. That's wonderful news. And we have a working implementation. That was so, so simple. A lot easier, a lot less issues than if you were to try and identify the Post by the slug itself. You save yourself so many headaches by still continuing to use, say, an identifier, the primary key in this case, and allow the slug just to be there for SEO purposes,

say, an identifier, the primary key in this case, and allow the slug just to be there for SEO purposes, just to be a little bit of additional information without being the primary source of identification. It's also incredibly simple to add the functionality to do with redirecting if you get an old URL or the incorrect URL. So super neat, super cool. I think that's a great addition to our forum, and we're ready to push forwards.

and we're ready to push forwards.