テスト駆動開発入門

テスト駆動開発入門

テスト駆動開発入門


ユニットテストはあった方が良い。
そんなことはもはや当然のことのように思えますが、
じゃあ、「テスト駆動開発ってどうやったらいいの?」
みたいな質問には、Webにある散文的な情報だけだとはっきり答えられない。


と、思ったので体系的に学ぶためにもこの本を読んでみました。


最もお気に入りだった文書は
p.199

TDDの皮肉の1つは、TDDがテスト技法ではない(カニンガム考案)ことである。TDDは分析技法および設計技法であり、実際には開発のすべてのアクティビティを構造化するための技法である。

というところ。
謎が解けたってくらいすっきりした。


あと、
ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉
はそのうち必ず読むと決めた。


以下に気になったところを書くけれど、「part3テスト駆動開発のためのパターン」の部分を見れば、そんなに気にしないといいことが読み終わって解った。

  • 三角測量(p.16)
  • メタファ(p.82)
    • メタファは単なる名前の出所だったはずだったが、明らかに違った
  • プロセス(p.84)
    • TDDのサイクルは以下の通りである。
      • 小さなテストを追加する
      • すべてのテストを実行し失敗する。
      • 変更を行う。
      • テストを実行し、成功する。
      • 重複を取り除くために、リファクタリングを行う。
  • テストの品質(p.85)
    • このテストをい可能用な別の型式のテストの代用にしようとは思ってはいけない。
      • パフォーマンス
      • ストレス
      • ユーザビリティ
    • TDDでリファクタリングが行われることに関して(p.86)
      • 全ての入力の順列をカバーするようにテストを増加させるのではなく、同じテストで、コードを縮小させながらコードのさまざまな順列をカバーする
  • 筆者は新しいプログラミング言語に直面すると、xUnitを実装する。(p.117)
  • 独立したテスト(p.123)
    • 独立したテストとは、テストが順番に依存しなくなることを意味する。テストの一部を選択して、それを実行したいときは、事前条件となるテストがないのでテストが失敗するなんてことを心配する必要はない。
  • テストリスト(p.124)
    • 何をテストすべきなのか。->開始する前に、作成する必要があると思われる全てのテストのリストを書く。
  • テストファースト(p.125)
    • テストファーストで開発すると、ストレスが減少し、テストを実行する確立が増加する。
  • テストデータ(p.127)
    • テストデータの代替案は実データである。
      • 現実の実行から集められた外部イベントのトレースを使用して、リアルタイムシステムをテストする場合。
      • 現在のシステム出力と、旧システムの出力を比較する場合(並列テスト)
      • シミュレーションをリファクタリングしていて、終了時に全く同じ答えを期待する場合。特に浮動小数点の精度が問題となる場合
  • 最初のテスト(p.132)
    • p.133のソケットサーバのテストはシンプルでいい
  • 休憩(p.136)
    • p.137の図26.1 疲労は判断にネガティブに影響し、判断も疲労にネガティブに影響する
    • ケントベックの年に一度バケーションをとった方が言いという主張
      • 休暇以外の期間を最も効率的に過ごすためには3週間、できれば4週間必要である。
  • モックオブジェクト(p.142)
    • 高価または複雑なリソースに依存するオブジェクトのテストはどのように行うのか。->定数を返す仮バージョンのリソースを作成する。
  • 表30.1 テスト駆動でのデザインパターンの使用(p.164)
  • ヌルオブジェクト(p.167)
    • 特殊な状況を、オブジェクトを使用してどのように表現するのか。->その特殊な状況を表現するオブジェクトを作成する。そして、通常のオブジェクトと同じプロトコルをそのオブジェクトに持たせる。
  • テストしなくてよいのは何か(p.190)
    • 不安が退屈になるまで、テストを作成する
    • 以下のリストを試し、テストすべきである
      • 条件分岐
      • ループ
      • 操作
      • 多相性
  • なぜTDDは動作するのか(p.198)
    • TDDの高価による別のメリットは、設計決定でのフィードバックループが短くなることである。
  • テスト駆動開発の名前の由来は何か(p.199)
    • TDDの皮肉の1つは、TDDがテスト技法ではない(カニンガム考案)ことである。TDDは分析技法および設計技法であり、実際には開発のすべてのアクティビティを構造化するための技法である。