Angular单元测试系列-Router、Component、Directive、Pipe 以及Service单元测试

本节将涵盖Angular经常使用的组件单元测试方法，例如：Router、Component、Directive、Pipe 以及Service，本来是打算分红两节，但后来一想放在一块儿会更适合阅读，虽然看起来比较长。

但，在此以前，我建议先阅读系列的前两节，可能先更系统性的了解Angular单元测试以及一些框架说明。

注：本节略长，所以，我将遵循如下规则。

• 每一小节为一个类型的起点，且互不冲突。
• 每一小节前都会先待测试示例开始。
• 全部容器测试组件都叫 TestComponent。
• [重要]beforeEach 由第一节统一讲解，后续将再也不说明。

1、beforeEach

将 beforeEach 作为标题是由于在Angular单元测试里面，它的做用很是关键，由于全部的一切都须要它的引导。

beforeEach 目的为了简化咱们的测试代码，将一些重复的工做放在这。

当咱们须要写一段Angular单元测试时，是须要先提供一个测试模块，即：使用 TestBed.configureTestingModule 来构建，Angular工具集提供的用于快速建立一个测试 NgModule，而且他接受的参数，跟 NgModule 并没有任何差别。

beforeEach(() => {
    TestBed.configureTestingModule({
        imports: [HttpModule],
        declarations: [TestComponent]
    });
});

当你须要对任何东西进行测试时，若是有依赖，好比：Http，那么你须要 imports: [HttpModule]，这一切都跟 NgModule 写法彻底一置。

模块有了，还须要建立组件，这是由于当你须要测试某个组件时，组件自己带有一些HTML模板的渲染，例如：页面中显示用户信息，因此咱们须要一个测试组件作为该待测试组件的容器，以便咱们能够对渲染的结果进行测试。

但是，等等，若是像 Pipe 自己无任何HTML模板而言也须要吗？因此，咱们将这两种状况分开。

一、无模板

所谓无模板，指的是组件、指令、服务等等可能他们无须任何 HTML 模板的渲染，所以，也没必要说非要构建一个测试组件容器出来，这种状况咱们只须要利用强大的DI系统，将咱们组件以注入的形式，或者说咱们本意只须要测试组件（或Service）类而已。

let directive: LogDirective;
beforeEach(() => TestBed.configureTestingModule({
    providers: [ LogDirective ]
}));

beforeEach(inject([ LogDirective ], c => {
    directive = c;
}));

固然模块确定是须要的，只不过咱们采用 inject 将咱们的 LogDirective 指令注入之后，咱们就能够获得该指令的实例对象。

二、有模板

如同前面说，当咱们须要一个组件容器来确保咱们渲染的结果的时候，就须要构建一个容器测试组件。

@Component({
    template: `<trade-view [id]="id" (close)="_close()"></trade-view>`
})
class TestComponent {
    id: number = 0;
    _close() { }
}

beforeEach(() => {
    TestBed.configureTestingModule({
        imports: [HttpModule],
        declarations: [TestComponent]
    });
    fixture = TestBed.createComponent(TestComponent);
    context = fixture.componentInstance;
    el = fixture.nativeElement;
    dl = fixture.debugElement;
});

首先，TestComponent 为测试容器组件，注意：这里并无 export，由于对于容器咱们压根就不必被其余测试使用。

另，咱们也不须要对 close 业务进行操做，由于对于测试而言咱们只须要确保该事件被调用就行。

其次，经过 TestBed.createComponent(TestComponent) 来建立组件，而且将返回值存储起来。

fixture 包括组件实例、变动监测以及DOM相关的属性，它是咱们后面用来写单元测试的核心，这里我将经常使用的几个属性存在外部，这样全部 it 均可以方便调用。

nativeElement与debugElement的区别

前者原生DOM元素，后者是由Angular进行包装并提供诸如：

• query 查询组件、指令等等。
• triggerEventHandler 触发DOM事件。

以及一些便于咱们写测试代码比较通用的操做，还有更多细节，会在每一小节遇到时再作解释。

2、Component

一、示例

订单列表 ngOnInit 组件初始化时会远程请求交易订单数据。

// trade-list.component.ts
@Component({
    selector: 'trade-list',
    templateUrl: './trade-list.component.html',
    styleUrls: [ './trade-list.component.scss' ]
})
export class TradeListComponent {

    constructor(private srv: TradeService) {}

    ngOnInit() {
        this.query();
    }

    ls: any[] = [];
    query() {
        this.srv.query().subscribe(res => {
            this.ls = res;
        });
    }
}

