1. UnitTest のためのクラス設計 (スライド)
1.1. UnitTest の考え方
1.1.1. 単体での確認ができればよい
1.1.1.1. その先のメソッドはそれ単体で確認する
1.2. UnitTest のためのクラス設計の指針
1.2.1. 強い依存を徹底的に避ける
1.2.1.1. クラス間
1.2.1.1.1. コンストラクタやメソッドの引数でオブジェクトを渡す
1.2.1.1.2. セッタで上書き可能なメンバ変数にする
1.2.1.2. 外部システム
1.2.1.2.1. プロキシパターン
1.2.2. 複雑度を下げる
1.2.2.1. 同じタイミングで実行されるとしても関係のないコードを同じ場所に置かない
1.2.2.2. if の入れ子になったらメソッドを分割する
1.2.2.3. ループの中は別メソッドにする
1.3. モックを使うための注意
1.3.1. メソッド内で new してたら差し替えられない
1.4. まとめ
1.4.1. そのクラスに関連するオブジェクトはメンバ変数にする
1.4.2. メンバ変数はセッタで上書き可能にする
1.4.3. メソッドは小まめに分ける
1.4.4. 外部システムとの絡みはラッパーを作る
2. よい単体テストの特徴と、書くためのヒント - builder
2.1. それぞれのテストは、ほかのあらゆるテストと直交するものにする
2.1.1. 特定の振る舞いは 1 つのテストでのみ指定されているようにする
2.1.2. 不必要なアサーションは設定しない (あるいは 1 つのテストにつき 1 つの論理的アサーションのみを設定する)
2.1.3. 1 度にコードの1つのユニットのみをテストする
2.1.4. 外部のすべてのサービスや状態にはダミーを用いる
2.1.5. 不必要な前提条件を避ける
2.2. 設定に対する単体テストは行わない
2.3. 単体テストに対しては、わかりやすく一貫性のある名前をつける
3. テストしやすく 作る ことで より良い プログラムに なる
4. テストに 使える 技法
4.1. DI
4.1.1. DI はテストのためにある
4.1.1.1. InfoQ: 依存性注入(DI)は成功したか？
4.1.1.2. DI する理由 - クリプトメディア技術メモ
4.2. Guice
4.2.1. Guice による依存性注入 - developerWorks
4.3. ScalaTest
4.3.1. sbt で使う
4.3.1.1. build.sbt に libraryDependencies += "org.scalatest" %% "scalatest" % "1.8" % "test"