４章 良い単体テストを構成する4つの柱
| 退行(regression)に対する保護 | 本質的には繋がった性質 * プロジェクトが始まってすぐに重要となる | テストをすることでどのくらいバグを検出できるのか |
| リファクタリングへの耐性 | * プロジェクトが始まってすぐに重要とならない | テストをすることでバグがないことをどのくらい示せるのか |
３本は相反する性質。全てを最大にするテストは不可能。
極端な例
- E2E
- 迅速性：×
- 取るに足りないテスト
- data classのgetterのテストのようなやつ
- プロダクションコードと同じことを別の書き方で表現しているだけ！
- 退行に対する保護：×
- 壊れやすいテスト
- whatではなく、howに目を向けているため、コードと密結合
- リファクタリングへの耐性：×
３つのうち、どれを優先・犠牲にするかは決断が必要。ただし、いずれかが完全に欠如したテストケースはNG
テストピラミッド
- 高い層であるほど、退行に対する保護を備えなくてはならない
- 低い層であるほど、迅速さを備えなくてはならない
- すべてのテストは、偽陽性を可能な限り排除するよう務めなくてはならない
ブラックボックステストとホワイトボックステスト
- リファクタリングの耐性を備える必要があるためブラックボックステスト
- テストケースからビジネス要求が導き出せないのであれば作り直すか破棄しなければならない
- ただし、アルゴリズムにおける複雑さを備えたユーティリティコードの場合は例外
- しかし、テストケースの分析にホワイトボックステストの観点を参考にすることはできる
第５章 モックの利用とテストの壊れやすさ
テストダブル
- ダミー、スタブ、スパイ、モック、フェイク
モック：
- 外部に向かう出力を模倣
- 模倣するだけでなく検証もおこなう
スタブ
- 内部に向かう入力を模倣
- 模倣だけ
スパイ
- モックと同じ役割
- 開発者自身の手で実装される（手書きのモックとも呼ぶことがある）
ダミー
- 一時しのぎで使われる文字列などシンプルなハードコーディングされた値
フェイク
- スタブの目的とほぼ同じであるが、まだ存在しない依存を置き換えるために作成される
スタブとのやりとりを決して検証してははらない
過剰検証
モックとスタブが混在する場合もある（＝モック）
コマンド・クエリ分離の原則
- コマンド：モック
- クエリ：スタブ
テストの壊れやすさに影響を与えるものがリファクタリングへの耐性
単体テストにおいてもっとも重要な柱
第５章 モックの利用とテストの壊れやすさ
テストダブル
- ダミー、スタブ、スパイ、モック、フェイク
モック：
- 外部に向かう出力を模倣
- 模倣するだけでなく検証もおこなう
スタブ
- 内部に向かう入力を模倣
- 模倣だけ
スパイ
- モックと同じ役割
- 開発者自身の手で実装される（手書きのモックとも呼ぶことがある）
ダミー
- 一時しのぎで使われる文字列などシンプルなハードコーディングされた値
フェイク
- スタブの目的とほぼ同じであるが、まだ存在しない依存を置き換えるために作成される
スタブとのやりとりを決して検証してははらない
過剰検証
モックとスタブが混在する場合もある（＝モック）
コマンド・クエリ分離の原則
- コマンド：モック
- クエリ：スタブ
テストの壊れやすさに影響を与えるものがリファクタリングへの耐性
単体テストにおいてもっとも重要な柱
第５章
思ったこと
- Androidの場合、「アプリケーションの境界」はどこになるかを考えたい。それによりどこからをMockすべきかが決まる
第６章 単体テストの３つの手法
- 単体テストの手法の比較
- 関数型アーキテクチャとヘキサゴナル・アーキテクチャとの関係
- 出力値ベース・テストへの移行
単体テストの３つの手法
- 出力値ベース・テスト
- オブジェクトの状態が変わらない前提。
- テスト対象は戻り値だけ。
- 関数型
- 状態ベース・テスト
- 検証する処理の実行が終わった後にシステムの最終的な状態を検証
- コミュニケーションベース・テス
- モックを用いてテスト対象システムとその協力者オブジェクトとのあいだでおこなわれるコミュニケーションを検証
保守のしやすさ
- 状態ベース・テスト
- 対策
- ヘルパーメソッドで改善可能
- （第３部）
- 値オブジェクトの導入により値として比較することで改善可能
- ヘルパーメソッドで改善可能
- 上記が可能なのはテスト対象が本質的に「値」の場合のみ
- 対策
- 上記が可能なのはテスト対象が本質的に「値」の場合のみ
- テストを単純化するためにプロダクションコードを汚染することがあってはならない（第11章）
関連
「Googleのソフトウェアエンジニアリング」「12.2.3 相互作用ではなく、状態をテストせよ」
７章
プロダクションコードを分類する2つの視点
- コードの複雑さ、もしくは、ドメインにおける重要性
- プロダクションコードに含まれる分岐の数で計測
- （循環的複雑度）
- プロダクションコードに含まれる分岐の数で計測
- 協力者オブジェクトの数
- == 可変、もしくはプロセス外依存のこと