出版社内容情報
マーチン・ファウラー(あとがき・・より）
テスト駆動開発を伝えるうえで最も困難なものの1つは、TDDを行う人の精神状態である。
最初のC3プロジェクトで、ラルフ・ビーティと開発を行った。その開発では複雑な支払条
件群を実装しなければいけなかった。ビーティはその条件群をテストケース群に分割し、
その1つ1つを私たちは動作させていった。進捗は順調だったが急いではいなかった。落
ち着いていたので、ゆっくりのように感じたが、成し遂げた作業量を振り返ると、進捗は
本当に速かった。
どのような素晴らしいツールがあっても、プログラミングは困難である。プログラミング
時に、複数のボールを同時に空中に投げているかのような感覚になることが多くあった。
集中が途切れると、すべてがこぼれ落ちる。テスト駆動開発はこのような感覚を減らすこ
とに役立つ。結果として、ボール回しのような高速での落ち着きを得られる。
その理由はテスト駆動開発で作業すると、1度に1つのボールを空中に投げているかのよ
うな感覚が得られるからだろう。そして、そのボールだけに集中して、本当によい仕事を
行うことができる。新機能を追加する時、よい設計かどうかは気にしない。できるだけ容
易にテストをパスさせるだけだ。リファクタリングモードに入ると、新機能の追加のこと
ではなく、正しい設計にすることだけを心配する。どちらの場合も、1度に1つのことだ
けに集中する。その結果、1つのことをよりよくすることに集中できる。
テストファーストによる機能追加とリファクタリングは単一で論理的なプログラミングで
ある。最近私はキーボードに向かって、別の種類のプログラミングである、パターンのコ
ピーを経験した。データベースからデータを取り出す小さなRubyスクリプトを作成してい
た。まず、データベーステーブルをラップするクラスに取り組み、データベースパターン
の書籍を執筆したばかりだったので、パターンを使用すべきだと考えた。サンプルコード
はJavaだったが、Rubyに適応させるのは難しくなかった。そのプログラミングの間、本
来の問題のことはまったく考えなかった。パターンのRubyへの適応と、操作対象の具体的
なデータへの適応だけを考えた。
パターンについて語る時、パターンのコピー自体はよいプログラミングではないとつねに
強調している。パターンはつねに生焼けで、プロジェクト固有のオーブンで適応させる必
要がある。しかし、そのためのよい方法は、まず何も考えずにパターンをコピーし、その
後リファクタリングとテストファーストの混合を利用して、適応を行う方法である。そし
て、パターンのコピーを行う時は、パターンにだけ集中することができる。1度に1つの
ことを行う。
XPコミュニティはパターンを適合させる場所を求めている。XPコミュニティがパターンに
好意的であるのは明らかである。結局、XPの提唱者とパターンの提唱者は大きく重なる。
カニンガムとベックは両方のリーダーである。おそらく、パターンのコピーは、テストフ
ァーストやリファクタリングとともに、3つ目の単一論理モードだろう。そして、他の2
つと同様に、単独だと危険だが、合わさると強力である。
アクティビティを体系的にする大部分は、中核のタスクを見分け、1度に1つだけに集中
できるようにすることである。組立ラインは単調な例である。単調なのはつねに1つのこ
とを行っているからである。おそらくテスト駆動開発の提案内容は、プログラミングを基
本的なモードに分割する方法であるが、それらのモードを高速に切り替えることによって
単調を避けようとしている。単一論理的なモードと切り替えの組み合わせによって、集中
のメリットを提供すると同時に、組立ラインの単調を回避しながら、脳へのストレスを低
下させる。
こうした考えは若干生焼けだ。これを執筆した時点で、自分の発言内容に確信はないので、
数ヶ月間は熟考し続けるだろう。しかし、読者がこの考えを気に入り、テストファースト
開発が適合する大きな図式を考えるきっかけとなるかもしれない。まだはっきりとは見え
ない図式ではあるが、緩やかにその姿を表すだろう。
目 次 [CONTENTS]
まえがき v
謝辞 ix
はじめに xi
Part 1 Moneyの例
第1章 複数通貨のMoney 3
コラム ［依存性と重複］ 8
第2章 オブジェクトの退化 11
第3章 すべてに対する等価性 15
第4章 プライベート化 19
第5章 「フランク」に話す 23
第6章 再度、すべてに対する等価性 27
第7章 りんごとみかん 33
第8章 オブジェクトの生成 35
第9章 生きている時（times） 39
第10章 興味深い時（times） 45
第11章 諸悪の根源 51
第12章 ついに、加法 55
第13章 動作 61
第14章 変化 67
第15章 通貨の混合 73
第16章 最後に抽象化 77
第17章 Moneyの例の回顧 81
Part 2 xUnit の例
第18章 xUnitへの第1歩 89
第19章 テーブルの設定 95
第20章 完了後の掃除 99
第21章 カウント 103
第22章 失敗の扱い 107
第23章 スイートにまとめる方法 111
第24章 xUnitの回顧 117
Part 3 テスト駆動開発のためのパターン
第25章 テスト駆動開発のパターン 121
第26章 レッドバーに関するパターン 131
第27章 テストに関するパターン 141
第28章 グリーンバーに関するパターン 149
第29章 xUnitに関するパターン 155
第30章 デザインパターン 163
第31章 リファクタリング 179
第32章 TDDの習得 189
手順はどの程度の大きさであるべきか 189
テストしなくてもよいのは何か 190
よいテストがあることをどのように知るのか 190
TDDはフレームワークをどのように導くのか 191
どれだけのフィードバックが必要なのか 192
いつテストを削除すべきか 193
プログラミング言語や環境がどのようにTDDに影響するのか 194
巨大システムをテスト駆動することができるのか 194
アプリケーションレベルのテストで開発を駆動することができるのか 195
途中でどのようにTDDに切り替えるのか 195
TDDは誰のためにあるのか 196
TDDは初期条件に敏感なのか 197
TDDはパターンとどのように関係するのか 197
なぜTDDは動作するのか 198
テスト駆動開発の名前の由来は何か 199
TDDはXPのプラクティスとどのように関係するのか 199
ダラク・エニスの挑戦 201
付録Ⅰ 影響図 203
付録Ⅱ フィボナッチ 207
目次
１ Ｍｏｎｅｙオブジェクトの例（複数通貨のＭｏｎｅｙ；オブジェクトの退化；すべてに対する等価性 ほか）
２ ｘＵｎｉｔの例（ｘＵｎｉｔへの第１歩；テーブルの設定；完了後の掃除 ほか）
３ テスト駆動開発のためのパターン（テスト駆動開発のパターン；レッドバーに関するパターン；テストに関するパターン ほか）
著者等紹介
長瀬嘉秀［ナガセヨシヒデ］
１９８６年、東京理科大学理学部応用数学科卒業。朝日新聞を経て、１９８９年、テクノロジックアートを設立。ＯＳＦ（Ｏｐｅｎ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ）のテクニカルコンサルタントとしてＤＣＥ関連のオープンシステム推進を行う。ＯＳＦ日本ベンダ協議会ＤＣＥ技術検討委員会の主査をつとめる。現在、株式会社テクノロジックアート代表取締役。ＵＭＬによるオブジェクト指向セミナーの講師、ＵＭＬ関連のコンサルティングを行っている。ビジネスオブジェクト推進協議会（ＣＢＯＰ）コンポーネントモデリング分科会主査（理事）ＯＭＧでＵＭＬ Ｐｒｏｆｉｌｅ ｆｏｒ ＥＤＯＣの提案者、ＩＳＯ／ＩＥＣＪＴＣ１ ＳＣ３２／ＷＧ２委員、情報処理相互運用技術協会（ＩＮＴＡＰ）オープン分散処理委員、電子商取引推進協議会（ＥＣＯＭ）ＸＭＬ／ＥＤ標準化調査委員。明星大学情報学部講師
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。
感想・レビュー
※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。
kaizen@名古屋de朝活読書会
Luo Yang
ショウヤ
Kazuyuki Koishikawa
kojinose
