Togetter - 「TDD について」

これはいい議論。喉の小骨がとれた感じ。 RT @wyukawa: TDDはテスト手法か否か　http://togetter.com/li/6759

テスト一個書く->RED->実装一個書く->GREEN->テスト一個追加->RED->実装変更->GREEN->テスト一個追加->GREEN->異常テスト追加->RED->実装変更->GREEN->異常テスト追加->GREEN そして反復 自分のやり方はこのリズムの繰り返しかなー

途中、GREENである事が確実になるテストを検証するために入れることはあるけど、基本最初はREDで始めるし、新しいことやってREDにならなかったらまず慌てふためく

愚直といえば愚直なんだけど、最初にREDである事を確認するのは安心のための儀式になるんだよね

最近は、開発手法としてのTDDではなくて品質保証としての自動テストに悩みを持っていたりする。むー。

ユニットテストを出力するもTDDの目標化もしれんけど、主な目標じゃない。TDDの主な目標は細かく継続的に実装作業のフィードバックを得ること

IDEとTDDとの関係は、IDEの「お助け度」によって色々と調整が入って当然じゃないかと思ってるかな

そこらへんテストエンジニアの方にはイメージしにくいのかもしれんね。だけど協調とか対立は駄目とか主張するなら、相手の視点に立って考える必要もあると思うんだけどな

勢いで今から考えをまとめてブログに書いてみる

たとえばメソッドの名称を変更したとして、IDE無しだったら一々コンパイルを通してエラー吐かなくなるまで頑張るけど、IDE有りだったら今ならリファクタリング機能で一発だし

TDDのテストがテストじゃないとか、品質保証（の一部）じゃないとか、意味分かんない。

作っているシステムが品質に非常に敏感立ったりする(飛行機や自動車の制御システムとか)場合、まずTDDで開発、そしてカバレッジ等も考慮してUnitTestを後から拡充、というやり方もあると思う。もちろん、それをやるための工数が確保できること前提

UnitTestとそれを使った自動反復テストは十分に品質の担保になりえるからね

あ、コードの仕様的な領域においての品質ね

TDDやっておまけでついてくる美味しい部分に感動して、そこをアピールしたくなるのは分かるけど、肝心のテストがまずかったら、結局TDDうまくいかないでしょ。

ひとつ言えるのは、UnitTest出現以前の「単体テスト」は、TDDの品質の足元にも及ばない悪い品質しか「保証」できなかったってことかな。最終的なガワの品質がなんとかなってたのは、それ以降のテストの厚みと最終的にはベテランのカバーだった

テストとTDDが違うのはTDDはモチベーションが必要でかつモチベーションでぐるぐる回せるということじゃないかと思ってる。テストは単純にテストによる動作の保証の担保の確認。

まさに。TDDは開発者頭、テストはテスタ頭になる。帽子をかぶりなおすともいうらしい。 RT @sunaot : テストコード書くときと TDD するときの視点てまったく違うよね。それはクラス設計しているときとテスト設計してるときで視点が違うのとまったく一緒で。

TDDについて、これだけ日本の技術者が持論を語り合うという場が成立していること自体が素晴らしいなぁ

いろんな人の意見はよく理解できる。けど、もし自分の下につく新人が、「TDDのテストはテストじゃねーんですよ」とか言ったら、はり倒す。

まずリファクタリングに耐えうるテスト書いてから言えやコラ。そのレベルを既に超えてる人が何を言っても、その人なりの理解でOKだと思う。

TDDを推進してる人がなぜ「テスト」「品質保証」という用語に敏感になっているのか、という背景には、テスタや品質保証の専門家が関わるような、組織・プロジェクト全体をまたがる品質保証プロセスの存在も無視できないと思う。

総合的な品質保証プロセスの中で、有効性を保ったままTDDをどのように位置づけて取り込んでいくか、というのはすごく難しい問題。単にそういう規模の開発プロジェクトは対象外と切り捨る方法もあるかもしれないけど、そうなると、TDDのフィールドがすごくせまくなってしまう。

品質保証というのは高いスキルや専門性を必要とする分野なので、TDD推進活動の初期段階でそこに踏み込むには時期尚早というかおそらく推進者自身の経験も不足しているから、あえてそこは触れないようにした、というTDDを普及させるための戦略だった可能性も考えた方が良いんじゃないだろうか。

.@t_wadaをはじめとする２周目以前の人々のおかげで、自分も含めた３周目のTDD実践者がずいぶんと増えたので、今こそそこに取り組む段階に来たのかなーと思う。なので「テストっていわないのはおかしい」じゃなくて「品質保証プロセスとの適合性」についての意見が聞きたいですね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「TDD→単体テスト・結合テスト」あたりで、なんかうまいつなぎ方というかショートカットがないものか。できれば属人的ではなくプロセス的に確立した方法で。一応SIerなので。

例えば。仮に開発を滞らせるようなテストケースがあったとしたら。(条件にもよるけど) テストから省くことも有力な選択肢になりえるはず。後で検証すべき項目に加えておく、とかして。テストに引きずられてしまうのであれば、本末転倒。 #tdd

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

これは、テスト手法ではないからこそ認められる選択肢なのではなかろか。テスト手法であるならば、それが必要なテストケースならば必ず検証しなければならない、となるのでないかしら。/ ここでは、工数とかの実務上の制約は措いとく。 #tdd

今宵は皆スタンドアローンで TDD に対する自分の考えをつぶやくモード?

TDD で作られたテストケースが品質保証のテストとして *も* 有用ならば再利用すればいいし、そうでなければ捨てればいい。 #tdd

で、品質保証でいうところのどのテストをカバーできるの。もしくは、テストケースがどこをカバーできるのかどうやって判定するの。判定できたとして、どう再利用するの。もしくは、不足しているものが何か、どうやって特定するの。 #tdd

自分は、ほとんど全部のコードを赤緑で書いて、それ以降特にユニットテストの工程を必要としないようにやる方向に落ち着いてる。捨てるのはむしろテストなしで書いた仮実装コードで、テストは捨てない流。

あえて、独白にすることで各自が注目する軸に沿った、各自の持論を垂れ流すメソッド。別に意図した訳じゃないけど。こういう多軸なトピックで一々＠つけてると、お互いのポジションを確かめ合うだけで時間とパワーを使ってしまうような気がする。

昨夜以降の TDD 議論を @yojik_ に少し追記していただきました。感謝。 http://togetter.com/li/6759

自分も実践上はほぼ同じ感じです。RT @quicy: 自分は、ほとんど全部のコードを赤緑で書いて、それ以降特にユニットテストの工程を必要としないようにやる方向に落ち着いてる。捨てるのはむしろテストなしで書いた仮実装コードで、テストは捨てない流。

この流れなら言える。 第10回 xUnit Test Patterns 読書会 03/27 13:00 から川崎市産業振興会館にて。 TDD やテストの議論に興味ある方はぜひ参加ください。 http://atnd.org/events/3331

テストに関してもっとつっこんで考えたいから、実践アジャイルテストって本は早く読まないとだな…

でもいったん書いちゃったテストは(他のコード同様)独り立ちして、勝手に育っていくので、読みやすく書きたい。TDDではどっちのコードもきれいになる。テストが読みやすいコードは、レビューによる品質の評価もしやすい。メンテや、不要テストの除去もたぶんラク。

今の僕がかかわってるプロジェクトの開発の半分ぐらいの人はTDDで開発してる。で、品質は異常に高いと主観的に思う。で、個人的に課題は、結合テスト？機能テスト？が自動化できてないなと。ようは、正常系をSeleniumでテスト化しないといけないだろうと思ってる

「TDDはテスト手法か否か」<http://togetter.com/li/6759 > を読んでいて。恥ずかしなら画、「反証テスト」に変な引っ掛かり方をして、誤解釈してしまっていたとかいう。先の一連のそれは、その辺を見直してメモしてたついでに出てきたものだったりする。 #tdd

某先生語録「テストで品質があがるわけではない。確認できるだけ」

TDD議論を読みふけってしまったけど、やらなきゃいけない仕事から逃避するのに丁度いい逃げ口上になってしまった。仕事やらねば。TDDってのは個人に属して、テストってのは組織に属するというところが論点がかみ合わないところじゃないだろうか。

@bohnen TDD は個人に属するものなの? チームで共有されるものではないのかしらん。

@nsiena メンバーの能力と価値観が揃っていればそう考えてもいいと思います。現実はそれを狙って構成するのは結構難しいですね。僕のチームでは無理。

@bohnen 揃ってないなら揃えればいいじゃない、っと。つ[ペアプロ+ペア交代] / 言うは易し ^^;

個人か、組織かというより開発者か、QCか、というふうに考えてもいいかも

@nsiena その難しさを端的にわかってもらうには、研究室(D5もM1もB4も混在)の開発レベルを揃えることを想像してもらうといいと思います :-)

仕事から逃避したいのか、また読みふけってしまった。なるほど、僕はあえてTDDはテスト技法でないと言いたい派だな。テスト技法と言ったときの弊害が大きいので、むしろテストとTDDとを混ぜるなと主張したい。

ブログ更新: TDDは品質担保のためでは無い？ http://bit.ly/ccQ4cB

@goyoki 何を言いたかったのかが良く分かりました。信頼性や性能のテストのことだったんですね。ただ、コンテキストの問題と言うより、品質保証担当者がやるテストって言う「役割」の話と、品質保証そのものの「目的」「活動」を混同してる問題だと思います。

開発者が自分でコードをかいたものをシステムテストと同じように基準を設けたりするのは確かに無理があると思うし、テストを完璧に準備してからコードを書かないといけないっていうのも無理があると思います。なので、後で見やすく、追加しやすくしておけば良いのでしょう。それも同意。

けど、それ以前の問題も多い。

デベロッパーテスト、カスタマーテスト、QAテストって切り口は、要はテスト戦略の1パターンです。この布陣で、開発者は、設計レベルの機能性や保守性、顧客は製品としての機能、QAは信頼性や性能をテストして、全体的に品質を保証するってことじゃない？

最終的にいいものができるよう、バランスをとってコーディネイト出来てれば良い話で、それぞれにはそれぞれのやり方があって当然だと思います。

