ユニットテストを書こう！http://qiita.com/kompiro/items/78f2c8d2022a685baa83
プロダクションコードの変更時、既存と振る舞いが変わる箇所はテストが失敗する。そのため、変更が影響を及ぼす範囲がわかる
ユニットテストを書くと、コードの振る舞いがテストコードに明示されるため、振る舞いを予測可能な範囲が増える
ユニットテストを書くときは、APIの利用者になるため、APIの利用者から見て利用しやすいコードを目指すモチベーションを産みやすい
複雑なテストを書きたくないため、単機能に絞ったわかりやすいコードを目指すモチベーションを産みやすい
多数のテストに影響を及ぼさないクラスを目指すモチベーションを産みやすい
プロダクションコードに書かれた処理がユニットテストに例示されるため、プロダクションコードの理解を助ける
- テストコードに対象のProductコードをimportしてテストランナー上でその動作を検証する
- ProductコードにはModule性が求められる
- DBや外部APIへのアクセス(JSだとDOM操作も)などがある場合はそのシミュレートが必要になる
- Mock
- テスト対象に依存するObjectを擬似Objectに変更してテストしやすくする.
- ex.) DBアクセスを行うオブジェクトをMockしてテスト時にはDBアクセスを省略する
- Stub
- ユニットテストに邪魔な関数を任意の戻り値を返す関数に変更してテストしやすくする
- ex.) 外部APIの呼び出す関数を任意の戻り値を返すように偽装してAPIアクセスを省略する
- 関数型プログラミング
- 副作用が局所化されるためtestableなコードを書きやすい
- クリーンアーキテクチャ
- 外界との結合が疎になるのでtestableなコードを書きやすい
- http://qiita.com/kondei/items/41c28674c1bfd4156186
- DI
- Objectの依存関係をObject内部に抱え込むことなく外部から設定可能にするデザインパターン
- http://www.atmarkit.co.jp/ait/articles/0910/29/news111_2.html
- Mockの注入が簡単
Scalaのテストフレームワーク
http://etorreborre.github.io/specs2/
以下の機能(library)を標準で備えている
- matcher
“hoge” must be “hoge”のような形式で期待する結果を記述できる- https://etorreborre.github.io/specs2/guide/SPECS2-3.6.4/org.specs2.guide.Matchers.html
- Mockito
- Mockライブラリ
- mocking以外にもstubや関数が呼び出されたか検証する機能(verify, spy)もある
- https://etorreborre.github.io/specs2/guide/SPECS2-3.6.4/org.specs2.guide.UseMockito.html
- ScalaCheck
- テスト対象の関数にランダムな入力値を与えて結果の検証をする（それを複数回。デフォルトだと100回検証）
- テスト作成者が必要十分なテストケースを書くとは限らない
- https://etorreborre.github.io/specs2/guide/SPECS2-3.6.4/org.specs2.guide.UseScalaCheck.html
- コンソール上で特定の関数を実行することができる
$ sbt console- Application, テストランナーの起動よりも高速にフィードバックを得られる
- 軽量なユニットテスト
- TDDのRed/Green/RefactorサイクルをREPLで実践して、テストコードはある程度まとまった段階で残すなどのやりかたもあり.
- REPL Driven Programming http://tyano.shelfinc.com/post/48110396231/repl-driven-programming
- テスト駆動開発 https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA