Up And Running with Pest
Playing
17. Tidying up with more custom expectations

Episodes

0%
Your progress
  • Total: 4h 19m
  • Played: 0m
  • Remaining: 4h 19m
Join or sign in to track your progress

Transcript

00:00
Let's dive back into Pest's custom assertions and change up these authenticated checks here. We're going to be repeating these a lot so it would make sense to adjust these so we have something we can reuse really easily and that reads really nicely.
00:15
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
00:36
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
00:58
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
01:26
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
01:46
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
02:06
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
02:26
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
02:46
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
03:14
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
03:41
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
04:06
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
04:26
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
04:52
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
05:18
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
05:40
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
06:00
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

Episode summary

In this episode, we focus on improving our Pest test suite by introducing more custom expectations to tidy up our test code. We notice that certain authentication checks are popping up all over our tests, which can make things repetitive and less readable. So, we set out to create a custom expectation that lets us easily assert whether a guest user is redirected, making our tests more expressive and maintainable.

We walk through the process of refactoring a test for unauthenticated (guest) users, aiming for a syntax like expect_guest()->toBeRedirectedFor('books.store'). This would hide the implementation details and provide a smoother, more fluent way to express our intent. We encounter some typical issues, such as Pest expecting a user object, and solve them by customizing the helper to pass null and handle that scenario gracefully. This little hack shows just how flexible Pest can be when you want to streamline your tests.

After setting up the helper and ensuring it works for both authenticated and guest flows, we run our tests to make sure nothing broke. Everything passes, our tests read a lot better, and we've got a reusable pattern that's handy across multiple parts of the app. It's a small refactor, but it goes a long way in making repeated test scenarios much easier to write and read.

Episode discussion

No comments, yet. Be the first!