深夜のテストTL

Koichi ITO @koic

BDD フレームワークで使われている語彙は良い方向に進んでいる。

ゆーけー @ukstudio

BDDは実質TDDと変わらないと思ってる。TDDのテストって言葉がややこしいし、TDDで検証してるのって振舞いだよね、だったらBDDの方がよくね?って話だったはず。

ああああ @miyucy

@t_wada なるほど なぜよく言われるTDD(Red>Green>Refactoring)からThinkが抜け落ちたか？が知りたいですね

Koichi ITO @koic

BDD という名前が付いたことが失敗で、それは QWAN であるべきなんじゃないか。

tkskkd.deso | Takeshi Kakeda @kkd

@koic TDD->BDDで回避したかった議論がTLにいっぱいあると感じているのですけどね...

ゆーけー @ukstudio

Spec Driven Development

ゆーけー @ukstudio

@koic BDDという名前が悪かったのか、そもそも名前を付けるべきじゃなかったのかは僕にはわかりませんが、TDDの誤解に関する問題提起や仕様に近い語彙を使うといった点でBDDは存在してよかったと思いますけどね。

tkskkd.deso | Takeshi Kakeda @kkd

ATDDが日本で流行ってないのは単にユーザーストーリーがきちんと理解されて使われていないだけと感じる。ストーリーには満足/完了条件を設定するし、それをテスト//ビヘイビアという形に変換し、自動化したいという欲求は自然な流れ。

tkskkd.deso | Takeshi Kakeda @kkd

TDDはKJ法と同じだよ、って言っても通じる人はあまりいなそう...

tkskkd.deso | Takeshi Kakeda @kkd

TDDはよいプログラマとしての実施/思考プロセスを形式化し実現可能にしてくれたもの。だからプログラマが不安を取り除けるし、結果としてよいものができる。

tkskkd.deso | Takeshi Kakeda @kkd

ただTDDに含まれない、もっと細かい粒度の思考プロセスもあって、それが @m_seki がいうところの「TDDではまだ粒度が粗い」だと感じている。

ヨシオリX @yoshiori

@kkd 僕がこんな発言をしちゃったから BDD の時にさんざん話しあわれてたのを蒸しかえしちゃったのかもしれません＞＜ http://bit.ly/as1xT4

tkskkd.deso | Takeshi Kakeda @kkd

@yoshiori いえいえ、いいんです。つまりこの議論はまだ綺麗に終っていない、ということなので。多分二周目はもっとよい議論ができるのだと信じています。

ヨシオリX @yoshiori

僕も基本的な感覚は一緒です。 RT @kis: テストとかよくわからんので、プログラム動作確認のときのSystem.out.printlnしたものに関しては、assertEqualsに書き換えてテストとして保存している。

tkskkd.deso | Takeshi Kakeda @kkd

TDDはAgileのコンテキストとは独立して語れるのは同意できるけど、自分はセットで語りたい派。なぜならTDDは漸進的開発プロセスのプログラマレベルのものだから。

ヨシオリX @yoshiori

@kis 基本は不安をテストしたいので、「System.out.println した」→「値を確認したかった(不安だった)」になるので、それをテストとして書くのも TDD だと思います。

ヨシオリX @yoshiori

@kis テストが開発のための動力源であれば、TDD だと思ってます。

Satoshi Kojima @skoji

TDDの話とテストファーストの話と、そしてUnitTest自体の話がやっぱりごっちゃになりがちなんだな。TDDで書かれるテストは(原則として)単体テストなんだから、製品としての品質保証に不十分なのは当たり前なんだがのう。

Satoshi Kojima @skoji

TDDは自動化されたUnitTestをうまく書く手法と捉えてもよいと思う。

Satoshi Kojima @skoji

TDDの「テストコードがどんどんダメになってく」問題への回答は、xUTPやThe Art of Unit Testingに書かれている。異論はあるだろうけど、でもこのレベルをおさえらずに実践されているTDDが多いのではないか。

Satoshi Kojima @skoji

TDDの議論も重要だけど、それとは独立してUnit Testの書き方を、独立して見なおす必要もあるのではないか。

Satoshi Kojima @skoji

TDDは個人レベルの話、って意見もあるが、個人「でも」できるが、それよりチームでやるほうがずっと好ましいと思う。

Satoshi Kojima @skoji

TDDはともかく、Unit Testについては、書き方も含めコーディング規約のようにチームで運用ルールを決めないと、コードのメンテナンスフェーズでの旨みがなくなっちゃう。

Satoshi Kojima @skoji

Unit Testがプログラマの不安を軽減する効果があるのは間違いないが、それを強調しすぎると、自分のためだけのテストになって、そうすると陳腐化するのも速くなる。メンテナンスフェーズで、他のひとがコードいじるときに使い物にならなくなっちゃう。

Satoshi Kojima @skoji

自分のためだけにUT書いてると、せっかくUTがあるのに、簡単に「レガシーコード」になっちまうわけですよ兄さん。