Running tests

Writing tests is great, but running them is important too.

Previous: Reporting Next: Setting up a test server

Now you're a dab hand at writing tests that check your code, and running them from the command line using the test runner of your choice, it's time to think about whether or not that's really the best way to use the available tools. Waiting for a test suite is a bit boring, and if your project is substantial it can take a while to complete. Wouldn't it be nice if the tests ran in the background, hidden away, and only notified you when they aren't working?

There are numerous ways of running your tests but they typically have one thing in common - they're linked to your source control system and run when something happens there. That might be a new commit, or pull request, or before a pull request is merged in, but whatever the strategy you adopt they'll be hooked in there somewhere.

Aside: This presents us with an obvious prerequesit: you need to be using something for source control. If you're not then I really recommend stopping reading this book and finding a resource to learn something like git instead. Working without source control is at best ill-advised, and at worst actively wreckless with your code and your client's projects. If you aren't using source control then you need to fix that problem first.

Back on topic. Most source control software has the option of running a script when an event occurs. git does, and it's one of the most popular options, so we'll concentrate on that.

Your test runner should have an option to select test files when you run it. There might be command line options to do other things too, like excluding files, including tests based on their name, and more. It's worthwhile reading the documentation.

If you're using Protractor the way you'd tell it what tests to include is;

protractor --specs mytests.test.js

The way the test runner actually runs the tests is defined in a separate file called conf.js. You can have several different configuration files, and tell Protractor which to use by defining one in the command to run it.

protractor conf.js --specs mytests.test.js

If you run tests locally and on a test server then you could have files called local.conf.js and remote.conf.js.

There's much more content coming soon(ish). If you're interested in reading it as it's added, please subscribe to my email updates. You won't get many emails - it'll only be one a month at most, and your email address will never be shared with any third parties. I would recommend adding something like "+testtheweb" to your email name, eg onion2k+testtheweb@gmail.com, to make filtering easy, and to be sure that your address has not been shared. It's supported on gmail, hotmail and many other email providers.

Many thanks to Tinyletter for their awesome (and free) service.

powered by TinyLetter

Previous: Reporting Next: Setting up a test server