PoohSunny's blog

生きるために食べるのか、食べるために生きるのか。

『JUnit実践入門』写経・実践会 in 横浜 #3 に参加してきた #junitbook

前回は遅刻してしまったので、今回は最初から参加しました。
『JUnit実践入門』写経・実践会 in 横浜 #3 - connpass

当日のまとめはこちら。@shinyaa31さんが勉強会が始まるまえからまとめを作っていることが話題になったりしましたw　仕事早すぎです。今回もありがとうございました。


当日はドタ参で@t_wadaさんが来てくれることになり、
急遽、新刊である『O'Reilly Japan - SQLアンチパターン』のサイン会と相成りました。
まとめて近くの本屋さんの在庫を確認し、タネマキさんにとりにいっていただいたうえで！
さらに人数分ないところ私が購入させていただき、サインいただきましたー。
ありがたやー。
そして、当日はいろいろ出た疑問もたくさん答えてくださり、すごくためになった勉強会でした。
@t_wadaさんありがとうございました。

さらに、@sue445さんが@irofステッカーを持ってきてくださり、
私も一枚頂戴しました。ありがたやー。
f:id:swimming_pooh:20130203155749j:plain



ではでは、まとめを読み直しながら自分的に参考になったポイントを書いて行きます。

Spockが便利そう

勉強会が始まる前に、ちょっとGroovy + Spock でのテストを見せてもらったのですが、
パラメタライズドテストとかが便利そうな予感。わくわく。

プロダクションコードがJavaで、テストをGroovyってのもありだそうで。
（そういえばこの点、川口さんが「JUnitのテストをGroovyで書かないなんてもはやありえない」とすらおっしゃってますね）

というわけでちょっとちゃんと勉強しなくては！　と思いました。
当日のもくもく時間があればトライしたかったのですが、
議論が盛り上がったのであまり時間なく。次回までの自分の宿題にします。

private メソッドのテスト、する？

私にとって勉強会で一番よかったなーと思ったのがここでした。
privateのメソッドでテストしたいようなメソッドがあったとき、スコープをデフォルトにしてテストするか、テストしないか、みんなどうしているか、という問いかけ。

私は生業として、レガシーコードになんとかテストを書く、という修行をしているので、
同じような問題意識がありました。

意見として出てきたのは、

  1. スコープを広げてテストする。そしてそれをコメントに書いておいたりする
  2. リフレクションで無理やりやる
  3. Groovyならできる
  4. privateはテストを書かない。privateにテストを書かなきゃいけない状況というのは、そのメソッドが債務を持ちすぎている状態。なので何かpublicな債務が混じってしまっているのでは？そこをなんとかする。
  5. レガシーコードで、魔改造するってのはあり。

現時点で私がやっているのは、リフレクション使ってprivateだとやっちまうぜ！
というもの。
でもそれだと、IDEとかのリファクタ機能が追ってくれないので、リファクタしにくくなってしまうという指摘をいただきました。確かに。
ただ、上述の通り相手はレガシーコードなので、今回の勉強会では、



というスタンスでしばらくいようと思いました。
でも今のリフレクションバリバリはちょっと修正しようかな、と思いましたね。
スコープを広げてもいいんじゃないかともっと考えるようにします。

Mockist vs Classist

モックについての文脈で、Mockの使いどころについて考え方の違いがあるそうです。
モック愛好主義者がMockistだそう。
t_wadaさん曰く、一度Mockistに行って痛い目を見てちょっと戻ってくるくらいがちょうど良い、とのこと。
私は今のところClassistに憧れるMockist見習いというなんとも中途半端な感じかなーと思いました。
ここは相手にしているプロダクションコード次第でキャラを自在に変えたいですね。
当日紹介されたxUTP Magazine - 第一回 xUnit Test Patterns の世界観 あたりを読んだら参考になるかしら。

Mockライブラリの選び方

自分が会社に選定・導入するときに結構悩んだ点だったので聞いてみました。
選び方のコツを教えてもらったところ、
ユニットテストの語彙やパターンが、ちゃんとツールに反映されていれば、（mockとかspyとか）真面目系ライブラリとして良いのではないか、とのこと。
そういう意味ではMockitoはやはりバランスが良いのだそうです。
jmockitからみた機能比較表も教えてもらい参考になりました。でもjmockito = 魔改造、という噂も。
レガシーコード改善屋としては気になるところではあります。

テストの成長とともに人も成長する

自分の実体験ですが、テストを良くしようというニーズによって、
テストだけでなく人も進化していると思います。
なので常に新しいライブラリとか、ツール導入したりとかして、
みんなでテストを作って行く形にしたいなーと考えてます。

速度のためにモックを使う時代は終わった。

今は速度は金で買う時代。よし、それでいこう。

テストの有無によるプロジェクトの比較とか統計ってあるの？

テストがあるプロダクトに、もしなかったらこうなってた、あるいはその逆というのは
たらればの話になってしまうので、だいたい統計としてあるのは、
大きな企業が似たようなプロジェクトを二本走らせて比較したもの、とのこと。
ただしユニットテストしておかないと今後の機能追加がしにくくなるので、
テストのメリットを周りに説明するなら、その方面がいいのではないか、とのこと。

ですよね。この辺りの統計もう少しちゃんととってみなきゃ。と思いました。


というわけで、非常に有意義な勉強会でした。
企画してくれた@shinyaa31さん、飛び入りで参加していただきいろんな質問に答えていただいた@t_wadaさん、参加者のみなさん、ありがとうございました。
次回はDBUnitの部分。元気があればLTしたいけど、自信は皆無。