Now of course this is completely optional and things are going to get a little bit hacky around Pest but it's just going to go and show you the power of Pest and how you can customize it. So remember that we did a very similar thing over in our login test. We had here expect the user to be redirected and we had a user that was signed in and we want them

when they access the login page to be redirected when they hit that. Basically here we don't want users who are signed in to access the login page. Now we're going to do a similar thing here but for users that are not authenticated. So if a user hits the store test for creating a book and they're not authenticated we expect them to be redirected as well. Let's just scaffold out how we would want

this test to look. So let's go ahead and run this test first of all specifically. So feature and book store test and of course that passes and let's change this up to something that looks a little bit nicer. So we want to say maybe expect guest and we'll see why we need to do this in a minute to be redirected for and then we want to make sure that they're redirected when they post

through to books. So you can change up the syntax of that if you don't like it but that's kind of what we're going for and of course you can use this as inspiration to create your own custom assertions. Now at the moment of course this is going to fail because we have an unexpected expect guest method. Now the reason that we're doing this is if for example we were to say

something like expect nothing to be redirected let's just see what happens when we try that. You can see that we've got too few arguments through to expect. We need to pass something through to expect to be able to be passed through to this to be redirected for method that we created earlier or this custom assertion that we created earlier. Now let's just remind

ourselves over here when we die dump on this value what we get. So let's die dump on that and then let's add just something in there and if we come over and give that a refresh we get abc dumped out. Now the only problem with this is we need to pass something into here which doesn't make sense because we are trying to test that if the user is not authenticated they're redirected

so we don't just want to put null in there because then it sort of doesn't make the test read nicely. So we're going to say expect guest so this is going to be responsible for basically passing nothing through to that expectation method. Now to achieve that we're going to come over to pest let's get rid of this die dump and we're going to come down here we're going to create an entirely

new function to allow us to create this. This is kind of like overriding the normal expectation so let's go ahead and say expect guest and in this we're going to return test which we can then chain on the expect function and we're going to pass null in so now this is hidden away rather than us have to do expect null e.g. a non-authenticated user to be redirected so that just

adds sort of like a little helper that we can use in that case so it's like an expectation but passing through null. Okay let's just go ahead and try this out and of course it fails because if we just have a look inside of here we expect to pass an authenticatable thing through to here acting as this needs an authenticatable thing to be able to work so if the value that we pass in

here is null we don't want to act as that user because it's a guest so we can just add a little if statement in here and just say if the value is empty or null then we want to return and do something slightly different we just want to chain on from test we still want to hit that same method we still want to hit that same url and we still then want to assert that the status

is 302 and we could sort of assign this and then do all of these assertions at the bottom we might just tidy this up in a minute but basically if there's no user just try and hit that url that we're requesting and check that we're redirected let's run our test again and just see what happens and sure enough it passes so a really sort of simple change just sort of moving everything

to this custom assertion but just helps to tidy our tests up and then hopefully when you're writing these it makes it that little bit easier to write these tests which are pretty much going to be on lots of pages within your app so we could tidy this up if we wanted to and we could assign the request here to either this or this or the test response for example that's probably

more appropriate because we have a test response coming back from this so we could set this to null to start with and then we could in here assign the response to this get rid of the assertion so that's going to be the response eg with an unauthenticated user and then otherwise and again this gets a little bit messy but we are abstracting it away so it's not the end of the

world we're going to use acting as so we're going to assign that otherwise and of course you can chop and change this if you want now we can just say assert that the response we get back based on whether the user is signed out or signed in has a status of 302 just rerun this just to make sure we didn't break any of our other tests let's run all of them together and that looks good and as

well what you could do is assert a redirect in here just do whatever you want to make sure it goes through to the right page it's entirely up to you but that's just a way that we can just fiddle around with pests just to make our lives a little bit easier when we're writing really repetitive tests like this and of course we also have our book create test as well so we could just easily

change this over now and just say that we want to expect a guest is redirected for books create and that's a get so we don't need to provide that method let's again run rerun all of our tests and we've got green so an optional refactor there but something that might help you out when you're writing tests like this over and over again