# テスト駆動開発

# 17章

## 全体像

- コードを書いて、ひと段落したらコードの直しを！
- 細かくテストしよう！
- テストカバレッジ上げる方法は、テストを増やすことだけではない！

## なぜ、それを知らないといけない理由。どのような問題が発生するのか

- コードを書き終えたことに満足し、より良い解決策を発見する機会を失う
- TDDを品質を上げるための、万能薬だと思ってしまう

## 本編の解説

- ひと段落したら、コードの批判的に捉える
- テストが不足していないか
- 設計を見直す。新しい概念を発見できないか探索する。
- 設計の言葉と概念に齟齬がないか
- 除去が難しい重複処理はないか
- 体験談: 売上を上げるために、値引きクーポンがほしいという要求。特典(何らかのインセンティブがほしい)という概念を発見しシンプルな設計になった。
- 発表したやつ
- https://www.youtube.com/watch?v=eqPA5A7elp0

- テスト品質
- コードの品質にのみ影響する
- パフォーマンステスト
- 負荷テスト
- ユーザービリティテスト
- コードのテスト欠陥密度が十分に低いとより探索的なテストに割ける時間が生まれる
- 欠陥挿入というテスト品質測定手法があり
- テストカバレッジを上げる方法
- テストを書く
- 実装をシンプルにする
- 分岐を少なくする
- プログラムをさまざまな側面から検証しているテストの数を、テストすべき側面の数（ロジックの複雑度と言い換えてもいい）で割ったもの
- 「テストを増やすことによってすべての入力の組み合わせ（より正確に表現するなら、取りうる値を網羅する必要十分な組み合わせ）をカバーするのではなく、同じテストのままで、コードを減らすことによってより多くの組み合わせをカバーする」

## 念押しをしたいところ

テストカバレッジ上げる方法は、テストを増やすことだけではない。
プログラムをシンプルにするという選択肢も！

以下より複雑度を下げれば、カバレージが上がるということ
プログラムをさまざまな側面から検証しているテストの数を、テストすべき側面の数（ロジックの複雑度と言い換えてもいい）で割ったもの

## メモ

- このあとどうするのか
- 完了で済ましてはいけない
- 立ち止まって、コードを批判的に見る。その際は、Lintツールが補助輪になる。
- テストが不足していないか
- TODOリストがない場合は、設計を見直す。
- 概念の見直す
- ヒント
- 設計の言葉と概念に齟齬がないか
- 除去が難しい重複処理はないか
- メタファー
- メタファーを使うことで、シンプルな設計になる
- JUnitの使用状況
- 細かくテストしよう。この本のコードを書いているとき、もっと大きい実行間隔は1min以内
- テスト品質
- コードの品質にのみ影響する
- パフォーマンステスト
- 負荷テスト
- ユーザービリティテスト
- テストカバレッジを上げる方法
- テストを書く
- 実装をシンプルにする
- 分岐を少なくする
- プログラムをさまざまな側面から検証しているテストの数を、テストすべき側面の数（ロジックの複雑度と言い換えてもいい）で割ったもの
- 「テストを増やすことによってすべての入力の組み合わせ（より正確に表現するなら、取りうる値を網羅する必要十分な組み合わせ）をカバーするのではなく、同じテストのままで、コードを減らすことによってより多くの組み合わせをカバーする」

# 18章

## xUnit

## 全体像

2章の全体像: テストフレームワーク(xUnit)を自作しよう。

急がば回れ

## なぜ、それを知らないといけない理由。どのような問題が発生するのか

- TDDの魅力を知る前に、TDDをやめてしまう。

## 本編の解説

- 慣れないうちは、小さくステップで始めよう。TDD過程でコードが汚くなることを恐るな！
- 今回ご覧いただいたような小さな手順に厳密に従う必要はない。TDDを習得したら、より大きな機能追加をテストを書きながら行えるようになる。しかしTDDをマスターするためには、いつでも必要に応じて小さな手順に引き戻せるようでなければならない。
- 小さく始めると抽象化されてないコードを書く機会が発生する。過程でコードがベタ書きになるのは気にしない。

## 念押しをしたいところ

PluggableSelectorパターン(オブジェクトが呼び出すメソッドなどを動的に変更する方法)が紹介されているが、メソッドが使われているか静的解析できなくなるのでやめよう！

## メモ

PluggableSelectorパターンは、たぶん動的ディスパッチのこと

# 他の人の発表を聞いたメモ

## 1章,2章

後回しにする。TODOに残しておく。まずは、先に進める。仕事術的なやつと似てる。

不安のスコープもだいぶ小さくなった

三角測量
複数の具体など意味ないみたいな話？抽象的に考える的にやつ？
境界値テストではないらしい

意図をテストしよう

junitは、rspecのようにnestしたテストを書けないらしい。Java Iner Classを使うらしい。

5つのサイクルがある。サイクルによって重視するポイントが異なる。(5章) TODO: あとで絶対読む！

- テストを書く。
- コンパイラを通す。
- テストを走らせ、失敗を確認する。
- テストを通す。
- 重複を排除する。

TODOリストを少しずつ増やしていく。わかっている範囲で！アジャイルっぽい
これが終わればOKではない。