I'm loving Angular, but running unit tests on Karma gets my nerves. It's too slow for me.
In this post, I explain mechanics under Angular's testing module and how to improve the performance.
To evaluate Angular unit testing performance I captured the CPU profiling with running Karma.
The above profiling was captured under the following condition:
- Angular version: 4.0.3
- Scaffold with angular-cli
- Put 300 components to app module
- Run 15 specs on Karma and Chrome
/* app.component.spec.ts */
import { TestBed, async } from '@angular/core/testing';
import { AppComponent } from './app.component';
import { AppModule } from './app.module';
describe('AppComponent', () => {
beforeEach(async(() => {
TestBed.configureTestingModule({
imports: [
AppModule, // This module has about 300 components.
],
}).compileComponents();
}));
for (let x = 0; x < 15; x++) {
it('should render title in a h1 tag ' + x, async(() => {
const fixture = TestBed.createComponent(AppComponent);
fixture.detectChanges();
const compiled = fixture.debugElement.nativeElement;
expect(compiled.querySelector('h1').textContent).toContain('app works!');
}));
}
});The above pictures indicates that the execution time of compilation components accounts for over 70%.
The test proceeds as follows:
- Start a spec
- Configure testingModule
- Create component fixture for AppComponent
- Compile all components and parse their templates included in AppModule
- Create a module factory using the compilation result
- Create an AppComponent
- Assertion
- End the spec
- Start the next spec...
The main point is that the compilation all components is executed in every specs.
Imagine bootstrapping your application in JiT compilation mode dozen of times.
Make component unit tests independent of other modules. This technique is called "isolated unit tests".
If you want detail, see https://angular.io/docs/ts/latest/guide/testing.html#!#isolated-component-tests .
Check the module imported from TestBed is really necessary for your test? The compilation time gets longer as the module gets larger. If the module includes a lot of unused components, you can separate them into another module. And purge the separated module from TestBed.
- before
+----------------------------+
| AppModule |
|----------------------------|
| |
SomeComponent(test target) --- (depends on) --+-> FooComponent (used) |
| |
| HogeComponent (unused) |
| |
| BarComponent (unuesd) |
| |
+----------------------------+
- after
+----------------------------+
| Module1 |
|----------------------------|
| |
SomeComponent(test target) --- (depends on) --+-> FooComponent (used) |
| |
+----------------------------+
+----------------------------+
| Module2 |
|----------------------------|
| |
| HogeComponent (unused) |
| |
| BarComponent (unuesd) |
| |
+----------------------------+
Keep dependencies small !
This technique is so hacky.
In many cases, TestBed has the same configuration for each specs in a test code. For example:
/* MyComponent.component.spec.ts */
describe('MyComponent', () => {
let fixture: ComponentFixuture<MyComponent>;
beforeEach(async(() => {
TestBed.configureTestingModule({
imports: [ AppModule ]
}).compileComponents();
fixture = TestBed.createComponent(MyComponent);
fixture.detectChanges();
}));
it('should render something when someCondition is true', async(() => {
fixture.componentInstance.someCondition = true;
/* assertion something is rendered... */
}));
it('should not render something when someCondition is false', async(() => {
fixture.componentInstance.someCondition = false;
const compiled = fixture.debugElement.nativeElement;
/* assertion something is not rendered... */
}));
});In the above example, the both specs need AppModule (and MyComponent included it). TestBed creates dynamic testing modules twice and the created testing modules have the same declaration because they depend on the same module and components. In other words, the compiled module factories are reusable in this file.
So if you customize the compiler used by TestBed to be able to turn use the executed compilation results, you can reduce the total compilation time. I've created a helper library to do this.
But don't forget that this method has a risk of destroying the idempotency of the unit testing. If you practice this technique, take the risk into consideration.
Thanks for this investigation; It's very interesting. I'm working in a project that has over 1600 tests and it is taking a long time for them to run. I've been recently looking into ways to write our tests to trim the time down as well as understand what's going on ' under the hood '.