订单详情页指定个 id 交易编号，并根据该编号从远程获取数据并渲染。同时提供 close 用于关闭详情页时回调通知。

// trade-view.component.ts
@Component({
    selector: 'trade-view',
    template: `
    <h1>trade {{id}}</h1>
    <dl *ngIf="item">
        <dt>sku_id</dt><dd>{{item.sku_id}}</dd>
        <dt>title</dt><dd>{{item.title}}</dd>
    </dl>
    <button (click)="_close()">Close</button>
    `,
    host: {
        '[class.trade-view]': 'true'
    },
    styles: [ `.trade-view { display: block; }` ],
    encapsulation: ViewEncapsulation.None
})
export class TradeViewComponent {
    @Input() id: number;

    @Output() close = new EventEmitter();

    constructor(private srv: TradeService) {}

    ngOnInit() {
        this.get();
    }

    item: any;
    get() {
        this.srv.get(this.id).then(res => {
            this.item = res;
        });
    }

    _close() {
        this.close.emit();
    }
}

以上两个待测试组件，我尽量把咱们平常可能遇到的（@Input、@Output、依赖、HTTP）状况考虑进来。

下面的测试并不是按示例的顺序来，而是根据单元测试步骤。

二、测试模块 @NgModule

若是根据 beforeEach 节咱们采用有模板的来构建测试模块，大体应该是这样：

@Component({
    template: `<trade-view [id]="id" (close)="_close()"></trade-view>`
})
class TestComponent {
    @ViewChild(TradeViewComponent) comp: TradeViewComponent;
    id: number = 0;
    _close() { }
}

beforeEach(() => {
    TestBed.configureTestingModule({
        imports: [HttpModule],
        declarations: [TradeViewComponent, TestComponent],
        providers: [TradeService, UserService]
    });
    fixture = TestBed.createComponent(TestComponent);
    context = fixture.componentInstance;
    el = fixture.nativeElement;
    de = fixture.debugElement;
});

因为 TradeViewComponent 的构造函数依赖 TradeService（其又依赖 UserService），所以须要注入全部相关的服务，以及 HttpModule 模块。

但是，咱们的服务大都数是依赖于远程数据请求，并且咱们不能由于远程数据的不当心变动倒置咱们单元测试失败，这样的数据在单元测试里面压根就没法获得有效保证、并不靠谱。

所以，咱们须要使用 spyOn （jasmine）全局函数来监视，当 TradeService 的 get 被调用时返回一些咱们模拟的数据。

let spy: jasmine.Spy;
const testTrade = { id: 10000 };
beforeEach(() => {
  // ...
  spy = spyOn(tradeService, 'get').and.returnValue(Promise.resolve(testTrade));
  // ...
});

很是简单，咱们只不过在原有的基础上增长 spyOn 的处理而已。

异步beforeEach

trade-list 组件与 trade-view 有一个明显的区别，那即是HTML模板与样式文件是由引用外部URL地址的，而获取这些数据的这一过程是一个异步行为。所以，咱们在构建 @NgModule 测试模块时，所以须要使用异步的方式构建 NgModule。

