Up And Running with Pest
Playing
08. Logging in

Episodes

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

Transcript

00:00
Before we dive into any of the more fun stuff that we're going to be building, let's go ahead and test the login functionality. We've already got the register functionality working and then in the next couple of episodes we'll look at how once again we can refactor our tests just to make them that little bit simpler. Okay, so let's go and start with a test for the
00:22
login page. So let's go ahead and make a test in here and of course we're going to call this login test and sure enough we're going to pass the pest flag down to that. So let's open login test and this is going to test two things. The first thing is that when we hit the login page if we are already logged in it's going to redirect us somewhere else and the second
00:43
kind of set of tests are just going to be logging the user in make sure that they are logged in. So let's start with the first one. It redirects and let's say an authenticated user. So we're going to go ahead and get rid of all of this and just sort of start from scratch and we already know that we can use higher order tests here so like we did over on our register test we could
01:05
do something like this and then assert that we redirected somewhere. What we're actually going to be doing in the next couple of parts is building some helpers just to make this even easier. So let's go ahead and say get slash login and we need to be acting as a user here so actually we can't quite use a higher order test so let's just go ahead and do this in a standard way and then
01:27
we'll look at how we can shorten this down with a custom assertion. So we're going to go ahead and say user and we'll go ahead and create a user out in here and of course we're going to need our refresh database trait so let's pull this in and let's go down here and pull the user model in as well. There we go and let's put our get helper in here and let's go ahead and get that login page
01:55
so it's just forward slash auth forward slash login and we basically want to assert that we're redirected somewhere else. So we could actually assert that the status just to keep things simple is a 302 so a temporary or a permanent redirect. So let's just try and run this and of course we get a failure. Let's specifically run this test just to make it a little bit easier so let's go
02:19
into our feature tests and specifically run login test. Okay so we get a 404 that's pretty obvious we haven't built out the login page yet so let's go ahead and create a controller for this so make controller and login controller and let's go over to that login controller and let's go ahead and implement an invocable magic method. We won't do anything in here just
02:45
for now because we just want to make sure that this test passes and let's go and pull this in. We actually called this register index controller and we've just called this login controller but let's leave it for now we don't really care too much. Okay so let's go ahead and run our test again here and let's go up and we get a 200 because
03:06
we're hitting that and we're not being redirected anywhere that's where our middleware comes in so let's go ahead and create a constructor out in here and we'll go and add some middleware to this we could do that at the root level it doesn't really matter and we're going to say that we have to be a guest so if we rerun that test then let's see what happens oh we still get a 200
03:25
so that is because in our test we didn't act as a particular user so let's go and say this acting as of course user because what we're testing is that if we are signed in it's going to redirect us across and let's rerun that great we get a pass okay so now that we've done that we could start to refactor this we could move this to the root level if we wanted to let's go ahead
03:50
and just run the rest of our tests to actually hit that login post route that fortify provides us and once we're done with that we'll kind of come back to all of our tests and see if we can clear anything up so let's start with the really simple one and say it shows an error or flashes an error if the details are not provided and again you can go ahead and change that test name around
04:14
if you wanted to let's post through to login remember we don't need to be authenticated at this point so we can just use a higher order test here and we're just going to assert that the session has the email and the password error so let's say email and password so let's rerun our tests here and we get green great okay so the final test just to keep things simple of course
04:34
you could make this a little bit thorough if you wanted to is just to check that it logs the user in so it logs the user in let's go ahead and create a closure for this because it's going to be a little bit more complex and let's create our user so we need a user in the database to be able to actually log the user in of course so let's go ahead and create a user out here
04:55
now of course in a password in a form to log in we need the password so we're going to need to provide a password in here or use the default that exists within the rfl factory which is just password what i like to do my test is be a little bit more clear within the actual test and define the password out here myself so i know when i look at the test which password it's expecting
05:18
rather than that value that's hidden away in the factory so it's totally optional but i'm going to go ahead and use the bcrypt helper here to just say something like meow i'm a cat or some silly password and then we can go ahead and log in and we can see which password we're expecting here so let's go up we've pulled in the get helper let's pull in the post helper as well here
05:38
and let's go down and let's post through to slash login and we're going to pass in the email address here which we can just extract from the model you could define that out if you wanted to as well and we know that the password here needs to be meow i'm a cat and that is pretty much it so we want to assert that we're redirected over to the home page remember we changed that over earlier
06:06
in our root service provider really important that we're redirected over to the right place and then down here as a separate we want to go ahead and say this assert authenticated let's pull that up and let's go and run our test and there we go it works so we know now that when we post through with the credentials that are in the database we get a redirect and we are authenticated
06:31
now we could go ahead and tidy this up and technically create a higher order test you might find that when you have more complex tests like this that have a kind of user creation then posting through then asserting something that creating a higher order test doesn't really add that much value to each of your tests so if you wanted to change this to a higher order test
06:53
let's just go through this one more time just so we can kind of practice so let's get rid of this entire closure just here remember what we need to do is tap this so we could do this up here and for this it'd probably be better not to use a shorthand and just use a regular closure and we would want to go ahead and create the user within that closure so let's pull that into there and
07:14
again if you wanted to you could just get rid of that password there if you know the default is password and then you're going to want to go ahead and post through to login so let's pull that in here so it's kind of the same we're really doing the same thing here and then down here at the end of that we can then go ahead and assert that we are authenticated so let's go ahead and pull that
07:37
in and there we go so that would be the higher order version of the test minus the password that we're manually passing in so let's just go ahead and run our test i think that's going to fail because we've got the same name here let's just add an x on the end and yeah that actually fails so let's have a look in here the user is not authenticated okay so let's have a look at what
07:58
we're doing yeah because the password's wrong so let's change that to password and there we go we get green so you could change that over to a higher order test if you want but to be honest for things like that it kind of looks the same so in this case i tend to just pass in a closure now there are a ton of tests we could write but we're really focusing on pest syntax here
08:19
so what we're going to do in the next episode is refactor this we're going to start with a really simple refactor using a custom function and then we're going to take it a little bit further in the episode after that and we're going to look at creating a custom assertion which is going to help to clear this up

Episode summary

In this episode, we're digging into testing the login functionality of our app before jumping into the more exciting features. We've already sorted out registration, so now it's time to make sure users can log in smoothly.

We start by writing a test for the login page. The first thing we check is if a logged-in user tries to access the login page—they should get redirected elsewhere. Then we focus on actually logging users in, ensuring the whole flow works as expected. Along the way, we run into a missing login page (cue a quick controller creation!), set up the necessary middleware to handle guest access, and troubleshoot a few little bugs that pop up.

We also write tests to make sure users get proper validation errors when required details aren't provided. Lastly, we cover the full login process, confirming that a user can log in with the correct credentials and gets redirected to the home page—and, of course, we check that they're truly authenticated after logging in.

We experiment with refactoring our tests to use higher order functions, talking through when that's worth it and when sticking to closures might just be simpler. And don't worry if you feel like there's a million more tests we could write! Here, we're keeping our emphasis on learning good testing practices (especially with Pest) so we don't get lost in the weeds.

Next up, we'll kick off some refactoring using custom functions and later, custom assertions, to help keep our tests neat and tidy.

Episode discussion

No comments, yet. Be the first!