本节将涵盖Angular常用的组件单元测试方法，例如：Component、Directive、Pipe 以及Service，原本是打算分成两节，但后来一想放在一起会更适合阅读，虽然看起来比较长。而后一节，我将介绍一些我们不太用到的单元测试，诸如：Router。
　　但，在此之前，我建议先阅读系列的 前两节 ，可能先更系统性的了解Angular单元测试以及一些框架说明。
　　注：本节略长，因此，我将遵循以下规则。
　　每一小节为一个类型的起点，且互不冲突。
　　每一小节前都会先待测试示例开始。
　　所有容器测试组件都叫 TestComponent 。
　　一、beforeEach
　　将 beforeEach 做为标题是因为在Angular单元测试里面，它的作用非常关键，因为所有的一切都需要它的引导。
　　beforeEach 目的为了简化我们的测试代码，将一些重复的工作放在这。
　　当我们需要写一段Angular单元测试时，是需要先提供一个测试模块，即：使用 TestBed.configureTestingModule 来构建，Angular工具集提供的用于快速创建一个测试 NgModule，并且他接受的参数，跟 NgModule 并无任何差异。
beforeEach(() => {
    TestBed.configureTestingModule({
        imports: [HttpModule]，
        declarations: [TestComponent]
    });
});
　当你需要对任何东西进行测试时，如果有依赖，比如：Http，那么你需要 imports: [HttpModule] ，这一切都跟 NgModule 写法完全一置。
　　模块有了，还需要创建组件，这是因为当你需要测试某个组件时，组件本身带有一些HTML模板的渲染，例如：页面中显示用户信息，所以我们需要一个测试组件做为该待测试组件的容器，以便我们可以对渲染的结果进行测试。
　　可是，等等，如果像 Pipe 本身无任何HTML模板而言也需要吗？所以，我们将这两种情况分开。
　　1、无模板
　　所谓无模板，指的是组件、指令、服务等等可能他们无须任何 HTML 模板的渲染，因此，也不必说非要构建一个测试组件容器出来，这种情况我们只需要利用强大的DI系统，将我们组件以注入的形式，或者说我们本意只需要测试组件（或Service）类而已。
let directive: LogDirective;
beforeEach(() => TestBed.configureTestingModule({
    providers: [ LogDirective ]
}));

beforeEach(inject([ LogDirective ]， c => {
    directive = c;
}));
　　当然模块肯定是需要的，只不过我们采用 inject 将我们的 LogDirective 指令注入以后，我们可以得到该指令的实例对象。
　　2、有模板
　　如同前面说，当我们需要一个组件容器来确保我们渲染的结果的时候，需要构建一个容器测试组件。
@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事件。
　　以及一些便于我们写测试代码比较通用的操作，还有更多细节，会在每一小节遇到时再做解释。
　　二、Component
　　1、示例
　　订单列表 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）情况考虑进来。
　　下面的测试并非按示例的顺序来，而是根据单元测试步骤。
　　2、测试模块 @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();
    // 同上
　　}));
　　除了 async() 异步方法，以及 compileComponents() 两处以外，无任何其他差别。其实可以很容易理解这一点，当异步去请求数据时，总归需要等待它加载完的，才能有后面的行为吧。而这里 compileComponents() 是如此，他会一直等待直接 templateUrl 及 styleUrls 都请求完成后才会继续。
　　3、测试用例
　　首先，从测试角度而言，我们第一个测试用例，应该要确保组件被初始化成功，那么我们如何去检验这一点呢？
　　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 具体业务，因为这是另一个组件事情了。