nebashitaito-web

学んだ事

• 単体テストのカバレッジは、何の指標にもならない。コードの書き方によっていくらでも上下するので、高くても良い単体テストとはならない。
• 単体テストの真価を発揮する条件
• 継続的に単体テストを実施している事
• 重要なコードが対象範囲である事。
• 単体テストの派閥が2つあり、デトロイト学派とロンドン学派
  • デトロイト学派　モックを最低限しか使わず、1つ（単体）のソースコードのビジネス的な振る舞いを検証する。1ファイルや1クラスが検証対象とは限らない。デトロイト学派で単体なのは、テストコード
  • ロンドン学派　モックを多用する。プログラムと対になる1つ（単体）のテストコードを用意する。1ファイルもしくは、1クラスを検証する。ロンドン学派はで単体なのは、ソースコード
  • この本では、デトロイト学派を支援しており、以下の内容を主張している。 モックの利用は壊れやすいテストを生む。何でもかんでもモックするな、コントロール不可なプロセス外依存（対向先システムや、共通DBなど）のみをモックするべきである。
• 単体テストをしやすいコードを作るには、単一責任原則を徹底する。
• モックは、外部に向かうコード（出力） 例、メールの送信
• スタブは、内部に向かうコード（入力） 例、DB
• 単体テストのアンチパターン
  • テストコードの為に、ソースコードを変更する事
  • ソースコードとテストコードの結びつきが生まれるような事である。
• 単体テストの良い流れは、準備・実行・確認の3つである。
  • Given・When・Thenも同じ
  • Given＝準備
  • When＝実行
  • Then＝確認
• 確認フェーズでは、ヘルパー関数を作れ。（同じ事を何度も確認しているコードは関数にして重複を排除せよ。）
• 出力値ベーステストとは、関数やクラスの戻り値を確認する
• 状態ベーステストとは、モックを利用しないで、関数がもたらす結果を確認する（DBの状態など）
• コミュニケーションケースベーステストとは、モックを利用した、関数の引数や呼び出し回数を確認する