Testing

Testing with TypeScript mostly works just the same as you'd expect in a non-TypeScript Ember application—so if you're just starting out with Ember, we recommend you read the official Ember Testing Guides first. The rest of this guide assumes you're already comfortable with testing in Ember!
When working with TypeScript in Ember tests, there are a few differences in your experience, and there are also differences in how you should handle testing app code vs. addon code.
App tests
One major difference when working with TypeScript in app code is that once your app is fully converted, there are a bunch of kinds of tests you just don't need to write any more: things like testing bad inputs to functions. We'll use an admittedly silly and contrived example here, an add function to add two numbers together, so that we can focus on the differences between JavaScript and TypeScript, rather than getting hung up on the details of this particular function.
First, the function we're testing might look like this.
Here we’re using the assert from @ember/debug. If you’re not familiar with it, you might want to take a look at its API docs! It’s a development-and-test-only helper that gets stripped from production builds, and is very helpful for this kind of thing!
1
// app/utils/math.js
2
​
3
export function add(a, b) {
4
  assert(
5
    'arguments must be numbers',
6
    typeof a === number && typeof b === number
7
  );
8
​
9
  return a + b;
10
}
Copied!
Then the test for it might look something like this:
1
// tests/unit/utils/math-test.js
2
​
3
import { module, test } from 'qunit';
4
import { add } from 'app/utils/math';
5
​
6
module('the `add` function', function(hooks) {
7
  test('adds numbers correctly', function(assert) {
8
    assert.equal('2 + 2 is 4', add(2, 2), 4);
9
    assert.notEqual('2 + 2 is a number', add(2, 2), NaN);
10
    assert.notEqual('2 + 2 is not infinity', add(2, 2), Infinity);
11
  });
12
​
13
  test('throws an error with strings', function(assert) {
14
    assert.throws(
15
      'when the first is a string and the second is a number',
16
      () => add('hello', 1)
17
    );
18
    assert.throws(
19
      'when the first is a number and the second is a string',
20
      () => add(0, 'hello')
21
    );
22
    assert.throws(
23
      'when both are strings',
24
      () => add('hello', 'goodbye')
25
    );
26
  })
27
});
Copied!
In TypeScript, that wouldn't make any sense at all, because we'd simply add the types to the function declaration:
1
// app/utils/math.ts
2
​
3
export function add(a: number, b: number): number {
4
  assert(
5
    'arguments must be numbers',
6
    typeof a === number && typeof b === number
7
  );
8
​
9
  return a + b;
10
}
Copied!
We might still write tests to make sure what we actually got back was what we expected—
1
// tests/unit/utils/math-test.ts
2
​
3
import { module, test } from 'qunit';
4
import { add } from 'app/utils/math';
5
​
6
module('the `add` function', function(hooks) {
7
  test('adds numbers correctly', function(assert) {
8
    assert.equal('2 + 2 is 4', add(2, 2), 4);
9
    assert.notEqual('2 + 2 is a number', add(2, 2), NaN);
10
    assert.notEqual('2 + 2 is not infinity', add(2, 2), Infinity);
11
  });
12
});
Copied!
—but there are a bunch of things we don't need to test. All of those special bits of handling for the case where we pass in a string or undefined or whatever else? We can drop that. Notice, too, that we can drop the assertion from our function definition, because the compiler will check this for us:
1
// app/utils/math.ts
2
​
3
export function add(a: number, b: number): number {
4
 return a + b;
5
}
Copied!
Addon tests
Note, however, that this only applies to app code. If you're writing an Ember addon (or any other library), you cannot assume that everyone consuming your code is using TypeScript. You still need to account for these kinds of cases. This will require you to do something that probably feels a bit gross: casting a bunch of values as any for your tests, so that you can test what happens when people feed bad data to your addon!
Let's return to our silly example with an add function. Our setup will look a lot like it did in the JavaScript-only example—but with some extra type coercions along the way so that we can invoke it the way JavaScript-only users might.
First, notice that in this case we’ve added back in our assert in the body of the function. The inputs to our function here will get checked for us by any TypeScript users, but this way we are still doing the work of helping out our JavaScript users.
1
function add(a: number, b: number): number {
2
  assert(
3
    'arguments must be numbers',
4
    typeof a === number && typeof b === number
5
  );
6
​
7
  return a + b;
8
}
Copied!
Now, back in our test file, we’re similarly back to testing all those extra scenarios, but here TypeScript would actually stop us from even having these tests work at all if we didn’t use the as operator to throw away what TypeScript knows about our code!
1
// tests/unit/utils/math-test.js
2
​
3
import { module, test } from 'qunit';
4
import { add } from 'app/utils/math';
5
​
6
module('the `add` function', function(hooks) {
7
  test('adds numbers correctly', function(assert) {
8
    assert.equal('2 + 2 is 4', add(2, 2), 4);
9
    assert.notEqual('2 + 2 is a number', add(2, 2), NaN);
10
    assert.notEqual('2 + 2 is not infinity', add(2, 2), Infinity);
11
  });
12
​
13
  test('throws an error with strings', function(assert) {
14
    assert.throws(
15
      'when the first is a string and the second is a number',
16
      () => add('hello' as any, 1)
17
    );
18
    assert.throws(
19
      'when the first is a number and the second is a string',
20
      () => add(0, 'hello' as any)
21
    );
22
    assert.throws(
23
      'when both are strings',
24
      () => add('hello' as any, 'goodbye' as any)
25
    );
26
  })
27
});
Copied!
Gotchas
The TestContext
A common scenario in Ember tests, especially integration tests, is setting some value on the this context of the tests, so that it can be used in the context of the test. For example, we might need to set up a User type to pass into a Profile component.
We’re going to start by defining a basic User and Profile so that we have a good idea of what we’re testing.
The User type is very simple, just an interface:
1
// app/types/user.ts
2
​
3
export default interface User {
4
  displayName: string;
5
  avatarUrl?: string;
6
}
Copied!
Then our component might be defined like this:
1
{{! app/components/profile.hbs }}
2
​
3
<div class='user-profile' ...attributes>
4
  <img
