Up And Running with Pest
Playing
10. Creating a custom Pest assertion

Episodes

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

Transcript

00:00
We're now going to take a quick look at custom expectations and then we're going to turn this test into something that reads a little bit better. These kind of tests are the ones that we're going to repeat a lot,
00:10
particularly for redirecting unauthenticated users when we get to pages where we need users to be signed in, so it'd be great if we could just really quickly write very simple tests for this. Okay, so let's go over to pest.php
00:25
and come down to this custom expectations section. You can see one's already been defined out for you. Now this allows us to create literally a custom expectation function and then do anything we like in here. Let's take a look at a really simple example and say
00:41
to be Alex. So we want whatever's passed in to expect when we write these now tests to be Alex. So you could do anything in here and you can leverage the existing expectations that pest has. Okay, so let's just go and write a really
00:57
simple test just to demo this out. So it is Alex and we'll go ahead and create out a closure in here and let's say expect Mabel to be Alex. So that is the name of the custom expectation that we created. Of course when we go
01:16
ahead and run this test it's going to fail because Alex doesn't equal Mabel, but we can fix that up by just switching this string over. If I can spell my name correctly and there we go we get a pass. So that's as easy as it is to create a custom expectation and you
01:31
can create them for anything that you frequently repeat across your test just to clear them up. Now we don't want to do that. We want something a little bit more useful and what we're going to do is we're going to create an expectation which allows us to do
01:45
something like this. So we're going to say expect and we're going to pass a user in so a factory user to be redirected when visiting and then we're going to give a page auth and login like this or when
02:03
requesting or anything like that. Let's just shorten this down actually and say for to be redirected for auth login. I think that makes a lot more sense. Okay so that's a lot shorter. It's a lot shorter to write and for me at least a lot easier to read.
02:19
Now at the moment of course this isn't going to work because we don't have an expectation with that name. You can see here to be directed for is an undefined method. So we're going to go ahead and create that out to be redirected for
02:34
and then of course we're going to need to pass in the url so within custom expectations we can actually pass these in as well. So I'm going to go ahead and just paste all of that in here just for now and that is what we want to end up with.
02:49
What we can also potentially do is give the request method as well. We'll leave it by default as a get but we'll allow that to be passed in. So let's go ahead and also accept in a string for the method that we want to make a request as because we also might want to use this for posting.
03:05
So let's pull this all up to one line and this value now we need to get from somewhere. Now just to demo this out if we just die dump on this and we just comment this out and we run this test notice that what we get if we just scroll
03:21
all the way up here it's a little bit hard to see in the terminal is a pest expectation but the value property of this contains that user. So what we can now do is say this value and that's going to give us out the user model that we originally passed in
03:37
to the expect method. We've got it all here so what we can do is take this value pass it into acting as and of course we're going to need to return this then we can dynamically call a method here. So let's pass that method in pass the
03:55
url in and now we've extracted away this testing functionality specifically just using this custom expectation. For example you might also want to chain on other expectations in here in which case you've now refactored that to one place so this is
04:13
now a very very simple thing to write regardless of what checks you are doing in here. Okay let's just test this out so I'm going to go ahead and run our login test and sure enough we get green. So you can do pretty much anything here this is probably a more complex way of
04:27
doing things and of course this might not be to your taste you might want to change this up. So we're going to be using this on the login and register page so we may as well go ahead and change this over or add this over to the register page as well.
04:44
So when we hit the register page we also want to be redirected when this user is signed in. Let's go ahead and finally just run pest all together and yeah we get a failure just because we don't have the user model pulled in. Let's do that now and let's run pest and it still doesn't
05:02
work so let's have a look. Yeah so we get a 200 so actually we've written a test for this and we now know it's failing. So let's head over to the register index controller and let's go ahead and create out a construct magic method here
05:16
and let's go ahead and say this middleware and let's say guest. Great so if we go over to our login test or our login controller we know that we've got that in there that's working nicely now that's been added to register when we run pest we get all green.

Episode summary

In this episode, we dive into how to create custom assertions (or 'expectations') in Pest, which can really clean up your repetitive test code. We start by looking at why you'd want a custom expectation in the first place—think about those tests you write over and over, like making sure unauthenticated users are redirected when accessing certain routes. Instead of rewriting the same logic multiple times, Pest lets you encapsulate it in a custom expectation.

We walk through the basics by making a super simple custom expectation that just checks if a value is "Alex". From there, we level up and build something more practical: an expectation to test whether a user gets redirected when accessing a protected route. This new expectation tidies up the test, making it much more readable and easier to write.

We also handle passing in parameters like the URL and optionally the HTTP method. Along the way, you'll see how to access the value inside the custom expectation, use that value (like a user instance), and even chain this with methods like actingAs to simulate authenticated requests.

Finally, we show how to use this custom expectation on both login and register routes, troubleshoot a failing test, and fix the controller middleware as needed. By the end, you've got a handy new tool for DRY (Don't Repeat Yourself) testing in Pest!

Episode discussion

No comments, yet. Be the first!