どのタイミングでparameterized testにするか？

ぽけば @pocketberserker

Spockは流れるようにparameterized testの形にリファクタリングできるのがいいな

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker 最初はparameterized testで書かないの？

ぽけば @pocketberserker

君のJUnit力が低いだけだと言われればそこまでだけど！だけど！

ぽけば @pocketberserker

@kyon_mm 練習のときは意味もなく最小のテストコードを書きがちです

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker ん。。。む？1パターンだとしてもparameterized testで書けばいいのではなく？

ぽけば @pocketberserker

@kyon_mm コメント部分に具体値を記述しているときはparameterized testにしてないですねー

ぽけば @pocketberserker

コメント？シナリオという言い方のほうが正しいのか？

ぽけば @pocketberserker

"fooでhogehogeしたらbarが返る"とだけ書いている時はparameterized testじゃなくてもいいかなーと

山本康彦＠BluewaterSoft @biac

@pocketberserker NUnitで[Test]属性は使わなくなりました。パラメタライズドテストじゃなくても、とにかく[TestCase]属性を付けちゃう f(^^;

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker なるほど。僕はいつも補完使ってSpock書いているからほとんどparameterized testになっている気がする。使い分けた方がいいのかな。

ぽけば @pocketberserker

@kyon_mm 規約や趣味の問題だと思います。@biacさんもきょんさんの同様の形でやってるみたいですね。

ぐるぐる系SQL @bleis

俺は最初からparameterized testにすることは稀ですかねー。YAGNI

ぐるぐる系SQL @bleis

先が見えていてかつ時間がないときは最初っからparameterized testにしちゃうけど

ぐるぐる系SQL @bleis

一度にそこまで抽象化しちゃうと、具体的なものを見れなくなってしまって怖い、というのもありますね

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker @biac なるほど。。。僕の趣味だと必ず三角測量をするからparameterized testで始めから書いておく方が楽って言うのがあるかな。

ぐるぐる系SQL @bleis

俺にとってはそれは一歩が大きいんです。まぁ人によると思うよ。

ぐるぐる系SQL @bleis

テストを書き始める時と言うのは、最初の一歩なので、できる限り小さくいきたい派

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@bleis あるある

ぽけば @pocketberserker

フレームワークの問題もあるだろうな。NUnitやSpockは確かにparameterized test書きやすい。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker JUnitだったら書かないです。できるだけ書かないです。@Theoryとか面倒すぎる。。。

ぽけば @pocketberserker

RSpecとかはどうなのだろう？

ぽけば @pocketberserker

@kyon_mm ですねー。JUnitのときはDRYと見やすさのどちらを重視するかいつも迷います。。。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@pocketberserker ゆえにSpockですね。

irof @irof

自分にあった一歩の大きさを見つけるのが重要だよね。小さ過ぎても大き過ぎても歩きづらい。歩き慣れてきて、気分が乗ったらスキップしても良い。

ぐるぐる系SQL @bleis

JUnitでparameterized testするときは、JUnitの機能は使わずにヘルパメソッドを抽出する感じでやるなー