For most of this series, we'll follow a BDD approach. Write a spec, watch it fail, and then make it pass. But in real life, often those tests are filled in after the fact. And that's entirely okay. So with that in mind, why don't we use the Laracasts codebase as an example? Let's write a series of tests to ensure that the login form works the way we expect. For example, if I don't provide an email address, or an invalid email address, we should receive feedback. Or if I provide an email address that doesn't exist in our system, you should also receive feedback.

Or if I provide an email address that doesn't exist in our system, you should also receive feedback. Or if I provide an email address and an invalid password, of course, we should receive feedback. And then of course, lastly, if you provide proper credentials, it should sign you in. All right, let's get started. We'll switch to my editor. I am in the Laracast codebase here. Within Cypress, why don't we go ahead and add a loginspec.js file. So we're going to describe our login functionality. And then if you think about it, we have two different contexts.

So we're going to describe our login functionality. And then if you think about it, we have two different contexts. So again, I could write describe or context, they are aliases. So one context would be with invalid credentials. How should the form behave? But another one would be with valid credentials. So if you think about it, with invalid credentials, we might have some requirements, like it requires a valid email address, just like we discussed at the beginning. Another one would be it requires an existing email address in our system. And then of course, it requires valid credentials as a whole.

And that can be really useful when organizing your brain and figuring out what needs to be done. If we give it a shot, npx cypress open, and here's what we get. So notice how the tests are muted to indicate you haven't yet written the logic for them. But nonetheless, we now have an outline of sorts. So let's get started. It requires a valid email address. So let's think about the steps, and then we'll speed up after this first test. It'll be something like, given I have an account, when I visit the homepage and click the sign in button, and I then provide an invalid email address, I should see a validation

So why don't we do this? Well, you could do it in a beforeEach if you want to create a new User before every test. Or if you can get away with it, and you're not going to be polluting the other tests, you could maybe do it in a single before, which means it'll run once before all of the tests. So we're going to reach for that lericast/cypress package we learned about in the last episode, and that gives me sci.create to create a factory. So I could say lericast/user, and why don't we give it a username of John Doe and an email address of john@example.com. And then finally, a password of foobar, or how about example.

an email address of john at example.com. And then finally, a password of foobar, or how about example. Okay, so now, before any of my tests run, we're going to seed my users table with a single record. However, before I do that, I want to make sure that our database is clean and ready to go. And again, I use that term polluted. We don't want these tests polluted by the state from previous tests. So what you can do in that case is call that php artisan migrate:refresh command we learned about. And then also for Laracasts specifically, there are a set of app specific default records.

So what you can do in that case is call that php artisan migrate:fresh command we learned about. And then also for lericast specifically, there are a set of app specific default records that I expect to be there. So I'm going to call cypress.seed as well. So if you were to map this to the traditional artisan commands, it would be something like this, migrate:fresh, and it's basically that, but these are split into two separate commands. So it would be something like that. And the default class would be something like DatabaseSeeder, I believe. That's what we're doing there. Okay, so before all of my tests, refresh the database, seed it, and then create a single

That's what we're doing there. Okay, so before all of my tests, refresh the database, seed it, and then create a single User. Now, again, it just depends on what you're testing. But in some cases, you might want to do this and before each that way before every test, you have a clean database, I just happen to know it won't be necessary in this case. So let's not waste any time. All right, we're ready to get going with invalid credentials. And I'll clean this up. All right, given I have an account, well, we know we have an account.

Same thing. But you can also do things like this. We could say cypress.get the sign in link if that happened to exist, or a class. Or you could even set up specialized Cypress attributes, like get the anchor tag where the data Cypress attribute equals sign in button. You know, there's all these different selectors you can use. But one that I often like is get me the link that says sign in. I don't expect that to change almost ever. So I'm okay using that text specifically. Cypress, give me the anchor tag that says sign in and click it.

So I'm okay using that text specifically. Cypress, give me the anchor tag that says sign in and click it. Okay, let's switch over to Cypress. Let's give it a run. Now you'll see it does take a few seconds because I do have to reset my database. But once that's done, it should go very quickly. And sure enough, we got to this point. So here's everything we're doing. php artisan migrate:fresh, php artisan db:seed, create a User. That's our setup.

php artisan migrate:fresh, php artisan db:seed, create a User. That's our setup. Then we visit the homepage. Then we find the link, and there it is. You'll see it's highlighted there. And we clicked it. Okay, let's keep going. Next, and I then provide an invalid email address. So I can say this, get the input with an ID, and I happen to know I gave it an ID of email. So you could do this or that.

Cool. So now we move on again. I'm going to copy this one last time, and then we'll see if we can move any of that logic into a beforeEach. Okay, try to sign in, provide an existing email address. So let's paste that in. Next, the password, we're going to type invalidPassword. So we're going to provide credentials for an actual User, but credentials that are not correct. And we will expect the...

First test passes, second one passes, and the third one passes. Great. It's so easy. Now let's do the happy path. It works. So one more time, let's grab this, and we're going to say, visit the homepage, try to sign in, provide a correct email and password, which is example. And behind the scenes, that gets encrypted. So that's fine. Let's paste it in, click the button, and now we should be signed in.

So that's fine. Let's paste it in, click the button, and now we should be signed in. So I know that I have a flash message that says, you are now logged in. But if you want, we could also do things like this. Now that I am signed in, let's visit a page like settings/account, and I should be able to access it, and I should see something like update your account. You don't have to do this. It's just a way of showing, well, once you're signed in, we should be able to access a subscription only endpoint. Alternatively, if you don't want to visit the page, by the way, you could use sign.request.

This is just a simple explanation with no code.