TDDはテスト手法なのか? 議論。(http://togetter.com/li/6759) ポパーの反証主義でいうところの「反証」って言葉をそのまま使うのは不用意な気がした。ポパーあれは科学と疑似科学の線引きにかかわる話で、コードの検証との類似はあるが別の話、だと思う。

@goyoki 読みました。よくまとまっていますねー。大勢の人に読まれると思うので今のうちに「などと読んでいるテストの定義は」は「などと呼んでいるテストの定義は」に直しておきましょう。

goyokiさんも品質保証を知らないっぽい。保証=基準を満たしていると証明する。TDDでは計測しない=保証できない #tddnet QT @nsiena:TDD談義への反応に対する雑感http://d.hatena.ne.jp/goyoki/20100223/1266939139

TDDはコードがtestableになって安心して開発を進めることのできる開発手法であってテスト技法そのものではないけど、testableで安心感を得るためにはある程度テストコードに網羅性が必要で、そういう意味で品質にも寄与するよ、って言えばいいんじゃないのかなぁ。

@goyoki 読んでいる→呼んでいる。という誤字は置いておきます。TDDでやりたいことや、目指しているものは、分かります。では、品質保証の人達が求めていることは、どのように実現するのでしょうか？ それが書かれていれば、良いと思います。

「最初から網羅してなくても始められるよ、大丈夫」と言ってあげられるか否か、という問題のような気がする。ただ実際最初は苦労するけどw 自分も「ちゃんと実践できてる」とは言わないし。「以前よりテストしやすくてメンテしやすいコードが書けるようになった」とありのままを言う。

"TDDは割に合う具体的な実装手法" "ロールを跨ぐ議論では他への敬意必要"RT @goyoki: TDD談義への反応に対する雑感 http://d.hatena.ne.jp/goyoki/20100223/1266939139

@goyoki 一部の優秀な技術者が実施しているTDDではなく、よく無い人達が実施しているTDDを対象にしています。日本において、TDDをやったというプログラムには、多くのバグが残っています。従来の単体テストに比べて、多いケースもあります。この課題に対する見解を聞きたいのです。

品質に寄与しない技法ってなにかなあ。

「品質保証」は、品質を上げることではない。品質を計測して、一定の品質を持っていることを、顧客に対して証明すること。 #tddnet

@mkoszk それはもうひとつのテストファーストって書いてあるような気がするのですが。

@goyoki TDDはテストでないとするならば、バグを取るために、何をやっているのかを示たら、誤解はなくなります。TDDを批判しているのではありません。TDD以外のどんな方法を採用して、バグを取るのかを知りたいのです。

個人的にはTDDとバージョン管理は意識を変える必要があるという意味で同じだと感じてる。最初はやっぱ面倒。でも慣れるとないとやってられない。TwitterやiPhoneと一緒。「何が面白いの？」「やってみりゃ分かるって！」「やるのがメンドイんだって。」

書こうとしたものが書けたかどうかが知りたいのか、役に立つもの（あの人が欲しかったもの）が書けたかどうか知りたいのか‥

TDDがダメだとは誰も思ってなくて、TDDでやるとバグがないんです、みたいな宣伝を心配してるんじゃないすかねえ。もうそんなこと言ってる人はいなくなったかもしれませんが、大昔はそれっぽいタイトルの本や宣伝が流行ってましたから。

TDD の話はマーケティングと論理性を分けるのがいい。Kent Beck は業界切ってのマーケターでありアーティキュレーション上手。

テストコードが使い捨てじゃなくて再利用可能になった点がすごくでかかったのを思い出した。

結局似たようなことは以前からやってたな、という人にとってはメリットもデメリットも限界も想像できる範囲を超えない。当たり前の話だけど。

「TDDはテストとして意味ないんでしょ」とか「TDDで全部解決するんだって？」とか思われるのが心配っていうのは分からなくもない。そういう短絡的な思考する人はたぶんコード書いてなくて決裁権のある人だから。

そういう人を内部的に騙すためにわざとそう言っちゃうのはアリな気がする。外部から騙すのはNGだけど。

いや、ソフトウェアテストとしては意味ないよ？

TDDってxUnitで自分が書こうとするもののゴールを書いて進む行為だよね？また違うの？xUnitのこと？それともxUnitで書かれたテストケース？

あるいはもっと広くて、テストによって駆動された開発全て、だとしたら、それはテストによって駆動された開発だもんなー。うちのチームはそうだ。それはテストじゃない。チームの活動。きっと品質と関係ある。

TDDって、コンパイルする言語でいうところの、コンパイルは通りました！みたいな感じじゃない？もうちょっと品が良いかもしれないけど。プロトタイプ宣言すると品質あがるんですよね、みたいな。

そういうわけで、コンパイルする言語を使ってたので、Cucumberみたいな粒度のテストケースにしてた。TDD的な正義はわからないけど、そうしないと旨味がなかったから。

@m_seki TDDの説明とするならば、そこに進化的設計の要素が欲しい気がします。つまりテストを足場にして設計を改善する

型にはいり、そして破り、離れるという守・破・離という段階が重要な分野はいろいろあって、たぶんソフトウェア開発もそう。なんだけど、肝心の守るべき型が、それほど安定していないのが困りものなんだよな。

この感覚はすごくある RT @m_seki: TDDって、コンパイルする言語でいうところの、コンパイルは通りました！みたいな感じじゃない？もうちょっと品が良いかもしれないけど。プロトタイプ宣言すると品質あがるんですよね、みたいな。

@mkoszk TDDをやった結果バグが多くなるという状況は考えていませんでした。TDDそのものを上手にできないとか、誤解しているというのでなければ、どうしてそうなってしまうんでしょうか。

@yattom TDDそのものの問題ではなく、TDDはここまでって境界をひいてしまうことで、誰も関与しないグレーゾーンが出来てしまい、最後のテストでバグが出続ける現象が 起きてしまうのだと思います(実話)。

@goyoki 具体的なイメージで話をすると伝わるかもしれません。まずは品質管理の立場の人になってみます。品質管理の人の多くは、バグ密度（規模あたりのバグ数）を気にします。単体テストにおけるバグ密度は、１０００ステップあたりいくら、みたいなものです。

@goyoki TDDはバグ密度は測れません。そのため、品質管理の人達は、納品されたソフトウェアの品質がよいものかどうかを定量的に測れないので困ります。そして、受け入れテストをすると、彼らの常識では考えられないぐらいバグがでることがあります。

@goyoki 納品物を差し戻しても、TDDをやったと言っている人達は、新たなバグを取れないのです。品質管理の人達が指摘をしたバグを修正することはできますが、品質管理の人達が求めている品質にすることができないのです。

@goyoki 彼らは、TDDの価値、良さ、目的を否定しているわけではありません。ただ、TDDをやったと言う人達の作った納品物の中には、受け入れられないレベルのものがあり、その説明を求めて答えてくれない（開発者が品質管理の文脈で説明できない）ので、問題だと言っているのです。

@goyoki 誤解をしてほしくないのですが、TDDを否定しているわけではありません。ただ、ブログを読む限り、TDDの目的、価値について書かれているのですが、品質管理の面でどうするのかが書かれていないのが気になっているのです。

@yattom TDDをやったからバグが多くなったと言っているのではありません。「TDDを実施したので、品質指標値（バグ密度）を提出できません。」と言う開発者のプログラムに多数のバグが入っているケースがかなり見受けられます。その原因はTDDをちゃんとやれていないのかもしれません。

なるほど。RT @mkoszk: @goyoki TDDはバグ密度は測れません。そのため、品質管理の人達は、納品されたソフトウェアの品質がよいものかどうかを定量的に測れないので困ります。そして、受け入れテストをすると、彼らの常識では考えられないぐらいバグがでることがあります。

@yattom 僕の仕事は品質管理ではありませんが、彼らの立場からすると、TDDを否定しているわけではなく、もしTDDのやり方が良くないのであれば、何を見れば良くないことが分かるのかを知りたいのだと思います。

@yattom 従来、彼らが使っている品質指標値（バグ密度など）以外で測定できるのであれば、それを指標値にすれば良いだけなので、品質管理からの問題提起は少なくなると思います。

@skoji .@mkoszk さんのいわれるような、TDDやってるけどものすごく品質がひくいケースは、品質管理の文脈理解以前に、おそらくTDDとして致命的にまちがってます。それを解決するのが本質ではないかとおもいます。

とはいえ開発者も、品質管理の文脈で会話できなくてはいけないですね。

そこで、JUnit Max ですよ。RT: @yattom: この感覚はすごくある RT @m_seki: TDDって、コンパイルする言語でいうところの、コンパイルは通りました！みたいな感じじゃない？もうちょっと品が良いかもしれないけど。プロトタイプ宣言すると品質あがるん

@mkoszkさん経由で「TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等）」を読んだ。「開発、品質、テストが協調しあうのはとても大事なことだけれど、それだけにこういったロールをまたがる話題では相手の世界を尊重する視点が欠けてはならないと思う。」は良い言葉だね。

でもね、こんな経験を思い出したんだ。

知り合いに、小さい頃お家があまり裕福でなかった方がいた。僕が知り合ったときはとても金持ちだったのだけれど。

TDDで欠陥密度はかれ、っていわれても本質的に無理というか無意味ってのもあるなあ。

彼女は小さい頃、バターをほとんど食べられなかったんだそうな。安価に手に入るマーガリンばかり。だからマーガリンをバターと呼んでいたそうだ。そしてバターを「本バター」と呼んでいたとのこと。

マーガリンをバターと呼び、バターを本バターと呼ぶ。彼女の中では整合性が取れており、全く混乱が無い。しかし聞いている僕は、マーガリンはバターではないよ、と思っていた。バターにはバターの良いところがあり、マーガリンにはマーガリンの良いところがあるからだ。僕は、彼女を可哀想だと感じた。

TDDのテストにはTDDのテストの良いところがある。一般的な単体テストには一般的な単体テストの良いところがある。TDDのテストが一般的なテストで無いならば、テストという用語を使うべきではない。マーガリンをバターと呼ぶべきではないように。

@mkoszk なるほど、わかりました。品質保証のための指標(のひとつ)が使えなくなるという形で、開発者と品質保証担当のあいだにギャップができてしまうんですね。「TDDというプロセスの実施品質」を測りたい、という気持ちでしょうか。

TDDのテストが「TDDはコーディングを進めるための手段であり、テスト設計を主要な目的としていない」のであれば、TDDのテストは単に「コーディング促進技術」的な名前を付ければよいと思う。なぜわざわざ、目的の違う技術の名前をつけるのだろうか。そうすれば両者とも幸せだろうに。

最近の TDD の話題は、そもそも TDD のとらえ方が人によってずれているから発散しちゃってるのか。僕も開発者と単純に TDD と云っちゃうときはただのテストファースト開発について使ってるからなぁ…。TDD ムズかしい…。

いつも思うが、アジャイルの人達は素晴らしい思想を持っていて、それを高いレベルで具現化しているのに、なぜテストとかトヨタとか、他のドメインの用語を使って自分達を表現したがるのだろうか。もっと自分達の誇りを持って、適切な名前付けをすればよいのになぁ、と思う。

とはいえ、かくいう僕も、もしかしたらバターとマーガリンの違いを理解していないのかもしれない。可哀想なのは、僕の方かもしれない。

@yumotsuyo どこまでがTDDの領域で、どこからがテストの領域、という認識が合ってないということでしょうか。。。これもまた「TDDは品質保証の手段ではない」という考え方をすれば、そもそもテストはテストで（TDDじゃないとき同様)やるよね、となるように思います。

大事なことは、みんな書いているが、TDDのテストでどこまでできて、どこからができないのか、単体テストとの包含関係や相違点、共存の方法、切り分けのタイミングをどうすればよいのか、を議論することだと思う。そうすれば、みな幸せだし、何より議論していて楽しい。

TDDの良いところは、よく分かっているつもりです。2000年頃（もう十年前か）、TEFの勉強会【21世紀のテストシリーズ】で、XPとTDDを知って、すぐに使ってみました。うちの会社でも早い方だと思います。今までのコーディングとは異なり、気持ち良さというか、心地よさを感じました。

マーガリンを普及するために「バターには3種類ある。マーガリンを理解するためには、バターという言葉のイメージを変えよう」と叫ぶのは自由だ。マーガリン屋さんも、バター屋さんも、そう理解できるのであれば、特に問題は生じないだろう。バター屋さんだって、マーガリンを排斥したいわけではない。

@mkoszk 私もよく、TDDで品質がどれだけ上がるのか、上がったのかと聞かれて、基本的には答えに窮しています。コードカバレッジ、コートとテストの量の比率、レビュー回数や結果ぐらいで、相手も困った顔になります。

僕の指摘事項は、プログラム経験に焦点を当てているのではなく、契約というか、受け入れテストというか、そういう類のことに焦点を当てています。別の言い方をすると、TDDを理由にやるべきことをやらない人達に対して、どうすればよいのかを考えたいのです。

しかし考えておくべきなのは、マーガリン屋でもバター屋でもない、お客さんがどう認識するかだ。バターと書いてある商品を買ってマーガリンが入っており、注意書きをよく読むと「うちのマーガリンはバターと呼んでいます」と書いてあったら、怒るだろう。トランス脂肪酸を避けたい人には迷惑だ。

TDDで「テスト完了」と聞いた人は、上位層に行けば行くほど、何かしらの（一般的な）テストが完了したと感じると思う。アジャイルの人達がテストの定義を変えるのは自由だが、アジャイルのテストは一般的なテストを意味していないということを、上位層にもきちんと説明すべきだ。

でも私が付き合いのある組織のアジャイルな人達（割とジュニアな人達）は、TDDをするために「単体テストをきちんとやるわけですから品質が上がりますよ」という説得をしている。シニアなアジャイルの人達は、口をつぐんでいることが多い。エキスパートなアジャイルの人達は、きちんと説明するね。

アジャイルの人も、テストの人も、上位層も、みんな誤解しないような棲み分けのマップができるといいよね。どちらの強みも弱みもきちんと書いてあるような。世界を前向きにしよう。それが僕たち技術者のミッションだ。

@mkoszk この文脈で、実施されていない「やるべきこと」とはなんでしょうか？

というわけで、長くなりましたが、@goyokiさんのブログの感想でした。

品質やテストの人たちが、TDDを基本的に価値があるものと捉えて、そのうえでソフトウェア開発全体を良くするためにどうすべきか考えていることがわかった。今日の嬉しい驚き。驚いてたら失礼ですね。

昨夜からはあまり追えていないですけど、 TDD の話はどこまで伝播したのだろう。 togetter で皆で共有できるといいなと思います。

おお西さんだ! 鈴木さんも! すごいな。

結局TDDの話は参戦するタイミングを逸してしまったが、こうして各分野のエキスパートが前向きに議論を行う様は横から見ていてとてもエキサイティングだ。以前から思っているのだが大きな意味で顧客に満足を提供するためにある技術なのだから、変に壁を作らなくとも良いはずだよね。

対立の構造を作るのは技術ではない、どちらかというと人の問題だ。

TDDは開発者視点の仕様＆検証で、単体テストはユーザ視点の仕様＆検証。だから、両者は完全に一致しないが補い合う部分も多い。結果、ユーザから見た品質は向上されるのは自然。…とかどうですか？ #tdd

ユーザが明示的に要求していること、暗示的に要求していること。開発者が明示的に実現していること、暗示的に実現していること。主に4つの要素がある。とか論じてる人はいないですか？

そろそろ、TDDBCホクリクの合宿のテーマなんかも考え始めたいところ。

TDD はあの TDD の本に書いてある事以外の何かがあるんだろうか。だとしたら学ばねば。

@babie そのあたり理解生半可なんで違ってたら指摘下さると 嬉しいです。プログラミングは科学理論ではないのだから、反証主義をそのまま適用するのはなんかちがうぞ？ というのが言いたかったことです。

.@babie あ、ちょっと間違えた。プログラムは科学的な仮説ではないのだから、そもそも反証主義的検証の対象ではないのでは？ です。

InfoQっぽい。「さらっと」！！ RT @ryuzee: ｶﾞﾝｶﾞﾚ! RT @kawaguti: TDDの議論をさらっと英語に直してブログとかに書けると、日本からの情報発信ということになるのだろうか

@babie なるほど。納得しました。「テスト対象コード」が問題を解決する方法の仮説とみなせるのか、というところがちょっともやもやしますが、自分で考えてみます。

TDDもそうだけど、複数の目的があるプラクティスを説明するのが難し過ぎる...

@akiyama924 ご指摘ありがとうございます！

@yumotsuyo すみません。その点は理解不足で読解ができていなかったかもしれません。見直してみると結構根が深そうなこちらの勘違いのようですので、少々考えさせてください >品質保証担当者がやるテストって言う「役割」の話と、品質保証そのものの「目的」「活動」を混同

@biac エントリをもう少し読み込んでみてください。その品質保証の定義はエントリで言う「一般的な品質保証」に含まれるもので、Kent Beckや和田さんがTDDの文脈で使用していた品質保証のテストと定義が異なります。

@biac エントリでは品質保証をKent Beckや和田さんの定義で使用していますが、その一般的な品質保証と定義が違いすぎて混乱の元となっているため、最初の用語の定義づけ部分とTDDに対する開発者のコメント引用以外では使用していません。

@biac また「開発者のいう品質保証の定義」の項目で重ねて一般的な品質保証の定義と意味が大きく異なると明記しているので、間違った印象は与えないと思います。

@mkoszk （見識不足のため誤認識もあると思いますが）TDDでは「自分の手元の作業で欠陥が混入したか」という視点で欠陥を洗い出すため、現実としてテスト担当の方が行うような詳細なバグ出しのテストを、TDDで補間できると保証できないように感じます >何をやっているのか

@mkoszk 例えばテストコードと上流仕様のトレーサビリティは通常考慮されませんし、網羅的な欠陥検出を行うようにテストコードを再設計するという視点も、TDDの説明ではあまり語られていないように感じます。

@mkoszk そのためTDDをバグだしのテストとして運用してしまうと、その通り欠陥密度が増えるような事態になるリスクは十分に考えられると思います。「TDDを理由にやるべきことをやらない」状態もかなりリスクを伴っていると感じます

@mkoszk TDDで品質向上というのは、手元のミスの検出が品質に寄与することに依存するように感じます。とても曖昧なので、例えば和田卓人さん等は、TDDで具体的に品質が向上すると説明する代わりに、「感覚的に」「副作用的に」品質が向上するといった表現を使われることがあります

@mkoszk 永田敦さんや森崎さんからも同じ指摘を受けましたが、その視点でみれば、TDDはリスクを持っていると思います。なので話が逸れるかもしれませんが、（レビューやテストコードの共有といった形による）一般的なソフトウェアテストとの協調や相互補間はとても重要な課題だと思います

TDDは失敗するようなテストを書くというテストの記述方針が明確なのが良いかも。ぼんと製品コードがあって、そりゃあ仕様からブラックボックステスト書けば良いのだろうけど、何からはじめていいのかわからなかったり。TDDは次なにすれば良いか迷うことが無い。

@babie なるほどなるほど。そうだとすると、その方法論はTDDとは直交するかもしれませんね。

反証テストという言葉を持ち込むのが適切なのか分からないのと、それを正しく理解しているか分かってないので。気になったことを書き出しておく。適当な推測なので、真偽は知らぬい。(^^; #tdd

@yattom 品質管理者とプログラム開発者の価値観が違うというのは置いておいて、TDDで作られたプログラムの狭義の品質（バグが少ない／ない）をどのように評価するかが論点の一つです。

反証テストは、「命題はX → Xと矛盾するYを仮定 → Yは起こりえない → ゆえに、Xは正しいはず」ということの検証。有り得ない状況を想定して、それを否定することで、少なくともその点において命題が偽でないことを検証する。 #tdd

@yattom バグ密度が有効な指標値かどうかは議論のあるところですが、組織の中で使われているものを無くしたとき（TDDでバグ密度と言われても困りますよね）、それに変わる基準または指標が欲しいのだと思います。

ソフトウェアテストでの対応していそうな検証は。(A)「Fの仕様はX → Fが失敗するはずの条件Yを検証条件として設定 → y∈Yは実際にエラーになる → ゆえに、Xは正しいはず」。 #tdd

(B)「Fは仕様Xを実装している → Fが成功するはずの条件x∈Xをテストケースとして設定 → xが失敗する → ゆえに、Fは仕様Xを実装していない → 即ち、FないしXは間違い」。 #tdd

(A) と (B) は検証していることが違う。反証テストは (B) の方なのだろな。 #tdd

TDDは、品質保証に似た振る舞いをするけど、品質保証ではありません。で良いのかな…教典読み直してみるか。

@yattom 「TDDを実施したのでバグが少ない」という組織／個人もあると思いますが、TDDをやってもバグが減っていない、逆に増えるという組織／個人もあります。このとき、品質管理者の立場で考えると、どのように対応したらよいのか分からなくなってしまいます。

@yattom ですので、TDDを推し進めている方々に、品質管理者を納得させられる、何かを示唆してもらいたいと思っています。

(A) が対応するテストは。そのコードを利用する際には起こり得ない状況を想定して、*正しく* 失敗することを確認することで、「それを受け入れないという仕様」が正しいことを検証する。 #tdd

(B) に対応するテストは。これ <http://twitter.com/babie/status/9481804700 > みたいな、途中段階のコードの正しさの検証ばかりかしら。最終的なコードに対する反証テストは、TDD で扱われるべきものだろか。 #tdd

@goyoki TDDの品質面での寄与として、入出力に目を向けさせるというものがあります。初心者プログラマは、ロジックの実行順序に目を向けやすく、データの加工、つまり、入力と出力の対応関係を考慮外にしてしまい、仕様の実装漏れが起きやすくなります。そういうミスを未然に防いでいます。

ところで。(A) は反証テストではない、という理解が正しいとしたら。境界条件のテストの多くは、実証テストと反証テストの組合せではなく、実証テストのみでされるのでないかしら。 #tdd

@YasuharuNishi コメント大変恐縮します。その通り用語の定義や命名にも問題はあると思います。TDDでもテストという命名は問題があり、混乱回避のためTDDをBDDと言い換えようといった議論があります http://bit.ly/YW1lL

受理可能な入力範囲の内部にある境界のテストは、実証テストの組で境界の両側を検証。入力範囲の端点という境界のテストは、内側の実証テストのみ。反証テストは範囲外の値でのテストということになるけれど、当然仕様外の未定義動作だから無意味なのでやらない。ということでいいのかしら。 #tdd

@goyoki だからTDDの良い面、すばらしい面を踏まえつつ、他の技術／アプローチを取り入れられる余地を残していただけると、よいと思っています。

受理可能ではないのでエラー/例外送出にするというコードになっていて、それを検証するのだとすれば。そういう動作をするという仕様のテストになるので。やはり実証テスト、と。 #tdd

すみません。数が多いため、残りの返信等は夜頃行おうと思います

QAの人たちの主張はわかるんだけど、顧客「に対して」機能の質を保証するって考え方は*契約的*で、そこはAgileの顧客「と一緒に」サービスの質を考えていくって*ビジネス・パートナ*スタンスとは相容れない気がするんだよな

@skoji 質問の意図に正しく答えているかどうか不安なのですが、「TDDで作成されたプログラムおよびプログラム群の品質情報を提供する」が、実施されていない「やるべきこと」だと思っています。この場合の品質情報は狭義の品質、つまりバグの有り無しの情報で、まずは十分だと思います。

@goyoki う～ん、読みが浅かったかな… 「軽快にテストコードを書かないとTDDのメリットを殺してしまう」から「TDDは品質保証を目的としない」という結論に至ることを認めている、と読んだんだけど。メリットを殺してもTDDであることに変わりはなく、目的にできちゃうよね。

@mkoszk ありがとうございます。うーむ「バグありなしの情報」をTDDで開発したコードで提供するのは不可能、ですよね? 何か誤解してる気がするのですが、いかがでしょう。

WF界隈でもUnitTestが定着しつつあって、「だったらTDDで」とやりだす開発者が増えてきたことで、やっぱりある*違い*の部分でこういった談義が発生してきてるんだと認識してる

@mkoszk 補足です。誤解してるのは私のほうだと思ってます。

@goyoki TDDやってる側が「目的としない」・「考えない」・「扱いたくない」と思ってるだけでは弱くて。QA部隊に言い返すべきは「TDDでは品質管理項目の計測をしないから、品質保証はできない。必要なら何を計測すべきか言ってくれ、TDDとは別作業になるけど。」 #tddnet

TDDは、場を作りたいのだと思う。ばをつくるために、一見矛盾した説明しにくいプラクティスを導入するのは、常套手段。意図された、ダブルバインド。

TDD議論で思うのは、品質の属性のどこを重要視するかだと思うのさ。 結局xDDに始まる駆動開発は、品質の特定の属性を担保するものとして考えられるんではないかなと。

TDDでは、たくさんテストするけどバグは0件なんだよね。レッドが残ってたらチェックインできんのだから。でも、「バグ検出率 0%」だからといって、潜在バグ数(未発見のバグの推定値)がゼロということにはならない。品質保証に使えない。 #tddnet

@mitim プロとして負うべき品質保障の範囲と、協働によって達成すべき品質保障の範囲を顧客と話し合わなければならないのだと思う。「情報公開をもとめるが、全てを許すわけではない」via "ヒューマンエラーは裁けるか？"

@skoji 品質管理の方々の立場では、統計的にいうとプログラムにはある程度バグが混入していて、レビューやテストで除去するという考え方があります。そのため、いわゆるテストを実施したとき、そのバグ検出率を知りたくなります。

TDDやると品質は上がる。その後の工程で品質保証するためのコストは下がる。だから、品質保証活動の一環としてTDDを推奨することは、大いにありえると思う。 「TDDは品質保証に掛かるコストを下げる」 (その意味で「TDDは品質保証に寄与する」) #tddnet

気をつけなきゃいけないのは、潜在バグ数を出してしまうと現在あるどんなテスト手法も品質保証できない、ということになってしまいます。 RT: @biac: (略)…潜在バグ数(未発見のバグの推定値)がゼロということにはならない。品質保証に使えない。

@skoji ところが、TDDで行った「テスト」の場合、バグ検出率という概念そのものがナンセンスなので、品質管理者に提供できる情報が一つ少なくなります。TDDというプロセスを採用することによってバグが少なくなるという傾向が見えれば、問題は少ないはずです。

100% 品質というものが達成不可能な領域だからこそ、QA界隈でも*計測*が手法の主流になっている側面があるわけで

@skoji しかし、現実には「TDDを実施しました。だからバグ密度は出しません。」という組織／個人が納品したプログラムには、バグが多かったりするケースがあります。そういうとき、何を見れば品質をコントロールできるのかを見たいのです。

@skoji 一つのアプローチとしてテストケースの質を計るというものがあります。別の言葉を使うと、テスト設計のレビューという言い方になるかもしれません。ただ、このアプローチもTDDをやっている方々には受けが良くないので、何か別の情報が欲しいと思っています。

ごめん、わからない。潜在バグ数=0 じゃないと品質保証したことにならない? QT @mitim: 気をつけなきゃいけないのは、潜在バグ数を出してしまうと現在あるどんなテスト手法も品質保証できない、ということになってしまいます。 RT: @biac: (略)…

文脈からそうとれるように感じたので。潜在バグをどれだけ抑えるかは、テスト手法だけでなくあらゆる手法の課題ですよね;-) RT: @biac: ごめん、わからない。潜在バグ数=0 じゃないと品質保証したことにならない?

@mkoszk 丁寧にありがとうございます！ 問題の在処を理解しました。特に品質がわるいときは、簡単な話じゃないですね。

あらゆる手法の「果たそうとしている」課題、かorz

あー、待って待って。ごめん。私はQAとQCをゴッチャにしてるかもしれない。宿題… (汗;

今のところ、(A)「テストケース数」と（B)「質(観点の網羅性や確認手段)」あたりが品質面でのメトリクスに使えて、かつ、現実的かなぁ。(B)は大変に思えるけど、サンプリング方式、かつ、ソースコードレビューの一環でテストケースも合わせてチェックすれば、それほどでもないような。

潜在バグと顕在化について、量子力学をアナロジーにしたくなる症候群orz

.@mkoszk さんの一連のツイートが非常にわかりやすくて、かつ、SIerという組織における自分の関心事に近くて、非常にためになります。

品質管理者を納得させるためには、品質管理者の考え方がわからんとだめだね。

TDD TLで品質保証ってワードが散見されるが、人によって「品質」のさしている領域がかなり異なる感じがする。ここがぶれたままでよいのかね

ああそうか、TDDやっぱり品質"保証"を考慮に入れるのはおかしいな。要件をハッキリ確定するとか、シンプルな設計にするとかと同じく、作っていく過程での品質作りこみなのよな。

テスト＝試験工程＝品質保証って考えがちだったが短絡的だったね

TDDの議論から、「開発者が開発し、品質保証担当者が品質を保証する」という役割分担の問題点と、その次の段階が見えてくるといいんじゃないかと思った。

品質という言葉の定義がなんであれ、「(TDDとかで)品質を上げよう」とする開発者と、「(必要なだけ)高い品質にしよう」という品質保証の人、これだけ近い目標を持っている人たちのやってることが大きく違うというのはおかしい。

ここ二日くらいの TDD に関する議論を togetter する場合はこの前の議論の後ろにつなげるんじゃなくて新たに立てた方が良いですかね? http://togetter.com/li/6759

@t_wada 新たに立てて欲しい派です。

まだ読んでない方はぜひ読んでみてください「TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等）」by @goyoki さん http://bit.ly/aJ2uLq

@t_wada 別の方がうれしい派です。トピック自体も違う気がします。

了解、 togetter する場合はこの前のにつなぐんじゃなくて新たに立てた方が良さそうですね。

ソフトウェアとしての品質ではなく、プログラミングとしての品質ってなんだろう？コーディング規約の遵守度とか複雑度とか静的解析した結果とかになるのかな？ *Tw*

@t_wada ひと段落してたと思うので、分けて、相互にリンクするのが嬉しそう。前のまとめを読んだ人が、差分がどこからか探さなくてもすむと思うし。

とかいって、@t_wadaさんのTLからピックアップすると相当大変だと思うので、無理せずに「あとは各自よろしく方式」で良いと思います

TDD談議をみると人によってテストと言ってる内容が違うように見える。TDDのテストってプログラマがソースを書くためのテストやプログラムの振る舞いを確認するテストであってユーザーオペレーションに基づくテストではないとおもうんだけどなぁ

@cactusman 定義によると思うけど、ソフトウェアとしての品質は「きっちり動いている、パフォーマンスやリソースもバランスがいい」こと、プログラミングとしての品質は「コードの巧みさ、見やすさ、よりよい方法の選択(アルゴリズムなど)」かなーという漠然としたイメージ。

@regtan 「テスト」には確認対象による違いが一杯あるからきっちり限定しないと範囲が広すぎるね

@keisuke_n その辺の定義がしっかりしてないと議論が変になるのかな、と。TDD（CIも）自体、プログラミングの品質がメインの話じゃないかと。 *Tw*

TDDで書かれたソースが結果として、お客さんの求める品質に合致しているのであれば、TDDで品質保証が出来たといえる。けど、TDDのゴールって動く綺麗なソースを作るってことなんだから、必ずしもお客の求める品質を保証するわけではない

まだまだ続いている TDD に関する議論は本当に貴重です。皆でまとめませんか? 全員編集可にしてありますので、お気軽にどんどん追加しちゃってください http://togetter.com/li/6923

@cactusman TDDの本質と現場での目的が必ずしも一致していないのもTL上で議論されているところなんでしょう。現場では「負の資産を残さない」ことと「品質を上げる」ことがメインでしょうね。

@KKI おお、それは面白い視点。 > 「バグ曲線が嘘をつかないこと」を目指す *Tw*

@koizuka @t-wadaさんの言葉を借りるならばDeveloperTesting　CustomerTesting　QATestingという分類が出来てTDDでいうところのテストはDeveloperTestingを指すそうです

@cactusman プログラミングの品質は感覚的にはメンテナンス性とほぼ同義かなぁ メンテナンス性が複雑度や規約遵守度と繋がる感覚

自分としてはCIでチェックできるものが興味対象で、それって何？というところ。 *Tw*

@cactusman ウチは特にそれなりの規模のプログラムをチームで開発してるので、メンテナンス性をかなり高く見てるかも 俺が今担当してるのも約10年メンテしてる(かつこれからも拡張される)ものだし

TDDで品質保証までしようとするととても苦しい場面がある。マルチスレッドプログラムでデッドロックしないことの保証なんてTDDでやろうとしたらしんどすぎる。TDDのテストでたまたまデッドロックするのを見つけたりはするけど、それはデッドロックしないことの保証にはならない。

http://d.hatena.ne.jp/goyoki/20100223/1266939139 自分はTDDは身についてなくて、まだ単に不安をなくすために自動テストを使っているだけに過ぎないなあ。

@goyoki そうですね。@goyokiさんの仰るように、TDDが本質的にテストでないのであれば、設計の語彙を使った方がよいと思います。

でも僕がTDDに期待しているのは、単体テストを先に設計することで、詳細設計／コーディングで考慮すべき事項をすべてあらかじめ思いつくことができて、一発完動のコードを書けるような、開発者が自らを賢くすることのサポートなんですよね。

