TDD について

t_yano @t_yano

私は実用主義タイプなので，当初どういう意味だったかとかわりとどうでもよくて，今の時代のTDDとはなんなのか，TDDを実践する上での障壁はなにで，どう回避して，どう開発に役立てられるのか，のほうに興味があり， *P3

t_yano @t_yano

名前は後付けでもなんでも，名前に興味がある人が決めてくれ，それ使うから，くらいの認識。名前が同じでも違ってても，やってることが同じなら同じだものん。 *P3

Hideki Kishida @quicy

TDDとQAの関係に関する疑問自体がよくわからない (T_T)

t_yano @t_yano

まあ一方で，名は体を表すので，実体を表すより適切な名前が提唱されるのならば，今後はそれを使いたいね。なので，それこそが重要だ！という人が名前決めて。 *P3

Yasuharu Nakano @nobeans

自分の例で言えば、TDDと品質保証との適合性は割と実用的な身近な悩みですね。ただ、SIerの受託開発とかじゃないとあんまり関係ない世界なのかも。どうなんだろう。

t_yano @t_yano

BDDはいまいち，ピンとこない名前なんだよね。。。 *P3

Hideki Kishida @quicy

どのフェーズのテストまでTDDを回せるのかって言う話なのかしら。QAテストまでTDDのサイクルに入れようという壮大な計画だったり。自分はユニットと機能くらいで閉じてるけど。

goyo @goyoki

ブログ書いた。勢いで書いてろくに推敲していないので、色々おかしい：TDD談義への反応に対する雑感 http://d.hatena.ne.jp/goyoki/20100223/1266939139

goyo @goyoki

おかしいところがあったら指摘ください。恥をかく前に修正してしまいます

Hideki Kishida @quicy

そうかー。自分は、TDDでやるべきでないレベルのテストをやってたのかー。だから話が噛み合なかったんだなー。へー。でも実際やってて、やるべきでないとは感じなかったな。

findup @findup

TDDのテストは、一般的に言われる単体テストほどの網羅性は持たないということなのかな。乱暴に言えば「コードの実装が終わったら要らなくなる」感じか。コードの修正に対する退行テストは"単体テスト"レベルでやらないと信頼性がないだろうし。

NISHIMOTO Keisuke @keisuke_n

TDDが品質保証をするものじゃない、という指摘って誰かしてたっけ?(少なくとも私はしてないが)

NISHIMOTO Keisuke @keisuke_n

テストが含まれてるんだから、当然動作の保証はされる。TDDがすすめばある程度以上は改善される。

@nsiena

#article 読んでる: 「TDDはテスト手法か否か」<http://togetter.com/li/6759 > : 先日の議論を振り返りつつ。

やましろ @yamashiro

TDDって開発をするエンジニアのものなんだなと素直に思っている。で、例の議論は正直僕は頭が悪いのでよくわからない。結局頭の悪い僕らはどうすればいいのだ？！

Yasuharu Nakano @nobeans

@quicy いや、実際自分もやります。テストファーストしたり、後付けで単体テスト(と自分は思っている)レベルのテストメソッドを追加したり。そういうのもTDDでOKですよ、とのことでした。ただ「ベーシックなTDD」だとはいえないようです。実装の駆動目的には、ちょっと豪華すぎますね

@nsiena

ほとんど既出の意見の繰り返しになるけれど。ひとことで言うと、「ともみなせる」と「とみなすべきものである」は違うかな、と。 #tdd

@nsiena

件の主張は。TDD は、基本的なテスト手法の一部を利用した設計・開発手法であって。主目的はテストをすることにあるのではなく、(仕様・実装の検証をしつつ) 開発を進めることにある、ということだよね。 #tdd

@nsiena

目的からして異なるので。手法の包含関係でテスト手法か否かを論じるのは違和感。<<include>> とか <<is-a>> とかではなく、<<use>> な関係。テスト手法ではない、と断定していいと思うのだけれど。だめ? #tdd

やましろ @yamashiro

エンジニアってかプログラマのためのTDDがあって、そのときに、あんまり単体テストかくのはよくないのってのはあるんだよね。かつ、別途単体テストを書くフェーズは必要だよねって思う。もっというとTDDレベルで不安がないなら、自動でできる結合レベルのテストでもいいと思うけど

@nsiena

テスト手法として不十分か否か、ということ自体がスコープ外なのではないかしらん。仕様の詳細化と、それとコードとの同一らしさの検証に役立つか否か、という観点しか持ってないと思ってる。 #tdd

やましろ @yamashiro

単にコストと利益の問題なんじゃねーのとか思うんだけど、違うのかな。

Yasuharu Nakano @nobeans

しかも、TDD→テストケース補充で品質保証をしてるんだ、という流れで、最終的な品質保証をしようとすると、組織的には異端なので理論武装を自前でやらないといけないのがつらいところ。しかも、専門的に問い詰められたら、相手を納得させられるかどうか自信はない。

@nsiena

「詳細化された仕様が適切で、かつ、コードがそれと同一と判定できる」という度合が高くなるので、結果的に成果物の品質が高くなるであろう、というだけで。 #tdd

Yasuharu Nakano @nobeans

だから、実装フェーズでTDDをしつつも、極端にいえばむしろTDDのテストは捨ててしまって、単体テスト・結合テストなどを普通に実施するというプロセスに落ち着くんだよなー。すくなくとも文書化されるようなプロセスとしては。