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

　　4、佳实践
　　至此，我总感觉有些不对。
　　那便是 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 了，干净了！
　　5、小结
　　如果按举一反三来讲的话，上面大概可以完成所有包括：Directive、Pipe、Service这些测试编码了。
　　故，为了完整度，后续可能会出现一些和Component相同的内容。
　　三、Directive
　　1、示例
　　一个点击次点指令。
@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);
    }
}

  2、测试模块 @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 。
　　3、测试用例
　　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() 会中断执行，直到订阅结果返回。
　　四、Pipe
　　1、示例
　　一个根据交易状态返回中文文本的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}`);
        }
    }
}
　　2、测试用例
　　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('待支付');
});
  五、Service
  1、示例
  交易类：
@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会员'];
    }
}
　　2、测试用例
　　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 略长一点行啦。
　　六、结论
　　Angular单元测试其实非常简单，很多代码都是重复的。当然了，这里头的概念也没有很多，总归只是以 TestBed 为入口、以DI系统为简化依赖、以 spy 监听事件，仅此而已。
　　本节一共有24个用例，所有的你都可以在 plnkr 中找得到（注：由于 templateUrl 在plnkr中测试代码会失败，所以plnkr中依然以 template 形式）。