要するに、TDDで賢くなる、ってことなんです。リズムももちろん重要なんですが、賢くなる方がもっと重要だと思います。単にビヘイビアを考えるだけでは、そのコード部分で考慮すべき事項をすべて挙げられるとは限らないような気がしてなりません。

その意味では、すなわち考慮すべき事項をすべて考慮できていればバグなんて入り込まないわけですから、パス網羅なんてどうでもいいんですよね。

@YasuharuNishi 狭義のTDDでは、先に単体テストを設計しません。狭義のTDDは、コードの前にテストケースを書きますが、そのテストケースは不安を解消させるために記述するもので、テスト設計はやらないという選択をしていると聞いています。リズムが崩れるのでやらないと。

仕様書に書いてないことたくさんテストしてるけどなぁ。

@mitim なるほど、たしかに。これでどうかな f(^^; ⇒ 「TDDでは潜在バグ数の推定は出来ない。すなわち、品質保証でよくある潜在バグ数の保証は、TDDの範疇では不可能」

@biac 「TDDは品質保証を目的としない」は開発者のコメント引用であって、和田さん定義の品質保証です。biacさんのいう品質保証の定義ではありません。引用外ではその部分は「最初から一般的な単体テストを書くべきではない」として「品質保証」の用語をあえて使っていません

@biac 品質保証の用語については、仕事でテストを手がけますし、テスターのコミュニティやJSTQB等で学ぶ身ですので、重々知っているつもりです。ちょっと心外なところもあるので、後でエントリに追記したいと思います

@biac あと @biac さんは品質保証の意味を取り違えているように感じます。（JSTQBやIEEE等で定義される）一般的な「品質保証」は品質要件を基準以上に満たしていることを保証することを意味するのであって、どれぐらいバグが許容されるかは品質要件と基準によって変わります

@biac 例えば品質要件と基準をISO認証パスとするならば、そのQAでは認証に対する妥当性検証をパスすることに焦点が置かれます。そこでは認証に全く無影響なバグは潜在的・顕在的を問わず別に見逃しても品質保証に影響を与えません

@biac なので品質要件によってはTDDのテストコードのみでも品質保証が可能です（テストコードが品質要件を内包しているかが基準）。そうした背景があるので、エントリでは「TDDでは品質保証としない」という表現はさけ、「目的としない」「考えない」といった曖昧な表現を使っています

TDDで書くテストと品質保証のテストをベン図使って書いたら解決しそうなのだけれど。

「TDDはテスト手法ではない」がやはり正しいと確信した。というのはプログラミングにデバッグはつきものではあるが、プログラミングがデバッグではないように、isとhasの差がそこにある。

TDD議論がいつまでたっても進んでない気がするのは、実例がないからだろうか

自分がプログラマだと思ってる人も、テストエンジニアだと思ってる人も、自分の分野じゃないと信じたい辺りのプラクティスをやってみたらいいのに。

そういうわけで、id:goyokiに無責任な応援コメントを送った。

ここは了解。私の誤読でした > QT @goyoki: @biac …引用外では…「品質保証」の用語をあえて使っていません

どういった品質要件が計測できると考えていますか? > QT @goyoki: @biac なので品質要件によってはTDDのテストコードのみでも品質保証が可能です（テストコードが品質要件を内包しているかが基準）。…

TODO:帰ったらTDDのビックウェーブ乗る

経営者がビジョンやサービスを示し、顧客が機能を示し、開発組織がソフトウェアの仕様を示し、開発者が実装を示し、エンドユーザーはそれらのディティールによって価値をみいだす。と乱暴に定義すれば、皆さんの行っている品質保証とはどこの品質を確認する為の行為だろうか？

しかし、これだけTDDに関して、各者各様、様々な立場の人達の発言がデータベース化できたという事実だけですごいと思う。色々意見はあるとおもうけど、これだけの量がまとまって眺められるってだけですごい。

キャッチアップしたい！ QT @biac: ありがとうございます♪ 追加33人! 読み応え沢山 f(^^; > QT @t_wada: TDD TL の議論をひとまず 33 人分ほど足しました。「TDD について」 http://togetter.com/li/6923

「エンドユーザーはそれらのディティールによって価値をみいだす。」⇐これの品質保証はリリース前に100%網羅することは不可能なはずだが、現状やれていると感じている方も多いのかな？僕はTDDがこの辺の品質担保できないのではなく他の現状プロセスでも実は全く担保できていないと思う

xUnitなアーキテクチャで品質保証可能なものとプロセスとして品質保証の対応が必要なものとがごっちゃになっている気がする

コードや機能、サービスなどの「示されたもの」については「テスト」することで品質保証できると私は感じる。

TDDについていろんな意見があるが、ひとつだけ強く言っておきたいこと。書いたテスト「実装終わったら捨て」ちゃダメ! ぜったい! メンテナンスするときどうするんだよ!

RT @t_wada: 「TDD について」ひとまず編集終わり。まだ漏れがありますが、これから移動なのでしばらく触りません。興味のある方はどんどん編集してください。貴重な記録になると思います。 http://togetter.com/li/6923

エンドユーザーは僕らの想像を超えた使い方をするものだし、それを担保するのを普通の品質保証と一緒にしてはいけないと思う

TDDの話題とあまり関係なくなっちゃてる気もするが、まあ続けます。

@skoji 単体テストをxUnitで書いてれば、単体テストのテストケースを使う事ができるかと。テストが自動化されてないなら、確かに消しちゃダメ。

TDDで品質保証できるという人は、ファイル読み込みとかDB接続とかもxUnitでテスト書いて保証するの？テストコードが環境依存になり易いし、ならないように書くのにExcelをDB代わりにするとか面倒くさい。なら今まで通りの単体試験する方が好み。

品質保証って語が非常に曖昧で混乱の元凶なのか。僕的頭の中のイメージは、コード品質保証(xUnit)、機能品質保証(xUnit or 結合テスト)、サービス品質保証(xUnit or 結合テスト)、ディティールの一部品質保証(QA or βリリース)

@nobeans ん? 伝わってない気がします。わたしがいいたかったのは、TDDの過程で、xUnit使って書いたテストを捨てちゃダメ、ってことです。

あとプログラマ側のひとには、品質「保証」って言葉を「バグがない証明」みたいなナイーブな意味にとらえちゃってるひともいるような。そんなことはほぼ不可能ナリよ。

@skoji はい。伝わってます。捨てる派の場合はその後の単体テストで別途品質保証用のテストケースをJUnitで書くと思うのです。なので、TDDで書いたやつは捨ててもかまわない、という判断があるのかと思います。後々に残る自動テストが全くないのに、TDDのテスト捨てちゃだめですよね

@nobeans あ、なるほど。そういう派のことを想定してたんですね、理解しました。

恐らく、アクターが特定されないまま単語だけが独り歩きしてるからじゃないかと思いますねぇ RT @skoji: あとプログラマ側のひとには、品質「保証」って言葉を「バグがない証明」みたいなナイーブな意味にとらえちゃってるひともいるような。そんなことはほぼ不可能ナリよ。

最近は他人のコードをリファクタリングする時か、クラスを別プロジェクトで使いまわす時くらいしかTDDしてない。品質保証のためには使ってない。

でも、TDDのテストはそれまでの実装を駆動したんだから、やっぱりその後もきちんと有効活用したいなーという気持ちはあるんですよね・・・

「TDDでは品質保証できない」と、QA側から開発者に言うべきなんでしょう > @mkoszk: TDDを理由にやるべきことをやらない人達に対して、どうすればよいのかを考えたいのです。

先にも書いたが、「示されたもの」については「テスト」することで「示された範囲の品質保証は」できると私は思う。

正常系にしろ異常系にしろ「示されなければ」「テスト」は行えないし、偶然の産物で見つかるのは課題や問題であって、テスト項目的な何かではない

私も言ってます。「(現在単体テストをやってない組織では)品質が上がりますよ。」(でも、前提を上手く伝えられなかったり、言い忘れることすら… 反省) > @YasuharuNishi: TDDをするために「単体テストをきちんとやるわけですから品質が上がりますよ」

経験上設計してIF意識してTDDでリファクタリングしてくより、とりあえず機能を実現してからリファクタリングした方が良い設計になる。だったら最初からTDDでやるより、えぐいリファクタリングをするときだけTDDした方がテストコードが足かせにならない。

定義や明確化がされていないものをテストすることができないのは、コードでも機能でも、サービス、ディティールどのレベルでも一緒と思う。

最近の TDD 議論についてちゃんと僕の気持ちを書いてみる http://d.hatena.ne.jp/Yoshiori/20100224/1267015034

TDDで品質を上げるテストコードを書くのは結構難しい。テストコードとソースコードを見て漏れているテストコードを思いつくには単体試験の項目出すのと同じ能力が必要。試験項目書がない分コードレビューやペアプロが重要になる。

示された個々の機能やサービスが正しく機能していても設計にミスがあれば不具合は発生する。最近アメリカで物議をかもしだしている某日本車のように

品質保証のテストにはxUnitを使ってますか？ RT @yoshiori: 最近の TDD 議論についてちゃんと僕の気持ちを書いてみる http://bit.ly/bsEIvq

設計の漏れ、抜け、重複といった部分については、、、xUnitな話ではなくプロセスで解決する問題な気がする

リリース後も継続的に開発／メンテがつづく場合、品質保証の網羅的なテストだとスローテストになるというときにはどうしたらいいんだろう。TDDの軽量テスト群をその目的のためにとっておいて使い回せばいいのかな。

賛成。テストケースって、外部設計(external design)の具体例だしね。 > @YasuharuNishi でも僕がTDDに期待しているのは、単体テストを先に設計することで、詳細設計／コーディングで考慮すべき事項をすべてあらかじめ思いつくことができ…

TDDはアーキテクチャとしての側面とプロセスとしての側面を両方とも持っているけど、TDDのみで完成されるものでもない気がする。

TDDのテストは品質を完全に保証するテストではないと思う。というか、完全に保証するとテストがガチガチになって仕様変更に対応するためにコードをけずるはめになる。

しかしながら、ということは品質保証のテストは「ある時間的に定まった一点」をターゲットとして記述する必要があるのではないだろうか？ それも変更があった場合使い捨てられるテストにならないだろうか？

@nobeans いま、そこを自動化出来てないのがウチのプロジェクトの問題だと思ってます。 http://bit.ly/9leXeP

テストはユニットテストとインスペクションで担保すべきというのはイエスでもありノーでもあるな。インスペクションで担保し続けているコードを何処でユニットテストに切り替えるべきか...

自分が知ってる品質管理は、プロセスから出てきた動くソフトウェアの出来ばえとプロセスの具合をみて、もっかいプロセスを微調整していくこと。それを何度も何度も繰り返すこと。決まった手順が守られているかとか、バグ数が妥当かなんてことはどうでもよい。

それは一部は再利用できるかもしれないけれど、大きな変更があった場合は品質保証のテストケースを全て作り直した方が早い気がする。 (コードを対象とするテストを対象としていることに注意)

@yoshiori なるほど。そうするとTDDでできたテストだけですでにスローテストが発生してるんですね。

でも、まぁテスタブルなコードを書くかデバッカブルなコードを書くか、というと後者の方が比較的簡単なのは事実。むーん。

普通はメンテが続くので、その通りだと思います。RT @nobeans: リリース後も継続的に開発／メンテがつづく場合、品質保証の網羅的なテストだとスローテストになるというときにはどうしたらいいんだろう。TDDの軽量テスト群をその目的のためにとっておいて使い回せばいいのかな。

自分が知ってる品質保証は、客の好むものをだすために何をつくるか？何がつくれてるか？それが客の好みか？を繰り返すこと。潜んでるバグがどれだけあるかなんてことはどうでもよい。

個人的なスタンス表明。TDDが「テストコードを書くから」品質保証行為だ、には大反対。TDDの祖先はTry&Errorの書き方論だととらえてるから。ただし、TDDを行った結果生産されたUnitTestコードが、QAテストの礎になるんだという話なら、大いに賛成。

なんかちょっとずつ何かがみえてきてる、そんな気がする

当たり前と思えるところからおさらいしてみると何か見えるのかな？

｢TDDはテスト手法｣の人も｢TDDは開発手法｣の人も、プロジェクト全体としてみた場合に、どういう流れで開発してるのだろうか？全体の流れの中でTDDを見た場合にどんな位置にあるのか知りたいなぁ。僕はTDDを実践できてないので、イメージができないのです。

いや完全どころか、まったく保証できんでしょう。仕様書⇒テストケースのトレーサビリティを保証する仕組みがTDDには入ってないから。 QT @a_hisame: TDDのテストは品質を完全に保証するテストではない…

開発者の*危ないぞ*ノウハウやシグナルは、QAの質を底上げすると思ってる。

@nobeans そうですね。特にDBまわりのモック化が出来なくてそこで発生しています。発表の時も言ったのですが、cayenne を使用していて Entity が結構DBと密結合になってしまっていて発生しています。モック化まで手がまわってないのも個人的には残念な点ですね。

両方の考えの人で、TDDのほかのテストをどのようにやっているのか気になる。特にTDDを開発手法と考えている人がほかにどんなテストをしているのか。

逆に考えてみる。。。例えばTDD適用しない状況で「品質保証」できてると本当に言えるのか？できてると思ってるだけの状況も多いはず

なので、品質保証のテストコードでありつつ、コードの変更にジャマにならないという2つの要件を満たすテストがTDDで書かれるべきテストの目安なんじゃないかな？ 品質保証はある意味、TDDのテストが足りない部分を補うためのパターンをとことん試す場所、としても良いのではないか？

@kaorun55 うちの会社は基本WFモドキ(全工程オーバーラップでw、メソッドレベルの単体テスト抜きw)なので、TDDやってもやらなくても、次は結合テストですw

@biac 個人的には仕様で「0以上の整数を取る、取らない場合は例外を投げる」といった関数があった場合、この辺りをTDDでテストを加えると思うのですが、このテストが正しいとすれば、品質（のほんの一部ですが）を保証することになりませんかね？

TDDという開発手法の先にはDDDという問題解決方法につながると信じているんで、誰か一緒にDDDの勉強しないかと言ってみたり。

ソフトウェアに求められる*品質*ってやつは、けして一定ではなくて分野によって大きく動く変数なのだから、その分野と顧客の要望とを係数に入れないで*品質*をどう保証するかっていうのは、議論がすれ違う気がするなぁ

工程でぶったぎると、TDDは製造工程のアクティビティかつ進捗の基準にしてました

.@makotan 割とそれに近い結論かも。TDDがどうでもいいわけではなくて、品質保証は別途という点で。ただ、TDDが入ったことで品質保証のための今までのメトリクスデータからずれてしまう点をどうやって説明づけるかという課題が残る。勢いで説明したおすというのは無しの方向で。

あと自分的TDDとして「予測」的手法を用いて設計向上するという使い方もできると思っているんだが、あまり同じ意見の人に出会わないなぁ。

同意。くどいようだけど品質の属性は意識して議論したいところ。 RT @mitim: ソフトウェアに求められる*品質*ってやつは、けして一定ではなくて分野によって大きく動く変数なのだから、その分野と顧客の要望とを係数に入れないで*品質*をどう保証するかっていうのは、議論がすれ違う

そこまで詳細な仕様書が書かれてれば、テストケースへのトレーサビリティを示すのもまだ楽だろうなぁ QT @a_hisame: @biac 個人的には仕様で「0以上の整数を取る、取らない場合は例外を投げる」といった関数があった場合…

ケースの網羅性でいうとTDDだけだと穴だらけですわな。作った物が思った通り動くかの確認だから、思ってもみないことが無いことの確認ではない。

(A)新しいメトリクスをみつける、(B)TDDを含むプロセスに対する既存メトリクスデータを溜めて補正する、(C)顧客と調整して納得してもらう、(D)その他

品質保証とは思ってもみないことが無いといえるかの確認ととらえてます。

保証するには、まさにその「このテストが正しい」ということが言えないといけないわけですよ > QT @a_hisame: @biac …このテストが正しいとすれば、品質（のほんの一部ですが）を保証することになりませんかね？

TDDしなかったら、作ったものが思った通りにうごくかわからんがらくたしかできあがらない。

@biac しかしそれをいうと、テストそのもののテストが必要になり・・・（以下無限再帰） となりません？ 故に仮定を置いたのですが。

だから、「仕様書のxxは、テストケースyyに書いてあります。それはレビューして確かにそうなってると確認しました。」といったトレーサビリティで保証するわけ > QT @a_hisame: @biac しかしそれをいうと、テストそのもののテストが必要になり・・・（以下無限再帰）…

@a_hisame ちなみに、手動の単体テストも結合テストも、もとの仕様書から正しく導かれていることをレビューしたりして確認してる (…ことになってますw)

ただ、一連のTLを読んで思ったことは、TDDのテストは確かに一部の品質保証を含む。しかしながら、実行程でいうテストのフェーズにおいてTDDのテストを使おうとしても、おそらくそのテストの粒度が人によってバラバラ（少なくとも現状では）。

おー、最悪はビッグバンアタックですね！ RT: @biac: @kaorun55 うちの会社は基本WFモドキ(全工程オーバーラップでw、メソッドレベルの単体テスト抜きw)なので、TDDやってもやらなくても、次は結合テストですw

そうなんですね。 変わらないのはバグの発生数ということでしょうか。RT: @bash0C7: @kaorun55 私の場合はいわゆる試験工程はTDDしようがすまいが変わりなかったですね。

これら2つを結合する方向に持って行っても良いけれど、いっそ現場のテスト工程のテスト(単体テストなど)とTDDのテストは完全に切り離して考えた方が、他の人に受け入れられやすいかもしれない

そういう意味ではTDDという開発手法も柔軟性や保守性といった品質の属性を保証する一面もあると思うのさ。

@biac いっそTDDで作られたテストと仕様書で作られたテストとで完全に切り離してしまうのもありかなと思うんですよね。 手間は増えるかも知れないけれど、品質保障者は好き勝手やれるでしょうし。

製造業的視点で言うと、設計とテストを同じ人がやるなんてありえません! f(^^; > QT @a_hisame: …現場のテスト工程のテスト(単体テストなど)とTDDのテストは完全に切り離して考えた方が、他の人に受け入れられやすいかもしれない

@biac 同じ人がやったあと（自分の仕事がある程度正しいかを確かめた後）で、別の人がもう一度チェックする（こっちが本番のチェック）をしてもいいですよね？ 先に出した自分の意見は、前者がTDDのテスト、後者が品質保証のテストです。

アジャイル開発の中のTDDは、きっと「居心地」が良いんでしょうね。 > @mitim: 顧客に対して機能の質を保証するって考え方は契約的で、そこはAgileの顧客と一緒にサービスの質を考えていくってビジネス・パートナスタンスとは相容れない気がするんだよな

前者・後者が違う人なら、いいです。 QT @a_hisame: @biac …前者がTDDのテスト、後者が品質保証のテストです。

@nobeans それだとテストが十分か、バグを十分に出したかという答えが難しいので、過去実績からあらかじめテスト密度やバグ密度を予想したりしています。

@yattom はい、認識が合っていないです。TDDがテストじゃないって文脈だと、欠陥を見つけるためにいじわるなテストをシステムテストでやってバグがどんどこでるのは当然なのかもしれませんが、もっと早く見つけた方が効率よいんじゃないかと思うバグも多いわけです。

@babie 有難うございます。BDD については混乱を名前を変える事で解決しようとしてる(そしてそれは似た様な事を表す別の言葉が出来て逆に混乱の元なのでは？)としかとらえていなかったのてちゃんと学んでみようと思います。

ただ統計はデータの条件が異なるので困難です。web系の案件とc/sの案件を同列にする訳にもいかないですし。定量的とはいっても、目安程度で少なかったり多かったときの言い訳は定性的です（笑）

品質保証を目的としてTDDを行うかは戦略（意思）の問題で、少なくともテストのないコードと比較して品質は向上しているという結果は得られると思う。

@bohnen はい。定量的に進めるにはその通りですね。ただ、例えばTDDなり自動生成なりで、実際のバグ密度が低かったときに、じゃあバグ数がたりなかったのでテスト追加します、というのが妥当とは思えなくて。バグ密度が低い理由が考えられるならそれを理由に低い数字の妥当性を説明してます

同意。TDDは自分だけでも行う価値はあるスキルだと思う。(もちろん協力発展が出来ないとはいっていないので注意) QT @exKAZUu: 品質保証を目的としてTDDを行うかは戦略（意思）の問題で、少なくともテストのないコードと比較して品質は向上しているという結果は得られると思う。

少なくとも自分が使う分にはTDDは有用な技法であると感じるのでもっと学んでみたい。一方で、TDDによって引き起こされる問題もあるので、どうやってそれを解決して、どうすればより多くの人にとって有用な技法になるのかってことに興味を感じるなぁ。

"アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ" http://tumblr.com/xap6rjkxb

そう、少なくともスキルとして価値を感じるんですよね。 RT @a_hisame: 同意。TDDは自分だけでも行う価値はあるスキルだと思う。(もちろん協力発展が出来ないとはいっていないので注意) QT @exKAZUu: 品質保証を目的としてTDDを行うかは戦略（意思）の問題で、

TDDの副作用って何かある？ 品質保証どうしよう？という話以外になんかデメリットはあるんだっけ。

いえいえ。そんなことないです。　QT　@quicy　そうかー。自分は、TDDでやるべきでないレベルのテストをやってたのかー。

TDDをやっていて、かつ単体テストに置ける障害検出数が過去より少なかった場合、TDDによって品質があがった為と考えるか、TDDをやっているからと単体テストがおざなりになったからなのか、どうやって区別すれば良いんやろう？

さっき「スローテスト」が問題という話はあったけど、これはTDDに限った話ではなく、自動テスト一般の話だし

「TDDはテストではない」から単体テスト工程を品質保証の一環として行った場合の話。

@uokumura 単体テストの試験密度が過去のメトリクスデータと遜色ないのであれば、「TDDによって品質が上がった」でいいんじゃないでしょうか。試験密度があきらかに低ければ単体テストの手抜きってことで。

例えばね、テスト分析や設計の話でも、「そんなに早く出来ません」とか「全部の仕様を理解している時間がありません」って言う話が出るわけですよ。時間が無いとかそういう問題ですか？と言いたい。

TLがTDDの流れなので、乗ってみる。私はテストを書く事によってプログラマの工数が減るならユニットテストは書くべきだと思う。顧客からすれば、マトモに動くシステムが納品されるのは当たり前で、それを"当たり前"にするために確認（＝テスト）している。

「仕様を理解する時間がありません」って言っている人がテストしてたら心配になりませんか？

全部理解出来ていないかもしれない。けど、出来ませんって人はそこで終わりますから。

書いてから気づいた。これTDDじゃなくて、テストの自動化の話だ。

. @orangesignal @a_hisame これは自分一人で考えたネタではないのですが。TDDにおいて記述されたテストに冗長性があると思います。（片方のテストケースがもう片方を包含している等）。その積み重ねがテストの（時間）効率性や保守性を下げる可能性があるかなと。

確認項目多くて大変だから自動化する訳で・・・みたいな事書こうとしてたのに。

@nobeans カバレッジ取ったとして、例えば真面目にTDDしてたら常に100%で、ただし実装はfake itが残っちゃってる、とかですよね？で、中途なのに赤くするテストを思いついていなかった場合、おざなりな単体テストではおそらくバグを出せないかも、とか考えると…＞＜

@exKAZUu 自分としての意見は「2度チェックできる分信頼性上がる」とも考えられませんか？ ですね。 自分の中ではTDDのテスト=ファストテストなので、時間効率が下がるとしたらそれはTDDのテストではないと思っていますし。

メソッドレベルの外部設計書や単体テスト仕様書を書けなくなるw 半分はマジで、いまの若い人たちって書いた経験がまったく無いってのが珍しくない。そんなんで、設計書からテストケースを考えられるハズもなく… (;; > QT @nobeans: TDDの副作用って何かある？

@yoshiori TDDには一義的に設計・開発手法であり、二義的にテスト手法（しかし不十分）である。BDDは不完全な二義的な意味を剥ぎとって、一義的な設計・開発手法に的を絞った。というのが私の認識です。

帰宅。見事に今宵も TDD TL の模様?

@biac ？ それはTDDを実践した結果現われる副作用ですか？

周りから見たらどう映ってるのかわからないけど、自分で損してると思うくらいならTDDやらないからなー。むずかしい。

@uokumura カバレッジではなくて、僕が書いたのは試験密度ですね。コード1000行あたりN件の試験項目があります、というやつ。だいたい組織ごとに過去のPJの統計データがあったりして、それより多いか少ないかで試験の量が十分かどうか判断できます。

もちろんいい加減なテストをたくさん用意して試験密度を上げることもできるので、基本的には参考値だったりします。あ、試験項目レビューでそういうのはつぶすのかな。

@babie 僕も同じ認識なのですが、言葉を変える事によって二義的な意味を剥ぎとろうとした。けどそこまで普及しなく、逆に似た様な事を表す別の言葉になってしまっているのではないかなぁという認識です。

なんかTDDの定義で盛り上がってるな－。TDDは「Driven」が指すように「テスト→開発」という時間軸が重要だと思う。「テスト手法」って言われているのはいわゆる時間軸を無視して期待通り動くかどうかを確認する論理的なところだと思う。着目するところが違うのだから一緒ではないだろう。

. @a_hisame 完全に重複（包含）したテストコードはあり得ますよね。テストを完全に設計してコード化するのではなく、TDDがインクリメンタルなプロセスである故、比較して品質向上に貢献しないコードが出やすいと思います。それは改善可能な性質ですから別の技術で解決したいと思います

@makotan ?? 確かに俺はまったくデバッガ使わないけど (一部では有名だよね) そんな話したの?

TDDやるひとは、TDDistじゃなくてTDDerなのね。てぃーでぃーでぃあー？てぃーでぃーだー？

メソッドレベルの外部設計書を書かせている組織は、書けないヤツを教育してる。TDDが上手くいって、その設計書を書かなくなれば、教育もしなくなる。組織としては、そのスキルを失うことになる。 QT @a_hisame: @biac ？ それはTDDを実践した結果現われる副作用ですか？

ただ、重複したテストがどの程度問題を引き起こすのかというのはあまり実感できていないかも。でも、重複しないにこしたことはないかなーと。

@babie 僕が BDD の説明を読んだ時には常に「TDD ではこのような誤解が……」のような説明ばかりだったので、「TDD ありきじゃないと BDD は語れないんじゃない？」と感じたので偏見が入っているかもしれませんが＞＜

TDDにこだわる必要はなくて、作る機能を確認するための方法を先に用意しておくと色々メリットあるのかーぐらいに考えている。

網羅性とかなんとかは、どう開発するかという時間軸が含まれていないからTDDの本質とは違うと思う。そして、「いいテスト手法」を用いてTDD使えば最終品質は良くなるだろう。これは当たり前。「悪いテスト手法」を用いてTDDを使っても最終品質が良くなるわけがない。これも当たり前。

@nobeans あ、なるほど。…むむ。やっぱり、テストとともに実コードも成長するので、おそらくテスト数と実コード行数の比率ってそんなに変わんないですよね？タスクに取り掛かった最初とC/I直前でテストコードと実コードと触る比率はあんま変わんないと思いますし。

@yoshiori なるほど。周知・普及が充分でないという認識ですね。BDDは日本のRuby界隈（特にRails界隈）ではmoroさんやyuguiさんの尽力により割と普及していると思うのですが、Javaなどではそうでもないですか？

@biac 別にTDDのテスト=メソッドレベルの外部設計書と思わなければ問題がないのでは？

和田さんのTLをまとめたやつの中に、顧客に機能の質を保証するって考え方は契約的でパートナー的じゃないよーって話が正直嫌な気分になりました。私が言いたいのは、ソフトウェアは使ってもらってなんぼだってこと。楽しい、仲間だぜって感じでやる話じゃないってこと。

TDD は Takuto Dame Dame とか Takuto Deeply Drunken の略だとか言ってるのは誰だッ！！

@exKAZUu 個人的には重複したテストも「対象領域」が違うので、狭義の重複には当らないのではないかと「考えています」。 まあ、実践or識者の意見を聞きたいところです。

テストレビュワーとしてはそれはちょっと。まず有効でないテストケースが多いのではないかと疑います。RT @nobeans: @uokumura 単体テストの試験密度が過去のメトリクスデータと遜色ないのであれば、「TDDによって品質が上がった」でいいんじゃないでしょうか。

う～ん、そうかなぁ? メソッドレベルの外部設計書をまともに書けない人にTDDやらせると、テストケースがボロボロだよ? QT @a_hisame: @biac 別にTDDのテスト=メソッドレベルの外部設計書と思わなければ問題がないのでは？

TDDと品質保証の話のポイントは、詰まるところ開発者責任はどこまでかという問いに収束するように思う。で、私は「仕様書に書いてあることは全てその通りに動くことまで」が開発者の責任だと思っている。

DRY原則に～という論調で片付けていたけど、具体的に不味い事例とかは欲しいな

@babie 残念ながら TDD すら周知・普及がまだまだだと思います。また、BDD の話しになっても rSpec ウラヤマシス とはなっても、Jbehave マンセー にはなっていないと思います。

@yumotsuyo そう。にしさんらしい、いい話なので騙されそうになっちゃうんだけど私は違うと思う。

@biac 逆です。自分が言いたいのはTDDが適切に出来るのであればメソッドレベルの外部設計書は書けませんか？ ってことを主張したい。

@akiyama924 賛成　QT　私は「仕様書に書いてあることは全てその通りに動くことまで」が開発者の責任だと思っている。

@a_hisame ええ、そうですね～。そもそも重複の定義とはなにか、そしてその重複は本当に問題であるのかっていうのは議論の余地があると思います。ただ、テストコード削除しないとやべーよっていう状況もあるそうなんで、そういう状況に拍車をかけやすいのかなーぐらいに思ってますー。

なるほど、それは正しいと思う QT @a_hisame: @biac 逆です。自分が言いたいのはTDDが適切に出来るのであればメソッドレベルの外部設計書は書けませんか？ ってことを主張したい。

なんとなく BDD と TDD って言語論争とかエディタ論争とかと似ている気がしてきた

@exKAZUu そのテストコードってどっちのテストです？ > TDDのテスト or 作業工程内のテスト / 自分には削除理由が思いつかない...

何故、違うと思うかというと、TDDは今はマーガリンかもしれないけど、本来はバターにならなければならないと思うから。だから、「あなたはバターなんだよ」と皆が声をそろえて言うことが大切。

TDD/BDD は設計/開発手法ということで FA だと思ってたんだけど、世の中的にはあまりコンセンサス取れてないのかね？

後、TDDはチームのスキルに依存する。仮に先輩から「TDDは現場で今から使えるか？」と聞かれても「既存コードがレガシーすぎて無理。後、圧倒的にスキルが足りない」としか回答出来ない。

@exKAZUu どの様な重複が問題で、どの様な重複が問題ないのかの線引きを研究にすればいい。

いろいろなところで議論されてますが、開発規模とか組織とか契約形態とかが多様で、前提や経験の共有が難しいですね。予想されたことですが…

俺の中でBDDは語彙や振舞いに注目してるってだけで、TDDと本質的にはなんら変わらないものだと思ってたんだけど。TDDのテストは振舞いをテストしてるんだから、TじゃなくてBだろ!的な。

ただ、そうなってもらうには、なにをどう教えればいいか…? QT @a_hisame: @biac …TDDが適切に出来るのであれば…

というのは、mkoszkさんも言っていたけどTDDを使ってもバグがあまり取れないケースがあるから。そして、TDDを使って品質をかなり高めている組織もあるという事実があること。

TDDって、設計技法なわけなんだけど、それは熟練者がやるからこそ大きな意味がでてくる。だから「TDDしなくてもそこそこのクラス設計ができる人」がやんないとあんまし大きな効果は得られないと思うんだなあ。もともと設計がヘタクソな人がTDDやっても、結局だめクラスが生産されちまうんだ。

TDDはテスト手法なのか？ってあたりで盛り上がってるみたいですが、開発手法でもありテスト手法でもあるって感じかなぁ。そもそも開発したらテストしないといけないっていうのも考え直さないとだめかもね。

素直な考え方は、前者のやり方に問題があって、後者のやり方がベターだということでしょう。

確かに難しいですが、各人のベースを明確にした上で語るのであれば全く問題ないと思いました。色々興味深すぎる。 RT @t_wada: いろいろなところで議論されてますが、開発規模とか組織とか契約形態とかが多様で、前提や経験の共有が難しいですね。予想されたことですが…

開発したものが問題ないって証明できる・担保できるものがあるなら、テストしなくてもいいかも(それが出来るかどうかは別として)

@zecl 個人的にはテスト可用性を満たす（＝テストし易い）ようにコードを書いてくと、比較的まともになるのではないかと思っているのですが。 設計が下手＞上手へのステップアップのためにも仕えませんかね？＞TDD

@yoshiori TDDすらですか。であるとすれば、yoshioriさんのスライドは、正確性はともかく、最初のステップとして、意義があったと思います。私の実感はちょっと大勢と剥離していたようですね。

TDDやってUTのバグが少なかったら・でなかったらどうするのか=>どうもしない。なぜ少ないか、でなかったかを定性分析として試験報告書を出すだけです。

@a_hisame 例えば、テストフレームワークにてテストコードの実行に2時間もかかっていたら問題ですよね。そういう状況を仮定した場合、重複という基準を設けて、重複を検出するという技術は役に立ちます。僕が呼ぶ重複はカバレッジを基準に判定しますが、その妥当性はまだ分かりません。

@akiyama924 もうBDDの範疇に入ってしまうかしれないですけど、TDDの場合、ユーザーストリーやざっくりユースケースと画面をベースにユニットテストや受け入れテストを仕様を洗練させる手段としても使っているのでちょっとその認識は違うのではないでしょうか？

@akiyama924 そうですね。そのとおりだと思います。ただ、にしさんはそう思っているんだけどちょっと皮肉っぽく書いたのではないかと思います。

でも大丈夫。TDDやっても単体試験工程でいくらかのバグはでます。さっきもつぶやいたけど、TDDでは作った物が思った通り動くかの確認レベルなので、たっぷり試験工程で叩き上げる余地があります。

そして、私が前者の人のTest用のコードを読んだところテストの知識が不足していると感じ、後者の人の方はテストの知識があったと感じたこと。

@a_hisame テストコードは常に多ければ良いというわけではありません。そうであれば、自動生成の技術はもっと脚光浴びていい。時間効率と品質保証のトレードオフはあるのですから、同様に削除する理由も存在すると考えています。

@exKAZUu テストフレームワークの領域次第なのでは？ 例えばデイリーテストであれば、2時間程度ならばみんながいない時間帯に自動実行させることもできます。

BDDは、テスト実行時に1クッション入るのと、テストコードと製品コードの間で文法脳wを切り替えなきゃならんので、今のとこ好きじゃない。 f(^^;

TDDの議論を見るとどうも品質系の人たちは今の開発から離れてしまっているからか、そもそも開発者ではないからか、仕様は実装前にきっちり決めるべきという前提の下、TDDの徐々に実装も仕様も洗練するという抜きにTDDというものを話している感があります。

@nobeans そうですね、私も諦めベースで言ったのではなくて、本当にいろんな人が TL にいるという感嘆でもあります。

太田さんきたー

なので、TDDで品質が向上するとしても、いくつかのプロジェクトを経て定量的に傾向が見えないと、定量的な基準の元で、単発のプロジェクトでは「TDDのおかげで品質が向上し、バグが少なくなっているため」という理由はなかなか難しいのではないかと。

@a_hisame そうですね。設計を学ぶステップアップに利用できますね。ただ経験不足の人がやると独りよがりになってしまいがちですから、おっしゃるとおり、やはりペアプロなり識者によるレビューなりも併用する必要がありますね。

なんか中途半端な自分はどっちもありだとは思うのですが、現実路線としてはなんとなく全体性は頭に浮かべながらも(かくたにメソッド)、徐々に足場を固めながらというアプローチの方がしっくり来ます

TDDやったらUTでのバグ発生数が少なくなるので品質が担保できない。だからTDDは使えない、というのは手段と目的が逆転してるよね。

そうかんがえると、TDDは生産性、モチベーションの向上でプロジェクトに寄与しているのでいいじゃない、テストは従来通りやれば。切り離して考えれば、というのが僕の考えです。

TDDに書くべきテストはファストテスト=一個0.1秒もかからずに終わる程度のものなので、「TDDのテストと品質保証のテスト間の重複」に限れば、重複の検出がそれほど効果的だとは思えないんですよね・・・ / 無論再利用可能だと思うが、再利用しない前提だと。

@oota_ken その場合でもテストの考え方を知っておいた方がよいでしょ？　ざっくりとかリズム良くとか言うけど、私はそんなにリズムが落ちるとは思えないんだ。

@nobeans @bohnen テストレビューは有効そう。テストの品質はレビューで担保した上で、テストの質量に対して問題の発見率を見る事で、ある程度製品のの品質も読めそうですね。

@a_hisame リファクタリングを行った際にテストって実施しますよね。テストは人間が予期せぬ変更を見つけるために実施します。でもリファクタリングの1ステップ毎に2時間のテストを実施するわけにはいかない。かといって、*人手*で実施テストを限定するのもおかしい。とかもありえるかな

@akiyama924 TDDにさらに通常の意味での単体テストの観点を加えて、各種のテスト技法を用い、両方を実践している開発者から構成されるチームは強いです。

必要ないとまでは言わないですが、ユニットテストがあるのでデバッガを行う頻度が非常に少ないです。私はほとんど使いません(嫌っているのではないですよ)。 QT @*****: @t_wada そんなことより、TDDで作ると何故デバッガが必要無くなるのか書いてよ

製造工程の完了基準として”単にコンパイル完”か”TDDの結果オールグリーンを維持”か、どちらが製造工程成果物として価値を見出せるかな

テストはまた開発手法と兼ねる必要はないですし。自動テストもxUnit以外にQuickTestとかあり、QC専任としての人員調達もやりやすい。開発手法と混ぜると、開発者をテスト兼務とすることになり、これが本当に開発者幸せ？という気がする。

@akiyama924 でもさ、マーガリンはバターになりたくないんだよ。どうやら。バターになるべきだというのはバターの論理で、マーガリンの論理じゃないみたい。

@exKAZUu リファクタリング単位で「TDDのテスト」は実行しますが、それ以外のテストは実行しないと思います。（多分...^^;）

@oota_ken 最初から完璧になんて思ってないですよ。最初はざっくりでも、わかってきたらテストも足していけば良いのではないでしょうか？それにテスト設計することで仕様の曖昧さが見つかるってこともあるし。そう言うやり方はTDDじゃないのでしょうか？

@a_hisame ええ、そういう意識には同意です。テストコードの量が多すぎても保守できないという問題があるかなと。僕は、本当に消しても良いテストコードであることに納得できれば、消せるものは消すべきだと思ってます。テストコードのリファクタリング（再構成）もありえないでしょうか。

おそらくかくたにさんが悟りを開いたというwholenessを感じながらしかしボトムアップにTDDを実践するというのが、アレグザンダーの言うところのパタンランゲージの実践なのだろうとかなんとか

まあもっと言うと、マーガリンのままの方がいいマーガリンがあってもいいし、バターになりたいマーガリンがあってもいいと思う。その違いを、マーガリン自身がきちんと表現し選択できて、バターはその弱みをカバーしてあげるのがいいかな。

@babie 私の観測範囲では”JUnitのテストコードすらない”は決して珍しい話じゃなかったです…。

そういうマーガリンとバターの役割分担のマップを作りたいね、と書きましたが、もっと進めて、役割分担のパターンをいくつか提示してもいいかもしれませんね。成功例はたくさんあるわけでしょうし。

代用品（BDD?）でやったふりするんじゃなくってさ、本物（TDD?）を身につける方法を模索した方が良いと思います。

@yumotsuyo そうですね。僕もTDD急進派ってわけじゃないので、開発者は両方の視点を合わせて補完するというのがよいと思います。僕はスピード感より安心感を重視するというところもあるからそのアプローチは同意です。

TDDって、オブジェクト指向設計やプログラミングのためのGood Practiceだと思うんですけど。TDDやってバグだししたり、単体テストの代わりにして品質あげるとか、それって違うような気がします（それが目的なら、別のことしたほうが効率ってことで）

@akiyama924 テストの知識も必要だけど、形式検証の知識があればもっと良いと思っています。TDDの人たちがassertを入れていく過程はダイクストラの最弱事前条件を決めていく過程とオーバーラップして私には見えているので

@a_hisame 僕もしませんが（ぉ、例えば、リファクタリングの際に結合テストは不要であるというのはテストを削除しろという主張と同じぐらい乱暴かなぁと。

@exKAZUu ありえますありえます。ただ、自分が言いたいのは「開発＋TDDの行程(+ここで生産されるTDDのテスト)」と「品質保証のためのテスト」間でのお話で。これらの「」内でのくくりの重複は消すべきだと思います。

@YasuharuNishi 「マーガリンのままの方がいいマーガリンがあってもいい」という理由が分かりません。

@exKAZUu しかし、別の「」間の重複は消さなくてもよいのではないかと思うのです。 無論、うまく利用できるなら別なのですが・・・・・・

しかし思うのだが、コーディングと品質保証が対立概念で語られている時点で、お客様のことなんか考えてないのではないかと邪推してしまう。だって理想的には、開発者がきちんと作れれば品質保証部なんかいらないわけで。

あんまりTDDの話やテストの会話ってする機会すくないのよな

@akiyama924 ただ、その場合もまあ分野にはよいと思いますが、今の仕様と実装を分離する(実装をカプセル化する)のが主流なオブジェクト指向言語を使った開発の場合、ブラックボックステストの技法を使うのがよいと思います。

@akiyama924 代用品じゃないんだよ。味よりダイエットなんだよ。（マーガリンのままでいいと言っている）マーガリンは、あえてマーガリンでいることを選択しているんだよ。

TDDの問題はTDD、Test Driven Development、テスト駆動開発という名前がどれも求心力があり過ぎること。TDDのテストと品質保証のテストがなんか違うなと思っても今更名前を変えられない位のパワーがある。

@a_hisame なるほどー。そういう視点で考えたことはなかったです。ちなみに、目的意識の異なるテストコード間の重複を削除しないで良い理由、というよりも削除したくない理由ってなんでしょうー？

ホワイトボックステストで実装の中身に強く依存するテストは実装の変化にもろいってらへんは @t_wada さんがどっかで説明していたはず

TDD慣れてくるとふとデバッガ使ってない事に気付いて、それはそれで物足りないんですよね(笑) RT @t_wada: 必要ないとまでは言わないですが、ユニットテストがあるのでデバッガを行う頻度が非常に少ないです。私はほとんど使いません(嫌っているのではないですよ)。

私は最近の流れをきっかけにテスト技法に興味を持つプログラマが増えればいいなと考えていますし、そういう若手が気軽に参加できる勉強会がもっと知られればいいなと考えています。壁を作るなんてもったいない。