■1 xSpecとjBehave

ま た c o d e h a u s か ! ! !

xSpecという考え方がある(らしい)。xUnitによる単体テスト、あれはテストではない、仕様だ。なのに「テスト」と呼んでしまっている。だから、従来からの伝統的なテストの概念やQA部門と開発チームとのあいだに混乱と軋轢が生じる。名前重要。

テストケースと呼ぶから、プロダクトコードの後にユニットテスト書くような輩が絶えない。テストではなくスペック(仕様)と呼べばよい。仕様をプロダクトコードの前に書くのはフツウだ。これまでだってそうしていたはず。

で。このxSpec的概念を実装していると思しきライブラリが、jBehave 。テストメソッドはtest[DoSomething]ではなく、should[DoSomething]。assertEqualsではなくVerify.equal。

——と、脊髄反射的に書いてしまったが、そもそもフライパン氏のxSpecの話って私は機会がなくてちゃんと聞けてなかったり。軽くググってみたけど、よくわからない。

verify? should?

Specの発想は全く同じだよ。shouldとverifyの感覚は逆だ(xSpecではverify?がテストメソッド)。

とあるけれど、いまやってるプロジェクトではテストメソッド名は「testShuoldDoSomething」となっていることが多い。テストメソッド本体のいわゆるassertの部分では、Mockをたくさん使っているところはmock.verifyになっている(なってしまう)。メソッド名で表明(should〜)して、本体で検証(verify)する、というのはそんなにおかしい話でもないと思うのだがいかがか。ご参考まで。

jBehave、使用上の注意

jBehave は現在、安定した1.0版リリースに向けて、ガリガリ開発中。なので、いまのところは本番プロジェクトでの採用はオススメしません。けれど、開発版やスナップショット版を試して、フィードバックをもらえるととても嬉しいです。α版、β版、そして最終リリースのアナウンスはメーリングリストに流します。

JUnitからのスイッチングコストが気になる。いまやEclipseからの手軽な実行と、Maven(Antでもいいけど)からのバッチ実行＆レポート生成ができないと、代替品としての捺印ナビリティはお話にならない。今後に期待しつつ、生温かく見守りたい。

■2 「Don't Mock Me: Design Considerations for Mock Objects」

xSpecの話題がADC2004のサイトのどこから辿れるかと思ったのだが、果たせず。その過程でExperience Reportsの中に、上述タイトルのペーパーを発見。PDFをざっと眺めたら、きわめて実践的(当たり前か)な印象だったので、近いうちに読んでみよう。

■3 隅田川花火大会

今年も自宅から。義母が料理を色いろ用意してくれて充実の鑑賞体制。妻の友人が赤子を連れて遊びにきたが、生後1年に満たない彼は花火にはまだ興味は持てない様子。

今年はプログラムを見ながら、第1会場のコンクール作品を堪能してみた。が、やはりヤケクソな感じの第2会場のほうが好みだ。

ポケモン花火は、どこらへんがポケモンなのか微妙だった……。縁取りが黄色っぽいのはとりあえずピカチュウなんだろうな、とは思うが。