undefinedor 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:
as anyfor your tests, so that you can test what happens when people feed bad data to your addon!
asoperator to throw away what TypeScript knows about our code!
thiscontext of the tests, so that it can be used in the context of the test. For example, we might need to set up a
Usertype to pass into a
Profileso that we have a good idea of what we’re testing.
Usertype is very simple, just an
Userto 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!
userfield 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
thisnow has a
userproperty on it.
thisin each test assertion includes the
userproperty, of type
User. We’ll start by importing the
TestContextdefined by Ember’s test helpers, and extending it:
this.userin the test body.
this.userproperty was optional. That means that TypeScript won’t complain if you do
this.userbefore 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!