Way of httpInterceptor in Angular 2

4/10 に開催された[Angular 2 ハンズオン](http://connpass.com/event/28985/)のチューターとして参加してきました。  
チューターしている合間に、Angular2 での HttpIntercepor のやり方を調べてたので、その辺りを紹介します。



ついでに LT してきました。LT の資料はこちらです。

Angular2 HttpInterceptor Needed  
<https://gist.github.com/mitsuruog/6f7f0ca3f546b245bccdd3ebc14375d8>

## HttpInterceptor とは

`HttpInterceptor`とは、XHR(つまり Ajax)に関連する横断的機能(cross-cutting feature)を分離するためのものです。

Controller などの後続処理から、XHR 通信時に発生する例外処理などを分離して`HttpInterceptor`で一括処理します。
Angular1 では、`HttpInterceptor`を使うことで綺麗に分離することができました。

refs: [AngularJS: API: $http](https://docs.angularjs.org/api/ng/service/$http)

## Angular2 では簡単にはできない

Angular2 でも簡単に実現できると考えていたのですが、思ったより面倒でした。
公式リポジトリの Issue にて実現方法について議論されていました。(めっちゃ長いです)

[RFC: Http interceptors and transformers · Issue #2684 · angular/angular](https://github.com/angular/angular/issues/2684)

## Angualr2 での HttpInterceptor の実現方法

以下の手順で実現できます。

1. `Http`を継承した`CustomHttp`を作成する。
1. `bootstrap`にて、既存の`Http`プロバイダを Ovarride する。

では順に見て行きましょう。

### `CustomHttp`を作成する

まず、`CustomHttp`を作成します。`Http`の API を 1 つ 1 つ Warp します。  
例外が発生した場合は、`catch`で捕捉して private 関数の`handleResponseError`で一括処理させるようにしています。

**custom-http.service.ts**

```ts
import {
  Http,
  ConnectionBackend,
  RequestOptions,
  Request,
  RequestOptionsArgs,
  Response,
} from "angular2/http";
import { Observable } from "rxjs/Observable";

export class CustomHttp extends Http {
  constructor(backend: ConnectionBackend, defaultOptions: RequestOptions) {
    super(backend, defaultOptions);
  }

  request(
    url: string | Request,
    options?: RequestOptionsArgs
  ): Observable<Response> {
    return super
      .request(url, options)
      .catch((res: Response) => this.handleResponseError(res));
  }

  get(url: string, options?: RequestOptionsArgs): Observable<Response> {
    return super
      .get(url, options)
      .catch((res: Response) => this.handleResponseError(res));
  }

  // ...長いので省略

  //
  // Here's to handle error stuff
  //
  private handleResponseError(res: Response) {
    if (res.status === 401) {
      // do something
    } else if (res.status === 500) {
      // do something
    }
    return Observable.throw(res);
  }
}
```

### `Http`を上書きする。

つづいて、`bootstrap`時に`Http`を`CustomHttp`で上書きします。
次のコードは、`provide`を利用して、Angular2 が DI を処理する際にインスタンスを生成する方法を変更しています。

**main.ts**

```ts
import { provide } from "angular2/core";
// RxJS本体のObservableを利用するための設定
import { bootstrap } from "angular2/platform/browser";
import "rxjs/Rx";

import { AppComponent } from "./app.component";
import { CustomHttp } from "./common/services/custom-http.service";

bootstrap(AppComponent, [
  provide(Http, {
    useFactory: (backend: XHRBackend, defaultOptions: RequestOptions) => {
      return new CustomHttp(backend, defaultOptions);
    },
    deps: [XHRBackend, RequestOptions],
  }),
]);
```

## まとめ

Angular2 でも`HttpInterceptor`を実現できそうですが、少し面倒でした。

こちらに`custom-http.service.ts`のコード置いておきます。(しばらくはこのままで使えるはず。。。)

[custom-http.service.ts](https://gist.github.com/mitsuruog/6f7f0ca3f546b245bccdd3ebc14375d8#file-custom-http-service-ts)

> (追記)
> LT では`new Providor()`としていましたが、 [@laco0416](https://twitter.com/laco0416)さんから、
> `Providor`を Warp している`provide`を利用した方が破壊的変更が起きにくいとアドバイスいただき変更しました。ありがとうございます！！

Angular2でHTTP Interceptorを使いたい

3/31 に酒を飲みながら Angular について話す素敵な催し[ng-sake](http://connpass.com/event/27707/)が開催されたので、Angular2 のユニットテストについて話て来ました。



当日のレポートは主催の[らこ](https://twitter.com/laco0416)さんが書いたものを参照ください。

- [ng-sake を開催しました | Angular2 Info](http://ng2-info.github.io/2016/03/31/ng-sake-1-report/)

## 当日の模様

Angular を使い込んでいる人が多かったので、濃い内容の話ばかりでした。

> [やばい、参加者がニッチすぎて面白い](https://twitter.com/mitsuruog/status/715153394558705664)

> [わいわい、がやがや。こういう形式もありだよね。angular に関わる人の熱意を感じる ](https://twitter.com/mitsuruog/status/715160894632828930)

> [ディレクトリ構成が盛り上がってて楽しいｗ](https://twitter.com/mitsuruog/status/715149679609192448)

## 発表内容

私の資料はこちらです。

[Angular 2 unit testing overview](https://www.slideshare.net/mitsuruogawa33/angular-2-unit-testing-overview)

Angular2 は別物になっているので、テスト周りの状況も心配していたのですが、結論としては Angular1 とあまり大差なかったです。

こちらに比較表作ってみました。

[Angular 1 to 2 Quick Reference In unit testing](https://gist.github.com/mitsuruog/9e3e5c2c5d17a15a4c2a)

当日紹介したテストのサンプルコードはこちらです。

<https://github.com/mitsuruog/_angular2-unit-test-sample>

[Angular2 Unit Testing - カバレッジ編 | I am mitsuruog](http://blog.mitsuruog.info/2016/03/how-to-test-angular2-application-coverage.html)で紹介したカバレッジが出る仕組みが入っています。
カバレッジフェチの方は動かして楽しめると思います。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/ng-sake-coverage.png)

## まとめ

Angular2 のテストについては公式のドキュメントが足りていない、かつアップデートが激しいです。
最新の情報をチェックしたい場合、生のコードを読みつつ、本家のリポジトリのテストコードを見るのが一番確実です。

最後に、主催の[らこ](https://twitter.com/laco0416)さん、[83](https://twitter.com/armorik83)さん、本当にありがとうございました。
今後も続くといいなー。

ng-sake #1 でAngular2のテストについて話てきた

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は XHR が関連するテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## XHR のテスト

XHR 通信が関連するテストについて紹介します。

Angular1 には XHR 通信を行う`$http`サービスがありました。
XHR 通信をテストする場合は、`$http`を Mock する[$httpBackend](https://docs.angularjs.org/api/ngMock/service/$httpBackend)を利用し、実際の XHR 通信を`$httpBackend`でダミーのレスポンスに置き換えてテストを行っていました。

Angular2 にも`MockBackend`という`$httpBackend`と同様の役割のものがありますので、利用方法について紹介します。

- [MockBackend - ts](https://angular.io/docs/ts/latest/api/http/testing/MockBackend-class.html)

## 標準 HTTP の Mock を準備する(beforeEachProviders)

`MockBackend`は`@Injectable`指定されているため、他の Provider と同様に`beforeEachProviders`で呼び出した後に、`inject`でテストコード中に DI して利用する必要があります。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  beforeEachProviders(() => [
    BaseRequestOptions,
    MockBackend,
    provide(Http, {
      useFactory: function (backend, defaultOptions) {
        return new Http(backend, defaultOptions);
      },
      deps: [MockBackend, BaseRequestOptions],
    }),
    HeroService,
  ]);

  // ...省略
});
```

上のコードでは、`Provider`API を利用して、テスト専用の`HTTP`を生成しています。
`Provider`は、Angular2 の中で`@Injecter()`によって DI がされる際にインスタンスの生成方法を指定する API です。

- [Provider - ts](https://angular.io/docs/ts/latest/api/core/Provider-class.html)

ここでは、`dependencies`で`HTTP`が利用している Provider を DI し、`useFactory`内部で新しい`HTTP`インスタンスを作成しています。
インスタンスを作成する際の`backend`に、`dependencies`で指定した`MockBackend`が設定されます。

`dependencies`に設定している各 Provider は、後にダミーのレスポンスを返却する設定を DI するための楔(くさび)だと考えてください。

## ダミーのレスポンスを設定する(inject)

続いてダミーのレスポンスを設定します。

先に生成した`HTTP`がテスト対象の Service に DI されるタイミングで、`inject`を利用して`MockBackend`のレスポンスをダミーで書き換えます。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  // ...省略

  beforeEach(inject([MockBackend], (backend: MockBackend) => {
    const response = new Response(
      new ResponseOptions({
        body: {
          data: [
            { id: "1", name: "mitsuru" },
            { id: "2", name: "ogawa" },
          ],
        },
      })
    );
    backend.connections.subscribe((conn: MockConnection) =>
      conn.mockRespond(response)
    );
  }));

  // ...省略
});
```

ダミーのレスポンスを返却する部分は少しややこしいですが、まずは形から入りましょう。

大事な部分は`ResponseOptions`にダミーのレスポンスを設定する部分です。
上の例では、body の`data`プロパティにダミーのオブジェクトを設定しています。他にも設定できるプロパティが存在するので、詳しくは API を参照してください。

- [ResponseOptions - ts](https://angular.io/docs/ts/latest/api/http/ResponseOptions-class.html)

実際のレスポンスは`MockConnection`を利用して行います。他にも`mockDownload`, `mockError`など使えそうな API があります。

- [MockConnection - ts](https://angular.io/docs/ts/latest/api/http/testing/MockConnection-class.html)

`ResponseOptions`の部分はダミーレスポンス専用のクラスにしておき、テストコードの先頭で import して利用するともっとスッキリすると思います。

## テストを検証する(it)

では XHR 通信が正しく Mock されているか検証します。

その前に、テスト対象の HeroService についてです。
HeroService は、`Hero`のリストを XHR 通信で取得した後に、Observable でラップして返却する(Angular2 的には)シンプルなデータアクセスクラスだとします。

**hero.service.ts**

```ts
@Injectable()
export class HeroService {
  getHeroes(): Observable<Hero[]> {
      return this.http.get(this.URL)
        .map(res => <Hero[]>res.json().data);
    }
}
```

先ほどの設定してダミーレスポンスを実際に検証してみます。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  // ...省略

  it("2件取得できること", inject([HeroService], (testee: HeroService) => {
    testee.getHeroes().subscribe((res: Hero[]) => {
      expect(res.length).toEqual(2);
      expect(res[0].name).toEqual("mitsuru");
    });
  }));
});
```

無事、2 件取得できることが確認できました。
めでたし。めでたし。

## まとめ

HTTP のテストについてでした。

テストの全体像についてはこちらを参考にしてください。

<https://github.com/mitsuruog/_angular2_http>

Unit テスト全般に言えることですが、テストを行うための Mock などの下準備が非常に面倒くさいです。
下準備は定型文的なものが多いため、再利用できるようスニペットなどにしておくことが大事です。

今回は、Service クラスを題材にしたため、テストコードの中で HTTP を置き換えています。
Component など HTTP から遠いレイアーでは、今回のように HTTP を置き換えるのではなく、Service クラスごと Mock 化して`beforeEachProviders`で Service クラスを置き換え方がテストしやすいと思います。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - XHRのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は DOM が関連するテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## DOM のテスト

DOM のテストについて紹介します。

DOM のような状態が不安定なものをテストする場合、テスト対象の状態を一定に固定するため、`fixture`と呼ばれる土台(仮の DOM)を利用してきました。
Angular2 の DOM のテストでも、これまでと同様に fixture を利用します。

## fixture を準備する(TestComponentBuilder)

まず、テストで利用する fixture を準備します。

Angular2 にはテスト用 fixture を作成するための API`TestComponentBuilder`が準備されています。
`TestComponentBuilder`は、fixture 用の Component を作成して外側から操作・検証する API を提供します。

DOM のテストのおおまかな流れは次のような形です。

```ts
import {
  it,
  describe,
  expect,
  inject,
  injectAsync,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder
} from 'angular2/testing';
import {Component} from 'angular2/core';

describe('DOMのテスト', () => {

  beforeEachProviders(() => [
    TestComponentBuilder
  ]);

  it('なにかのテスト', injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    // ここに実際のテストコードを書く
  }));

});

// fixture用Component
@Component({ selector: 'container' })
class TestComponent { }
```

`TestComponentBuilder`は`@Injectable`指定されているため、他の Provider と同様に`beforeEachProviders`で呼び出した後に、`injectAsync`でテストコード中に DI して利用する必要があります。

続いて、テストで利用する使い捨て Component を作成します。これをテスト用 fixture として利用します。

- [TestComponentBuilder - js](https://angular.io/docs/js/latest/api/testing/TestComponentBuilder-class.html)

## fixture を作成する(overrideTemplate, createAsync)

続いて実際に fixture を作成します。

テスト用 fixture が準備できたので、この Component をテンプレートを上書きして DOM を作成します。

```ts
// itの部分だけ抜粋
it(
  "なにかのテスト",
  injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    let template = "<div>Hello Angular2 :)</div>";
    return tcb
      .overrideTemplate(TestComponent, template)
      .createAsync(TestComponent)
      .then((fixture) => {
        // ここに検証コードを書く
      });
  })
);
```

`overrideTemplate`に Component と上書きするテンプレートを渡して、`createAsync`を呼び出すと、実際にテストする fixture が作成されます。

実際には、テンプレートに Component や Directive を含めることが多いかと思います。
Angular1 での`$compile(template)($rootScope)`とほぼ同じものだと考えて大丈夫です。

`TestComponentBuilder`で作成された fixture は`ComponentFixture`クラスなり、次のようなテストで利用する API が準備されています。

- debugElement
  - テスト用の Helper クラス
- componentInstance
  - TestComponent のインスタンス
- nativeElement
  - テスト用 fixture の HTMLElement を表す
- detectChanges()
  - テスト中に Component を変更するために、Component の変更検知サイクルを発火します。

よく利用するものについて紹介します。

- [ComponentFixture - js](https://angular.io/docs/js/latest/api/testing/ComponentFixture-class.html)

## fixture を検証する API(nativeElement)

`nativeElement`はテスト用 fixture の`HTMLElement`を返す API です。
`HTMLElement`は HTML 標準の API であるため、これを利用してテスト用 fixture を検証・操作します。

[HTMLElement - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement)

```ts
// itの部分だけ抜粋
it(
  "なにかのテスト",
  injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    let template = "<div>Hello Angular2 :)</div>";
    return tcb
      .overrideTemplate(TestComponent, template)
      .createAsync(TestComponent)
      .then((fixture) => {
        let div = fixture.nativeElement.querySelector("div");
        // HTMLElementを検証する
        expect(div).toHaveText("Hello Angular2 :)");
      });
  })
);
```

## fixture を変更する(detectChanges)

`detectChanges()`は、Angular1 の`scope.$digest()`に似ており、強制的に Angular へ変更を検知させる仕組みです。

Angular2 内部では Angular1 の`dirty checking`に代わる独自の変更検知サイクルを持っています。
テストで Click イベントなどの非同期を利用する場合、この変更検知サイクルを発火して Angular2 に変更を検知させる必要があります。

Angular2 の変更検知サイクルについてはこの記事が詳しいです。

- [Change Detection in Angular 2 | Victor Savkin](http://victorsavkin.com/post/110170125256/change-detection-in-angular-2)

次のテストコードは、マウスが当たると文字色が red に変わる Component のテストだと仮定します。

```ts
// ... describeの部分だけ抜粋
describe("DOMのテスト", () => {
  let mouseenter;

  beforeEachProviders(() => [TestComponentBuilder]);

  beforeEach(() => {
    // mouseenterイベントを定義します
    mouseenter = new MouseEvent("mouseenter", {
      view: window,
      bubbles: true,
      cancelable: true,
    });
  });

  it(
    "mouseenterするとredに変わること",
    injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
      let template = "<div>Hello Angular2 :)</div>";
      return tcb
        .overrideTemplate(TestComponent, template)
        .createAsync(TestComponent)
        .then((fixture) => {
          let div = fixture.nativeElement.querySelector("div");

          // mouseenterイベントを強制的に起こします
          div.dispatchEvent(mouseenter);

          // detectChangesしないと変更が検知されない
          expect(div.style.backgroundColor).toEqual("red"); // => NG
          fixture.detectChanges();
          expect(div.style.backgroundColor).toEqual("red"); // => OK
        });
    })
  );
});
```

## まとめ

DOM についてのテストは以上です。

DOM が関連するテストはやはり面倒ですね。メンバーの習熟度や学習コストを鑑みて、自動テストをしないという選択肢もありだと思います。
テストコードの全体像は、こちらで雰囲気をつかめると思います。

[\_angular2-attribute-directive/highlight.directive.spec.ts at master · mitsuruog/\_angular2-attribute-directive](https://github.com/mitsuruog/_angular2-attribute-directive/blob/master/app%2Fcomponents%2Fhighlight.directive.spec.ts)

今回の例では、検証に fixture の`nativeElement`を利用していましたが、`debugElement`についてはまだ利用用途があまりはっきりとわかっていません。
機会があれば、もう少し掘り下げようかと思います。

- [DebugElement - js](https://angular.io/docs/js/latest/api/core/DebugElement-class.html)

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - DOMのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は Pipe のテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## Pipe のテスト

Pipe のテストについて紹介します。

Angular2 の Pipe は Angular1 の filter に相当するものです。
Linux コマンドの`|(パイプ)`と同義で、入力内容を Pipe 内で(transform, replace など)処理し、結果を出力する単純なものです。

## Pipe のテストは至ってシンプル

文の区切りの最初の文字を大文字にする Pipe をテストします。

```
例）
abc     => Abc
abc def => Abc Def
```

Pipe のコードはこちらです。

**init-caps.pipe.ts**

```ts
import {Pipe, PipeTransform} from 'angular2/core';

@Pipe({
  name: 'initCaps'
})
export class InitCapsPipe implements PipeTransform {
  transform(value: string): string {
    return value.toLowerCase().replace(/(?:^|\s)[a-z]/g, (m) => m.toUpperCase());
  }
}
```

Pipe は単純な class であるため、テストクラス内でインスタンスを生成してテストします。
至ってシンプルです。

下の例では、`beforeEach`でテスト対象の Pipe を読み込んでテストしています。

**init-caps.pipe.spec.ts**

```ts
import {
  describe,
  it,
  expect,
  inject,
  injectAsync,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder,
} from "angular2/testing";

import { InitCapsPipe } from "./init-caps.pipe";

describe("Test: InitCapsPipe", () => {
  let testee;

  beforeEach(() => {
    testee = new InitCapsPipe();
  });

  it('"abc"が”Abc”に変換されること', () => {
    expect(testee.transform("abc")).toEqual("Abc");
  });

  it('"abc def"が”Abc Def”に変換されること', () => {
    expect(testee.transform("abc def")).toEqual("Abc Def");
  });

  it('"Abc Def"は変換されないこと', () => {
    expect(testee.transform("Abc Def")).toEqual("Abc Def");
  });
});
```

ただし、Pipe 内部で DI している provider がある場合は、`beforeEachProviders`で読み込んだ後に`inject`で DI する必要があるでしょう。

## まとめ

Pipe のテストは以上です。

Pipe は構造がシンプルなためテストも簡単です。テストの最初にトライするものとしては最適だと思います。
サンプルコードはこちらを参照してください。

[mitsuruog/\_angular2_pipe](https://github.com/mitsuruog/_angular2_pipe)

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - Pipeのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は基本編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## 基本編

Angular1 は他の JavaScript フレームワークと比較して、テスタビリティ(テストのしやすさを)重視したフレームワークでした。

Angular2 もテスタビリティを重視したフレームワークとなっており、本体の API の中に`angular2/testing`, `angular2/http/testing`, `angular2/router/testing`などテスト専用のものが組み込まれていることからも伺い知ることができます。

## テストフレームワークは Jasmine が基本

テストフレームワークは[Jasmine](http://jasmine.github.io/2.4/introduction.html)を利用します。
これは、`angular2/testing`の中で Jasmine の API を overwrap しているためです。
いまのところ、Angular2 のテストは Jasmine を利用したほうが幸せになれると思います。

## テストクラスの構成

簡単なテストクラス(.ts ファイル)の構成についてです。
ファイル名は慣例としてテスト対象のファイルに`.spec.ts`を付けることが多いです。

```
例）
hero.service.ts
-> hero.service.spec.ts
```

`angular2/testing`の中で Jasmine の API を overwrap しているため、基本的には Jasmine の書き方と同じです。  
テストクラスに含まれる要素は大きく 3 つです。

1. import
1. describe
1. it
1. expect

### テストで利用するモジュールを読み込む(import)

import 部分では、テストで利用するモジュールを読み込みます。  
最低限`angular2/testing`とテストするモジュールを読み込む必要があります。

```ts
import {
  describe,
  it,
  inject,
  injectAsync,
  expect,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder
} from 'angular2/testing';

import {HeroService} from './hero.service';

...つづく
```

### テストケースをグルーピングする(describe)

複数のテストケースをまとめてグルーピングします。
`describe`はネストできるため、複数のテストケースをグルーピングして見通しを良くすることができます。

```ts
describe("Test: なにかのServiceのテスト", () => {
  describe("Test: 正常系", () => {});

  describe("Test: 異常系", () => {});
});
```

### テストケースを記述する(it)

`it`には実際のテストケースを記述していきます。`it`の中にはテストを検証するためにいくつかの`expect`が含まれます。

```ts
describe("Test: 正常系", () => {
  it("ステータスコードが200であること", () => {});
});
```

### テストを検証する(expect)

`expect`はテストを検証する function です。`matchar`とも呼ばれます。

`expect`は用途に応じていくつか種類があり、`angular2/testing`の`expect`は Jasmine の matchar を overwrap しているため、Jasmine の API はそのまま利用できます。
他にも Angular2 独自で拡張している matchar(NgMatchers)もあります。詳細については割愛します。

[NgMatchers - ts](https://angular.io/docs/ts/latest/api/testing/NgMatchers-interface.html)

```ts
expect(testee).not.toBe(undefined);
```

全体像はこちらで雰囲気を掴んでください。

[app.component.spec.ts](https://github.com/mitsuruog/angular2-minimum-starter/blob/master/app%2Fapp.component.spec.ts)

つづいて Angular2 ならではの機能について紹介します。

## beforeEachProviders

`beforeEachProviders`はテストで利用するモジュールを override する仕組みです。
Angular1 の`$provide`を利用したモジュールの上書きや、[angular.mock.inject](https://docs.angularjs.org/api/ngMock/function/angular.mock.inject)(`_moduleName_`の気持ち悪いやつ)と同等です。

```js
// Angular1($window.locationを上書きする例)
beforeEach(function () {
  module(function ($provide) {
    $window = {
      location: { href: null },
    };
    $provide.value("$window", $window);
  });
});
```

```ts
// Angular2(MyServiceをMyServiceMockで上書きする例)
describe("", () => {
  beforeEachProviders(() => [
    provide(MyService, {
      useClass: MyServiceMock,
    }),
  ]);
});
```

beforeEachProviders では Provider と呼ばれる`Injector`インタフェース(`@Injectable`指定したもの)を持つものや、`@Component`を設定します。(要確認)

[beforeEachProviders - ts](https://angular.io/docs/ts/latest/api/testing/beforeEachProviders-function.html)

## inject, injectAsync

`inject`, `injectAsync`は beforeEachProviders で読み込んだ Provider を`it`や`describe`の中に DI します。
Angular1 での inject と同等のものです。

Angular2 でも`@Injectable`を利用した強力な DI 機能を持っており、異なる`it`のコンテキストの中で利用する Provider を柔軟に選択することができます。

```js
// Angular1
it("should provide a version", inject(function (mode, version) {
  expect(version).toEqual("v1.0.1");
  expect(mode).toEqual("app");
}));
```

```ts
// Angular2
it('should provide a version', inject([mode, version], (mode: string, version: string) => {
  expect(version).toEqual('v1.0.1');
  expect(mode).toEqual('app');
});
```

`injectAsync`は`it`や`describe`の中が非同期の結果を返す場合に利用します。

```ts
it('...', injectAsync([AClass], (object) => {
  return object.doSomething().then(() => {
    expect(...);
  });
})
```

## まとめ

基本編は以上です。

Angular1 と同じ系譜を辿っていることがわかると思いますが、モジュールの override の部分が少し洗練されてきたかなと感じます。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - 基本編

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回はカバレッジ編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## カバレッジ編

> コード網羅率（コードもうらりつ、英: Code coverage ）コードカバレッジは、ソフトウェアテストで用いられる尺度の 1 つである。プログラムのソースコードがテストされた割合を意味する。
> [コード網羅率 - Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E7%B6%B2%E7%BE%85%E7%8E%87)

カバレッジを取得することのメリットは、コードの危ない部分に対して効果的にテストができているか客観的に評価できることです。。
特に HTML 形式のレポートは、コードとテストを実行した部分を重ねて表示することができ、結果を視覚的に見やすくしてくれます。

最近の JavaScript のテストではカバレッジ取得のための環境が整ってきたこともあり、積極的に活用していくべきです。

## karma-coverage でカバレッジを測定する

Karma でカバレッジを取得するためには、プラグインの 1 つである[karma-coverage](https://github.com/karma-runner/karma-coverage)を利用します。
早速、リポジトリの`devDependency`に追加します。

```
npm install karma karma-coverage --save-dev
```

続いて`karma.conf.js`の設定を変更します。

**karma.conf.js**

```js
'use strict';
// Karma configuration

let baseLibs = [...];

module.exports = function (config) {
  config.set({

    // ...省略

    // (1)
    // (*.spec.js, *.mock.js)以外のJavaScriptファイルをカバレッジ測定の対象とします
    preprocessors: {
      "app/**/!(*spec|*mock).js": ['coverage']
    },

    // (2)
    // テスト完了時のreporterにカバレッジ用reporterを設定します
    reporters: ['mocha', 'coverage'],

    // (3)
    // カバレッジ用reporterの出力先, フォーマットを指定します
    // see https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md
    coverageReporter: {
      dir : 'report/coverage/',
      reporters: [{
        type: 'html'
      }]
    }

    // ...省略

  })
}
```

テストを実行すると`report/coverage`の直下に HTML 形式のカバレッジレポートが出力されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-1.png)

karma-coverage 内部では、JavaScript のカバレッジ測定ツールとして有名な[istanbul](https://github.com/gotwarlost/istanbul)を利用しています。
HTML レポートでは、ディレクトリやファイルごとにカバレッジを知ることができます。これを見ながらカバレッジの低い部分などに追加のテストを書いていきます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-2.png)

コードとテスト実行した部分を重ねあわせて表示することで、テストが不足している部分を容易に発見できます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-3.png)

ところがこのままでは、レポートのコードが ts ファイルをトランスパイルした JavaScript ファイルとなっているため、実際に作成した ts ファイル上のどの部分に該当するかが非常に分かりにくいです。

## remap-istanbul で ts ファイルとリンクさせる

先ほどのカバレッジレポートを改良してトランスパイル前の ts ファイルをリンクさせます。リンクさせるには[remap-istanbul](https://github.com/SitePen/remap-istanbul)を利用します。

remap-istanbul とは、ts ファイルをトランスパイルした際に生成される SouceMap(ここでは inline SouceMap)を元に、カバレッジレポートをオリジナルの ts ファイルにリンクさせるツールです。
早速、リポジトリの`devDependency`に追加します。

```
npm install karma remap-istanbul --save-dev
```

続いて`karma.conf.js`の設定を変更します。カバレッジレポートのフォーマットを`html`ではなく`json`に変更します。

**karma.conf.js**

```js
'use strict';
// Karma configuration

let baseLibs = [...];

module.exports = function (config) {
  config.set({

    // ...省略

    // (1)
    // (*.spec.js, *.mock.js)以外のJavaScriptファイルをカバレッジ測定の対象とします
    preprocessors: {
      "app/**/!(*spec|*mock).js": ['coverage']
    },

    // (2)
    // テスト完了時のreporterにカバレッジ用reporterを設定します
    reporters: ['mocha', 'coverage'],

    // (3)
    // カバレッジ用reporterの出力先, フォーマットを指定します
    // see https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md
    coverageReporter: {
      dir : 'report/coverage/',
      reporters: [{
        type: 'json',
        subdir : '.',
        file : 'coverage-final.json',
      }]
    }

    // ...省略

  })
}
```

テストを実行すると`report/coverage/coverage-final.json`に JSON 形式のカバレッジレポートが出力されます。
これを remap-istanbul で HTML 形式のレポートに仕立てて行きます。

```
node_modules/.bin/remap-istanbul -i report/coverage/coverage-final.json -o report/coverage/ -t html
```

コマンドを実行すると`report/coverage`の直下に HTML 形式のカバレッジレポートが出力されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-4.png)

今度は ts ファイルとカバレッジレポートがリンクするようになりました。
めでたし。めでたし。

## まとめ

カバレッジの取り方とレポートの表示についてでした。
HTML レポートの出力方法は他にもあると思いますので、いろいろ試してみるといいでしょう。
カバレッジレポートを取得することで、テストが十分でない箇所を明らかにすることができ、つまらないテストにゲーム的な要素が加わってテストを書くことが楽しくなります。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんカバレッジも取得できます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - カバレッジ編

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は準備編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## 準備編

Angular1 の場合と同様に、Angular2 でもユニットテストを実行する前に少し下準備が必要です。
今回は、Angular1 経験者向けに変更点などを紹介します。

サンプルはこちらを参考にしてください。
[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

## Karma ＋ Jasmine の構成はそのまま利用できる

ユニットテストの構成は Angular1 と同じ構成です。

- テストランナー
  - [Karma](https://karma-runner.github.io/0.13/index.html)
- テスティングフレームワーク
  - [Jasmine](http://jasmine.github.io/2.4/introduction.html)

Karma の設定は次のような形です。

**karma.conf.js**

```js
"use strict";
// Karma configuration

let baseLibs = [
  "node_modules/systemjs/dist/system-polyfills.js",
  "node_modules/systemjs/dist/system.js",
  "node_modules/es6-shim/es6-shim.js",
  "node_modules/rxjs/bundles/Rx.js",
  "node_modules/angular2/bundles/angular2-polyfills.js",
  "node_modules/angular2/bundles/angular2.dev.js",
  "node_modules/angular2/bundles/router.dev.js",
  "node_modules/angular2/bundles/http.dev.js",
];

module.exports = function (config) {
  config.set({
    // base path that will be used to resolve all patterns (eg. files, exclude)
    basePath: "",

    // frameworks to use
    // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
    frameworks: ["jasmine"],

    // list of files / patterns to load in the browser
    files: [
      ...baseLibs,
      "node_modules/angular2/bundles/testing.dev.js",
      "karma.shim.js",
      { pattern: "app/**/*.js", included: false },
    ],

    // list of files to exclude
    exclude: [],

    // preprocess matching files before serving them to the browser
    // available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
    preprocessors: {},

    // test results reporter to use
    // possible values: 'dots', 'progress'
    // available reporters: https://npmjs.org/browse/keyword/karma-reporter
    reporters: ["mocha"],

    // web server port
    port: 9876,

    // enable / disable colors in the output (reporters and logs)
    colors: true,

    // level of logging
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,

    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: true,

    // start these browsers
    // available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
    browsers: ["Chrome"],

    // Continuous Integration mode
    // if true, Karma captures browsers, runs the tests and exits
    singleRun: false,

    // Concurrency level
    // how many browser should be started simultaneous
    concurrency: Infinity,
  });
};
```

~~Karma の設定ファイルの`frameworks`にてテスティングフレームワークを変更できるので、mocha など他のものを利用することもできると思います。~~  
(2016-03-10 追記) Angular2 内部で Jasmine の DefinitelyTyped を参照しているため、Jasmine を使った方が幸せになれる気がします。

`karma.shim.js`という見慣れないファイルについては後で説明します。

## モジュールロードシステムが独自から systemjs に変更となった

Angular2 で大きく変わった点の一つは、モジュールロードシステムが[systemjs](https://github.com/systemjs/systemjs)に変更された点です。

Angular1 はモジュール名の名前解決による独自のモジュールロードシステムを持っていました。
基本的には`<script>`タグでロードした外部スクリプトを、Angular 上でモジュールとして再ロードすることで利用していました。

Angular2 では systemjs の設定ファイルにて利用する外部スクリプトを定義して、systemjs を介してモジュールをロードするようになります。
これまではテストランナーでテスト用のファイル一式をロードすれば十分でしたが、間に systemjs が 1 枚存在する形になります。

そこで、`karma.shim.js`の登場です。

## karma.shim.js とは

`karma.shim.js`とは、テストを行う前に systemjs にてモジュールがロードされていることを保証するために、Karma と systemjs の初期化のタイミングを制御する役割をするものです。

`karma.shim.js`の処理を大きく分けると次の 3 ステップでテストを実行しています。

1. systemjs 内にアプリケーションの静的リソースをロード
1. テスト用のブラウザと接続
1. Spec をロード&テスト実行

[refs](https://github.com/mitsuruog/angular2-minimum-starter/blob/master/karma.shim.js)

## サンプル Spec を作成して実行してみる

最後に簡単な Spec を実装してみます。シンプルな`AppComponent`です。

**app.component.ts**

```ts
import {Component, OnInit} from 'angular2/core';

@Component({
  selector: 'my-app',
  template: `
    <h1>Angular2 Minimum Starter Kit</h1>
  `
})

export class AppComponent {}
```

Spec を書いてみます。

**app.component.spec.ts**

```ts
import { Component, provide } from "angular2/core";
import {
  it,
  inject,
  injectAsync,
  beforeEachProviders,
  TestComponentBuilder,
} from "angular2/testing";

import { AppComponent } from "./app.component";

describe("Test: AppComponent", () => {
  beforeEachProviders(() => [AppComponent]);

  it("AppComponentが存在すること", inject(
    [AppComponent],
    (testee: AppComponent) => {
      expect(testee).toBeDefined();
    }
  ));
});
```

テストを実行してみます。

```
karma start karma.conf.js
```

テストを実行すると結果が表示されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-1-run.png)

## まとめ

モジュールロードシステムが SystemJS に変更されたことで、少し面倒になりましたがこれで Angular1 と同様にユニットテストを行う準備ができるはず！！

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんすぐテストできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

### 参考

- [juliemr/ng2-test-seed: Work in Progress - Example, cloneable setup for an Angular2 application with tests.](https://github.com/juliemr/ng2-test-seed)
- [ghpabs/angular2-seed-project: Angular 2 Seed Project – Gulp, TypeScript, Typings, Karma, Protractor, Sass and more.](https://github.com/ghpabs/angular2-seed-project)

Angular2 Unit Testing - 準備編

SPA を構築する場合、Component をまたがったデータの共有をどのように実現するかが重要になってきます。  
Angular1 の場合は、SharedService を利用するケースが多かったです。  
そこで Angular2 でも試してみようとしたところ、少し勝手が違ったので自分用メモを残しておきます。



## 結論

- Angular2 では基本的に`@Injectable()`の DI は新規のインスタンスを生成します。
- Singleton で扱いたい場合は、`bootstrap(.., [ServiceA,ServiceB])`で DI すること。

## サンプル

Angular2 の公式ページでよく利用される HeroList を例に説明します。

- 画面の component は一覧(HeroListComponent)と詳細(HeroDetailComponent)の 2 つ。
- Hero 一覧データは HeroService に格納され、各 component は HeroService を参照する。

簡単な図に示すとこのような構造をしていると仮定します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/IMG_20160229_001319.png)

## 失敗パターン

すべてのサンプルはこちら  
[plnkr](http://plnkr.co/edit/R1q9vzDa1gHXHBUClu1s?p=preview)

失敗パターンでは、HeroDetailComponent にて Hero を削除しても消えません。  
これは HeroDetailComponent の`providers`で HeroService を DI した場合、新規でインスタンスを生成してしまうためです。
結果、HeroListComponent と HeroDetailComponent では、別の HeroService のインスタンスを参照していることになっています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/IMG_20160229_001409.png)

HeroDetailComponent で`@Component`を DI している箇所を抜粋します。

**hero-detail.component.ts**

```ts
import {Component,  Input}  from 'angular2/core';
import {Hero, HeroService}   from './hero.service';

@Component({
  selector: 'hero-detail',
  template: `
  <span class="badge">{{hero.id}}</span> {{hero.name}}
  <button (click)="remove()">remove</button>
  `,
  providers:  [HeroService]  // <- ここ
})
export class HeroDetailComponent implements OnInit  {
  @Input() hero: Hero;
  constructor(private service:HeroService){ }
  remove() {
    this.service.remove(this.hero);
  }
}
```

## 成功パターン

すべてのサンプルはこちら  
[plnkr](http://plnkr.co/edit/iYFMhuldCBqay72eWjay?p=preview)

こちらは SharedService として動作しているパターンです。`bootstrap(.., [ServiceA,ServiceB])`で HeroService を指定することで Singleton として扱うことができます。  
HeroDetailComponent で Hero を削除した場合、HeroListComponent の一覧も消えます。

**main.ts**

```ts
import { bootstrap } from "angular2/platform/browser";

import { AppComponent } from "./app.component";
import { Hero, HeroService } from "./heroes/hero.service";

bootstrap(AppComponent, [HeroService]);
```

## まとめ

Angular1 っぽい SharedService の作り方でした。  
正直、Two-way-binding と SharedService を利用した、手続き型っぽいやり方が Angular2 で最良の方法がどうかはわかりません。  
Angular2 でのベストプラクティスについてはまだ手探りな感じがします。

とはいえ、Angular1 を慣れている方であれば、Angular2 でも Component 間のデータ共有は SharedService でできることが分かりました。

refs [Angular2 "Services" how to @inject one service into another (singletons) - Stack Overflow](http://stackoverflow.com/questions/33575456/angular2-services-how-to-inject-one-service-into-another-singletons)

Tag: angular