zusaar（告知サイト）
http://www.zusaar.com/event/520003
以下の書籍をターゲットとした読書会なのです。
 | 実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) (2012/09/14) Steve Freeman、Nat Pryce 他 商品詳細を見る |
場所は新宿の某所で、参加者は主催者さん入れて5名でした。
小規模ですが、議論しやすい人数です。しかも翻訳者の和智さんまで参加！
でも私、途中でSUICAを駅に落として取りに戻ったため、30分ほど遅刻してしまいました。。。
ちなみにDevlove2012でも和智さんによるGOOSのセッションがありましたが、私も聴講してブログに書いてます。
「DevLOVE Conference 2012」に参加しました ～其の壱～
http://makopi23.blog.fc2.com/blog-entry-35.html
以下、みんなでディスカッションした際にとった、自分用メモ。
第Ⅰ部 導入
■インタフェースとモデルはウォーキングスケルトンを作成する前に決める。
■テストコードはプロダクトコードが無い段階で書き始める。
・当然、Eclipse上では赤アンダーラインでエラーが出るが、それで良い。
プロダクトコードがまだ無い（からエラーになっている）、という状態がわかるので。
・逆に、空コードを用意して既にあるものを使ってしまうと、その制約にひっぱられてしまう。
（プロダクトコードの適切なクラス名やメソッド名も、テストコード書いてる時に気づいたりするので、変えれるようにしておいたほうが良い）
■クライアント側が読みやすいように、テストコードから書いて、呼び出され側も書く
■モックは、外から中に流れていく作り方で使う。使う側から作る。
■どうしたいかを書いていく。何をしたいか、を考えて書く。読みやすくないといけない。
■メッセージパッシングのテストをやろうとするとモックを作らないといけない
■著者のNat PryceがDIをdisってるブログがある
・http://www.natpryce.com/articles/000783.html
・モック化する対象はP.56の「依存、通知、調整」
・大きな責務の関係性と実装レベルの分割があって、DIを使うと見えなくなってしまう
→責務を意識しないとダメなんだよ
Nat PryceによるDI論。彼のインターフェイスに関する考え方がよくわかるので、GOOSのお供に natpryce.com/articles/00078…
— Yukei Wachiさん (@digitalsoul0124) 2013年3月2日■マーティン・ファウラー による、「モック」と「スタブ」との違いに関する説明
http://martinfowler.com/articles/mocksArentStubs.html
日本語訳：「モックとスタブの違い」 http://d.hatena.ne.jp/devbankh/20100210
■スタブ：
・テストの間の呼び出しに一時的な回答を返すもの
・そのテストのためにプログラムされた値じゃないものは返せない
・スタブは実態がある
■モック：
・期待値をプログラムすること
・戻り値として返されるものがモック
■モックを使ったテストで和智さんがよく書くもの
・バックエンドでDBがいくつかあり、DbUnitでテスト作るのが面倒くさい場合に、
「ロジック→DAO→DB」の最初の矢印のトコにモックを置く。
■昔のJMockはAPIをベタ書きする必要があった。
→ JDK1.5でジェネリクスが出てきて、Expectationでメソッドを書けるようになった。
■JMockの作者は、GOOSの著者と同じ。
■モックはロールをモック化するべき。
スタティックメソッドとかモックにする。
■テストを書いている間に、振る舞いの結果に対してフォーカスがあたる。
モックを使うと、そのユースケースがテストコードに書かれる。
■DI
・XMLを見るだけで関係性が追える。
・アノテーションで書いちゃうと関係性が追えなくなる。
■WebのテストではSeleniumよりもcucumber-junitの方がお勧め。
第Ⅱ部 テスト駆動開発のプロセス
■発芽（P.64）
・「顧客コード」という概念を表現するのに、普通だとString型フィールドで用意しがち。
→ 主キーなので、DAOに渡したりするが、単にString型という属性しか付いていないと、なんでも渡せてしまう。
→ その対策として、「顧客コード」をStringじゃなく「顧客コード」というクラスに抜きだす。
・DAOには「顧客コード」というクラスを渡す制約にすると、それしか渡せなくなるので型安全にできる。
・その他に、「顧客コード」の3桁目に特定の意味を持たせたりとかも、クラスにすると表現できる。
・顧客コードは「右埋め」みたない意味を持たせたりもできるので、クラスにしておいたほうがいい。
・普通に考えるとオブジェクトになりにくいものをクラスにしちゃう。
・プレースホルダー ＝ 場所を予約する（クラスとして）
■GOOSの前提として「エリック・エヴァンスのドメイン駆動設計」という書籍がある。
・1部→3部→4部→2部の順に読むと良い。まず1部だけでも読むべし。
 | エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) (2011/04/09) エリック・エヴァンス 商品詳細を見る |
