実践テスト駆動開発: テストに導かれてオブジェクト指向ソフトウェアを育てる
- 翔泳社 (2012年9月1日発売)
本棚登録 : 330人
感想 : 10件
- Amazon.co.jp ・本 (376ページ)
- / ISBN・EAN: 9784798124582
感想・レビュー・書評
-
再読。良書だが難しい。3度目の通読でようやく7割くらい理解できたかなという感じ。
本書はテストの本ではなく、オブジェクト指向設計開発の本である。
第I部・II部でTDDによりオブジェクト指向設計を徐々に洗練させていくための原則や手法が説明される。
第III部では、実際にサンプルアプリケーションを開発していく流れを仮想体験できる。
第IV部・V部ではTDDのテクニックや高度なトピックが紹介される。
モックライブラリを生み出したいわゆる"ロンドン学派"の筆者によって書かれた本書では、エンドツーエンドを先に書くことで顧客やユーザーがソフトウェアに期待する振る舞いを明らかにした後、それを実現する上で必要なオブジェクト群を見出し、モックを使って少しずつ設計・実装を進めていくアプローチを取っている。
モックはテストしにくい対象をテストするための道具ではなく、探索的・発見的にインクリメンタルにオブジェクト設計を進めていくために生み出されたツールであることは余り知られていないかもしれない。
とにかく難易度が高く、サンプルアプリケーションもSwingなのでとっつきにくい。読むのに時間がかかるし、二度三度と読むべき本だと思うが、得られるものは図りしれず大きい。TDD、オブジェクト指向設計について改めて本気で考えたい上級者向けの本。
0
詳細をみるコメント0件をすべて表示 -
ある程度わかっている人がさらに詳しくなるための本
テスト駆動開発について，一つ一つ手順を踏んで解説している。
一番普及しているという理由でJavaとJUnitをサンプルとして使い，具体的なコードを出して，どうすればいいのか詳しく説明している。
ただし，サンプルのコードはけっこう実践的なので，実際に業務でオブジェクト指向型のプログラミング言語で開発を行っている人向きだと思った。書籍の題名にある「実践」とはここから来ているのだと思う。
テスト駆動開発初心者はまだこの本に手を出すのは早いような気がした。，
0
-
Javaプログラマでない自分にとって、サンプルコードを理解するのは容易ではなかった。しかし、ユニットテストの考え方や成長のさせ方は非常に参考になった。
0
-
Growing Object-Oriented Software, Guided by Tests
静的なクラス構造の観点から、動的なコミュニケーション構造の観点への転換。
予期せぬ変更を予期せよ。
命じよ、訊ねるな (Tell, Don't Ask)
モックオブジェクト
インターフェイスの発見
動くスケルトンから始める。
受け入れテストを書く。→実装の観点からではなく、ユーザーの要求の観点からシステムを理解できる。
進捗を測るテストと、リグレッションを検出するテストを区別する。
振る舞いのユニットテストを行え。メソッドをテストするのではない。
TDDの持つテストの側面 (これはTDDの大部分を占める)が与えてくれる最高のものは、コードを壊さずに変更できるという自信だ。恐れると先に進めなくなる。このときのコツは、自信を確実に裏付けることである。
何かを設計するときには、常にもうひとまわり大きなコンテキストの中で考えること。椅子ならば部屋の中にあることを考える。部屋なら家の中、家なら環境の中、環境なら都市計画の中。
一エリエル・サーリネン
保守を考えて設計する：関心を分離する／抽象度を高める
オブジェクト間はメッセージ送受信スタイル／オブジェクト内は関数型スタイル
ANDや OR、 BUTは禁止
単一責任の原則。オブジェクトが何をしているかは、接続詞（andやbut）を用いずに説明できなければならない。説明に節を追加しようとしているときには、協力し合う複数のオブジェクトに分解すべき。各節に対してひとつのオブジェクトが該当する。
オブジェクトピアのステレオタイプ
- 依存ピア：コンストラクタでピアを渡す
- 通知ピア：一方向で間接的
- 調整ピア：
コミュニケーションパターン、コミュニケーションプロトコルが大事。
オンデマンドの設計。クライアントオブジェクトがプルする。クラスがフィーチャーをプッシュするのではない。
私たちの最終的な目的は、より少ないコードでより多くを実現することだ。私たちが切望しているのは、 制御フローとデータ操作という観点からプログラミングすることを卒業し、より小さいプログラムを組み 合わせてプログラムを作るということだ。そういうプログラムでは、オブジェクトが振る舞いの最小単位を構成する。
開くコードが増えるほど、頭の中に溜めておかなければいけないことが増える。だが皮肉なことに、そうすると普通は動きが鈍る。テスト駆動開発のもたらした偉大な発見のひとつに、開発のステップは思っているよりも細粒度にできるということがある。
テスト駆動開発のサイクルにおいてはリファクタリングが決定的に重要。
依存ピアだけをコンストラクタで渡すこと。通知ピアや調整ピアは適当なデフォルトを設定しておいて、あとで設定すればいい。
TestDox命名規約：テスト対象クラスを暗黙の主語として、テスト名を一つの文として読めるように書く。
リーダブルテスト：レッド、レポート、グリーン、リファクタリング
# 雑感
『実践テスト駆動開発』の思想は、ぼくが取り組んできたアジャイル＆UCD とシンクロして面白い。 37signals の DHH が共著した『RailsによるアジャイルWebアプリケーション開発』も TDD で UCD だ。やはり 2005 年頃がターニングポイントか。
アーキテクトが実装コードは書かないにしても、受け入れコードは書いた方がよさそうだし、それが情報アーキテクトなら、なおよいかもしれない。「情報アーキテクト」と「IT アーキテクト」の脱構築に向けて。
「情報アーキテクトと IT アーキテクトの脱構築」の意味は、その二項対立のなかに、「どちらに属すか決定不可能な概念」が内包されていることを示し、「そもそも二項対立構図が妥当だったか？」「そもそも二項対立は可能だったか？」を問い直すということ。
二項対立構図が内包する決定不可能な項目を提示することにより、二項対立構図を内破させること。
領域横断的な共同作業（トランスディシプリナリー・コラボレーション）の準備として、「領域」に明確な「境界」がないことを示したい。各々の「領域」への過度な（腫れ物に触れるような）「尊重」から、互いの「領域」へ互いに踏み込んで学び合うような「尊重」への転換を仕掛けたい。
非エンジニアの情報アーキテクトに、ソフトウェア開発方法論の読み方を学んでもらいたいな。『エリック・エヴァンスのドメイン駆動設計』『実践テスト駆動開発』は情報アーキテクトにとって重要な示唆に富む書。セミナーとかワークショップとかやったらいいのかな。
『実践テスト駆動開発』 (GOOS) の「受け入れテスト」の思想や「振る舞い駆動開発」 (BDD: Behavior-driven development) は、心理学・哲学の Behaviorism や Cognitive Revolution に近いシステム観だと感じるなあ。
jMockの宣言レイヤのコーディングスタイルは素晴らしい。
context.checking (new Expectations() {{
oneOf(example).doSomething(with(any(String.class)));
}});
エンドツーエンドのTDDでは、ユーザーインターフェイスの設計をするタイミングが難しい。
↓
TDDとUI設計を並行して進める。UI（インターフェイス層）の設計が固まるのにあわせて、アプリケーション層やドメインモデル層もそれにあわせて固まっていく。レイヤー間の共進化設計プロセス。
↓
「いつUI設計すべきか」という問いの立て方が適切ではない。
というのが現時点の仮説で、ちょっと試してみようかなと。
UI設計におけるテスト：
- UI設計に自動テストは役立たない。
- UI実装のバグを検出するのには役立つ。
- UI設計におけるテストは生身の人間を用いた評価。
分野別テスト手法：
- UIプロトタイピングためにアプリケーションをモックする。
- アプリケーションの受け入れテストにUIは不要。テストコードがある。
- ドメインモデルのテストにインフラストラクチャは不要。モックする。
問題意識と作業仮説：
UI設計と要件定義は一体のものであって、どちらかが先ということはない、という思想でプロトタイピングするとき、テスト駆動開発はどのように実践できるか。
システムをUIサブシステムとアプリケーションサブシステムに分離して同時に開発することで共進化させる？
http://zerobase.hatenablog.com/entry/2013/01/11/183327
UIサブシステムとアプリケーションサブシステムが「疎結合」になるのは望ましいことだろうか。オープンなウェブサービスAPIのマッシュアップで優れたデザインが可能だろうか。「垂直統合」（密結合）の優位もあるはずだ。ケースバイケースで。
UIサブシステムとアプリケーションサブシステムを密結合にするから「共進化」が速くなる。疎結合なら進化も遅い。ただしオープンプラットフォームなら個々のアプリとは疎結合だ。結合の強さと、結合しうる相手の数はトレードオフの関係にある。だからハイブリッドが模索される。
UI設計とは本質的にはどういうことなのか？ より「透明」なUIが理想だとするならば、それをどのように実現するのか？ おそらくは、ユーザーの主観的なアフォーダンスやメンタルモデルと、ソフトウェアの振る舞いやドメインモデルとの、不一致をなくしていく方向だろう。
人間側のアフォーダンスやメンタルモデルと、ソフトウェア側のドメインモデルを一致させる。だからオブジェクト指向。オブジェクト指向とは、本質的には「シミュレーションによるプログラミング」のパラダイムだ。
ユーザー・インターフェイスの進化の本質は、情報・概念の〈物質化〉である。「シミュレーションによるプログラミング」としてのオブジェクト指向パラダイムへの本格的なシフトが重要だ。
http://zerobase.jp/blog/2012/10/post_113.html
RailsのActiveRecordを直接ドメインオブジェクトにするか、リポジトリオブジェクトにしたうえでドメインオブジェクトのピアにするか。
Ruby on Railsというフレームワーク上でアプリケーションを構築するとフレームワークに依存する。「アプリケーションをRuby on Railsフレームワークにアダプトする」ほうがDDD的かも。
BDUF(Big Design Up Front)は避けたいが、ある程度のインタラクションデザイン／UIデザインが進捗してからシステム設計したほうがよい。というのはフィーチャーやユースケースが定義できなければ、受け入れテストは書けないからだ。メンタルモデルに照らして素性のいいシステムモデルを設計しないといけない。次はDCIを学ぼう。
→DCIアーキテクチャ http://zerobase.hatenablog.com/entry/2013/01/09/140646
2012/12/27 ~ 2013/1/11 読了
0
Steve Freemanの作品
