# 第4章

## 理想的なテスト: p96

- A: 退行（regression）に対する保護: p96
  - 退行とはバグのこと
  - なんらかの変更（機能追加など）があっても既存の機能が意図したように動いているほど保護されている
    - テスト時に実行されるプロダクションコードの量を少なくする
    - プロダクションコードの複雑度を小さくする
    - プロダクションコードの扱う重要度を小さくする
- B: リファクタリングへの耐性: p98
  - テストが失敗することなくプロダクションコードのリファクタリングを行えるか
  - 偽陽性の発生が少ないほど耐性がある
    - 正しく（期待通りに）リファクタリングした結果、テストが失敗するようになることを「偽陽性」と呼ぶ
- C: 迅速なフィードバック: p113
  - テストを速やかに行えること
- D: 保守のしやすさ: p113
  - 保守コスト
  - テストケースの理解困難度
  - テストの実行困難度

### テストケースの価値: p114

- テストの価値 = A{0..1} * B{0..1} * C{0..1} * D{0..1}
  - いづれかの要素が0になったとき、そのテストケースの価値は0になってしまう
  - 理想的なテストケースはすべての要素の度合いが1になっていることだが、そのようなテストケースを作ることはできない
    - A, B, Cの3要素は互いに排反であるためである
      - ABを1にするとCは0になってしまう
        - e.g.) E2Eテストだけでは迅速なフィードバックを得ることはできない
      - BCを1にするとAは0になってしまう
        - e.g.) 取るに足らないテスト（プロダクションコードと同じことを別の書き方で表現しているだけのテスト）では何も検証していないも同然で、退行に対する保護は全く備わっていない
      - ACを1にするとBは0になってしまう
        - e.g.) 壊れやすいテスト（プロダクションコードをリファクタリングすると失敗するようになるテスト）にはリファクタリングへの耐性がない
    - p120の図が参考になる

### 実現可能なテストケースのうち、もっとも理想に近いテストケース: pp120-122

- B, Dを1とし、A, Cでバランスを調整する
  - 退行に対する保護と迅速なフィードバックのどちらかを多少犠牲にするということ
    - この感覚はデータストアなどで使われる「CAP定理」というものに似ているらしい
  - テスト・ピラミッドにあてはめると、以下のようなバランスとなる
    - 単体テスト: A{.3} * B{1} * C{.7} * D{1}
    - 統合テスト: A{.5} * B{1} * C{.5} * D{1}

#### CAP定理: p123

- C, A, Pのうち同時に保証できるのは2つまでだという考え方で、一般的にRDBMSはCA、NoSQL/分散データベースではCPまたはAPを選択する
  - Consistency: 一貫性
  - Availability: 可用性
  - Partition-tolerance: 分断耐性

  > CA分散データベースについては、理論上の検討を行うことはできても、実際的には存在しないと言えます。  
  > -- _[CAP定理の概要 | IBM](https://www.ibm.com/jp-ja/topics/cap-theorem#CAP%E5%AE%9A%E7%90%86%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8BNoSQL%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E5%88%86%E9%A1%9E)_

  - DynamoDBはNoSQLらしくAPデータストアになっている

  > アマゾンの経験では、ACID（Atomicity（原子性））、Consistency（一貫性）、Isolation（独立性）、Durability（永続性））を保証するデータストアは高可用性が維持できない。これは産業界でも学会でも広く認められていることだ。Dynamoでは高可用性につながるならば、一貫性を多少犠牲にしても運用できるアプリケーションをターゲットにしている  
  > つまり、いかなる場合でも顧客がショッピングカートに商品を入れられるように、データの一貫性を多少犠牲にしてでも可用性を優先するというアプローチをとっているということになる  
  > -- _クラウドの衝撃: IT史上最大の創造的破壊が始まった_ [^クラウドの衝撃]

## ブラックボックステスト・ホワイトボックステスト: pp124-128

- ホワイトボックステストでは偽陽性が多く含まれ、リファクタリングへの耐性が欠落する。また意味のある振る舞いを認識しづらくなる傾向がある。
  - よってブラックボックステストを選択（採用）するべき
    - リファクタリングへの耐性を高くするために、「実装の詳細ではなく、最終的な結果を確認する」: p106

| | 特徴 | 退行に対する保護 | リファクタリングへの耐性 |
|---|---|---|---|
| ブラックボックステスト | ソースコードなどの内部構造を知らずに検証する。仕様や要求から作成される | 劣っている | 優れている |
| ホワイトボックステスト | ソースコードなどの内部構造を検証する。ソースコードから作成される | 優れている | 劣っている |

* * *

## 感想など

「偽陽性」を抑えるためにリファクタリングへの耐性が必要という点は強く共感できる。

### 偽陽性への対処

- 偽陽性は「実装は正しい（期待通りである）のに、テストは失敗している」状態
- 偽陰性は「実装が間違っているが、テストは成功している」状態

ブラックボックステストを採用することでプロダクションコードとテストコードを「隔離」する。2章でも感じた（モックを多用したテストなどで発生しやすいであろう）「偽陰性」にも注意したい。

偽陽性についての文量が多く、コラムにも偽陽性によって起きた問題が書かれている。偽陽性の強い（？）プロジェクトではテストのことを考えなくなっていくという旨のことが書いてあるが、これは[『レガシーコード改善ガイド』の「第24章 もうウンザリです。なにも改善できません」](https://books.google.co.jp/books?id=UC9RCwAAQBAJ&pg=PT336)という部分にも通ずるところがあるのかもしれない。 [^Working-Effectively-with-Legacy-Code][^レガシーコード改善ガイド]



[^クラウドの衝撃]: [城田真琴, クラウドの衝撃: IT史上最大の創造的破壊が始まった, 東洋経済新報社, 2009](https://www.google.com/search?q=9784492580820&tbm=bks)
[^Working-Effectively-with-Legacy-Code]: [Michael C. Feathers, Working Effectively with Legacy Code, Prentice Hall Professional Technical Reference, 2004](https://www.google.com/search?q=9780132931755&tbm=bks)
[^レガシーコード改善ガイド]: [ウルシステムズ株式会社 平澤章 越智典子 稲葉信之 田村友彦 小堀真義 訳, レガシーコード改善ガイド, 翔泳社, 2009](https://www.google.com/search?q=9784798116839&tbm=bks)