随時更新します。まとまってきたらブログに書きます。
前提 / 方針
テストにはとにかく依存関係が大事。他オブジェクトに依存していればしているほどテストしづらいので依存関係を切れるような設計が必要となる。また、テストの実行も意外と大変なので自動化は早い段階で考えておく。
-
依存関係を切る
- setterを作る
- 引数にオブジェクトを取る
- Overrideして振る舞いを変える
- モックオブジェクトを活用して便利に検証する
- デメテルの法則を常に意識する
-
極力自動化しておく
- git hookでpush時に実行
- ファイル監視して変更があった時に実行
- Jenkinsのようなツールを使う
- Travis CIやCircle CIのようにSaaSを利用する
オブジェクト生成
- まずはオブジェクト生成
-
new Hoge();できたら生成できたらかなりラッキー。メソッドのテストに進む - 引数ありのコンストラクタしかなかったら
new Hoge(null, false, 0);みたいな感じでデフォルト値を渡して生成する - これもダメだったら
new Hoge(mockObject);のように引数としてmockObject（以下モックオブジェクト）を渡す（mockObjectはデフォルト値を返し続けるオブジェクトなど。実際の処理が行われない方がユニットテストっぽい） - モックオブジェクトも厳しそうだったらデフォルとコンストラクタ
public Hoge() { /* do nothing */ }を定義してしまう（テスト対象がコンストラクタに関わる処理の場合はこの方法は取れない） -
@VisibleForTestinを使っていテストにふさわしいスコープを少しだけ広げることを宣言する - どうしてもダメな時はコンストラクタ内の処理の一部を別メソッドに切り出してテスト側で
@Overrideしたテストケースなどを用意する。
-
メソッドのテスト
- オブジェクト生成がどうしてもうまくいかなかったらテスト対象のメソッドを
staticにしておくことを考える- ↑設計よりテストに重きを置くとでてくる選択肢の一つ
- どうしてもテストできない場合はまずは誰かに聞く、それでも分からなければ前向きに保留（TODOコメントだけ残しておくなど）
- オブジェクト生成が問題なくできたらあとはすぐ上の「オブジェクト生成」と同じように依存性と地味に戦い続けることにする