5
    src={{this.avatar}}
6
    alt={{this.description}}
7
    class='avatar'
8
    data-test-avatar
9
  />
10
  <span class='name' data-test-name>{{@displayName}}</span>
11
</div>
Copied!
1
import Component from '@glimmer/component';
2
import User from 'app/types/user';
3
import { randomAvatarURL  } from 'app/utils/avatar';
4
​
5
export default class Profile extends Component<User> {
6
  get avatar() {
7
    return this.args.avatar ?? randomAvatarURL();
8
  }
9
​
10
  get description() {
11
    return this.args.avatar
12
      ? `${this.args.displayName}'s custom profile picture`
13
      : 'a randomly generated placeholder avatar';
14
  }
15
}
Copied!
Not familiar with how we define a Glimmer Component and its arguments? Check out our guide!
Now, with that setup out of the way, let’s get back to talking about the text context! We need to set up a User to pass into the test. With TypeScript on our side, we can even make sure that it actually matches up to the type we want to use!
1
import { module, test } from 'qunit';
2
import { setupRenderingTest } from 'ember-qunit';
3
import { render } from '@ember/test-helpers';
4
import hbs from 'htmlbars-inline-precompile';
5
​
6
import User from 'app/types/user';
7
​
8
module('Integration | Component | Profile', function(hooks) {
9
  setupRenderingTest(hooks);
10
​
11
  test('given a user with an avatar', async function(assert) {
12
    this.user: User = {
13
      displayName: 'Rey',
14
      avatar: 'https://example.com/star-wars/rey',
15
    };
16
​
17
    await render(hbs`<Profile @user={{this.user}}`);
18
​
19
    assert.dom('[data-test-name]').hasText(this.user.displayName);
20
​
21
    assert.dom('[data-test-avatar]')
22
      .hasAttribute('src', this.user.avatar);
23
    assert.dom('[data-test-avatar]')
24
      .hasAttribute('alt', `${this.user.displayName}'s custom profile picture`);
25
  });
26
​
27
  test('given a user without an avatar', async function(assert) {
28
    this.user: User = {
29
      displayName: 'Rey',
30
    };
31
​
32
    await render(hbs`<Profile @user={{this.user}}`);
33
​
34
    assert.dom('[data-test-name]').hasText(this.user.displayName);
35
​
36
    assert.dom('[data-test-avatar]')
37
      .hasAttribute('src', /rando-avatars-yo/);
38
    assert.dom('[data-test-avatar]')
39
      .hasAttribute('alt', 'a randomly generated placeholder avatar');
40
  });
41
});
Copied!
This is a decent test, and TypeScript actually makes the experience of writing certain parts of it pretty nice. Unfortunately, though, it won’t type-check. TypeScript reports that the user field doesn't exist on the TestContext. Now, TypeScript does know that QUnit sets up that helpfully-named TestContext—so a lot of the things we can do in tests work out of the box—but we haven’t told TypeScript that this now has a user property on it.
To inform TypeScript about this, we need to tell it that the type of this in each test assertion includes the user property, of type User. We’ll start by importing the TestContext defined by Ember’s test helpers, and extending it:
1
import { TestContext } from '@ember/test-helpers';
2
​
3
import User from 'app/types/user';
4
​
5
interface Context extends TestContext {
6
  user: User;
7
}
Copied!
Then, in every test callback, we need to specify the this type:
1
test('...', function(this: Context, assert) {
2
​
3
});
Copied!
Putting it all together, this is what our updated test definition would look like:
1
import { module, test } from 'qunit';
2
import { setupRenderingTest } from 'ember-qunit';
3
import { render, TestContext } from '@ember/test-helpers';
4
import hbs from 'htmlbars-inline-precompile';
5
​
6
import User from 'app/types/user';
7
​
8
interface Context extends TestContext {
9
  user: User;
10
}
11
​
12
module('Integration | Component | Profile', function(hooks) {
13
  setupRenderingTest(hooks);
14
​
15
  test('given a user with an avatar', async function(this: Context, assert) {
16
    this.user: User = {
17
      displayName: 'Rey',
18
      avatar: 'https://example.com/star-wars/rey',
19
    };
20
​
21
    await render(hbs`<Profile @user={{this.user}}`);
22
​
23
    assert.dom('[data-test-name]').hasText(this.user.displayName);
24
​
25
    assert.dom('[data-test-avatar]')
26
      .hasAttribute('src', this.user.avatar);
27
    assert.dom('[data-test-avatar]')
28
      .hasAttribute('alt', `${this.user.displayName}'s custom profile picture`);
29
  });
30
​
31
  test('given a user without an avatar', async function(this: Context, assert) {
32
    this.user: User = {
33
      displayName: 'Rey',
34
    };
35
​
36
    await render(hbs`<Profile @user={{this.user}}`);
37
​
38
    assert.dom('[data-test-name]').hasText(this.user.displayName);
39
​
40
    assert.dom('[data-test-avatar]')
41
      .hasAttribute('src', /rando-avatars-yo/);
42
    assert.dom('[data-test-avatar]')
43
      .hasAttribute('alt', 'a randomly generated placeholder avatar');
44
  });
45
});
Copied!
Now everything type-checks again, and we get the nice auto-completion we’re used to when dealing with this.user in the test body.
If you’ve been around TypeScript a little, and you look up the type of the TestContext and realize its an interface, you might be tempted to reach for declaration merging here. Don’t! If you do that, every single test in your entire application will now have a user: User property on it!
There are still a couple things to be careful about here, however. First, we didn’t specify that the this.user property was optional. That means that TypeScript won’t complain if you do this.user before assigning to it. Second, every test in our module gets the same Context. Depending on what you’re doing, that may be fine, but you may end up needing to define multiple distinct test context extensions. If you do end up needing to define a bunch of different test context extension, that may be a sign that this particular set of tests is doing too much. That in turn is probably a sign that this particular component is doing too much!
Helpers
Working With Ember Data
Last modified 4mo ago
Export as PDF
Copy link
Edit on GitHub
Contents