This approach is different from narrowing the execution to a single test case or suite using functions like fit, iit or it.onyl or their describe counterparts, in that it doesn’t require code change and can be applied in runtime, depending on the use case.
What is a tag?
The #back plays the role of the tag.
There’s a couple of reasons you might want to tag your tests. First one is pre-commit tests. In this case, you tag a representative group of tests with a tag like #precommit. Before code commit, you then run only the tagged tests. This approach is especially useful for long running UI tests, rather than unit tests, which usually execute fast enough not to filter them.
A variation of this approach can be used in the CI pipeline, in case the project has a very high number of long UI tests, maybe due to testing browsers compatibility. The team may then decide to run the whole, extensive set of tests on a nightly basis and restrict the regular pipeline to a smaller set.
The second use case for tagging is to scope tests to a particular application area, like #login or #checkout. This is useful for target regression testing, prior to committing code.
The third application for tagging is non-invasive smoke testing. Tagging a group of tests with #noninvasive allows for a safe post-deployment smoke test, even in a production environment.
Below I present tag implementation for a couple popular test frameworks. For complete working examples, see this repo.
Jasmine has a concept of a specFilter. By default, it is switched off, but if the filter parameter is passed, jasmine will perform a regular expression test (RegExp.test) to select the test cases to run.
Here’s an example:
With tests defined this way, we can now pass the filter parameter as follows:
This will only run the test cases containing the #future tag.
Typically, you would run your tests with a karma runner, which abstracts the framework underneath. Karma exposes framework specific options through client.args property. Jasmin’s specFilter functionality is available as grep flag. Here’s what it looks like in the karma.config.js:
If you want to change the filter on per-run basis (e.g. by suites - pre-commit, integration, end-to-end), then the above solution will not satisfy you. Luckily, karma allows you to set properties on the config variable via command-line arguments as follows:
Which can than be used in karma.conf.js:
Using tags with protractor is very simple. There are two options, which are equivalent. You can either pass the filter via CLI arguments:
or in protractor.conf.js:
Tagging tests in mocha is the simplest of all outlined scenarios here. Simply do:
Applying tags mocha tags with a Karma runner is analogous to the karma-jasmine setup:
and the execution is identical: