Passwordless Authentication with Laravel
This episode is for members only

Sign up to access "Passwordless Authentication with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
09. Testing the login flow

Episodes

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

Transcript

00:00
We're now going to walk through testing the login flow and to do this we're going to use the PEST testing framework. We're going to get this installed if you've not worked with it before
00:08
that's fine we'll guide you through that and we'll go ahead and write a test that covers pretty much every scenario within login. More importantly making sure that it actually sends the email of course that's one of the most important parts of this flow. So before we even do that let's just write down some of the things that we need to actually test for.
00:28
The first thing is we want to make sure the email is valid. Really important we that's part of our validation. We want to make sure that the email exists so it needs to be in the database before we actually send it out and we want to make sure it sends an email to the user. So we're going to look at covering these three things and getting these tested. So to go ahead and install PEST
00:51
if you've not worked with it before we're going to head over and go ahead and require PEST in using composer and then we're going to go ahead and initialize this by initializing with the PEST binary. Let's go ahead and do that now. Let's just say no for now for starring that. Okay so that's it we can now go ahead and just run PEST on the command line. You should just be able to run PEST
01:13
on its own and that should start to run your tests. Now Laravel already has some tests included so we're going to need to do a little bit of chopping and changing. What we're also going to need to do is go over to our phpunit.xml file and just uncomment these two lines out. When we test we don't want the database that we're using to be affected so we're going to switch that over to an
01:35
SQLite database and an in-memory database. So that just makes it a little bit more convenient and also a lot faster. So now that we've done that we can go ahead and just run PEST and just see what happens. So let's go over to the command line run PEST and sure enough the two example tests that we have in our application already when we installed Laravel are now passing. We're going to
01:56
go ahead and delete these because we don't need them. So let's get rid of the example test here for feature and the example test here for unit and now sure enough if we run PEST we see no tests found but that's fine we can generate one and create it out. Obviously we're using Laravel here so we want to go ahead and pull in the Laravel plugin. So let's go ahead and install that as well
02:16
all of this is over on the docs and that's just going to give us access to some of the things that we would usually do within Laravel to test these out as well as the ability to generate out our tests as well. So this is the exact command that we want because we want to generate out a feature test and this is our login test so we want to make sure that we can log in and cover
02:38
these three things that we need to do. So let's head over to our login test that's just been created and you can see here if you're used to testing within Laravel not using PEST this has a slightly different structure we have a course on PEST as well if you want to learn more. So let's start with a really simple test we're going to say it ensures the email address is valid so it needs to be a
02:59
valid email address and let's get rid of all of this and just kind of start from scratch. Now before we do anything here I'm going to go ahead and pull in the refresh database trait in here and what that's going to do is it's going to wipe the database for every test to ensure that we have a nice clean slate to actually start to work on. This is the same as just pulling the trait into a
03:22
standard Laravel test if you've done that before. So every time we run a test for every test it's going to migrate and then it's going to roll back their migrations afterwards. Okay so let's go ahead and look at how we ensure the email address is valid. Now we have the plugin for Laravel installed so what we can do here is just say this post and we can post through to auth login and in here we
03:47
can just pass in the data that we want to send through that form. We're going to say email is nope because we know that this needs to be a valid email address and nope is not a valid email address. Now what we can do is say this and we can just use any of the standard methods so assert session has errors and we need to make sure that email is included in our errors. So let's go ahead and run
04:11
pest and we actually get a failure here so let's just take a look and yeah we just need to chain this on. So instead of doing that we need to do the following and let's just run that test again and there we go it passed. So we know now that the validation for our action that we're calling over on our login root is actually working because nope is not a valid email address. Just if you are new
04:34
to testing and if we come over to send magic link if we get rid of this validation rule and we run our tests again this does actually pass which is a slight issue because it's still taking this rule into account. Let's just change the order of our tests here because we're going to create another test which ensures the email address exists first of all. So let's do this first of all and change
05:00
this over to a valid email address. Now this doesn't exist at the moment because we're testing within an in-memory database and alex.cocourse.com hasn't been created at all so this should run two tests and both should pass but now if we go ahead and just get rid of this rule here and we get rid of email we'll see that this fails because the email is not valid. So we've covered
05:27
both of them scenarios and that will also cover that if you decide to remove this exists rule as well so both of them are in there. Now just before we carry on I want to just tidy this up because one of the benefits of PEST is that we can use higher order calls here so we don't actually need to create this closure and then do all of this inside of here. Let's look at a demo of changing
05:48
this around really quickly. So I'm just going to grab all of this here without referencing this we're going to get rid of that and then we're going to get rid of the closure and what we can actually do is pull this down and use higher order functions to chain this on. So it just makes your test a little bit shorter and in my opinion a little bit easier to read and you can see that
06:08
it still works and still passes. So I'm going to convert both of these over to do that I just find it a little bit more readable and there we go two very easy tests that are now passing just to validate that. Now the last test that we want to create if we head over to our list is that it sends an email this is probably the most important part of this so let's cover that now. So we're
06:32
going to say it sends a magic link email that's it now for this is slightly more complicated so we're not going to use higher order function tests but what we are going to do is start to fake mail generate our user with a factory post through and make sure that that email actually gets sent we're not going to verify that the email contains the signed URL because that gets a little bit more
06:56
complicated but we will actually verify that the email gets sent and then we could test the email separately to this. So we're going to go ahead and use the mail facade and we're going to fake email sending that's really important because in your tests of course when you run these you don't actually want the email to be sent. Next up we're going to create a user that we can actually use to
07:16
properly log in with and check that the email was sent to them so we're going to say user factory and create so let's create our fake user in here and pull the namespace in for user and we'll set the email address here to alexacocourse.com like so. Great so we've got a fake user now and now we want to go ahead and post through like we did up there to auth and login we want to send
07:44
the email address of that user so we can just reference that user in there and pluck their email just in case we change this and then we want to go ahead and assert that the session has success that's our first check we want to make sure it's redirected back and we have a success message now we want to check that the email was sent so to do this we're going to go ahead and use the assert
08:06
sent now if you queue your emails you're going to use assert queued but for us assert sent is fine and we're going to say magic login link like so that's it now we can make this a little bit more advanced and a little bit more specific we'll do that in a second but let's just check that this is working nicely and at the moment we get a failure so let's just have a look here
08:27
okay yeah so this is an error with our factory so if we head over to our user factory which is under database and factories this is how we generate our that fake user that we did just here now the problem with this is that includes a password and we deleted the password so we're going to get rid of that so the migrations match up with the data we're storing let's run our test
08:48
again and sure enough we get green here and it's passed so what i'm going to do is just go ahead and create a closure out in this mail thing and we're going to go ahead and pull in the mail that we get here what we can do with this is say mail and if we just set this to a mailable and pull that in under illuminate and mail we'll get a list of the methods here and if we just come down has
09:09
two and we're going to return that and we want to make sure it includes or is sent to that user so let's bring the user into scope and say user email so all this is doing is additionally aside from making sure this is sent it's grabbing the actual email that's being sent the mailable which has this has two method on it and it's just making sure but whatever we return from here needs to be
09:35
true for this test to pass it's making sure that the email matches what we should be sending to so if we run our tests again sure enough we get green just to give you an example if we would switch this out to another email address so maybellacodecourse.com which of course is not going to send to then that test is going to fail so let's swap that back and now we're pretty
09:57
confident that as well as the validation we included this is sending the email to the user who has requested it via this flow now that we've tested the login flow let's head up to the next episode and look at testing the registration flow which is pretty similar but has a couple of key differences to it

Episode summary

In this episode, we dive into testing the login flow of our application using the PEST testing framework. If you haven't used PEST before, don't worry! We walk through how to install and set it up from scratch.

We kick things off by listing what needs to be tested in the login process: checking that the email is valid, ensuring the email exists in the database, and verifying that a login email is actually sent to the user. After the initial setup, we configure our testing environment to use an in-memory SQLite database so that our tests run quickly and don't interfere with real data.

With the basics out of the way, we generate our first PEST feature tests. The first two tests are all about validation: making sure only valid email addresses get accepted and that the user actually exists in the database before we try sending anything. Along the way, you'll see some tips about making your tests cleaner and easier to read, thanks to PEST's higher-order features.

The last part, and maybe the most important, is confirming that a login email really gets sent out. We show you how to use Laravel's mail fakes so no real emails are sent during testing. You'll see how to check that a Magic Link email was sent to the specific user who requested it. If any part of this breaks (say, the email isn't sent to the right person), you'll catch it immediately in your tests.

By the end of this episode, you'll have a solid set of login flow tests, giving you confidence that your authentication works and that users get their login emails as expected. Next up: we'll apply some of these same ideas to the registration flow!

Episode discussion

No comments, yet. Be the first!