誰でも編集可能にしているので、どんどん発言を足したり、問題があったら削除したりしちゃってください。@mitimこれはいい議論。喉の小骨がとれた感じ。@hikaruworld最近は、開発手法としてのTDDではなくて品質保証としての自動テストに悩みを持っていたりする。@goyokiユニットテストを出力するもTDDの目標化もしれんけど、主な目標じゃない。@goyokiそこらへんテストエンジニアの方にはイメージしにくいのかもしれんね。@quicyTDDのテストがテストじゃないとか、品質保証(の一部)じゃないとか、意味分かんない。@mitim作っているシステムが品質に非常に敏感立ったりする(飛行機や自動車の制御システムとか)場合、まずTDDで開発、そしてカバレッジ等も考慮してUnitTestを後から拡充、というやり方もあると思う。@quicyTDDやっておまけでついてくる美味しい部分に感動して、そこをアピールしたくなるのは分かるけど、肝心のテストがまずかったら、結局TDDうまくいかないでしょ。@mitimひとつ言えるのは、UnitTest出現以前の「単体テスト」は、TDDの品質の足元にも及ばない悪い品質しか「保証」できなかったってことかな。@keisuke_nテストとTDDが違うのはTDDはモチベーションが必要でかつモチベーションでぐるぐる回せるということじゃないかと思ってる。テストは単純にテストによる動作の保証の担保の確認。@bash0C7まさに。TDDは開発者頭、テストはテスタ頭になる。帽子をかぶりなおすともいうらしい。するときの視点てまったく違うよね。それはクラス設計しているときとテスト設計してるときで視点が違うのとまったく一緒で。@quicyいろんな人の意見はよく理解できる。自分の下につく新人が、「TDDのテストはテストじゃねーんですよ」とか言ったら、はり倒す。@quicyまずリファクタリングに耐えうるテスト書いてから言えやコラ。そのレベルを既に超えてる人が何を言っても、その人なりの理解でOKだと思う。@nobeansTDDを推進してる人がなぜ「テスト」「品質保証」という用語に敏感になっているのか、という背景には、テスタや品質保証の専門家が関わるような、組織・プロジェクト全体をまたがる品質保証プロセスの存在も無視できないと思う。@nobeans総合的な品質保証プロセスの中で、有効性を保ったままTDDをどのように位置づけて取り込んでいくか、というのはすごく難しい問題。いう規模の開発プロジェクトは対象外と切り捨る方法もあるかもしれないけど、そうなると、TDDのフィールドがすごくせまくなってしまう。@nobeans品質保証というのは高いスキルや専門性を必要とする分野なので、TDD推進活動の初期段階でそこに踏み込むには時期尚早というかおそらく推進者自身の経験も不足しているから、あえてそこは触れないようにした、というTDDを普及させるための戦略だった可能性も考えた方が良いんじゃないだろうか。@nobeans.@t_wadaをはじめとする2周目以前の人々のおかげで、自分も含めた3周目のTDD実践者がずいぶんと増えたので、今こそそこに取り組む段階に来たのかなーと思う。「テストっていわないのはおかしい」じゃなくて「品質保証プロセスとの適合性」についての意見が聞きたいですね。