Lesson Outline

Introduction to Angular's TestBed

In previous lessons, we have talked about the concept of isolating our unit tests. If we are running tests on the SomePage component then we don't care about the rest of the application. In fact, we want the rest of the application completely out of the picture.

This is simple enough if we are just testing a simple object that can be instantiated in isolation, like this example of testing a provider:

import { MyProvider } from './my-provider';

describe('My Provider', () => {
  let myProvider;

  beforeEach(() => {
    myProvider = new MyProvider();
  });

  it('should do something', () => {});
});

If the service or component is simple enough, then we can structure our tests like this just fine. Angular applications aren't always so simple, and if we are relying on dependency injection or importing modules then things get a bit more complicated - it becomes a bit harder to just instantiate a new instance of the class we are testing using:

myThing = new MyThing();

to set up the component we are testing. This is where Angular's TestBed comes in. As with most things related to testing, people have opinions about TestBed. Some people like using it, others swear by not using. Personally, I don't have strong opinions either way. I find it easy to set tests up with, and it is baked into Angular by default. You can set up your tests without it, or you can use a 3rd party package, but I think TestBed makes sense as a default approach.

We will dive into a specific TestBed example in a moment, but these are the key ideas behind using it: