10. Creating a custom Pest assertion


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,
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
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
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
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
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
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
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
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.
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
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.
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.
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
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
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
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
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
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.
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
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
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.
35 episodes4 hrs 19 mins


Pest is a PHP testing framework that brings beautifully simple syntax to your tests, without sacrificing on features. In this course, we'll get up and running with Pest in a Laravel project and write tests for a real-world application that we'll build along the way.

You'll learn how to set Pest up in a Laravel project, write tests with Pest's built-in assertions, generate code coverage, and more.

Alex Garrett-Smith
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!


No comments, yet. Be the first to leave a comment.