CODEWITHSUNDEEP
angularunit-testingjasminekarma-runner
Cedric Reichenbach
Cedric Reichenbach

Reputation: 9319

Component declaration in spec files as opposed to loading the top-level module into TestBed

I have an Angular (4.x) application with a top-level module AppModule, which declares several custom components, so they can be used in templates.

However, for jasmine/karma tests the most common approach seems to be using BrowserDynamicTestingModule and declare any required custom components during beforeEach, e.g.:

beforeEach(async(() => {
  TestBed.configureTestingModule({
    declarations: [ MyComponent, SomeDependedUponComponent ]
  })
  .compileComponents();
}));

Considering we're simulating the main application's environment anyway, why wouldn't one just initialize the testBed with AppModule, so every custom component is available to all tests? Something like:

getTestBed().initTestEnvironment(
  [BrowserDynamicTestingModule, AppModule],
  platformBrowserDynamicTesting()
);

If I'm not missing something, this is much closer to the main application's setup and even reduces boilerplate code in individual spec/test files. Orre there any disadvantages, such as a performance penalty?

Upvotes: 2

Views: 1504

Answers (1)

Estus Flask
Estus Flask

Reputation: 222651

The said approach is wrong because this way the tests are de facto integration tests, while they are supposed to be unit tests.

The purpose of unit test is to test a single unit. Adding additional moving parts prevents it from being tested in isolation and complicates trouble solving when one of the units fails. The isolation can be improved with isolated unit tests without TestBed, although TestBed is still necessary to test DI annotations.

This approach requires to provide integration/e2e tests as well to be sure that all units were properly tested in unit tests and can really interoperate.

If the specs result in boilerplate code, this can be further improved with proper setup, like is shown here.

Upvotes: 3

Related Questions