haru01のめも

■Growing の勉強会に参加

まだ最初の方。 特に印象に残ったものをメモしておく。

メッセージ指向

この著者の強調しているブジェクト指向はクラス分類、属性配置、関係というよりも、「メッセージ指向、コラボレーション指向」が強い。 「UMLのシーケンス図やコミュニケーション図で出ててくるメッセージのやり取りの【→】。テストコードで、この【→】（テスト対象のオブジェクトが隣人のオブジェクトとどのようなメッセージのやり取りをしているか）を簡潔かつ解りやすく明記するにはどうすればいいのだろうか」を考えると、mockフレームワークの豊富な語彙(API)の設計意図が読めてくる。

【→】 を Mockの語彙(API)を使って、テスト対象オブジェクトが隣人のオブジェクトどのようなメッセージのやり取りをしているかを、明記するとどうなるかのテストコード例としては、p26の ６、７を見てほしい。

テスト失敗時のエラーレポートを簡潔かつ解りやすく

また、この本では、Test Code を簡潔かつ解りやすく記述するだけでなく、テストが失敗した際のエラーレポートを簡潔かつ解りやすくすることの重要性に触れている。（まだ先の章だが、勉強会の中でも出てきた。）

Rspec の subject{}, it{} が出たとき、it { subject.aaa.should ...} it { subject.bbb.should ...} と書くと、エラーレポートが読めなくてしょんぼりしたが、its(:aaa) { should ... } と書けばよいのを後から知って、ほっとしたのを思い出した。

(個人的には、it { subject.aaa.should ... } と書いてもエラーレポートが解りやすくなっている方が、覚える語彙(API)が少なくて好みなのだが)

また、勉強したてのころ、Mockライブラリのエラーレポートが英語で、ぎょっとしていた。が、だんだん慣れてきて、読めば失敗する理由が書いてあるが解ってきたのを思い出した。 Mockはまぁ、別の意味で苦労することがあるのだが。

自然言語風のテスト記述

テストの記述を自然言語のように読みやすく書く（例えば matcher や mockライブラリーが提供している語彙（API）)のアプローチは賛否両論あるだろう。豊富な語彙がを使って、（テストの）意図を簡潔に記述できる一方、語彙（api）を覚える学習コストが上がる、そもそも英語で母国語ではなく、学習コストが高い（読めない）など。

うちの社内だと、豊富な語彙（API）を使って意図が伝わるように記述するアプローチがOKという風潮があり、集団で学習する感じになっており、学習コストが若干低くなっている。

Permalink | コメント(0) | トラックバック(0) | 08:09