■インタフェース（P.67）
・他のオブジェクトに何かを提供するサービスは、インタフェースにしましょう。
・GOOSでも、１つのクラスの中にインタフェースを持って、中で同一クラス内のインタフェースを呼び出す設計になっているところがある。
・第Ⅲ部では、インタフェースの考えがキモ。
→ 図12-1とかの図が、以降どのように変化していくのか、インタフェースの使い方と実装・設計の変化を追うべき。
ちなみにこの議論しているときに、図13-2が間違っていることが発覚。
図13-2で正しくは、auction sniperから下向きに、Auctionというインタフェースを介して「？」に矢印が伸びる。
■イテレーション・ゼロ（P.88）
・TDDは、アプリケーションとテスト基盤を同時に作らないといけないのでは大変。
→ それを避けるために、イテレーション・ゼロでTDDの基盤を回すための仕組みを作っておく。
(cf)P.36 「まずは動くスケルトンをテストする」
・GOOSだと、11章がウォーキングスケルトンに該当する。（図9-4のTo Doの１つ目）
・データベースもウォーキングスケルトンの段階で入れておく。
第Ⅲ部 動くサンプル
■分割とか発芽を実践する。
■第Ⅲ部の写経は苦しい。GOOSは写経しても幸せになれないかも。
・遠めに文章を読んで、これってどういう意味だろう、とコードを探ってみる読み方が良い。
■各章のTo Do（図9-4とか）を隣に置いて、オブジェクトの関連図（図11-1）を見て、なぜその設計になったのかを考える。
・各章で、これを意識して見ていくことが理解の早道。
（図11-1 → 図12-1 → 図12-2 → 図13-1 → 図13-2 → ・・・と、インタフェースとオブジェクト関連の設計の変化に着目）
・設計の変化は、テストコードが起因になってることが多いかも。
第Ⅳ部、第Ⅴ部
■第Ⅳ部、第Ⅴ部は読み物として纏まっている。第Ⅲ部と独立してるのでココだけ読むのもお勧め。
■テストを書く事で、テストからわかることある。
→ 設計の改善の余地がわかる。
■22章の序論の第２段落がおもしろい。
■「テストコードにも愛情をそそぎましょう」
■P.273のソースコードで、hatandcapeが既に用意したテストで、but()メソッドを介して、その内のある条件だけ抜くことができる。
■第Ⅳ部のテーマ：「テストを綺麗に書く」
■第Ⅴ部のテーマ：「テストで苦労する時にどうすべきか」
ご参考
■今日の参加者の一人、たのっちさんのGOOS書評。
@IT
http://el.jibun.atmarkit.co.jp/bookshelf/2012/11/post-a409.html
■たのっちさんが書いてくださった今日のメモ
GOOS（日本語版）読書会 #fromEvernote evernote.com/shard/s23/sh/6…
— たのっち@アレグラ無しでは生きていけぬさん (@dproject21) 2013年3月2日★感想：
参加者は5名でしたが、少ないからこそ濃い話ができました。翻訳者の和智さんもいらっしゃいましたし。
私、第Ⅲ部の写経を頑張ってたのですが、写経をしても幸せになれないかも、という話でした。
この発想は驚きでしたし、そーゆー考えもあるのかー、と気づきを得られました。
第Ⅲ部にコード満載なので、写経はするもの、という考えでいましたが、ちょと見方を変えてみよう。
きっと、第Ⅲ部で挫折した人って多いんじゃないかなーと推測してますが、上のような考えで第Ⅳ部以降を先に読むのも全然アリそうです。
あと、第Ⅲ部は各章のオブジェクト関連図とインタフェースの使い方の変化に着目して読むべし、ってのもGOOSへのとっつき方法として気づきの１つでした。
プロダクトコードが無い段階でテストコードを書く、という点についても、今日の議論でもやもや感が晴れた感じがしました。
これまでと少し違った観点で、もう一度GOOSに取り組んでみようと思います。
最後に今日参加された皆様、ありがとうございました。とても良い気づきが得られた一日でした。
