Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Specs are required for all Angular Components, Services and other classes.
  • All specs should be placed in the same directory as the Angular Component which they test. The filename should end in ".spec.ts".  For example, the login-page.component.ts has a corresponding login-page.component.spec.ts test file.
  • As much as possible/reasonable, follow the Angular Testing Guide, which provides detailed example tests. Jasmine also has good documentation/tutorials on learning to write tests.
  • Always mock all providers. Doing so ensures that you're only testing your own code, so a change to the service won't break your test. It also ensures that successive tests can't influence each other by sharing data through an service
  • When testing asynchronous code, verify that your expect is actually executed. The following test will always succeed, because the expect is only executed after the it function has already completed:
    it("should encounter an expect", () => {
    timer(1000).subscribe(() => {
    expect(true).toBe(false);
    })
    })

    The easiest way to fix this would be to use the callback function it provides:
    it("should encounter an expect", (done) => {
    timer(1000).subscribe(() => {
    expect(true).toBe(false);
    done();
    })
    })

    Now the test won't complete until the callback function done() is called, so the test above will fail. Other ways of testing asynchronous code include marbles, and fakeAsync.

    A quick way to verify that your expect is actually being used is to flip it and see if that causes the test to fail.

    Note that this applies to all functions in a test suite, not just it. Here's a commit that fixes a number of these issues in beforeEach and a few in it: 066e6cd.
  • If you are working on debugging specific tests, you can add a "focus" on those tests (e.g. fdescribe instead of describe).  However, be warned that you must remove that focus before the PR can be merged, as otherwise you'll see a large decrease in code coverage (i.e. all non-focused tests will be ignored)

Writing Integration (e2e) Tests

...