If you’re writing tests for a javascript web application, sooner or later you’ll need to be aware of whether you are using a parallel or serial test runner.
| Parallel | Serial | |
| How it works | Start all async tests at once and wait until they have all completed. | Wait for each test to complete before starting the next one. |
| Implications | Callbacks execute in the order they return so race conditions are possible. | Tests are isolated, but take much longer to run. |
| Examples | Jasmine, Vows | QUnit, Mocha |
I discovered this last week while porting all our tests to a different framework. Under QUnit, everything was green, but under Jasmine, most of the end-to-end tests (that exercise our whole app, simulating user actions via the DOM down to a live API and back) were failing with all sorts of weird errors.
The problem? Unlike our regular tests, the end-to-end tests run the whole application at once, using the entire DOM, plus a globally-scoped event aggregator.
In QUnit all the tests ran fine, because they were completely isolated from one another. But in Jasmine they were running concurrently, all racing to update the DOM at the same time, and publishing all sorts of events that were being picked up by other tests. We fixed the problem by switching to Mocha instead… but definitely something to watch out for!
