ember testing: speeding things up

2020-08-30

 | 

~2 min read

 | 

298 words

I’ve been working with Ember’s QUnit test suite a lot lately. We have over 600 tests which means that waiting for them all to finish can really slow me down when I’m trying to test a specific feature.

There are a few really simple ways to speed up my REPL. Before diving into that, some basics for running tests with the ember-cli:

  • ember test runs the test suite via Ember’s CLI.
  • ember test -s runs it on a test server that will rerun on changes.
  • ember exam also runs the test suite, but does so in parallel, providing speed advantages.
  • ember exam -s --filter unit only runs the tests that have unit in their name.
  • ember exam -s --module "my module" only runs test modules which have a name of my-module.

What about nested modules? How do those work? Are you able to just run a single nested module? Yes!

tests/components/generic-component-name/component-test.ts
import { module, test } from "qunit"

module("generic-component-name", function (hooks) {
    setupRenderingTest(hooks)
    module('"specific" variant', function () {
        module('"sub-specific" variant', function () {
            test("it renders", async function (assert) {
                /* Test goes here */
            })
        })
    })
})

In this case, to only test the sub-module ('"sub-specific" variant') of the test, we would do the following:

% ember exam -m generic-component-name > "notifications" variant > "sub-specific" variant

A few things to notice:

  1. Submodules are separated by >
  2. The CLI takes all words following a flag (in this case -m) as the argument for that option. They do not need to be wrapped in quotes.

Wrap Up

Testing is critical to ensuring a system’s continued health. That doesn’t mean it needs to be slow or painful. These are just a few ways I’ve sped it up for myself.


Hi there and thanks for reading! My name's Stephen. I live in Chicago with my wife, Kate, and dog, Finn. Want more? See about and get in touch!