For the past couple of years there have been two feature requests/rant inducers/fork justifications for Jasmine. First was support for one focused spec, or suite, via a syntax change. Second was support for beforeAll and afterAll – large, one-time test setup and teardown. If you’ve been paying attention to our commit log for the past few months you’ve noticed that support for both of these ideas is now on master. They will be included in the (imminent – watch the releases page) 2.1 release.
So let’s talk about why.
Focused Specs
Focused specs and suites – that you can run just this spec or suite – felt like an easy addition. Having focused specs helps in many other tech stacks so Jasmine should have it as well. But it’s never that simple. Having such a globally impacting syntax change – that one simple character could cut out the value of your entire test suite – just felt wrong.
Meanwhile we had many requests for “run this arbitrary subset of specs.” That’s a feature we could get behind – it’s so much more useful. Parallelization. Randomization. Filtering. And from there, “one” is just a special case. This feature almost made it in the 2.0 release. Now enough of this functionality is present to support fit and fdescribe for focused spec and suite running.
Jasmine and beforeAll
The case for beforeAll and afterAll is more complicated.
I’m firmly of the belief that having test setup that runs once – and only once – is a smell when writing unit tests. I’ve rarely heard of a use case for beforeAll that couldn’t be better solved with other techniques. Most of the arguments have been along the lines of, “My test suite has a long setup and I want to have quicker feedback loops when coding.”
I totally agree – short feedback loops is one of our key goals on any well-tested project. But there are more ways to increase speed than just running setup once. You can remove external dependencies and introduce dependency injection. You can decompose your project into smaller, less-coupled chunks/functions/modules that don’t need so much shared state. In the case of a JavaScript-heavy project, you can extract integration specs into another suite (maybe with something other than Jasmine) and then have lightning-quick, low-setup unit specs.
When you do add a one-time setup function in your suite you do run into some interesting risks. First is test pollution. If every test has to change and then clean up shared state, someone will eventually forget to reset that state. The resultant problems can be time sinks to find and fix. Next is that randomization of your test suite – which is useful for routing out side effects – becomes challenging, if not impossible. Focused specs (see above) take too long to run, meaning you lose a great productivity technique. A long setup function becomes like your garage (or basement) – nobody is sure what all is in there and they’re afraid to look inside. Now you have tech debt in your test suite. When will you make time to clean it up?
Why did we add the feature? Because the community wants it. And there is some utility.
The best argument for the feature was introducing Jasmine into poorly-tested and/or poorly-factored codebases. Using beforeAll makes sense in these situations – along with a plan to towards better-tested and better-factored ones. If one-time test setup can put your project on the road to better module-boundaries and more loosely-coupled code, then Jasmine should have the feature.
So enjoy these new features. And enjoy Jasmine 2.1.
About the Author
