拡張型TDD on JaSST2011Tokyo

みかまま @mikantsuki

テストの世界だと「実装後」に対してテストを書くのが通例（もちろんWモデルとかの話だとまた変わってくるみたいですが）なんで、「実装前」に書くユニットテストとちょっと違うところがある

みかまま @mikantsuki

でも、仕様を満たしているかという点からテストケースを作るというのは同じはずなんで、テスト技法は普通に使えるんですよ #tdd

鈴木三紀夫 @mkoszk

僕も同意見。みかままに賛成。 RT @mikantsuki TDDのコアコンセプトは「実装の前にその仕様が満たされているべき具体値を想定しておき実装時にそれを利用すること」だと思ってます #tdd

みかまま @mikantsuki

同値分割なり、境界値分析なり、直交表なり、もれてちゃまずいテストケースを拾い出すのに有効です #tdd

みかまま @mikantsuki

あんまりややこしいとテストケース割り出すのに時間がかかって実装の速度が落ちるんじゃない？って話もあるけど、適切なテストケースがないためにバグが追えない方が怖い #tdd

みかまま @mikantsuki

咳さんとかはごく普通にそういった割り出ししてるだろうから、拡張型と言われても「何普通のこと言ってるの？」になっちゃうんだろーなぁと、TDDセッション見てて思ったｗ #tdd

みかまま @mikantsuki

海外のプログラマはソフトウェア工学の素養があるのが普通なんで、本に「どういうテストケースを書くべきか」までは書いてないのよね(苦笑） #tdd

みかまま @mikantsuki

@katzchang まあだから、そのへんは「リスクベースドテスト」と同じで、それが押さえられると思われるバグがどれくらい致命的かって判断にかかってるんじゃないですかね #tdd

みかまま @mikantsuki

テストケースで全てを押さえられるわけでもなく、そんなコストもかけられない、それは「実装前」でも「実装後」でも同じこと #tdd

みかまま @mikantsuki

ただ、バグが見つかるのが遅いほど、手戻りのコストは増大するんで、「実装後」のテストを「実装前」に持ってくるのは正しい流れだと思うんですけどね #tdd

鈴木三紀夫 @mkoszk

@oota_ken ジャグリング和田さん経由で話を聞いたので、間違っているかもしれませんが、拡張型TDDは凄く違和感がありました。