テスト駆動開発はなぜ流行らなかったのか？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/12/22(日) 16:04:07.02みんなやらなくなりますよね。
0153デフォルトの名無しさん
2013/12/29(日) 21:38:32.30いや、assertは設計の一部だから、書き込むのはコードを書きだす最初のときでしょ
0154デフォルトの名無しさん
2013/12/29(日) 22:12:41.66assertが設計の一部なのはなぜ？
設計の一部だったら書き出す最初なのはなぜ？
今度は二つの質問に答えないといけなくなったね。
今度は説得力がある答えを言えるかな？
0155デフォルトの名無しさん
2013/12/29(日) 22:21:13.87昔からあるassertは全くの別物だけどね。
0156デフォルトの名無しさん
2013/12/29(日) 23:07:37.540157デフォルトの名無しさん
2013/12/30(月) 00:47:44.790158デフォルトの名無しさん
2013/12/30(月) 04:25:43.40assertが設計の一部なのは、assertが仕様の宣言的表現だから
設計の一部だったら書き出すのが最初なのは、書いてる途中も書き終わった後も実行中も修正作業中も満すべき表明が記述してあるから
0159デフォルトの名無しさん
2013/12/30(月) 04:28:55.35ドメインの要素の部分集合を網羅したコードがxUnitで、ドメインの補集合の部分集合を内包表記したコードがassert
同じモノですよ
0160デフォルトの名無しさん
2013/12/30(月) 04:35:09.73使っているだけみたいだなｗ
用語だけ言ってて具体的な説明が何もない。
0161デフォルトの名無しさん
2013/12/30(月) 09:08:04.41ところが使うには別のツールや知識がいる
テスト駆動ありか、なしか、も、どっちもテストがいることは認めてても、
どうしても最初にテストかかせたいやつと、あとでかきたいやつといるってこと
0162デフォルトの名無しさん
2013/12/30(月) 11:12:22.50テスト駆動（最初にテストを書く）という理由を何一つ言わないで
アサートはテストと同じと繰り返しているだけにしか見えないな。
テストと同じかどうかではなく、最初に書くかどうかって話をしてるのに。
0163デフォルトの名無しさん
2013/12/30(月) 11:38:55.64そもそも「テスト」と称する内容にコモンセンスが存在しないので、
テスト駆動開発ですっ(ｷﾘｯ と言ったところで、成果物の品質の保証
にはなりえない。 馬鹿に仕様やコードを書かせてはいけないように、
馬鹿にテストをやらせてはいけない。
0164デフォルトの名無しさん
2013/12/30(月) 12:15:18.80テストは高い技術力が必要なんだよ。
単純作業でやっていたらいくら時間が
あっても終わらないから。
0165デフォルトの名無しさん
2013/12/30(月) 13:53:07.51assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
例えば、整数kの階乗の計算でkと計算結果が整数以外でないことを内包的表現でチェックするのがassert
環境が提供できる整数1000個でチェックするのがxUnit
xUnitでエラーが出た場合、バグがあるコードを書いていたことになる
一方、assertがコケた場合、何を計算していたのか不明なので、何もコーディングしてなかったことになる
0166デフォルトの名無しさん
2013/12/30(月) 14:30:22.600167デフォルトの名無しさん
2013/12/30(月) 14:33:44.10> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
どの言語のassertの話をしてるの？
それをはっきりしないと、
具体的なものがないということで、
わーわー喚いているように聞こえないよ？
複数の言語があるのなら、
その言語を言えばいい。
0168デフォルトの名無しさん
2013/12/30(月) 14:35:15.83> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
なんで？
0169デフォルトの名無しさん
2013/12/30(月) 14:36:22.81どの言語もassertは一緒
1946年のチューリングが主張するセマンティクスでOK
自分が使ってる言語にassertがなければ作ればいいだけかと
0170デフォルトの名無しさん
2013/12/30(月) 14:36:50.03最初に書くという理由にはならないし、
assertを書いて不具合が出なければいいだけだし
やっぱり最初に書くという理由がないんだよな。
後から書いていいじゃん。（なぜかしらんけど）修正範囲が大きくなるだけでしょ？
0171デフォルトの名無しさん
2013/12/30(月) 14:37:26.38どの言語でも一緒といったね？
じゃあC言語でも一緒なわけだ。
じゃあ、C言語で書いてみてよ。
0172デフォルトの名無しさん
2013/12/30(月) 14:38:05.79どこを直すべきかの特定につながらないと言いたいんだろう たぶん
0173デフォルトの名無しさん
2013/12/30(月) 14:38:49.52最初に書くという根拠にはならないんだよな。
0174デフォルトの名無しさん
2013/12/30(月) 14:41:05.78例えば、c言語でintのつもりでコード書いてたら、intじゃなかったってことだから
0175デフォルトの名無しさん
2013/12/30(月) 14:49:09.43#define assert(t) ((t) ? (void)0 : printf("%s, %d %d %d\n", __func__, __FILE__, __LINE__, #t))
かな?
0176デフォルトの名無しさん
2013/12/30(月) 14:53:00.40assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど
1+1をaに代入するだけのコードを書く方法は、まず a:=1+1 を書くことだと思うけど
0177デフォルトの名無しさん
2013/12/30(月) 14:57:23.00やっぱり、”最初” である理由はないみたいね。
ただのテストの話してただけじゃん。
最初に指摘したとおりだった。
0178デフォルトの名無しさん
2013/12/30(月) 14:58:25.05> assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど
それなら後からassert書けばいいだけだよ。
0179デフォルトの名無しさん
2013/12/30(月) 15:16:19.950180デフォルトの名無しさん
2013/12/30(月) 15:34:39.860181デフォルトの名無しさん
2013/12/30(月) 16:05:51.76それで、優秀な人がまず最初にテストを書いて、優秀じゃない人に
テストを通るコードを書かせるんでしょ？
じゃあなんで最初から優秀な人にコード書かせないの？
優秀だからテストしなくてもいいっしょ。
0182デフォルトの名無しさん
2013/12/30(月) 16:08:30.80どっちにしろまともに動かなくて納品後も修正に来るんでしょ？
こっちがあきらめて検収するまで直すふりするんでしょ？
なんだか意味ないような気がするよ。
0183デフォルトの名無しさん
2013/12/30(月) 16:19:35.91自分で書けば？
0184デフォルトの名無しさん
2013/12/30(月) 16:20:50.87つまるところプログラマは自分のプログラムをデバッグするほど賢くない。
となれば、プログラマ１人に対してテスターが３人ぐらい必要になるから
0185デフォルトの名無しさん
2013/12/30(月) 16:24:25.300186デフォルトの名無しさん
2013/12/30(月) 16:24:31.56assertが入ったコードと、assertが抜けたコードがある場合、前者はテストコードですよ
0187デフォルトの名無しさん
2013/12/30(月) 16:27:02.87まさにそれ。
自分たちで書いたのを今運用してんの。
ちなみに単体テストすらしてません。
0188デフォルトの名無しさん
2013/12/30(月) 16:27:49.27正しくは、assertに書くべきモノが最初に「ある」ってことかな
例えば、実機そのものや実機の設計書もコードを書く前に「ある」はずけど、コードを書いた後に作っても問題ないし
0189デフォルトの名無しさん
2013/12/30(月) 16:29:07.89テスト駆動は防衛的プログラミングですよ
0190デフォルトの名無しさん
2013/12/30(月) 16:32:13.64目にいっぱい涙をためても手を緩めたらダメ。
あれはそうしろって上から言われてるんだよ。
泣きまねも絶対教育されてる。
0191デフォルトの名無しさん
2013/12/30(月) 16:34:18.57それには、その一切のミスをしない優秀な人が、実機やOSやコンパイルや補助ライブラリも全部作るという前提が必要
ちなみに、実際の現場での優秀な人のイメージは、ミスをしない人ではなく、ミスが少ない人
0192デフォルトの名無しさん
2013/12/30(月) 16:37:07.20相手側に予算と時間があれば、修正せずに別会社で最初からで、おつきあい終わり
0193デフォルトの名無しさん
2013/12/30(月) 18:33:40.58そうでもなんだね
基本設計(UseCaseシナリオ相当)で、運用テストシナリオを作る。
概要設計(Activiti図相当)で、結合テストシナリオを作る。
詳細設計(Sequence図相当)で、単体テストのバリエーションを作る。
それからプログラミングをする。
とやっておけば、まず、テスト作成を通じて、仕様が妥当かのチェック
ができる。(プロジェクト (Iteration/Sprint/...) の前半で!!)
また、プログラミングの目標が具体化される。(仕様を満たす
"完璧" なものを作る必要はなく、妥当な網羅性のあるテストに
合格すればOK)
テスト設計も順を追って詳細化されるので、設計上は、
単体テストに合格していれば、結合テストに合格し、
結合テストが合格なら、運用テストにも合格するはず。
裏を返せば、結合・運用テストでは、本来出てくるべき
不具合 (ちゃんと動くもの同士をつなげても、ちゃんと動かない)
の対処に注力できる。
しかも理論上は、かかる工数は同じ。(どうせテスト仕様は
どこかで作るんでしょ)
テスト駆動にしない理由のほうが見当たらないくらい。
0194デフォルトの名無しさん
2013/12/30(月) 18:36:51.50あとは日本の零細経営者はテスト工数を客に見積もれんとか言い出すしな。
ビル建築でも安全率の負担増加分やエレベータや施設のテストもろもろは
ちゃんと請求してんのにな。
0195デフォルトの名無しさん
2013/12/30(月) 18:37:15.600196デフォルトの名無しさん
2013/12/30(月) 18:38:16.91日曜さん?
テストケースは(日本で言う)プログラマが考えるんじゃないんだが。
0197デフォルトの名無しさん
2013/12/30(月) 18:39:22.51それまではサンドバッグです
0198デフォルトの名無しさん
2013/12/30(月) 18:44:08.150199デフォルトの名無しさん
2013/12/30(月) 18:54:54.45プログラマは、釘に金槌を叩きつけるだけ
0200デフォルトの名無しさん
2013/12/30(月) 18:58:40.61ただ単純に、1万行を超えるコードや人月が3ヶ月人を超えるコードを書いたことがないだけだと思う
趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ
0201デフォルトの名無しさん
2013/12/30(月) 19:13:29.280202デフォルトの名無しさん
2013/12/30(月) 19:31:06.80インターフェイス共通でレベルの低いディストリをわざとばらまかないと金儲けできないからな…
0203デフォルトの名無しさん
2013/12/30(月) 19:41:58.210204デフォルトの名無しさん
2013/12/30(月) 19:51:55.710205デフォルトの名無しさん
2013/12/30(月) 19:56:23.72残念だが、コードが完璧でも、実機やOSやコンパイラや言語仕様やユーザの要求は完璧じゃないんだ…
0206デフォルトの名無しさん
2013/12/30(月) 20:14:12.620207デフォルトの名無しさん
2013/12/30(月) 20:18:50.02いまどきはどこも、そんなきれいなV字ウォーターフローやってる暇はないでしょ。
0208デフォルトの名無しさん
2013/12/30(月) 20:19:54.07正確には「人という生物の特性のせい」
0209デフォルトの名無しさん
2013/12/30(月) 20:20:24.690210デフォルトの名無しさん
2013/12/30(月) 20:24:27.17> 趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ
お前がどうするかなんかしらんがなｗ
日曜プログラマの大半はテストコード書かないだろうってのは
大体想像できる。
0211デフォルトの名無しさん
2013/12/30(月) 20:27:09.10土下座の練習が欠かせない。
0212デフォルトの名無しさん
2013/12/30(月) 20:28:19.300213デフォルトの名無しさん
2013/12/30(月) 20:29:49.660214デフォルトの名無しさん
2013/12/30(月) 20:30:20.150215デフォルトの名無しさん
2013/12/30(月) 20:30:30.39テストファーストはしないけど。
0216デフォルトの名無しさん
2013/12/30(月) 20:31:24.44プログラミングのタイピングを途中で打ち切ることになって、これまでにどこまで進んだかを覚える必要が出てくるんだけど、次の週までどうやって覚えておくの？
0217デフォルトの名無しさん
2013/12/30(月) 20:33:20.52体に教え込まないと無理
10年かかってやっとわかった
プログラマは言って聞かせても無駄
体で覚えさせれば素直に言うこと聞くようになる
0218デフォルトの名無しさん
2013/12/30(月) 20:33:32.240219デフォルトの名無しさん
2013/12/30(月) 20:33:36.07コード見て思い出せばいいだろ？
なんなら何をやっていたかを
日本語で書いてもいいし。
0220デフォルトの名無しさん
2013/12/30(月) 20:34:15.51チケット。
0221デフォルトの名無しさん
2013/12/30(月) 20:35:23.51先週何をやっていたか
泉のように思い出すのです。
それが愛です。わかりましたか？
0222デフォルトの名無しさん
2013/12/30(月) 20:35:55.410223デフォルトの名無しさん
2013/12/30(月) 20:35:55.94テストの方が簡単じゃね？
0224デフォルトの名無しさん
2013/12/30(月) 20:36:38.48なんで質問するんだよｗ
テストの方が先週何をやっていたか
思い出すのに簡単である理由を説明しろよ。
0225デフォルトの名無しさん
2013/12/30(月) 20:37:28.20テストを先に書く習慣の人が自分のテストコードを見れば、何をやろうとしてコード書いてて、何ができてないなかったかが分かる
0226デフォルトの名無しさん
2013/12/30(月) 20:38:24.95それくらい覚えてる。一年後でも。
>>223
テストが簡単なコードだけとは限らないしねー
0227デフォルトの名無しさん
2013/12/30(月) 20:38:44.19テストが全部通った場合はどうなるのさ？
お前が言ってるのは、コンパイルが通らなかったら、
今ここをつくろうとしていたとわかるって
言ってるのと同じだよ。
0228デフォルトの名無しさん
2013/12/30(月) 20:39:31.76すごいね
0229デフォルトの名無しさん
2013/12/30(月) 20:40:47.180230デフォルトの名無しさん
2013/12/30(月) 20:41:03.90動的言語でもわざとエラーが起こるようにしておけばいいだけの話だし、
コメントではなくコードの中に日本語を書いておけば、
当然エラーも起きるだろうし、わかりやすい。
0231デフォルトの名無しさん
2013/12/30(月) 20:43:09.270232デフォルトの名無しさん
2013/12/30(月) 20:43:17.171. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識
0233デフォルトの名無しさん
2013/12/30(月) 20:46:26.66あほかｗ
お前の言ってるのは、テストが完璧に書いてあることが前提になってるだろ。
テストに漏れがない。テストに間違いがない。
> 1. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
そのテストに漏れがあったら？
テストを書いている途中だったら？
> 2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
テストが書いていなかったら？ テストがなかったら仕様がわからないよ。
> 3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識
テストが間違っていることもある。
0234デフォルトの名無しさん
2013/12/30(月) 20:46:39.27コーディングの前にテストを書く習慣の人が書いたテストが全部通ったら、コーディングの前にやろうとしてたことは終わった
コンパイルが通らなかったら、 今ここをつくろうとしていたとわかる
コンパイルが通ってテストが通らなかったら、今ここをつくろうとしていてスケルトン作って試行錯誤していたことがわかる
0235デフォルトの名無しさん
2013/12/30(月) 20:48:38.782を入れたら4が返るべきとなっている。
さて3を入れたらなんになるのだろうか？
テストが足りないから何がしたいのかわからん！
0236デフォルトの名無しさん
2013/12/30(月) 20:49:05.15コンパイルが通るコードを書いて実行結果を見て試行錯誤しながらコーディングしてた場合は？
0237デフォルトの名無しさん
2013/12/30(月) 20:50:14.19とは限らない。
なぜならバグを修正しようと思った時、
バグが見つかる前は、”テストが全て通った状態”なのだ。
テストが全て通っていても、
やるべきことが残っていることはよくある話。
0238デフォルトの名無しさん
2013/12/30(月) 20:52:19.110239デフォルトの名無しさん
2013/12/30(月) 20:52:29.71１．失敗するテストコードを書く
２．テストコードを通る”最低限の”実装を書く
とある
http://www.slideshare.net/KyonMm/jasst
> 30. Definition TDD
> 1. 失敗するテストコードを実装する
> 2. テストが通る最低限の実装をする
> 3. 1と2を繰り返す中で、テストの変更につよ くするための実装をする
> 1 - 3を30secから1minで繰り返す。
つまり、テストコードが通ったとしても、
それは最低限の実装であり、
すべてが終わったとは限らない。
0240デフォルトの名無しさん
2013/12/30(月) 20:53:05.60テスト書かなければ、コーディング終わってたのでは？
あと、テストコード書きは絶対に中断されない前提なのね。
0241デフォルトの名無しさん
2013/12/30(月) 20:53:20.85じゃなきゃちゃんと動くはず
0242デフォルトの名無しさん
2013/12/30(月) 20:54:30.20TDDに詳しいのかな？ｗ
0243デフォルトの名無しさん
2013/12/30(月) 20:55:52.10やっちまった奴はボーナスなし！
このくらいやってもらわないと。
0244デフォルトの名無しさん
2013/12/30(月) 20:56:11.97テストは間違っててもいい
テストかコードのどっちかが間違ってるということが分かるから
大前提として、基本的にテストには漏れがある (＝ つまり仕様に漏れがある)
0245デフォルトの名無しさん
2013/12/30(月) 20:56:55.17つまり、ソースコード管理ツールのことである！
0246デフォルトの名無しさん
2013/12/30(月) 20:57:14.620247デフォルトの名無しさん
2013/12/30(月) 20:57:22.20それは、次の人に渡すまでに、プログラマ本人が「自分の責任で」テストをするのが前提ですよね？
0248デフォルトの名無しさん
2013/12/30(月) 20:58:51.76> テストは間違っててもいい
話、ちゃんと理解している？
テストコードが間違ってる状態で、
どっちが正しいかをどう判断するのさ？
先週、何やっているかわからなくなっても
テストコードが失敗したら、そこから作業開始するんだろ？
テストコードしか、何をやっているか手がかりがない。
そのテストコードが間違っているのに、
どちらが正しいかどうやって思い出すのさ？
0249デフォルトの名無しさん
2013/12/30(月) 21:00:09.98テストコードがあれば思い出せるって言ったのだれさ？
自分の言葉に責任持てよ。
0250デフォルトの名無しさん
2013/12/30(月) 21:01:28.850251デフォルトの名無しさん
2013/12/30(月) 21:02:20.54テストは万能ではない
テストコード先に書いた方が、より「バグが少ないコードを書ける」ってだけ
テストコードもソースコードも間違うことがある
テストが間違っててコードが正しい場合と、コードが間違っててテストが正しい場合と、テストとコードが同時に間違ってて答えが異なる間違い方をしてる場合を検出できるってだけ
テストは「時間が許す限り可能な限りバグを減らす努力」のひとつに過ぎない
0252デフォルトの名無しさん
2013/12/30(月) 21:02:52.75責任は責任ある立場の人がとります。
■ このスレッドは過去ログ倉庫に格納されています