This episode is for members only

Sign up to access "Testing Inertia with Dusk" right now.

Get started
Already a member? Sign in to continue
Playing
20. Setting up a basic workflow

Transcript

00:00
If you're already using GitHub Actions for continuous integration or you want to start using it, we're now going to cover how to, when we push to a remote repository,
00:10
automatically set up and run our Dusk tests. So as with any environment, the first step, at least for now, is going to be grab our env.dusk.local. So remember we set this up earlier when we wanted to have slightly different settings for our local Dusk running and we're going to create a new environment file. Now the reason that this is important is because
00:35
your secret keys, your database names, any other values in here could change across environments, so we don't necessarily want to use the local one. Okay, let's go ahead and create this out then. So let's create out a new file just up here. We are going to call this .env.dusk and I'm just going to call this .ci, but you can call it whatever you want. So let's go ahead and paste that in,
00:59
and for now we're going to leave this as exactly as it is. Effectively, when we push our code up and we want to run our tests on GitHub Actions, we are just going to use all the values in here. In the next episode, we're going to look at how we can keep secret keys truly secret by not adding them to our environment files. Remember we are committing both of these files to our
01:22
repository, so having secret keys in here is not a great idea. So of course I'm going to cover how we can get around that. Okay, so I already have a repository set up here called myapp with all of the commits throughout the course. What we're now going to do is go ahead and create out a dusk.yml file and go ahead and add in all of the steps that we need to get this working. So in the root
01:46
directory, we're going to create a directory called GitHub, and then inside of this directory we're going to create another directory called workflows. There's nothing specifically that you need to do over on your GitHub repository to get this working. GitHub will detect if you have any workflows and it will go ahead and start running your actions for you. So inside of here we're
02:08
going to create a dusk.yml file, and this is a specific dusk workflow that we're going to run. This will contain all the steps that we need to set up our project, start our server, install our chrome driver, which we did very earlier on in the course, and of course go ahead and run our tests. Now rather than go through step by step for this, because they are over on the dusk documentation
02:31
and they do change quite often, I'm just going to paste in what I've already created and I'm just going to run through everything that this is doing. And of course you can adjust this based on what your project uses and change it around as you need. Okay so on push, so we just run this workflow when we push up. The name is dusk and it runs on Ubuntu latest, which is pretty standard.
02:52
So let's go through the steps here. So we have a standard checkout step which we use for all GitHub actions. The first thing we want to do is set up MySQL. Now what I'm going to do is get rid of this secrets here, because we're going to cover this in the next episode. We're going to choose a password that we want to use manually inside of here for now, and then we'll cover how we can make this
03:11
secret a little bit later. So for our MySQL database, we're creating a database called myapp underscore testing, exactly the same as we have for local. By the way this file is available over in the GitHub repository for this course, so you can go ahead and copy and paste it in if you want to experiment. Okay next step, pretty straightforward to set up PHP and provide the
03:31
version. Now we get to the point where we copy our env file. So remember when we work with dusk, this copies over the env file when we run this locally to the env file that we would usually use. What we're going to do is we're just going to manually do this. So we're going to copy manually the env.dusk.ci file over to env, so all of the things that we've configured in ci are now
03:58
going to be available when our dusk test runs. Then we go ahead and just do a standard install on all of our dependencies with compose reinstall, which we would have done locally. We generate a key, which at the moment we already have. So if we just take a look inside of our dusk.ca file, we do have an app key which we can get rid of, and that step that we just created
04:19
will go ahead and generate a new key for us. Okay next up, which is again something that we did a little bit earlier on in the course, we install the chrome binaries and we use the detect option. Then we start the chrome driver, which is not something that we had to do on our local machine because we already probably have chrome installed, but this will go ahead and run the chrome driver
04:39
for us. Next up we build our assets, so we build this for production essentially. So we use npm install and npm run build rather than npm run dev. Remember we need our assets built to test this because we're testing this in a browser environment, so it needs everything to be available. Next up we just run a basic php server with php artisan serve and we provide in the no reload option so
05:02
we don't get hot reloading. And then finally we execute our tests. So like I said, grab this from the github repository if you're following along and you want to test pushing this up. These do change so you might need to tweak it a little bit depending on versions and environments, but generally this is the workflow that I work with. Okay, so now that we've done that we can go ahead
05:21
and push this up. So let's just take a look at the two files that we've added here. Let's go ahead and add both of these in and let's go ahead and commit these and let's commit this as dusk actions. We might need to tweak this and push it up again as is the case with the actions and let's go ahead and push this. So we'll push this to the myapp origin and that should go ahead and push this
05:45
directly up to here. Great, so we now have that. So now that we have done this we should have that action over here now running. So we can open this up and we can take a look at the status of it. This will run through all of the tasks that we have created, setting up mysql, setting up php, all that kind of stuff and of course at some point it is going to fail. So you can see here it's actually
06:07
failed on the mysql option. I think this is just because the default password here is root so let's go ahead and add and commit that and we'll go ahead and push that up again and have a look. So once we've fiddled around with it and we've changed it over we can head back over to our actions. We can see that's running again. Okay so fingers crossed let's see if this runs through.
06:30
Okay so everything looks good and we've got to the point where we're starting the chrome driver. We're now building our assets so we're building this for production as we specified. Then it's going to go ahead and run the laravel server so let's just wait for that to finish and then finally it's going to go ahead and execute our test. So even at this point when you're running this you're
06:48
probably going to see a load of failures but of course because we have a dump here of the command line output we can actually see what's going on. So the problem that we've got here is a pretty basic one it's just that over in our environment file that we created for our dusk, so let's go over to dusk and ci let's go down to our database section so we'll look for db password you can see
07:09
that i haven't specified the password here. Now we're going to bring this in when we start to look at secrets because this kind of stuff should be secret but we want to match this up to the credentials that we have over on github actions. So when we created this the github actions mysql instance has a user of root and a password of root so obviously not specifying a password is not going
07:30
to connect to the github actions database. The database name is the same so that should be good so everything should be good here. I want to go ahead and add these go ahead and commit it again with the same name push it up and let's go back over to our actions and let's check out our third workflow and fingers crossed this goes ahead and runs through properly.
07:54
Okay so this has failed again and we're pretty much getting the same error now one thing that i did forget to do if we just come over to env.dusk.ci we have our appenv still set to local so what dusk is going to be doing is trying to read from our local environment file which of course is not great. Now we did do that copy step which i don't actually think we need so we'll review that
08:15
in a second but let's switch the appenv here over to ci and let's go ahead and commit and push these changes once again. Okay so let's go over to our summary back over to our actions and let's pray that this is going to work this time this is always the case with github actions there is a really good tool that you can use locally this is called act and it allows you to actually run your github
08:40
actions locally using a docker container but for now since we're working with quite a basic setup we're not going to worry as things get more complex you can go ahead and use that. Okay let's wait for this to run through and we'll see what we get when our tests run. Okay so our laravel server is now running let's just wait a second for our tests to start executing
09:04
and this is already looking much better because we have a little bit of a delay so this means we're now going through each of our tests as we usually would. Okay so this is still failing and it is another issue that we have with how we've set stuff up locally so once again let's head over to our dusk.ci file and let's look at the app url here so at the moment this is specified
09:30
as myapp.test which is great for a local environment but obviously this isn't going to be the case for our continuous integration environment so what we actually want here is the local url and here we want to specify the port as well that we're using for our laravel server which is 8000. Okay let's try this again so let's go ahead and add and commit this and push this up
09:54
and let's take a look and see if there's any difference so let's go over to our actions and we'll keep an eye on this one. Okay our tests are now running and it does look like these are going to all pass we have everything configured properly of course it took a little while but this is the nature of github actions
10:13
you're working in a completely new environment you don't get instant feedback so it's just a case of changing things and pushing them back up so this has now successfully passed we've got a little bit more work to do because there's a couple of other things that we can configure and also we want to talk about our secret key stuff so currently we have this example secret key
10:34
in here which really we do not want to commit at all to our repository we do have to commit this file because it contains vital things that our app needs to run and we want to be able to configure this properly but for secret keys like things for external services we want to keep secret let's cover that in the next episode
22 episodes2 hrs 53 mins

Overview

How do you test real flows through your Inertia applications? With end-to-end tests!

In this course, we’ll cover everything you need to know about setting up, writing and running browser-based tests. Once we’re done, we’ll configure CI (Continuous Integration) with GitHub Actions, to run your tests whenever you push new code.

Don’t use Inertia? No worries — there’s plenty to learn about end-to-end tests with Dusk in here too.

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

Episode discussion

No comments, yet. Be the first!