Growing の勉強会に参加
![Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck)) Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))](https://images-fe.ssl-images-amazon.com/images/I/51fUKOog3VL._SL160_.jpg)
Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))
- 作者: Steve Freeman,Nat Pryce
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2009/10/12
- メディア: ペーパーバック
- 購入: 3人 クリック: 76回
- この商品を含むブログ (32件) を見る
まだ最初の方。 特に印象に残ったものをメモしておく。
メッセージ指向
この著者の強調しているブジェクト指向はクラス分類、属性配置、関係というよりも、「メッセージ指向、コラボレーション指向」が強い。 「UMLのシーケンス図やコミュニケーション図で出ててくるメッセージのやり取りの【→】。テストコードで、この【→】(テスト対象のオブジェクトが隣人のオブジェクトとどのようなメッセージのやり取りをしているか)を簡潔かつ解りやすく明記するにはどうすればいいのだろうか」を考えると、mockフレームワークの豊富な語彙(API)の設計意図が読めてくる。
【→】 を Mockの語彙(API)を使って、テスト対象オブジェクトが隣人のオブジェクトどのようなメッセージのやり取りをしているかを、明記するとどうなるかのテストコード例としては、p26の 6、7を見てほしい。
テスト失敗時のエラーレポートを簡潔かつ解りやすく
また、この本では、Test Code を簡潔かつ解りやすく記述するだけでなく、テストが失敗した際のエラーレポートを簡潔かつ解りやすくすることの重要性に触れている。(まだ先の章だが、勉強会の中でも出てきた。)
Rspec の subject{}, it{} が出たとき、it { subject.aaa.should ...} it { subject.bbb.should ...} と書くと、エラーレポートが読めなくてしょんぼりしたが、its(:aaa) { should ... } と書けばよいのを後から知って、ほっとしたのを思い出した。
(個人的には、it { subject.aaa.should ... } と書いてもエラーレポートが解りやすくなっている方が、覚える語彙(API)が少なくて好みなのだが)
また、勉強したてのころ、Mockライブラリのエラーレポートが英語で、ぎょっとしていた。が、だんだん慣れてきて、読めば失敗する理由が書いてあるが解ってきたのを思い出した。 Mockはまぁ、別の意味で苦労することがあるのだが。