beforeEach(async(() => {
    TestBed.configureTestingModule({
      // 同上
    })
    .compileComponents()
    .then(() => { // 同上建立组件代码  });
}));

除了 async() 异步方法，以及 compileComponents() 两处之外，无任何其余差异。其实能够很容易理解这一点，当异步去请求数据时，总归须要等待它加载完的，才能有后面的行为吧。

而这里 compileComponents() 就是如此，他会一直等待直接 templateUrl 及 styleUrls 都请求完成后才会继续。

三、测试用例

首先，从测试角度而言，咱们第一个测试用例，应该要确保组件被初始化成功，那么咱们如何去检验这一点呢？

A、确保初始化

对于 TradeViewComponent 而言 ngOnInit 生命周期触发时就执行获取数据运行，然后模板进行渲染。

it('should be component initialized', () => {
    context.id = 1;
    fixture.detectChanges();
    expect(el.querySelector('h1').innerText).toBe('trade 1');
});

context.id = 1; 中的 context 指的是测试容器组件实例，咱们对其变量 id 赋值于 1，但对Angular而言并不知道数据的变化；因此须要手动的调用 fixture.detectChanges(); 来强制执行Angular变化检测，这样能确保数据绑定到DOM上。所以，咱们才能断言 h1 DOM标签的内容是 trade 1字符串。

自动变化检测

除了手动，咱们也能够引入 ComponentFixtureAutoDetect 让这种变化由 Angular 自动帮咱们。

TestBed.configureTestingModule({
  { provide: ComponentFixtureAutoDetect, useValue: true }
});

可是也并不是万能了，对于一些自己是由异步或计时器赋值的数据同样是没法被自动检测的。

B、spy 监视

固然这样远远不够，核心是数据请求而后再DOM渲染，以前已经利用 spyOn 监视服务方法的调用，因此咱们只须要利用 spy 变量来检测是否被调用，以及DOM的渲染是否是跟数据同样，就好了。

it('should be component initialized (done)', (done: DoneFn) => {
    context.id = 1;
    fixture.detectChanges();
    expect(spy.calls.any()).toBe(true, 'get called');
    spy.calls.mostRecent().returnValue.then(res => {
        fixture.detectChanges();
        expect(context.comp.item.id).toBe(testTrade.id);
        expect(el.querySelector('dl')).not.toBeNull();
        expect(el.querySelector('.sku-id').textContent).toBe('' + testTrade.sku_id);
        expect(el.querySelector('.ware-title').textContent).toBe(testTrade.title);
        done();
    });
});

首先，spy.calls.any() 表示有当有任何监视函数被调用时视为 true，固然这是必然，由于组件 ngOnInit 的时候会调用一次。

其次，spy.calls.mostRecent().returnValue 等同于 TradeServie 的 get() 方法的调用，只不过这里的返回的数据再也不是调用远程，而是返回由咱们模拟的数据而已。

C、异步测试

上面示例中，最后还使用了jasmine的异步方式，由于对于 get() 而言它自己是一个异步请求，咱们只可以等待 then() 执行之后，才能标记这个测试已经完成。

固然另外两种异步的写法：

async

it('should be component initialized (async)', async(() => {
    fixture.detectChanges();
    fixture.whenStable().then(() => {
        fixture.detectChanges();
        expect(context.comp.item.id).toBe(testTrade.id);
        expect(el.querySelector('dl')).not.toBeNull();
        expect(el.querySelector('.sku-id').textContent).toBe('' + testTrade.sku_id);
        expect(el.querySelector('.ware-title').textContent).toBe(testTrade.title);
    });
}));

将 spy.calls.mostRecent().returnValue 替换成 fixture.whenStable()，其返回一个Promise对象，Angular会在全部异步结束后触发Promise.resolve。

fakeAsync

it('should be component initialized (fakeAsync)', fakeAsync(() => {
    fixture.detectChanges();
    tick();
    fixture.detectChanges();
    expect(context.comp.item.id).toBe(testTrade.id);
    expect(el.querySelector('dl')).not.toBeNull();
    expect(el.querySelector('.sku-id').textContent).toBe('' + testTrade.sku_id);
    expect(el.querySelector('.ware-title').textContent).toBe(testTrade.title);
}));

相比较 async 代码更加同步化，这样代码看起来也很是爽。

fakeAsync与async区别

两者自己并没有区别，只不过是后者把前者的 fixture.whenStable() 换成 tick() 而已。

D、@Input() 输入参数

上面示例其实咱们已经在作了 context.id = 1; 就是表示咱们向 trade-view 组件传递一个交易编号为 1 值，而且也能从DOM找到 trade 1。

E、@Output() 自定义事件

trade-view 组件还有一个 (close) 事件，是如何确保它能被调用呢？由于当咱们须要这个事件时，并没有法经过一个相似订阅的方式知道说事件已经被调用了。那怎么办？

依然还须要 spyOn，如前确认初始化测试用例中同样。

首先，先监视容器组件的 _close()。

beforeEach(() => {
  // ...
  spyOn(context, '_close');
  // ...
});

最后。

it('should be call `close`', () => {
    el.querySelector('button').click();
    fixture.detectChanges();
    expect(context._close).toHaveBeenCalled();
});

由于 close 自己利用一个 Close 按钮来触发，所以，只须要查找到该按钮并触发其 click 事件；利用 toHaveBeenCalled 断言容器组件中的 _close() 事件是否被触发。咱们无须关心 close 具体业务，由于这是另外一个组件事情了。

四、最佳实践

至此，我总感受有些不对。

那即是 TradeService，咱们太过于依赖它了。假如 TradeService 的依赖变更了，那是否是还得再修改测试组件依赖，并且 TradeService 可能会在很我多测试文件中出现，因此这样作很蛋疼。

怎么办？

回想，Angular最强大的功能DI，它解决了各类依赖关系的复杂问题。可是，从测试角度出发，若是说组件与组件之间的依赖关系也在单元测试中出现，这样的事情很让人受不了。

正如 TradeService 内部还依赖 UserService，以致于，还须要注入 UserService，这都算什么事嘛。

固然，最好的组件测试代码应该是纯洁的、干净的。

Stub

trade-list 组件依赖 TradeService，而 TradeService 又依赖 UserService，那么何不咱们直接人为捏造一个 TradeService 呢？而后让这种依赖见鬼去。

Angular最强大DI系统，能够简单帮助咱们解决这个问题。如下使用 trade-list 组件为例：

const tradeServiceStub = {
    query(): Observable<any[]> {
        return Observable.of(tradeData);
    }
};
beforeEach(async(() => {
    TestBed.configureTestingModule({
        declarations: [TradeListComponent, TradePipe],
        providers: [
            { provide: TradeService, useValue: tradeServiceStub }
        ]
    }).compileComponents();
    // 等同上面
}));

@NgModule 测试模块的写法和上面大概同样，只不过这里咱们捏造了一个 tradeServiceStub，而且在注入 TradeService 时采用捏造的数据而已，就这么简单……

所以，这里就看不到 HttpModule、UserService 了，干净了！

五、小结

若是按触类旁通来说的话，上面大概能够完成全部包括：Directive、Pipe、Service这些测试编码了。

故，为了完整度，后续可能会出现一些和Component相同的内容。

3、Directive

一、示例

一个点击次点指令。

@Directive({ selector: '[log]' })
export class LogDirective {
    tick: number = 0;
    
    @Output() change = new EventEmitter();

    @HostListener('click', [ '$event' ])
    click(event: any) {
        ++this.tick;
        this.change.emit(this.tick);
    }
}

二、测试模块 @NgModule

// 测试容器组件
@Component({
    template: `<div log (change)="change($event)"></div>`
})
class TestComponent {
    @Output() changeNotify = new EventEmitter();

    change(value) {
        this.changeNotify.emit(value);
    }
}

beforeEach(() => {
    TestBed.configureTestingModule({
        declarations: [TestComponent, LogDirective]
    });
    fixture = TestBed.createComponent(TestComponent);
    context = fixture.componentInstance;
    el = fixture.nativeElement;

    let directives = fixture.debugElement.queryAll(By.directive(LogDirective));
    directive = directives.map((d: DebugElement) => d.injector.get(LogDirective) as LogDirective)[0];
});

这里没有涉及外部模板或样式，因此无须采用 beforeEach 异步。

但和上面又略有不一样的是，这里利用 By.directive 来查找测试容器组件的 LogDirective 指令。

By

By 是Angular提供的一个快速查找工具，容许传递一个 Type 类型的指令对象，这样给咱们不少便利。它还包括：css、all。

三、测试用例

A、确保初始化

只须要确保 beforeEach 获取的指令对象存在，均可以视为正确初始化，固然你也能够作更多。

it('should be defined on the test component', () => {
    expect(directive).not.toBeUndefined();
});

B、HostListener测试

[log] 会监听父宿主元素的 click 事件，而且触发时会通知 change 自定义事件。所以，须要给测试容器组件添加一个 (change) 事件，而咱们要测试的是，当咱们触发测试容器组件中的按钮后，是否会触发该事件。

it('should increment tick (fakeAsync)', fakeAsync(() => {
    context.changeNotify.subscribe(val => {
        expect(val).toBe(1);
    });
    el.click();
    tick();
}));

这里采用 fakeAsync 异步测试方法，由于 changeNotify 的执行是须要事件触发之后才会接收到的。

首先，订阅测试容器组件的 changeNotify，并以是否接收到数值 1 来表示结果（由于功能自己就是点击一个+1，开始默认为：0）。

其次，触发DOM元素的 click() 事件。

而 tick() 会中断执行，直到订阅结果返回。

4、Pipe

一、示例

一个根据交易状态返回中文文本的Pipe。

@Pipe({ name: 'trade' })
export class TradePipe implements PipeTransform {
    transform(value: any, ...args: any[]) {
        switch (value) {
            case 'new':
                return '新订单';
            case 'wait_pay':
                return '待支付';
            case 'cancel':
                return `<a title="${args && args.length > 0 ? args[0] : ''}">已取消</a>`;
            default:
                throw new Error(`无效状态码${value}`);
        }
    }
}

二、测试用例

A、确保初始化

Pipe至关于一个类，而对类的测试最简单的，只须要主动建立一个实例就好了。

固然，你也就没法使用 async、fakeAsync 之类的Angular工具集提供便利了。

let pipe = new TradePipe();

it('should be defined', () => {
    expect(pipe).not.toBeUndefined();
});

B、new 状态码

it(`should be return '新订单' with 'new' string`, () => {
    expect(pipe.transform('new')).toEqual('新订单');
});

C、测试DOM渲染

以上测试只可以测试Pipe是否能运行，而没法保证DOM渲染功能是否可用。所以，须要构建一个测试容器组件。

@Component({ template: `<h1>{{ value | trade }}</h1>` })
class TestComponent {
    value: string = 'new';
}

let fixture: ComponentFixture<TestComponent>,
    context: TestComponent,
    el: HTMLElement,
    de: DebugElement;
beforeEach(() => {
    TestBed.configureTestingModule({
        declarations: [TestComponent, TradePipe]
    });
    fixture = TestBed.createComponent(TestComponent);
    context = fixture.componentInstance;
    el = fixture.nativeElement;
    de = fixture.debugElement;
});

与以前看到的 NgModule 并没有什么不同。

测试用例

检验 h1 DOM标签的内容是否是如咱们指望的便可。

it('should display `待支付`', () => {
    context.value = 'wait_pay';
    fixture.detectChanges();
    expect(el.querySelector('h1').textContent).toBe('待支付');
});

5、Service

一、示例

交易类：

@Injectable()
export class TradeService {
    constructor(private http: Http, private userSrv: UserService) { }

    query(): Observable<any[]> {
        return this.http
            .get('./assets/trade-list.json?token' + this.userSrv.token)
            .map(response => response.json());
    }

    private getTrade() {
        return {
            "id": 10000,
            "user_id": 1,
            "user_name": "asdf",
            "sku_id": 10000,
            "title": "商品名称"
        }
    }

    get(tid: number): Promise<any> {
        return new Promise(resolve => {
            setTimeout(() => {
                resolve(this.getTrade());
            }, 500);
        })
    }
}

用户类：

@Injectable()
export class UserService {

    token: string = 'wx';

    get() {
        return {
            "id": 1,
            "name": "asdf"
        };
    }

    type() {
        return ['普通会员', 'VIP会员'];
    }
}

二、测试用例

A、确保初始化

当Service无任何依赖时，咱们能够像 Pipe 同样，直接构建一个实例对象便可。

固然，你也就没法使用 async、fakeAsync 之类的Angular工具集提供便利了。

let srv: UserService = new UserService();

it(`#token should return 'wx'`, () => {
    expect(srv.token).toBe('wx');
});

固然，绝大部分状况下不如所愿，由于真实的业务老是依赖于 Http 模块，所以，咱们还须要 Angular工具集的支持，先构建一个 NgModule。

let srv: TradeService;
beforeEach(() => TestBed.configureTestingModule({
    imports: [HttpModule],
    providers: [TradeService, UserService]
}));
beforeEach(inject([TradeService], s => { srv = s; }));

固然，它比咱们上面任何一个示例简单得多了。

it('#query should return trade array', (done: DoneFn) => {
    srv.query().subscribe(res => {
        expect(Array.isArray(res)).toBe(true);
        expect(res.length).toBe(2);
        done();
    });
});

B、为何没法使用 async、fakeAsync

虽然Service基本上都是异步方法，可是这里并无使用任何 async、fakeAsync，哪怕咱们的异步方法是 Observable 或 Promise。

细心的话，前面我提到两次。

固然，你也就没法使用 async、fakeAsync 之类的Angular工具集提供便利了。

这是其中一方面。

而另外一方面本示例也采用 Angular 工具集建立了 NgModule，可为何如下测试没法经过呢？

it('#get should return trade (fakeAsync)', fakeAsync((done: DoneFn) => {
    srv.get(1).then(res => {
        expect(res).not.toBeNull();
        expect(res.id).toBe(10000);
    });
    tick();
}));

这是由于 tick() 自己只能等待诸如DOM事件、定时器、Observable以及Promise之类的，可是对于咱们示例中 get() 是使用 setTimeout 来模拟一次请求要 500ms 呀，这对于 tick() 而言并不知道须要等待多长时间的呀。

因此，这里须要改为：

tick(600);

让等待的时长比咱们 seTimeout 略长一点就行啦。

6、Router

当前以上看似咱们已经懂得如何去测试各类组件及服务，但……有一项很重要的事实，那就是真正的项目老是冲刺着各类 Router 路由。

本来我打算独立另外一篇解释，可是一想，假若分开，会让人更加糊涂。

那么，若是咱们在上面的交易列表HTML模板增长路由跳转代码，例如点击交易编码跳转到交易详情页中。

<p><a [routerLink]="[ i.id ]">{{i.id}}</a></p>

那么，应该如何去检验这一过程呢？我认为应该从两种状况出发：

一是：是否有必要检验导航过程，若是说当前测试的组件导航至目前组件，而目前组件可能包含一些更为复杂的依赖，好比：权限。

二是：反之。

那么根据以上两种状况，我拆分红两种，一是Stubs，二是 RouterTestingModule
路由测试模块。

一、Stubs

根据上面分类，只须要测试当前组件 routerLink 的正确性，而不对路由导航进行验证。

可能这个会更简单一点，由于只须要 Spy 监视Angular 的 routerLink 的调用不就能够了吗？

可怎么作？

再回过头说Angular最强大的DI系统，利用它，本身 Stub 一个 RouterLinkStubDirective，而后利用DI替换 Angular 的 routerLink 不就能够了吗？

@Directive({
  selector: '[routerLink]',
  host: {
    '(click)': 'onClick()'
  }
})
export class RouterLinkStubDirective {
  @Input('routerLink') linkParams: any;
  navigatedTo: any = null;

  onClick() {
    this.navigatedTo = this.linkParams;
  }
}

替换 routerLink。

beforeEach(async(() => {
    TestBed.configureTestingModule({
        declarations: [TradeListComponent, RouterLinkStubDirective]
    })
}));

最后，能够写一个测试用例，来验证生成状况。

it('can get RouterLinks from template', () => {
    let allLinks = fixture.debugElement.queryAll(By.directive(RouterLinkStubDirective));
    let links = allLinks.map(linkDe => linkDe.injector.get(RouterLinkStubDirective) as RouterLinkStubDirective);
    expect(links.length).toBe(tradeData.length);
    expect(links[0].linkParams.toString()).toBe('/' + tradeData[0].id);
});

这类代码上面也有写过，这里使用 By.directive 查找页面全部 RouterLinkStubDirective，最后只是根据值进行断言。

二、RouterTestingModule

当须要进行路由导航势必须要与 location 打交道，得须要获取 URL 信息来验证导航的结果，是吧！

固然，没必要想太多，由于Angular工具集帮咱们作了一个很经常使用的 Spy Module，以便写测试代码，名也：RouterTestingModule。

beforeEach(async(() => {
    TestBed.configureTestingModule({
        imports: [AppModule, RouterTestingModule],
        schemas: [NO_ERRORS_SCHEMA]
    })
    .compileComponents()
}));

这是Angular工具集提供的一个很重要路由测试模块，它帮助咱们 Spy 几个平常模块：

• Location 相似于 Javascript 的 location，咱们能够利用它来验证URL。
• LocationStrategy 方便操做路由策略，无论 Hash仍是Path。
• NgModuleFactoryLoader 延迟模块加载。

location

导航验证最核心是URL的变化，那么能够获取已经注入的 Location。

const injector = fixture.debugElement.injector;
location = injector.get(Location) as SpyLocation;

NO_ERRORS_SCHEMA

若是说路由至某个页面时，而该页面可能会有其它组件 app-header 等之类的时候，而测试模块又没有导入这些组件时，可又会找不到，利用 NO_ERRORS_SCHEMA 能够忽略这部分组件错误。

1）、测试用例

导航路径自己还须要手动初始化。

router = injector.get(Router);
router.initialNavigation();

URL导航测试

it('should navigate to "home" immediately', fakeAsync(() => {
  expect(location.path()).toEqual('/home');
}));

点击导航测试

it('should navigate to "home" immediately', fakeAsync(() => {
    // 获取页面全部连接
    let allLinks = fixture.debugElement.queryAll(By.directive(RouterLinkWithHref));
    // 点击第一个连接
    allLinks[0].nativeElement.click();

    tick();
    fixture.detectChanges();

    expect(location.path()).toEqual('/10001');
}));

7、结论

Angular单元测试其实很是简单，不少代码都是重复的。固然了，这里头的概念也没有不少，总归只是以 TestBed 为入口、以DI系统为简化依赖、以 spy 监听事件，仅此而已。

固然，这里是有一些技巧，请见下一篇。

本节一共有27个用例，全部的你均可以在plnkr中找获得。

下一节，解释一些单元测试技巧。

happy coding!