テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう
ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
探検
【TDD】テスト駆動開発【TestFirst】
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2010/09/19(日) 21:26:12532デフォルトの名無しさん
2015/11/26(木) 10:12:43.24ID:wjty/3s6 >>531
ここにも勘違いしてる奴がいた
TDDはよりよい設計をもたらすものじゃない
TDDは、自分が正しいと思った設計で、それをコーディングするときに、テストの力を借りて
確信を得ながらコーディングするための手法だ
「自分が正しいと思った設計」が「Good Design」じゃない奴は、どんな開発手法を使っても
自動的には「Good Design」にはならない
ここにも勘違いしてる奴がいた
TDDはよりよい設計をもたらすものじゃない
TDDは、自分が正しいと思った設計で、それをコーディングするときに、テストの力を借りて
確信を得ながらコーディングするための手法だ
「自分が正しいと思った設計」が「Good Design」じゃない奴は、どんな開発手法を使っても
自動的には「Good Design」にはならない
533デフォルトの名無しさん
2015/11/27(金) 17:53:44.15ID:c/N8jVfb ほんそれ
534デフォルトの名無しさん
2015/11/27(金) 18:02:19.08ID:Ib2iKJmv >>532
TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。
TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。
535デフォルトの名無しさん
2015/11/27(金) 18:06:37.23ID:c/N8jVfb >正しく無い設計
この「無い」の漢字の使い方は可笑しい
これフィードバックな
この「無い」の漢字の使い方は可笑しい
これフィードバックな
536デフォルトの名無しさん
2015/11/27(金) 18:29:00.24ID:R6S7u3+S >>534
コードを全て実装した後でテストが失敗したとき、それは
・間違った実装をした
・テストの期待値が間違っていた
というのがわかる位だよ。
正しくない設計（というか稚拙な実装）でも、正しい結果（期待値と合致する）であれば、
たいていは気づかない。
コードを全て実装した後でテストが失敗したとき、それは
・間違った実装をした
・テストの期待値が間違っていた
というのがわかる位だよ。
正しくない設計（というか稚拙な実装）でも、正しい結果（期待値と合致する）であれば、
たいていは気づかない。
537デフォルトの名無しさん
2015/11/28(土) 22:21:29.95ID:bl9Uvb4J 三大期待しすぎてガッカリされる手法
オブジェクト指向
リファクタリング
TDD
オブジェクト指向
リファクタリング
TDD
538デフォルトの名無しさん
2015/11/29(日) 11:20:08.54ID:Qj6U8mrf オブジェクト指向が手法？
539デフォルトの名無しさん
2015/11/29(日) 12:57:18.55ID:MDC+yNGn >>535
喜んで頂けて幸いです。
喜んで頂けて幸いです。
540デフォルトの名無しさん
2015/11/29(日) 14:50:26.11ID:ywUk37EG >>536
TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。
テストは漫然とやるのではなく、情報収集の手段だと考えてやることが大事だよ。
TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。
テストは漫然とやるのではなく、情報収集の手段だと考えてやることが大事だよ。
541デフォルトの名無しさん
2015/11/30(月) 11:50:49.60ID:l98GVpDh >>540
> TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。
そういうことを経てTDD用のテストとコードが完成したとき、その設計がGood Designではないと
いうことは気づかないということだよ。
テスト容易性やネーミングは、Good Designのほんの一部。
> TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。
そういうことを経てTDD用のテストとコードが完成したとき、その設計がGood Designではないと
いうことは気づかないということだよ。
テスト容易性やネーミングは、Good Designのほんの一部。
542デフォルトの名無しさん
2015/11/30(月) 15:39:28.85ID:NGwAlAWY >>541
そりゃTDDのプロセスが1周すれば、残るのはTDDでは気付けない事や割りに合わないことが残るに決まってるよね。
TDDが完全に役に立たないと言いたいのではなくて、より良い設計を目指す手法としては割りに合わないと言いたいのだと思うけど、ではTDDより良い手法としては何があると主張してるのかな？
そりゃTDDのプロセスが1周すれば、残るのはTDDでは気付けない事や割りに合わないことが残るに決まってるよね。
TDDが完全に役に立たないと言いたいのではなくて、より良い設計を目指す手法としては割りに合わないと言いたいのだと思うけど、ではTDDより良い手法としては何があると主張してるのかな？
543デフォルトの名無しさん
2015/11/30(月) 16:20:33.71ID:l98GVpDh >>542
勘違いしてるかもしれないけど、俺は超TDD派だし、日々TDDでコーディングしてる。
ただ、TDDはよりよい設計を導き出す手法ではないと言ってるだけ。
もう少し言うと、「気付けない事」の中には「思い込みバグ」なんかも含まれる。
自分がそれが正しいと思ったら、それが正しくあるようなテストとコードを書くため、
それがバグであることがわからない。
もちろん、要求仕様との乖離があってもわからない。
TDDはそういうものを検出するものではない。
勘違いしてるかもしれないけど、俺は超TDD派だし、日々TDDでコーディングしてる。
ただ、TDDはよりよい設計を導き出す手法ではないと言ってるだけ。
もう少し言うと、「気付けない事」の中には「思い込みバグ」なんかも含まれる。
自分がそれが正しいと思ったら、それが正しくあるようなテストとコードを書くため、
それがバグであることがわからない。
もちろん、要求仕様との乖離があってもわからない。
TDDはそういうものを検出するものではない。
544デフォルトの名無しさん
2015/11/30(月) 20:00:07.27ID:JmXUnbN0 TDDは万能薬じゃないって解っていればOKなのだが、TDDのテストが通るからOKみたいなのはあり得ないってだけでしょう？
想定していない事態はTDDじゃ検出できない（想定外の事が起きたときに加える事は当然だけど)
テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。
想定していない事態はTDDじゃ検出できない（想定外の事が起きたときに加える事は当然だけど)
テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。
545デフォルトの名無しさん
2015/12/01(火) 11:33:20.20ID:Fb8Lo38E546デフォルトの名無しさん
2015/12/01(火) 11:36:18.07ID:Fb8Lo38E >>544
> テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。
エヴァンジェリストは、「○○は万能薬ではない」って大抵言ってると思うが。
「○○は万能薬」と思う（勘違いする）のは、良くわかってない奴か、「○○は万能薬だと言われている」
ことにしてdisりたい奴だけじゃないの？
> テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。
エヴァンジェリストは、「○○は万能薬ではない」って大抵言ってると思うが。
「○○は万能薬」と思う（勘違いする）のは、良くわかってない奴か、「○○は万能薬だと言われている」
ことにしてdisりたい奴だけじゃないの？
547デフォルトの名無しさん
2015/12/01(火) 13:00:01.79ID:j87epvlp >>543
どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
より良い設計というのはバグが無いという意味ではなくて、費用対効果の面で妥当な設計、と言い換えても良いけど。
新規の何らかのクラスを設計するときに、シーケンス図を書いて複数人でレビューしてから実装には入った方が費用対効果が高いのか、TDDで実装してから本体とテストコードをレビューした方が費用対効果が高いのか？
もし、TDDの方が高いとき、それは何故なのか？
っという観点の話にすれば、俺の主張は以下になる。
TDDはテストによってより早くフィードバックが得られるから費用対効果が高いが、そのフィードバックを解釈するのにも経験が必要で、テストが通りさえすれば良い、という考え方では効果は発揮できない。
また、レビューアにもフィードバックを解釈する能力が要求されるうえ、ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
シーケンス図の方も書けば良い設計になるわけじゃないし、シーケンス図から問題点を読み解く能力が必要だが、おそらくTDDよりはレビューが易しい気がする。
だが、TDDのテストは実行可能ということが利点であり、レビューアが疑問があればテストを追加して実行することが出来る。これを利用すれば、費用対効果を更に高めることが出来るのではないか？
どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
より良い設計というのはバグが無いという意味ではなくて、費用対効果の面で妥当な設計、と言い換えても良いけど。
新規の何らかのクラスを設計するときに、シーケンス図を書いて複数人でレビューしてから実装には入った方が費用対効果が高いのか、TDDで実装してから本体とテストコードをレビューした方が費用対効果が高いのか？
もし、TDDの方が高いとき、それは何故なのか？
っという観点の話にすれば、俺の主張は以下になる。
TDDはテストによってより早くフィードバックが得られるから費用対効果が高いが、そのフィードバックを解釈するのにも経験が必要で、テストが通りさえすれば良い、という考え方では効果は発揮できない。
また、レビューアにもフィードバックを解釈する能力が要求されるうえ、ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
シーケンス図の方も書けば良い設計になるわけじゃないし、シーケンス図から問題点を読み解く能力が必要だが、おそらくTDDよりはレビューが易しい気がする。
だが、TDDのテストは実行可能ということが利点であり、レビューアが疑問があればテストを追加して実行することが出来る。これを利用すれば、費用対効果を更に高めることが出来るのではないか？
548デフォルトの名無しさん
2015/12/01(火) 14:07:41.90ID:Fb8Lo38E >>547
本当にTDDを理解して実戦しているのか疑わしいレベル。
> そのフィードバックを解釈するのにも経験が必要
意味がわからない。
テストによるフィードバックは失敗あるいは成功しかなく、正しく実装できたはずなのに失敗するのは、
・テストが間違っている
・正しく実装できたはずというのが思い違い
のどちらか、あるいはその両方しかなく、解釈もクソもない。
自分が書いたテストが失敗して、その原因もわからないレベルなら、それはTDDをする資格がない。
というか、そんな奴にプロダクトコード書かせるな。
> ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、
> 設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
これも意味がわからない。
> どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
そもそも、TDDは設計手法というより開発手法と言うべきで、極言すれば実装手法でしかない。
というか「よい設計」の定義が俺と大幅にずれてる気がする。
俺が思う「よい設計」というのは、例えば
・SOLID原則が守られている（あるいはそれほど重大な違反は無い）
・カプセル化が守られている
・メンテナンス性が良い（リーダビリティが良い）
・パフォーマンスが良い
などなど。
そういう意味の「よい設計」ができる奴は、TDDをしなくとも良い設計はできる。
本当にTDDを理解して実戦しているのか疑わしいレベル。
> そのフィードバックを解釈するのにも経験が必要
意味がわからない。
テストによるフィードバックは失敗あるいは成功しかなく、正しく実装できたはずなのに失敗するのは、
・テストが間違っている
・正しく実装できたはずというのが思い違い
のどちらか、あるいはその両方しかなく、解釈もクソもない。
自分が書いたテストが失敗して、その原因もわからないレベルなら、それはTDDをする資格がない。
というか、そんな奴にプロダクトコード書かせるな。
> ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、
> 設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
これも意味がわからない。
> どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
そもそも、TDDは設計手法というより開発手法と言うべきで、極言すれば実装手法でしかない。
というか「よい設計」の定義が俺と大幅にずれてる気がする。
俺が思う「よい設計」というのは、例えば
・SOLID原則が守られている（あるいはそれほど重大な違反は無い）
・カプセル化が守られている
・メンテナンス性が良い（リーダビリティが良い）
・パフォーマンスが良い
などなど。
そういう意味の「よい設計」ができる奴は、TDDをしなくとも良い設計はできる。
549デフォルトの名無しさん
2015/12/01(火) 14:10:57.54ID:Fb8Lo38E あと、TDDにおける「素早いフィードバック」というのは、
・正しくテストが実装できたであろう実感(red -> green)
・思い通りのコードが実装できたであろう実感（green -> refactoring -> green)
だぞ。
設計が正しい、あるいは妥当であるというフィードバックではない。
・正しくテストが実装できたであろう実感(red -> green)
・思い通りのコードが実装できたであろう実感（green -> refactoring -> green)
だぞ。
設計が正しい、あるいは妥当であるというフィードバックではない。
550デフォルトの名無しさん
2015/12/04(金) 15:28:40.97ID:dm9hxmiU >>547
今時、シーケンス図を書いて複数人でレビューしてから実装に入るって、どんな分野のどれくらいの規模なの？
リファクタリングが一般化した現在、クラス図でさえ事前にかっちりしたもの書くと手戻りが発生していやがられるのに。
今時、シーケンス図を書いて複数人でレビューしてから実装に入るって、どんな分野のどれくらいの規模なの？
リファクタリングが一般化した現在、クラス図でさえ事前にかっちりしたもの書くと手戻りが発生していやがられるのに。
551デフォルトの名無しさん
2015/12/14(月) 22:58:51.50ID:dPco7zPj 手戻りが嫌ならプログラムを書かなければいい
552デフォルトの名無しさん
2015/12/16(水) 07:23:08.19ID:JxdBAlmf それは言える
メタプログラミングでプログラムは自動生成にしておけば
手戻り発生しても仕様書直すだけで済む
メタプログラミングでプログラムは自動生成にしておけば
手戻り発生しても仕様書直すだけで済む
553デフォルトの名無しさん
2016/02/14(日) 07:50:17.63ID:KRGWcZPF 自動生成するプログラムの修正が必要になるだろタコ。
554デフォルトの名無しさん
2016/04/01(金) 19:49:18.66ID:xvbiumjA test
555デフォルトの名無しさん
2016/04/18(月) 21:10:16.12ID:WJpLEkGK カバレッジって自動じゃないテスト(ようは手動の結合テスト)でも使えんの？
556デフォルトの名無しさん
2016/04/18(月) 21:36:07.56ID:QSS7pC1U ？
何を言ってるのかさっぱり理解できない
何を言ってるのかさっぱり理解できない
557デフォルトの名無しさん
2016/04/18(月) 22:20:56.27ID:i/DZEEkh >>555
使えるってどういう意味で？
使えるってどういう意味で？
■ このスレッドは過去ログ倉庫に格納されています
