Automated Testing with Codeception & Grunt

Hi, I'm Christopher Moss from A6 Software and in this video I'm going to demonstrate how you can use Grunt, the JavaScript Task Runner, for automating the running of our test suite whenever we make a change to one of our test files

And what you can see in the background here is actually the automated tests in progress, but to get that all set up and working, we're going to need to install Grunt

and I've demonstrated how to do this in an instruction file, but the rest of this video will basically show the full installation process

and taught you through how to install it using my GitHub-based instructions

So it's at GitHub.com forward slash ASIC software, then it's in a folder called Helpful

and then in a folder called Grunt Automated Testing Config. And as you can see, it's all there, just literally copy and paste it in

The only thing to really be aware of is if you've got an older

version of Ubuntu, you will probably need to do an app to get update and then an app to get upgrade

The reason being otherwise NPM, so Node Package Manager, will more than likely throw an error

unless you've got that installed, sorry, unless you've updated your Ubuntu server installation

to one of the later versions. The main reason to do this really is to save time

So when you're testing, it can be a little bit tedious to keep going back and forth

to the console, rerunning the command every time that you make a file change save

or file save. And then really what you want to do is have those tests running constantly so you know when things are breaking or you know it that constant feedback loop that you getting now there are downsides to doing something like this if you got heavily if your tests heavily use the database this can lead to situations where the reloading of the fixtures every time that you hit command s or control s you can end up obviously getting into a situation where you

tests are sort of not even finished running before you've hit ControlS again because you might

have made a typo or something. And that can cause your machine to go a little bit stir crazy

as it's trying to catch up. So what I would advise is you don't really run this against

heavily database intensive test files, nor would I really run it to trigger the acceptance

tests either. That can be something that can be done with like a Git hook, but that's not really

what we're trying to achieve here. But what I would say is whenever you're doing heavy unit

testing, this can be really useful. And really your unit tests shouldn't be hammering the database

anyway. You should try and mock off any calls to the database as, you know, you're only testing

the individual unit at the end of the day. You're not testing that there's a database there

That's not to say in the real world, that doesn't happen, but it is something that's going to

dramatically slow your tests down. So if you're going to do a lot of database

heavy testing that this perhaps wouldn't be the best solution but for a lot of just general unit

testing or maybe just unit testing one specific module that you're working on this can be a real

time saver and i hope you've enjoyed it