TDDはYAGNIに矛盾する？ - カタチづくり

Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests

[u_1roh]

ちょっと書き方が不用意だったと反省。TDDは以前実践したし、その効果・威力も経験した。だけどあまり効果的でない場面も経験したので、Joel氏の意見は理解できる。ただ、持論を人に押し付けるつもりは毛頭ないよ。

[wildcats]

コメントに反応。リファクタリングは複数のクラスにはまたがらないでしょ？ http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism あとTDDは設計手法だから仕様は確定しているが設計があいまいな状況で適用すべきと思う。

[t-wada]

同意する点が多い。なおTDDの観点からは、テストは 「1.プロダクトコードを導き出すため」「2. リファクタリングを行うため」 need it となりそうです。100%を求めると書きすぎて不良資産化するので不要になったら捨てます

[Nagise]

きしださん・・・。そこまで書くならエントリにしてトラックバックうちなよｗ きしだ++

[yuuAn]

この辺あまり理解できてない。前職ではModelのテストはしっかり書いてControllerのテストはほどほどにと習ったけど、たまに全パターンを網羅した完璧なテストを求める人もいて、その辺の判断が自分でできるようになりたい

[ngyuki]

コメント欄からが本番

[paz3]

Joel on Softwareから「何かあるまでテストは不要(=YAGNI)」と考えた話。コメント欄が非常に勉強になる：テストを書くのが面倒ならクラスが大きすぎる、テストはTDDよりBDDの観点で書くとよい。

[shuzo_kino]

本文も凄いがコメント欄も凄い

[calpo]

コメント見る。「クラス単位でテストクラスを作り、メソッド単位でテストメソッドを作る方法はウマくない」「状態毎にテストメソッドをクラスでグループ化、小さな振るまい単位にテストメソッドを書く」

[kkotyy]

コメント欄がすごい。

[fumikony]

[agileテスト可能性を考えるとあまり大きくなる前にクラスの責務を別なクラスに切り出す戦略とも言えますが、TDDでやってると小さく浅い指向スタックで仕事をするようになるので、自然とクラスが小さくなる

[hagayu]

すべてのコードに対してユニットテストを用意しなくてはならないという規律はYAGNIの思想と矛盾する？ きしださんのコメントも必読。

[nobeans]

きしださんのコメントが素晴らしすぎる

[Sixeight]

*そのテストコードこそ You Ain't Gonna Need It ではないのか。*

[atsushifx]

アジャイルなプログラミングをうまく行うための考え方。コメントをじっくり読むべし

[terazzo]

コメント欄で「漸近的に良いデザインに到達できるか」問題に言及あり。

[moro]

※欄「この面が滑らかにイイ感じに接続していること」はむずいなー。でも最終的には"いい感じ"をコードにするわけで、その過程でテストは使えるよ、という話かと。

[katzchang]

変更のために用意する割に仕様が安定しているものの方がうまく機能するというのは、全く逆な気がする。リファクタと仕様変更を別に考えるべき？