編集可能

TDD について

「深夜のテスト TL - http://togetter.com/li/5878 」 「TDD はテスト手法か否か - http://togetter.com/li/6759 」 の後も続いている議論を、皆でまとめませんか? 誰でも編集可能にしているので、どんどん発言を足したり、問題があったら削除したりしちゃってください。
TDD
83
MitiM(休業中) @mitim
これはいい議論。喉の小骨がとれた感じ。 RT @wyukawa: TDDはテスト手法か否か http://togetter.com/li/6759
MitiM(休業中) @mitim
テスト一個書く->RED->実装一個書く->GREEN->テスト一個追加->RED->実装変更->GREEN->テスト一個追加->GREEN->異常テスト追加->RED->実装変更->GREEN->異常テスト追加->GREEN そして反復 自分のやり方はこのリズムの繰り返しかなー
MitiM(休業中) @mitim
途中、GREENである事が確実になるテストを検証するために入れることはあるけど、基本最初はREDで始めるし、新しいことやってREDにならなかったらまず慌てふためく
MitiM(休業中) @mitim
愚直といえば愚直なんだけど、最初にREDである事を確認するのは安心のための儀式になるんだよね
hikaru world @hikaruworld
最近は、開発手法としてのTDDではなくて品質保証としての自動テストに悩みを持っていたりする。むー。
goyo @goyoki
ユニットテストを出力するもTDDの目標化もしれんけど、主な目標じゃない。TDDの主な目標は細かく継続的に実装作業のフィードバックを得ること
MitiM(休業中) @mitim
IDEとTDDとの関係は、IDEの「お助け度」によって色々と調整が入って当然じゃないかと思ってるかな
goyo @goyoki
そこらへんテストエンジニアの方にはイメージしにくいのかもしれんね。だけど協調とか対立は駄目とか主張するなら、相手の視点に立って考える必要もあると思うんだけどな
goyo @goyoki
勢いで今から考えをまとめてブログに書いてみる
MitiM(休業中) @mitim
たとえばメソッドの名称を変更したとして、IDE無しだったら一々コンパイルを通してエラー吐かなくなるまで頑張るけど、IDE有りだったら今ならリファクタリング機能で一発だし
Hideki Kishida @quicy
TDDのテストがテストじゃないとか、品質保証(の一部)じゃないとか、意味分かんない。
MitiM(休業中) @mitim
作っているシステムが品質に非常に敏感立ったりする(飛行機や自動車の制御システムとか)場合、まずTDDで開発、そしてカバレッジ等も考慮してUnitTestを後から拡充、というやり方もあると思う。もちろん、それをやるための工数が確保できること前提
MitiM(休業中) @mitim
UnitTestとそれを使った自動反復テストは十分に品質の担保になりえるからね
MitiM(休業中) @mitim
あ、コードの仕様的な領域においての品質ね
Hideki Kishida @quicy
TDDやっておまけでついてくる美味しい部分に感動して、そこをアピールしたくなるのは分かるけど、肝心のテストがまずかったら、結局TDDうまくいかないでしょ。
MitiM(休業中) @mitim
ひとつ言えるのは、UnitTest出現以前の「単体テスト」は、TDDの品質の足元にも及ばない悪い品質しか「保証」できなかったってことかな。最終的なガワの品質がなんとかなってたのは、それ以降のテストの厚みと最終的にはベテランのカバーだった
NISHIMOTO Keisuke @keisuke_n
テストとTDDが違うのはTDDはモチベーションが必要でかつモチベーションでぐるぐる回せるということじゃないかと思ってる。テストは単純にテストによる動作の保証の担保の確認。
BASH @bash0C7
まさに。TDDは開発者頭、テストはテスタ頭になる。帽子をかぶりなおすともいうらしい。 RT @sunaot : テストコード書くときと TDD するときの視点てまったく違うよね。それはクラス設計しているときとテスト設計してるときで視点が違うのとまったく一緒で。
Yasuharu Nakano @nobeans
TDDについて、これだけ日本の技術者が持論を語り合うという場が成立していること自体が素晴らしいなぁ
Hideki Kishida @quicy
いろんな人の意見はよく理解できる。けど、もし自分の下につく新人が、「TDDのテストはテストじゃねーんですよ」とか言ったら、はり倒す。
Hideki Kishida @quicy
まずリファクタリングに耐えうるテスト書いてから言えやコラ。そのレベルを既に超えてる人が何を言っても、その人なりの理解でOKだと思う。
Yasuharu Nakano @nobeans
TDDを推進してる人がなぜ「テスト」「品質保証」という用語に敏感になっているのか、という背景には、テスタや品質保証の専門家が関わるような、組織・プロジェクト全体をまたがる品質保証プロセスの存在も無視できないと思う。
Yasuharu Nakano @nobeans
総合的な品質保証プロセスの中で、有効性を保ったままTDDをどのように位置づけて取り込んでいくか、というのはすごく難しい問題。単にそういう規模の開発プロジェクトは対象外と切り捨る方法もあるかもしれないけど、そうなると、TDDのフィールドがすごくせまくなってしまう。
Yasuharu Nakano @nobeans
品質保証というのは高いスキルや専門性を必要とする分野なので、TDD推進活動の初期段階でそこに踏み込むには時期尚早というかおそらく推進者自身の経験も不足しているから、あえてそこは触れないようにした、というTDDを普及させるための戦略だった可能性も考えた方が良いんじゃないだろうか。
Yasuharu Nakano @nobeans
.@t_wadaをはじめとする2周目以前の人々のおかげで、自分も含めた3周目のTDD実践者がずいぶんと増えたので、今こそそこに取り組む段階に来たのかなーと思う。なので「テストっていわないのはおかしい」じゃなくて「品質保証プロセスとの適合性」についての意見が聞きたいですね。
残りを読む(713)
TDD

コメント

Yasuharu Nakano @nobeans 2010年2月24日
まずは自分の分だけ追加してみました
Takuto Wada @t_wada 2010年2月24日
@nsiena @biac @mitim @yattom @skoji @keisuke_n @quicy さんを追加しました。問題ある場合は自分で消すか、もしくは reply ください。
Takeshi Kakeda @kkd 2010年2月24日
@kkd(自分)のコメントを追加した。
thada @htada 2010年2月24日
@goyoki@biac の夕方あたりのつぶやきを追加しました
thada @htada 2010年2月25日
@ledsun さんを追加しました。リスト作成ありがとうございます!
MitiM(休業中) @mitim 2010年2月25日
RT @katzchang: TDDで作るテストコードは、開発者が意図している仕様となっていることを保証している、と言う部分は言い切っちゃっていいような気はする。問題は、その仕様が要件を満たすとは限らないということ。
文殊堂 @monjudoh 2010年2月25日
RT @mitim: ひとつ言えるのは、UnitTest出現以前の「単体テスト」は、TDDの品質の足元にも及ばない悪い品質しか「保証」できなかったってことかな。最終的なガワの品質がなんとかなってたのは、それ以降のテストの厚みと最終的にはベテランのカバーだった
MitiM(休業中) @mitim 2010年2月27日
自分、@mkoszkさん、@hsbtさん、@tomohnさん、@biacさんの25日のツイート、およびblogを書いた@babieさんの26日までのツイートを追加しました。中途半端ですみませんorz
MitiM(休業中) @mitim 2010年2月27日
新たに、25日分の@wtnabeさん、@t_wadaさん、@carnationさん、@maskennさん、@syama666さん、@kanu_さんの発言をごりごり盛り込みました。かなりランダム選択です。
ログインして広告を非表示にする
ログインして広告を非表示にする