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

2010-02-23 23:09:05
MitiM ヨ @mitim

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

2010-02-23 23:16:18
MitiM ヨ @mitim

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

2010-02-23 23:17:35
MitiM ヨ @mitim

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

2010-02-23 23:18:48
hikaru world @hikaruworld

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

2010-02-23 23:19:05
goyo @goyoki

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

2010-02-23 23:31:39
MitiM ヨ @mitim

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

2010-02-23 23:32:38
goyo @goyoki

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

2010-02-23 23:33:31
goyo @goyoki

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

2010-02-23 23:34:28
MitiM ヨ @mitim

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

2010-02-23 23:35:07
Hideki Kishida @quicy

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

2010-02-23 23:38:42
MitiM ヨ @mitim

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

2010-02-23 23:42:18
MitiM ヨ @mitim

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

2010-02-23 23:42:48
MitiM ヨ @mitim

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

2010-02-23 23:43:26
Hideki Kishida @quicy

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

2010-02-23 23:46:48
MitiM ヨ @mitim

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

2010-02-23 23:50:23
NISHIMOTO Keisuke @keisuke_n

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

2010-02-23 23:51:31
BASH @bash0C7

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

2010-02-23 23:51:38
Yasuharu Nakano @nobeans

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

2010-02-24 00:04:11
Hideki Kishida @quicy

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

2010-02-24 00:06:06
Hideki Kishida @quicy

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

2010-02-24 00:08:09
Yasuharu Nakano @nobeans

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

2010-02-24 00:32:39
Yasuharu Nakano @nobeans

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

2010-02-24 00:33:02
Yasuharu Nakano @nobeans

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

2010-02-24 00:35:07
Yasuharu Nakano @nobeans

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

2010-02-24 00:41:18
1 ・・ 30 次へ