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

[Backbone.js Advent Calendar 2012](http://www.adventar.org/calendars/15)の 22 日目の記事です。

今見たら 22 日目の担当がいなかったので、慌てて書いています。ネタが無くなってきました（汗）。

本日は Backbone.Events について Jasmine で機能テストを書いたので公開します。
Jasmine 使った Backbone のテストの書き方について、参考になれば幸いです。



コードはこちらにあります。
（1 時間くらいで書きました。Jasmine だからできたと言っておきます ww）

[https://github.com/mitsuruog/Learning_JS/tree/master/backbone/functional_test](https://github.com/mitsuruog/Learning_JS/tree/master/backbone/functional_test)

一式ダウンロードして「SpecRunner ～」をブラウザで実行すると Jasmine のテストが実行されます。
ちなみに「0.9.2」とかは Backbone の Version です。
（0.9.9 のみ once をテストしてます。）

で、きっかけは
[@ahomu](http://twitter.com/ahomu "http://twitter.com/ahomu")さんの「[render と presenter の分離パターン](http://havelog.ayumusato.com/develop/javascript/e541-backbone_patterns_tips.html)」を読んで、いいなと思ったのですが、その前に Backbone.Events 自体あまり理解して無いと思ったので、自分の認識が合っているかテストをして確認してみた次第です。

テストしてみた結果、少し知っていると便利だなと思ったところを 2 つだけ紹介します。

1.  イベント名フラグ値のようなものを付けて、別のイベントのように発火できる。
2.  イベント名の間にスペースを入れて、複数のイベントを発火できる。

こちらが、コードのサンプルです。

```js
var obj = {};

//Mixin
_.extend(obj, Backbone.Events);

//on
obj.on("hello:me", callback);
obj.on("hello:you", callback);

//フラグのようなものを付けた呼び出し
obj.trigger("hello:me");
obj.trigger("hello:you");

//スペース区切りで複数呼び出し
obj.trigger("hello:me hello:you");
```

Backbone の 0.9.9 では Events 周辺でも機能の追加がありました。「once」以外については時間切れでテストできていません、時間があったらテスト追加しておきます。

Backbone.Eventsの機能テスト

最近、私の中で Backbone.js と共に注目の Jasmine のドキュメントを和訳しました。  
[本家のドキュメント](http://pivotal.github.com/jasmine/)はこちらです。

和訳したものはこちらです。  
（もし、訳で怪しいところがあればご指摘ください。）

[http://mitsuruog.github.com/jasmine/](http://mitsuruog.github.com/jasmine/)



ちなみに Jasmine は Javascript のテスティングフレームワークの 1 つです。  
他のフレームワークを満足に扱ったことがないので、あまり偉そうなことは言えませんが、特徴として次のようなことを挙げておきます。

- standalone 版（JS ファイル）があり、ブラウザのみでテスト実行と結果の確認ができる。
- テストケースのネストが可能、（Java で言うことの）setUp、tearDown 機能がある。
- 豊富な matcher。
- Mock（Spy）が割と簡単に作れる。
- [jasmine-jquery](https://github.com/velesin/jasmine-jquery)プラグインが素晴らしい。

[jasmine-jquery](https://github.com/velesin/jasmine-jquery) については、後日機会があれば触れたいと思いますが、とにかく DOM やイベント周辺のテストがさらにやりやすくなり、もっと便利になります。

ちなみに Google で「Jasmine」で検索すると、まだ 4 番目ですね。もっと上位になるように頑張って情報発信していきたいです。

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

Jasmineを和訳しました

このエントリは[Backbone.js Advent Calendar 2012](http://www.adventar.org/calendars/15)の 5 日目の記事です。

[前回](2012/12/backbonelocalstoragejsbackbonesync)の Backbone.Sync と backbone.localstorage.js の話の続きで、Backbone.Model から見る Backbone.Collection との関連性についてお話します。



### このエントリでお伝えしたいこと。

1.  何をすると Backbone.Model と Backbone.Collection の結びつくか。

## はじめに

前回のテストコードですが、[Backbone.localstorage.js 本家](http://goo.gl/v1gFX)のテストコードを見たところ、どうやら Backbone.Collection の create()を使うのが正しい使い方ようなので、次のように書き直しました。  
（ちなみにユニットテストは[Jasmine](http://goo.gl/IUtf)を使ってます。）

```js
describe("test localstorage", function () {
  beforeEach(function () {
    this.collection = new collection();
  });

  it("test collection create", function () {
    this.collection.create({
      title: "hello",
    });

    var model = this.collection.at(0);
    expect(this.collection.localStorage.find(model)).not.toBe(null);
    expect(this.collection.localStorage.find(model).title).toBe("hello");
  });
});
```

なんだ Collection の create()を使えば良いのか。一件落着！  
と思いたいのですが。。。

確か、model.localStorage か model.collection.localStorage が存在しない場合、デフォルトの Ajax が動くのは前回確認済みです。上のテストコードのどこを見てもそのようなことはしていませんね。
なにやら黒魔術的な臭いがします。

## Backbone.Model と Collection の近しい関係

黒魔術的な臭いがする場合は、ソースコードを読むのが一番です。まず、Collection の`create()`を読みました。

```js
// Create a new instance of a model in this collection. Add the model to the
// collection immediately, unless `wait: true` is passed, in which case we
// wait for the server to agree.
create: function(model, options) {
  var coll = this;
  options = options ? _.clone(options) : {};
  model = this._prepareModel(model, options);
  if (!model) return false;
  if (!options.wait) coll.add(model, options);
  var success = options.success;
  options.success = function(nextModel, resp, xhr) {
    if (options.wait) coll.add(nextModel, options);
    if (success) {
      success(nextModel, resp);
    } else {
      nextModel.trigger('sync', model, resp, options);
    }
  };
  model.save(null, options);
  return model;
},
```

上は Backbone.js の 766 行目辺り。ざっと目を通してすぐ分かりました。

```js
model = this._prepareModel(model, options);
```

怪しすぎる ww。  
なので、`_prepareModel()`を読みました。

```js
// Prepare a model or hash of attributes to be added to this collection.
_prepareModel: function(model, options) {
  options || (options = {});
  if (!(model instanceof Model)) {
    var attrs = model;
    options.collection = this;
    model = new this.model(attrs, options);
    if (!model._validate(model.attributes, options)) model = false;
  } else if (!model.collection) {
    model.collection = this;
  }
  return model;
},
```

上は Backbone.js の 809 行目辺り。ありました。見たかったのはこれです。

```js
model.collection = this;
```

なるほど、こんなところで Model に Collection がセットされていましたね。
これで、上のテストコードがパスできる理由も分かりました。これですっきりです。

他にも Collection の中で`_prepareModel()`呼んでいる場所を調べたところ、`create()`も含めて 4 箇所ありました。

- [add](http://backbonejs.org/#Collection-add)
- [push](http://backbonejs.org/#Collection-push)
- [unshift](http://backbonejs.org/#Collection-unshift)
- [create](http://backbonejs.org/#Collection-create)

まだ Backbone の全体を見通せてないので、作ってて所々（？）となることがあります。ソースコード印刷して電車で読むことにしました。

**Backbone.js Advent Calendar 2012**

- ← 前日　[Backbone.js の MVC について](http://goo.gl/J28KM)（@tomof）
- → 後日　[Backbone.js 日本語リファレンス](http://ando19721226.github.com/Backbone/)[](http://www.blogger.com/blogger.g?blogID=5596737312884238083)（@ando）

Backbone.Modelから見るBackbone.Collectionとの関連性

このエントリは[Backbone.js Advent Calendar 2012](http://www.adventar.org/calendars/15)の 2 日目の記事です。

Backbone.js には[Backbone.Sync](http://goo.gl/xIbI9)という Model とサーバ側のリソースを常に同期させる仕組みがあり、これを Override することで同期させる仕組みを自体を柔軟に変えることができます。  
今回は[backbone.localstorage.js](http://goo.gl/qBk6P)のユニットテストを通じて、Backbone.Sync を Override する仕組みについて少しお話したいと思います。



### このエントリでお伝えしたいこと。

1.  backbone.localstorage.js はどのように Backbone.Sync と Override しているか。
2.  backbone.localstorage.js は Backbone.Sync を Override するコードの良いお手本だと思う。。

## はじめに

まず、きっかけですが、backbone.localstorage.js を使って localstorage に Backbone.Model を保存する簡単なサンプルを作ってユニットテストしたところ、思わぬところで fail してしまったことです。  
Backbone.js 側のコードとユニットテストのコードは次のとおりです。
（ちなみにユニットテストは[Jasmine](http://goo.gl/IUtf)を使ってます。）

app.js

```js
var model = Backbone.Model.extend({
  title: "",
});

var collection = Backbone.Collection.extend({
  model: model,
  localStorage: new Backbone.LocalStorage("backbone-blog-post"),
});
```

test.model.before.js

```js
describe("test localstorage", function () {
  beforeEach(function () {
    this.model = new model();
  });

  it("test model save()", function () {
    //Error: A "url" property or function must be specified
    this.model.save({
      title: "hello",
    });
    expect(this.model.collection.localStorage.find(this.model)).not.toBe(null);
    expect(this.model.collection.localStorage.find(this.model).title).toBe(
      "hello"
    );
  });
});
```

ユニットテストを実行した結果は、次のようなエラーが発生しました。

> Error: A "Url" property or function must be specified

初めは localstorage に保存しているのに、なぜ URL が必要なのかわかりませんでした。

## localstorage に保存するはずなのになぜ URL が必要??

その前に、Backbone.Model の`save()`と`Backbone.Sync`の関係、`Backbone.Sync`のデフォルトの挙動について抑えておく必要があります。

まず、Backbone.Model の`save()`と Backbone.Sync の関係についてですが、Backbone.Model の`save()`を呼び出した際に、内部で`sync`イベントが発生して、Backbone.Sync に定義されている function が実行されるようになっています。  
その際に、Backbone.Sync はデフォルトでサーバサイド側の REST API
(GET/PUT/POST/DELETE)と Ajax（jQuery か Zepto 依存）で通信をするようになっています。

これらの事により、先のエラーは Ajax 通信をしているため発生していることが容易に予想できるのですが、そもそも backbone.localstorage.js は Backbone.Sync を Override しているので、なぜ Ajax のコードが生きているのか分かりませんでした。

## なぜ Ajax が動いているのか?

この問題を理解するために backbone.localstorage.js のソースを読みました。  
（以下、核心部分だけ抜粋します。）

```js
// Override 'Backbone.sync' to default to localSync,
// the original 'Backbone.sync' is still available in 'Backbone.ajaxSync'
Backbone.sync = function (method, model, options, error) {
  return Backbone.getSyncMethod(model).apply(this, [
    method,
    model,
    options,
    error,
  ]);
};
```

上は backbone.localstorage.js の`134行目`辺り。
Backbone.Sync を Override しているところです。中で`Backbone.getSyncMethod()`を return しています。
自分でカスタムする場合は、ここに直接 Override するコードを書いても良さそうです。

```js
Backbone.ajaxSync = Backbone.sync;

Backbone.getSyncMethod = function (model) {
  if (
    model.localStorage ||
    (model.collection && model.collection.localStorage)
  ) {
    return Backbone.LocalStorage.sync;
  }

  return Backbone.ajaxSync;
};
```

上は backbone.localstorage.js の`123行目`辺り。本問題の核心部分です。  
読めば一目瞭然なのですが、デフォルトの Backbone.Sync を`Backbone.ajaxSync`という別名で保存してました。

しかも、`Backbone.getSyncMethod`では

- model.localStorage
- model.collection.localStorage

いずれかのプロパティが存在しない場合、Backbone.ajaxSync が return されます。

これですべての謎が解けました。

## 最初のテストコードはどうあるべきだったのか?

先に結論ですが、次のコードでテストが通りました。

```js
describe("test localstorage", function () {
  beforeEach(function () {
    this.model = new model();
    //collectionをmodelにセットする
    this.collection = new collection();
    this.model.collection = this.collection;
  });

  it("test model save()", function () {
    this.model.save({
      title: "hello",
    });
    expect(this.model.collection.localStorage.find(this.model)).not.toBe(null);
    expect(this.model.collection.localStorage.find(this.model).title).toBe(
      "hello"
    );
  });
});
```

ただ、なんとなく違和感が残ります。

Model だけをテストする目的であればこれも有りだと思いますが、テストを通すためにコードを足したようでなんとなく気持ち悪いですし、何か使い方が間違っている気がします。  
（[次回](/2012/12/backbonemodelbackbonecollection/)はこの違和感を取り除いて行く過程を書きます。）

ちなみに、backbone.localstorage.js はコードが 140 行足らずなので読むのは非常に楽でした。
実際に Backbone.Sync を Override するコードを書く場合は、ぜひ参考にしたいと考えています。

**Backbone.js Advent Calendar 2012**

- ← 前日　[Backbone.js で今つくっている構成について](http://goo.gl/s9JLG)
- → 後日　[Backbone.js が自動でやってくれるところについて](http://goo.gl/WxdVo)

Tag: jasmine