1. Starts with an empty list.

Be careful when you write tests. In this case there are a lot of ways this test can pass without actually testing anything. For example, if we don’t execute detectChanges() then the component might show some hard coded list but our test wouldn’t catch it. Always make sure your tests are actually testing something.

The rest of the test is straightforward, just grab all the links the page. There should be none.

2. Typing on the input box doesn’t change the list for 299ms.

This one is interesting in a lot of ways:

fakeAsync is used because we’re going to play with time on this test. The component waits 300ms before doing something so we’ll skip ahead 299ms and make sure nothing happened.

is used because we’re going to play with time on this test. The component waits 300ms before doing something so we’ll skip ahead 299ms and make sure nothing happened. We call detectChanges twice. Once to trigger the component’s lifecycle and again to update the HTML. If either one is missing then the test will pass without actually testing anything.

twice. Once to trigger the component’s lifecycle and again to update the HTML. If either one is missing then the test will pass without actually testing anything. We setup the hero service so it returns something if it’s called. We don’t expect it to be called but we’re going to use this to fail the test (update the tick to 300ms), just to make sure we’re testing something.

Updating the input value isn’t enough, you also have to dispatch the input event for Angular to pick up the changes. The test will always pass if you don’t.

event for Angular to pick up the changes. The test will always pass if you don’t. At the end of the test we call discardPeriodicTask to avoid the error “1 periodic timer(s) still in the queue.” It shows because our component still has one rxjs delay running. IMHO this should be taken care of by the framework, but that’s a rant for another day.

to avoid the error “1 periodic timer(s) still in the queue.” It shows because our component still has one rxjs delay running. IMHO this should be taken care of by the framework, but that’s a rant for another day. After all’s said and done our test should fail if we tick for 300ms instead of 299ms (always make sure you’re testing something).

3. The list of matching heroes appears after 300ms.

This test is similar to the previous one but this time around we do expect the links to be rendered. This isn’t the only way we could’ve tested this component (testing is more of an art than a science). For example, we could have added an expect here which checks the value passed to the service.

In the next example we’ll see a way test that searchHeroes is being exercised, without tying us up too much to the implementation.

4. Can perform multiple searches in a row — 300ms apart.

For this test we’re going to trigger two change event on the input box, 300ms apart. On the previous test we already checked that it works the first time, so we only need to check that the second search succeeds.

5. Doesn’t perform a search if the search term doesn’t change.

Same as the last test but we’re not changing the search value, and in the end we just check that the service was called once.