
JavaScript のテストフレームワーク[Jest](https://jestjs.io/en/)の小ネタです。

最近 react や react-native のプロジェクトでモジュールの参照に alias を使うことが多いのですが、Jest でこれを扱う方法について紹介です。

## alias を使ったモジュール参照

alias を使ったモジュール参照とは、プロジェクト内の特定のディレクトに別名(alias)をつけることで、`import`文の記述を簡単にすることです。

例えば、次のような相対パスでモジュールを import している箇所に alias を使ってみましょう。

```ts
// greet.ts は src/shared/services にあるとする
import { greet } from "../../../greet.ts";
```

alias を使う場合は、まず`src/shared`に`Shared`という alias をつけます。そうすると次のように相対パスを除いて書くことができます。

```ts
// Shared は src/shared を参照している
import { greet } from "Shared/services/greet.ts";
```

alias を使うメリットとしては、`import`文の記述を簡略化することもあるますが、相対パスを使った場合よりリファクタなどの変更に強いことが挙げられます。

## moduleNameMapper を使って alias を扱う

Jest で alias を扱うためには`moduleNameMapper`を使って alias と実際のパスをマッピングします。

- <https://jestjs.io/docs/en/configuration#modulenamemapper-object-string-string>

上の例の場合は次のようになります。

```js
module.exports = {
  moduleNameMapper: {
    "^Shared(.*)$": "<rootDir>/src/shared/$1",
  },
};
```

これで Jest でも、alias を使ったモジュール参照があるプロジェクトをテストすることができました。


Jestでaliasを使ったモジュール参照を扱う

[create-react-app](https://github.com/facebookincubator/create-react-app)で作っている React アプリを Circle CI 2.0 でビルドする手順について紹介します。

今回説明するのは、CircleCI 2.0 を使う上での大まかな流れについてです。



## 前提条件

フロントエンドのプロジェクトには`test`と`build`のタスクがあって、全て`npm run`で実行できるとします。
またデプロイについては、`build`タスクで 1 つのバンドルファイルを作成して S3 にデプロイします。

## 定義ファイルを作成する

まずは定義ファイルを作成する必要があります。設定ファイルは`.circleci`フォルダの中に`config.yml`を作成して定義していきます。

```
root
  .circleci
    config.yml
```

定義ファイルのシンタックスについては v1.0 と比べると結構変わっているので注意が必要です。
Slack の作業ログを見ると、Dashboard のどこかで定義ファイルが生成できたようですが、どこだか忘れてしまいました。

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

定義ファイルを生成すると次のようなファイルが作成されます。

デフォルトでは CircleCI が準備した Docker image を使います。(`image: circleci/node:8.9`の部分)
node, npm, yarn は既に image に含まれているので、最小構成であればこれで大丈夫だと思います。

```
# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
  build:
    docker:
      # specify the version you desire here
      - image: circleci/node:8.9

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/mongo:3.4.4

    working_directory: ~/workspace

    steps:
      - checkout

      # Download and cache dependencies
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}
          # fallback to using the latest cache if no exact match is found
          - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      # run tests!
      - run: yarn test
```

定義ファイルの書き方については公式サンプルプロジェクトを見てください。

- <https://github.com/CircleCI-Public/circleci-demo-javascript-express>

## Docker image を作成する

**（この工程は必要な場合のみです。）**

デフォルトでは CircleCI が準備した Docker image を使うのですが、これをさらにカスタムしてツールなどを導入したい場合は、新しく Docker image を準備する必要があります。

自分の場合、S3 にデプロイする場合は AWS-CLI ツールを利用するので、これをインストールした image を作成する必要がありました。
image を作成する際は、`circleci/node:8.9`を継承することができますので、ぜひそうしましょう。

```
FROM circleci/node:8.9

# ここから下にいろいろ定義する
...
```

実際に作成した image はこちらです。

- <https://hub.docker.com/r/mitsuruog/cool-build-frontend/>

docker image の作成方法についてはこちらを参照してください。

- [docker image を docker hub に公開する方法](https://blog.mitsuruog.info/2017/11/way-to-publish-docker-image)

## Job を定義する

次に Job を定義します。この後の手順としては、`Job`を定義してこれをワークフローの中で順番に呼び出していきます。

Job とは、CircleCI の中で再利用できると便利だなと思う一連のタスクをまとめたものです。例えば、`test` とか`test and build`などがそれにあたります。
とにかく次のワークフローの中ではこの**ジョブ名**を利用してフローを作成するので、このことを意識して定義するといいと思います。

基本的には`jobs:`の直下にタスク名(上の例では`build:`)を定義して、`steps:`の中にやりたいことを順番に書いていきます。
この辺りは 1.0 をやったことがある人であれば、想像できると思います。

```
version: 2
jobs:
  build:
    steps:
      - run step1
      - run step2
      - run step3
      ...
```

細かな設定は公式ドキュメントを参考にしてください。

- [Configuration Reference](https://circleci.com/docs/2.0/configuration-reference/)

## ワークフローを定義する

最後に定義した Job をワークフローとして組み立てていきます。

基本的には`workflows:`の直下にワークフロー名を定義して、`jobs:`の中にやりたいことを順番に書いていきます。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
      - deploy
```

ちなみに`test`などの、次の Job に進む前に完了していなければならない Job がある場合、`requires`を使うことで表現することができます。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
          requires:
            - test
      - deploy
          requires:
            - build
```

この場合、`test` -> `build` -> `deploy`の順にワークフローが実行されます。
ワークフローを定義する場合、同じ階層にある Job は並列に実行されるため、`requires`でフローの制御は必須だと思います。

また、特定のブランチのみ実行させたい場合は、`filters`と`branches`を組み合わせることで表現可能です。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
          filters:
            branches:
              only:
                - develop
```

この場合は`develop`プランチの場合のみ build の Job が実行されるようになります。

定義したワークフローは CircleCI 上の「WORKFLOWS」にて確認することができます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/circleci2.0-2.png)

## おまけ

Circle CI のデフォルトのマシンリソースは`medium`(CPU 2.0 RAM 4GB)となっていて、最近のフロントエンドのテスト、デプロイにおいてはスペック不足感が否めません。

> CPU はコア数かな？

自分の場合は、テストで js-dom を使っているのですが、頻繁に次のようなエラーが発生していました。

```
ENOMEM: not enough memory, read
```

そんな時は、`resource_class`でマシンスペックをあげることができます。
しかし、今のところ Circle CI のカスタマーサポートに依頼する必要があります。詳しくはこちらを見てください。

- <https://circleci.com/docs/2.0/configuration-reference/#resource_class>

> 有効にしたい Organization 名と一緒に依頼すると割と早めに対応してくれました。Circle CI のカスタマーサポート素晴らしい！！

> ![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/circleci2.0-3.png)

> とはいえ、将来的には`resource_class`はプレミアム機能になるかもしれないです。要注意！

## まとめ

CircleCI 2.0 でフロントエンドをビルドするための大まかな手順でした。
本題とは全く関係ないのですが、Circle CI のカスタマーサポート迅速でよかったなー。

CircleCI 2.0 の公式ドキュメントについてはこちらを参照してください。

- <https://circleci.com/docs/2.0/>

Circle CI 2.0でフロントエンドをビルドする

ニッチ過ぎて誰得なのか全くわからないのですが、同じようなことで苦しめられるであろう**未来の誰かのため**に、ここに手がかりを残しておきます。



> 正直このあたりのライブラリの変化が早過ぎるので、この情報がいつ風化するかわからないのだけれど。。。

## はじめに

詰まるところ[create-react-app](https://github.com/facebookincubator/create-react-app)をベースに React アプリを作っているのですが、Redux の`connect`を使っているコンポーネントをテストする際に、次のようなエラーが出ました。

これの解決方法を残しておきます。

```
Invariant Violation: You must pass a component to the function returned by connect. Instead received undefined
```

> <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

> これを読むと書いてあるんですが、redux store と一緒テストをする場合は、`<Provider>`でラップする必要があります。

今回は、redux store と切り離して純粋なコンポーネントとしてテストする場合の解決方法です。

## サンプルコード

例えば、こんなコードです。(ラフに書いたので、このままだと動かないかも)

Component.jsx

```
import React from 'react';
import { connect } from 'react-redux';

class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}

const mapStateToProps = (state) => {
  name: state.name,
};

const wrappedComponent = connect(mapStateToProps)(Component);

export default wrappedComponent;
```

Component.spec.jsx

```
import * as React from 'react';
import { shallow } from 'enzyme';
import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## 解決方法

上のやり方では、`Component.jsx`の default export が connect でラップされたコンポーネントなので、上のエラーが発生していました。

コンポーネント自体を connect なしでテストするためには、connect でラップされたものの他に、コンポーネント自体も export する必要があります。

このコンポーネントをテストで利用します。これでエラーも発生しません。

Component.jsx

```diff
- class Component extends React.Component {
+ export class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}
```

Component.spec.jsx

```diff
import * as React from 'react';
import { shallow } from 'enzyme';
+ import { Component } from './Component';
- import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## まとめ

まず、公式ドキュメントに目を通せ！ということでした。

- <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

でも、実際に一度困ってみないと、言っている意味がわからないものですねー。

react-reduxのconnectを使ったコンポーネントをテストする時にInvariant Violationが発生して困っている人のためのヒント

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 - 準備編

github private repository も無料で CI テストできるので[wercker](http://wercker.com/)を使うことが多いです。  
プロジェクト立ち上げ時に設定した後、安定すると放置になる設定周り。ついつい忘れてしまうので、自分用メモ。  
フロントエンドエンジニアでも CI テストできる最小構成です。



## ベースは Node 用の基本構成

まず、自動テストは Node.js で行うようにしていると思うので、Node 用の基本設定をベースにするのがいいと思います。

[wercker - docs - Nodejs](http://devcenter.wercker.com/docs/languages/nodejs.html)

```yml
box: nodesource/trusty
# Build definition
build:
  # The steps that will be executed on build
  steps:
    # A step that executes `npm install` command
    - npm-install
    # A step that executes `npm test` command
    - npm-test

    # A custom script step, name value is used in the UI
    # and the code value contains the command that get executed
    - script:
        name: echo nodejs information
        code: |
          echo "node version $(node -v) running"
          echo "npm version $(npm -v) running"
```

## Node バージョン指定

Node のバージョンを指定したい場合の設定方法。  
`box`で指定できます。Docker hub のコンテナを指定できるので、[Docker hub 上の Node の OFFICIAL REPOSITORY](https://hub.docker.com/_/node/)を指定しておきます。バージョン指定はよく間違えるのですが、`node:4.2.2`とします。`@`じゃないです。

```yml
box: node:4.2.2
```

## bower を使うには

フロント側のライブラリを bower から取得しているプロジェクトは、テストの前に`bower install`しておく必要があります。  
`build`フェーズにて bower をグローバルインストールして、`bower install`できるようにしておきます。permission で怒られるので`--allow-root`を忘れずに。  
(このあたりは独自で box 作成しておくと不要になりそうです。)

```yml
build:
  steps:
    #  npm install -g でbowerをインストールする
    - script:
      name: install npm -g
      code: sudo npm install -g grunt-cli bower

    # bower install
    - script:
      name: install bower
      code: bower install --allow-root
```

これで`package.json`の script の test にテスト用のコマンドが指定されている場合は`- npm-test`すれば OK です。

## おまけ

### CI テストはヘッドレスブラウザを使いましょう

ローカルは実ブラウザを使ったテストしている場合は、ヘッドレスブラウザを使いましょう。  
ヘッドレスブラウザは[PhantomJS](http://phantomjs.org/)が代表的です。だた、v1.0 系はモダンブラウザとの compatibility の問題があるため、v2.0 以降を使った方がいいです。

CI でも実ブラウザを使いたい場合は、wercker で頑張るより、お金を払って[Sauce Labs](https://saucelabs.com/)使った方がいいと思います。

### テスト結果を hipchat で通知する

テスト結果を hipchat などで通知したい場合は、`build`フェーズの`after-steps`で行います。  
hipchat の integration の例は公式サイトにあります。

[wercker - docs - Hipchat notifications](http://devcenter.wercker.com/docs/notifications/hipchat.html)

例）

```yml
build:
  # 省略。。。

  after-steps:
    - install-packages:
        packages: sudo gawk
    - hipchat-notify:
        token: $HIPCHAT_TOKEN
        room-id: $HIPCHAT_ROOM
        from-name: wercker
        on: failed
```

(※)`$HIPCHAT_TOKEN`と`$HIPCHAT_ROOM`は wecker で定義した環境変数です。

## まとめ

これで最低限の CI テストができるようになりました。  
初めてだと少し苦労する点があるので、まとめてみました。

### 実際の wercker.yml

`wercker.yml`はこちらに置いておきます。

https://gist.github.com/mitsuruog/ee724841d81c6ecab5e9

### 参考資料

もっと頑張りたい人向け。

- [Wercker の仕組み，独自の box と step のつくりかた | SOTA](http://deeeet.com/writing/2014/10/16/wercker/)
- [Github のプライベートリポジトリでも無料で使える CI、Wercker を使って rails new から Heroku のデプロイまでやってみる | mah365](http://blog.mah-lab.com/2014/01/08/rails-wercker-heroku-deploy/)

werckerでフロントエンドをCIテストする

小ネタです。  
いつも angular の controller を使うときは`ui-router`から`controllerAs`して使うことが多いですが、
controllerAs 仕様にした controller をユニットテストする際、少しハマったのでそのあたりを紹介します。



テストコードは angular 本家の[PhoneCat チュートリアル](https://docs.angularjs.org/tutorial)のものを利用します。

`controllerAs`仕様にカスタムした controller

contorller.js

```js
(function () {
  "use strict";

  angular.module("phonecatApp").controller("PhoneListCtrl", PhoneListCtrl);

  function PhoneListCtrl() {
    var vm = this;
    vm.phones = [
      {
        name: "Nexus S",
        snippet: "Fast just got faster with Nexus S.",
        age: 1,
      },
      {
        name: "Motorola XOOM™ with Wi-Fi",
        snippet: "The Next, Next Generation tablet.",
        age: 3,
      },
      {
        name: "MOTOROLA XOOM™",
        snippet: "The Next, Next Generation tablet.",
        age: 2,
      },
    ];
  }
})();
```

こちらがテストコード。

controllersSpec.js

```js
"use strict";

describe("Controller: PhoneListCtrl", function () {
  // load the controller's module
  beforeEach(module("phonecatApp"));

  var MainCtrl, scope;

  // Initialize the controller and a mock scope
  beforeEach(inject(function ($controller, $rootScope) {
    MainCtrl = $controller("PhoneListCtrl as vm", {
      $scope: scope,
    });
  }));

  it("phoneモデルが3つ作成されていること", function () {
    expect(scope.vm.phones.length).toBe(3);
  });
});
```

[$controller](https://docs.angularjs.org/api/ng/service/$controller)で指定する controller の constructor 指定の部分に`as`構文が使えるんですね。知りませんでした。  
$controller でテストする controller を inject したら、scope に設定した model などは`as`で指定した alias(今回だと vm)から参照できるみたい。

ちなみに、constructor で`as`構文を使わないと`expect`するところで`undefined`になります。

```
TypeError: 'undefined' is not an object (evaluating 'scope.phones.length')
```

Tag: unit test