Let's begin by creating a new Laravel app. Now if you want to learn how to use not just Cypress, but Cypress within a Laravel application, let's pull in a package to get you up and running in no time. So we have two steps. First we pull in Cypress through npm, and of course that's a development dependency. Next if I open this in my editor, you won't see any reference to Cypress yet. Let's go ahead and open it, npx cypress open. Now the first time we run this, it's going to scaffold a series of files and folders to get you started, as you can see here. Okay, so now if I go back to phpStorm, you'll see we have a new Cypress directory, as well.

to get you started, as you can see here. Okay, so now if I go back to phpStorm, you'll see we have a new Cypress directory, as well as a cypress.json. Think of this as your global Cypress configuration. So among other things, you'll want to set your base URL, and this will be the URL you access for your acceptance tests. I'm just going to use myapp.test. I'm using Laravel Valet behind the scenes, so this is how I would load our site, as you see there. All right.

Okay, let's close that, though. Now I'm just going to delete that, though. And if I were to add a new one here, exampleSpec.js, I could say, it works, and to be quick, we'll say expect(2 + 2).toEqual(4). And now, if I switch back, you'll notice that it instantly recognizes exampleSpec, and if I click it, it'll run our test. So in this case, it's a basic unit test, but of course, you can still run that in Cypress if you like. Most of the time, though, you'll be visiting pages, filling out forms, submitting requests, and things like that.

Most of the time, though, you'll be visiting pages, filling out forms, submitting requests, and things like that. Anyways, if you think about it, for any Laravel app, you will have certain needs and requirements, like log in a User and then visit this page. So it would be nice if I had commands like login, or what about, given I have three Posts, when I visit the /blog endpoint, I should see this Post. So traditionally, we can create factories to allow for those things. And yeah, of course, other things you might need, like log out the current User, or refresh the database, or trigger the given artisan command, or seed the database. So maybe you have a PlansTableSeeder class in your Laravel app, and you want to call

the database, or trigger the given artisan command, or seed the database. So maybe you have a plans table seeder class in your Laravel app, and you want to call that. These are the sorts of things it would be useful to have access to. Now of course, you could implement this yourself once you learn how, but it might be easier to pull in a package. So here's what I personally use in my projects. It's called laracast-cypress, and again, this is a development-only dependency. All right, so that should automatically, if I expand this, that will automatically register a new cypress-boilerplate command.

All right, so that should automatically, if I expand this, that will automatically register a new cypress-boilerplate command. So if I run that, you'll see it creates some new files and updates some existing files. And yeah, generally, you should run this right after installing cypress through npm. Okay, so now you'll see in our support directory, we have a place for simple assertions that you might need for a Laravel app, like assert that I was redirected to the given path. Next, we have this set of Laravel commands. Notice how it copies these commands into your support directory, which means you have full control if you need to modify it. So here's a cypress command to log in or log out, to get a token, to create a factory,

control if you need to modify it. So here's a cypress command to log in or log out, to get a token, to create a factory, to refresh the database, to seed the database, and to trigger an arbitrary artisan command. Or you can even trigger arbitrary php, should you have no other option. It's kind of funky, but cool. So if we go to index.js, we import your commands, which should be blank. We import those Laravel commands, and then we import the assertions. Okay, so the final step. Notice there are before and after hooks. So if you think about it, when you're running your tests, you need some way to delineate

Notice there are before and after hooks. So if you think about it, when you're running your tests, you need some way to delineate between your local environment and your acceptance testing environment, because you likely don't want those to share the same database. So here's how we allow for that. When you ran this cypress boilerplate command, it also created a .env.cypress file, and it does that by just copying your existing environment file. So there's your local environment, and here's your new cypress environment. So this is where you can update it however you need to. Maybe you want to set the environment to acceptance, or, most typically, or at the very least,

So this is where you can update it however you need to. Maybe you want to set the environment to acceptance, or, most typically, or at the very least, you want to update your database configuration. For example, in my database directory, I'm going to create a new file here, and we'll call it cypress.sqlite. Maybe when I'm running my acceptance tests, we're just going to use sqlite. Or create a MySQL database called cypress, whatever you want. Now I'm going to say, when running my cypress tests, I want to use sqlite. And the database, I can get rid of those, the database is going to be the full path. And as a quick warning, yeah, you can't do this, it does need to be the full path.

And the database, I can get rid of those, the database is going to be the full path. And as a quick warning, yeah, you can't do this, it does need to be the full path. So if I were to cd to the database and get the present working directory, there's your full absolute path. So I'm going to paste that in, and then we called it cypress.sqlite. All right, that's it. Feel free to tweak anything else here, but that should get you started. Okay, so now, if I switch back, what we can see here is before the test suite runs, we trigger this plugin, activate cypress environment file. And again, you have full ownership over this, just in case you need to tweak it, or remove

trigger this plugin, activate .env.cypress file. And again, you have full ownership over this, just in case you need to tweak it, or remove it, or change it. Here it is. And yeah, notice we, when you run your cypress tests, we back up your local environment, and then we rename .env.cypress to .env. So it's just a easy way to swap out your environment. And then when all the tests are done, we swap them back. And that's how we allow for it. So let's finish up by going into the integration directory, and let's just prove that it works.

And that's how we allow for it. So let's finish up by going into the integration directory, and let's just prove that it works. I'm going to say cypress.visit the homepage, and I expect that page to contain the current environment. So I will say environment, and maybe we'll call it acceptance. So let's come here, change it to acceptance, and let's give it a shot. I'll click on this one more time. And actually, before I do that, you have your option of using Chrome, Firefox, or Electron itself. Why don't we take that approach?

Does it work? No, we gave up. We did not see the current environment. Okay. Let's go to our routes/web.php file. The homepage, of course, loads the welcome view. So right down here where we have Laravel, let's swap that out with the current environment. And I can just say app and give me the environment. Okay. So if I come back and give this a refresh, or of course, I can press the letter R. Environment