ひどい実装をまともな方向へ戻す（2の例）：三角測量

例を追加するのに2つのやり方（Redのフェーズ）

1つのテストメソッドにassertを追加

複数のassertを持つテストが失敗する

その下の行が実行されない（＝テストされない）

状況としては後退している

どのassertで失敗したか調べないといけない（デバッグが必要）

動作するドキュメントとして、仕様が伝わりにくい

アンチパターン：アサーション・ルーレット（1:31:30）

質疑より：複数同時にアサーションしないと意味がないケースはある（1:40:00）

ユニットテストではテストの実行コストを考えなくていいので、1テストメソッド1アサーション

E2Eは実行コストが高く、1アサーションだと遅い

テストメソッドを増やす

失敗が自明

1のテストは通るし、2のテストは落ちるというのは脳内の理解とも一致する

one assertion per testの原則

リファクタリング

テストコードに重複がある（fizzbuzzインスタンスを準備するところ）

テストコードのリファクタリングは実装コードのリファクタリングより慎重になる（1:34:50）

ツー・アウト派（ケント・ベック、t-wadaさん）

スリー・アウト派（今回はこちら）

2箇所の重複は偶発的なものかも

3箇所で本質的な重複