トップページ⇒tech
1001コメント360KB

テスト駆動開発はなぜ流行らなかったのか？2

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2014/01/13(月) 08:09:14.87
まとめ

適切にテストコードを導入するためには
適切なコードの書き方や設計まで知っておく必要があり
既存のコードが適切で無い場合、大幅な書き換えが必要になるから。
最悪開発プロセスから変えないといけない。

またテストコードが書きづらい部分（GUIやウェブUI等）が存在し
書きづらいということを知っていないと、無理に書こうとして
挫折するか、無理矢理なテストコードを書いてメンテナス不能になるから
0002デフォルトの名無しさん2014/01/13(月) 11:09:56.95
関数型言語で書くとテストコードが書きやすいコードに自然になるけど、
バカなドカタどもには使いこなせないから
テストコードが書き難いなんて低レベルな争いになる
0003デフォルトの名無しさん2014/01/13(月) 12:02:39.90
GUIやWeb は、2014年現在では、自動テストの導入コストが高過ぎる
ので手動でテストすることになる。
でも、詳細設計やコーディングを始める前に、テスト仕様(=検収条件)
を定義することはできるので、TDD の考え方は適用できる。

この場合、Control・Model層 の自動テストをきちんとやることはもちろん
View層が疎かつ薄くなるように設計して、
人手による（高価な）GUI テストの範囲を限定する必要がある。

ただ、GUIやWeb の自動テストも、ミドルウェアやパッケージソフト
などの、寿命が長くて、自動テスト作成の費用が回収できる分野では
使われ始めているので、そのうち単発アプリでも使える方法が
見つかるでしょう。
0004デフォルトの名無しさん2014/01/13(月) 12:24:31.22
昔、ゲーム機のプログラムに見つからないように小さな機能を仕込んだんだよ。
テスターが遊んでるように見えたので、これを発見できなかったら遊んでると
はっきり言ってやろうと思ったんだ。
その後ずいぶん時間がたって、ちょっとしたおまけとかいたずらみたいなのを
イースターエッグと呼ぶようになった。
自分では、世界初のイースターエッグは俺がつけたやつじゃないかと思うんだよな。
だから、本当のイースターエッグはしゃれっ気どころか眉間にしわよせて作るものなんだよ。
0005デフォルトの名無しさん2014/01/13(月) 12:24:35.88
>>3
どういう姿を想像する？
キューカンバ君が活躍するとはとても思えない
0006デフォルトの名無しさん2014/01/13(月) 12:27:31.07
まず認知度が低い
次にツールが普及してない
最後にブログで派手に煽ってくれる人がいない

結局、海外で流行ってないのに日本で流行るわけがないんだよ
0007デフォルトの名無しさん2014/01/13(月) 12:32:21.69
枠組み（ツール）だけ導入して、使いたい人だけ使えばいい
というのがまず第一ステップ

そのあと、目に見える効果が出れば後は何も考えなくてよい
0008デフォルトの名無しさん2014/01/13(月) 12:38:28.76
出ないでしょ。
0009デフォルトの名無しさん2014/01/13(月) 12:45:57.42
既にそれが身についてる人がいれば効果は出るやろ
0010デフォルトの名無しさん2014/01/13(月) 12:51:07.37
TDDとは商材なんだよ。
セミナーで効果あると言ってるのは当たり前でしょ。
実際は効果ない。
何が悪いのだろうと思って次のセミナーも2時間10万円出す。
お得意様だよ。
0011デフォルトの名無しさん2014/01/13(月) 13:01:34.43
納期間に合わせるのに必死なところに、プログラミングの時間削って
テスト割り込ませるわけよ。
これでどうやって品質上がるの？
あほですか？
0012デフォルトの名無しさん2014/01/13(月) 13:05:13.05
そもそもTDDって俺らが80年代にBASICとかでやってたスタイルだよね？
0013デフォルトの名無しさん2014/01/13(月) 13:06:12.26
テスト重視は新規構築だけじゃなくて長期的な保守まで視野に入れる前提
0014デフォルトの名無しさん2014/01/13(月) 13:19:55.28
JUnit すらさわったことなくて無知をさらしてるやつらは何なの？
0015デフォルトの名無しさん2014/01/13(月) 13:26:40.25
ハイハイ、セミナー頑張ってくださいネ。
0016デフォルトの名無しさん2014/01/13(月) 13:30:15.01
俺のデバッグレベル１〜３ 大抵は１か２で足りてる。
１、printlnデバッグ
２、ロガーデバッグ
３、ユニットテスト
0017デフォルトの名無しさん2014/01/13(月) 13:30:55.18
レガシーコード改善ガイドは役に立ったな
unittestと言うよりは全体的なこと
0018デフォルトの名無しさん2014/01/13(月) 13:30:59.63
>>12
全く違う。
さすがに関数がないとTDDは無理。
（80年代のBASICには関数がない）
0019デフォルトの名無しさん2014/01/13(月) 14:00:31.04
>>12
意味は同じだけど、ツールが違うと別のものに見える人もいるだろね。
0020デフォルトの名無しさん2014/01/13(月) 14:04:47.56
>>1
TDDの是非とテストコードの是非は全く別ってことがまだ分からんのかね。
0021デフォルトの名無しさん2014/01/13(月) 14:16:05.96
>>16
TDDはどこに入るんだ？
0022デフォルトの名無しさん2014/01/13(月) 14:38:01.38
>>3
GUIは知らないけど、Webの世界にある Ruby on Railsでは、
自動テストやTDDに関してRailsフレームワーク側でサポートがある
Railsアプリケーションのデベロッパにとって、自動テストやTDDとは
(ぼんやりした将来像ではなく)現実にある必須技術の一つでしかない

何を言いたいかというと、Webに限らず：
　デベロッパはテスト支援を包含したフレームワークを選択すべきである
って話だ
0023デフォルトの名無しさん2014/01/13(月) 14:52:55.23
工数と締め切りのミスマッチでテストが軽視されてるんだよね?
0024デフォルトの名無しさん2014/01/13(月) 15:04:46.24
>>22
たいていのRailsにかぎらず、Rubyにかぎらず
有名どころのフレームワークには
テスト支援機能があるよ。
IDEにテスト支援機能があるものもある。
有名なjUnitとEclipseとかね。

だから選択すべきと言うまでもなく
普通に選択していると思う。
0025デフォルトの名無しさん2014/01/13(月) 15:14:12.97
>>11
テスト工数も含まない無茶な納期を決めてきたのは誰なのかをまず考えろ
0026デフォルトの名無しさん2014/01/13(月) 15:14:44.77
Web系ってクライアント側でしょ
0027デフォルトの名無しさん2014/01/13(月) 15:24:36.88
>>25
俺かお前か大五郎
0028デフォルトの名無しさん2014/01/13(月) 15:44:52.18
テスト駆動が流行る流行らない以前に、そもそもテストすら書いてなかったという話をしてんの？
0029デフォルトの名無しさん2014/01/13(月) 16:07:30.02
プログラムも書いたことありませんが。
そういうのは書かせるものですよね。
0030デフォルトの名無しさん2014/01/13(月) 16:10:09.61
文系がいいな。単語帳とか常備で。
0031デフォルトの名無しさん2014/01/13(月) 17:53:50.93
このスレってテストは書いてる前提の話じゃないの
テストすら買いてなくて、納期かなんかしらんけど、その理由をここでぐだぐだ言われたって
知らんがなってなるよ
0032デフォルトの名無しさん2014/01/13(月) 19:40:22.46
>>31
結局のところ、新規で始めれるプロジェクトより、そういうすでに動いている
プロジェクトに適用しやすいものじゃなかったからTDDが流行らなかったと。
世の中、完全に新規で始めれるプロジェクトなんて稀だからね。

まあ、そういうゴミみたいな既存のプロジェクトでもちょっとでも良くなるように
テストコードを書いてみたり色々やってる人がいる一方で、ただ愚痴を言って
何も手を動かさない人の多いこと。
0033デフォルトの名無しさん2014/01/13(月) 19:56:51.24
メンテ料をとっておきながら非メンテのコードが多すぎるんだよ
だからハードやシステムを変えられなくて高くつく
0034デフォルトの名無しさん2014/01/13(月) 20:09:35.60
te
0035デフォルトの名無しさん2014/01/13(月) 21:05:14.36
テストを書くということはバグを書きこむ気満々だから。
バグを書きこむつもりが無ければテストなんかするわけない。
0036デフォルトの名無しさん2014/01/13(月) 21:06:45.17
>>33
だって、誰でもメンテ可能なほど整備したコードを納品すると、
次回の契約更新では単価の安い大手を引き合いに出されたりするんだぜ
だから、
・ほどほどの日程遅延で、
・ほどほど動いて、
・ほどほどの品質で、
・ほどほどのメンテが必要な
開発が一番なのさ

自分は契約交渉なんて担当はしたことないけど、
以前、気合いを入れて日程厳守/高品質のプロジェクトを仕上げたら、
上も予測していなかったようで次の仕事が入ってこず、
しかたなく火が噴いた他のプロジェクトの応援にまわされた
アホラシ
0037デフォルトの名無しさん2014/01/13(月) 21:29:29.35
>次の仕事が入ってこず
ってのは予備日程の宙ぶらりんに入ってしまったってことかな

嬉々としてバカンスに突入すればいいのに
0038デフォルトの名無しさん2014/01/13(月) 21:47:05.45
ちょっと前提を確認させてくれ

このスレはテスト用のコードをそもそも書かない人向けなのか
それとも、テスト用コードは最終的には書くけど、それがコーディングの最初でない人向けなのか

そもそもテスト用のコードを書かない人、テスト駆動とか言う以前に他の開発手法でも異端であるから、自動テストの有無みたいなスレ立ててそっちでやってはどうか？
0039デフォルトの名無しさん2014/01/13(月) 21:52:43.27
>>38
自分は、これ
>テスト用コードは最終的には書くけど、それがコーディングの最初でない人

あと、テスト駆動開発ならば、
>最初にテスト用コード書いてから、コーディングを始める人
もいるのではないかと
004012014/01/13(月) 21:53:44.60
>>38

スレ主です

> このスレはテスト用のコードをそもそも書かない人向けなのか
> それとも、テスト用コードは最終的には書くけど、それがコーディングの最初でない人向けなのか

どっちもOK。前提があるならその旨書き込むこと

> そもそもテスト用のコードを書かない人、テスト駆動とか言う以前に他の開発手法でも異端であるから、自動テストの有無みたいなスレ立ててそっちでやってはどうか？

ここで問題無いですよ。
0041デフォルトの名無しさん2014/01/13(月) 21:56:57.44
テストを書く前提ってバグ仕込む気満々だな。
なんでそんなにバグ仕込みたいの？
0042デフォルトの名無しさん2014/01/13(月) 22:09:00.02
>>41
仮に絶対にバグを混入させない人でも、ハードウェア、OS、コンパイラ、API、その他モジュールを全部自作するわけではあるまい
0043デフォルトの名無しさん2014/01/13(月) 22:11:03.16
>>42
そもそもバグ0をどうやって証明するのでしょうか？
0044デフォルトの名無しさん2014/01/13(月) 22:16:19.88
>>43
ゲーデルの定理により、少なくとも自動では証明はできません
0045デフォルトの名無しさん2014/01/13(月) 22:19:10.36
テストは心の弱い人がすることですよ。
0046デフォルトの名無しさん2014/01/13(月) 22:24:52.27
テストを通したから大丈夫なんだって安心したいだけなんですよ。
無意味だって事は判っているんですホントは。
心の弱さなんですよね。
0047デフォルトの名無しさん2014/01/13(月) 22:55:57.49
特別なプロセスやツールを追加することなく100個のバグが99個に減る手法があるなら、それをやるべき
ただそれだけの話
0048デフォルトの名無しさん2014/01/13(月) 23:13:27.05
リファクタリングも心の弱さが原因です。
心の弱い人たちがコードをフローを追い切れず、
命名したメソッドを変更したくなるんです。
全ては心の弱さが原因。
0049デフォルトの名無しさん2014/01/13(月) 23:20:54.15
仮に我々の心が強靭であっても、ユーザはそうではない
0050デフォルトの名無しさん2014/01/13(月) 23:22:19.76
信念を持って命名したはずだったのに。
0051デフォルトの名無しさん2014/01/13(月) 23:29:32.53
仕様変更は俺らのせいじゃねーよ
0052デフォルトの名無しさん2014/01/13(月) 23:38:12.41
成長して過去の己を反省したなら名を改めるべき
0053デフォルトの名無しさん2014/01/13(月) 23:42:04.99
テスト駆動開発ってコーディング中に自分が成長する人向けだよね
最初から成熟したプログラマはこの手法は向かない
0054デフォルトの名無しさん2014/01/13(月) 23:50:39.33
学生さん向けですか。
0055デフォルトの名無しさん2014/01/13(月) 23:56:20.30
そこそこ動くコードを作ってから後で置き換えるタイプの俺はテストがかなり重要なんだよな
0056デフォルトの名無しさん2014/01/13(月) 23:57:23.87
それはアマチュアの特権ですね。
0057デフォルトの名無しさん2014/01/13(月) 23:58:53.63
手を動かさない理由を全力で考えるより、その情熱を少しでも手を動かす方に
回せばいいのに。
0058デフォルトの名無しさん2014/01/14(火) 00:02:24.29
手を動かさない理由を全力で考えるという行為は
手を動かすのに必要な問題点の列挙だよ。

何かがうまくいかない時、その原因を探すことは重要。
問題点を把握しなければ、問題点を解決することは出来ない。
0059デフォルトの名無しさん2014/01/14(火) 00:09:33.84
>>56
最終的に全テスト通して何十万台の商品に乗ってるわけだが
開発の進め方的に何が問題なんだいw
0060デフォルトの名無しさん2014/01/14(火) 00:15:24.31
> 何十万台の商品に乗ってるわけだが

ソフトウェアの話に台数がなにか関係あるの？
0061デフォルトの名無しさん2014/01/14(火) 00:17:39.41
立場をはっきりさせよう

a. テストは不要
b. テストは必要
c. (可能なかぎり)自動テストが必要
d. (可能なかぎり)自動テストが必要で、コードを書く前にテストを書くべき

少なくとも b.c.d. しかいかないと思ってたが、もしかしてa.の人もいるの？
0062デフォルトの名無しさん2014/01/14(火) 00:17:48.43
あの誤字だらけの人の製品を使ってるかと思うと
窓から投げ捨てたくなるね

それを言い出すなら俺だって1日数十万アクセスのサーバをながめてるだけの仕事だけど？
0063デフォルトの名無しさん2014/01/14(火) 00:18:17.21
>>60
ライセンスや損害賠償は台数の掛け算
0064デフォルトの名無しさん2014/01/14(火) 00:20:56.38
>>60
こいつ偽物の匂いがする
実務経験ほとんどないんじゃないかな？
0065デフォルトの名無しさん2014/01/14(火) 00:27:19.46
e. テストは害悪、気をしっかり持て！
0066デフォルトの名無しさん2014/01/14(火) 00:29:40.18
テスト工程の専門家っていないの？
どこにいっても新人の仕事だけど
0067デフォルトの名無しさん2014/01/14(火) 00:31:21.68
日本テスト協会を作って認定資格を作ればまた儲かる。
0068デフォルトの名無しさん2014/01/14(火) 00:31:27.73
開発プロセスの本で、テストが不要と書いてあるモノを見たことがない
0069デフォルトの名無しさん2014/01/14(火) 00:32:39.13
それは本を売らないといけないからだよ。
自動車屋さんが自動車は不要と言わないのと同じ。
0070デフォルトの名無しさん2014/01/14(火) 00:32:44.48
>>66
テスト駆動開発のテストはテスト工程の専門家がやるテストじゃなくて、テスト工程に渡す前に、プログラマ個人がやる習慣としてのテストではないかと
0071デフォルトの名無しさん2014/01/14(火) 00:34:44.46
それは心が弱いからすること。
俺の書いたものに間違いがあるわけない。
こう言い切れないなら別の職につけよ。
お客様が迷惑するだろ。
0072デフォルトの名無しさん2014/01/14(火) 00:34:56.19
>>63
> ライセンスや損害賠償は台数の掛け算

うん。だからそれはソフトの動作と何か関係があるの？
0073デフォルトの名無しさん2014/01/14(火) 00:37:28.17
>>72
協調動作するアプリじゃないかぎり台数とソフトの動作は関係ないけど、台数とソフトのリスクとソフトのコストは関係ある
0074デフォルトの名無しさん2014/01/14(火) 00:40:40.77
>>67
それあるんだけどな。
ttp://jstqb.jp/
0075デフォルトの名無しさん2014/01/14(火) 00:42:53.08
>>61
現状はcだな　dはまだ厳しい
というか小さい範囲だとそこまでテストファーストである必要はないし、大きな範囲だと環境依存がでかくなりすぎる。作業効率含めてちょうどいいバランスを模索している状況だね
結局、ロジックと振る舞いが現時点での限界だね
0076デフォルトの名無しさん2014/01/14(火) 00:54:09.31
TDDするのに便利なツールとかある？
0077デフォルトの名無しさん2014/01/14(火) 01:26:14.43
>>76
普段から自動テストをやろうとしている人は、TDDだから便利とかいうツールはない
ただ、テスト行程の人と同じツールにすると、テスト行程の人が喜ぶ
0078デフォルトの名無しさん2014/01/14(火) 01:43:36.36
emacsでCtr-x 2で画面を2つに分けて、上のバッファにテスト書いて、それ見ながら下のバッファにコードを書いてる
続けると、なんとなくコードがこじんまりした感じになる
0079デフォルトの名無しさん2014/01/14(火) 01:49:56.18
python とか java のドックストリングとかノーテションにテスト書けみたいな本があって、自動でテストもできることはできるんだけど、あれやるとコードが読みにくくなると思うのは俺だけか
0080デフォルトの名無しさん2014/01/14(火) 01:55:30.01
>>78
emacsやvimは１つで全てが完結する。そう考えていた日が僕にもありました。
たしか、quake作ってる会社のスクリーンショットに、
複数のエディタが立ち上がっているのを見て考えが変わったんだ。
道具を使いこなしたところで、すごいプログラマに成れるわけじゃないんだって
0081デフォルトの名無しさん2014/01/14(火) 02:36:46.26
そりゃそうだね。

道具に足を引っ張られていれば問題だけど、
そうでないなら、道具よりも力のほうが大きい。
ソフトウェアなんていかにコードを減らすかなんだし。

逆に技術低いのに道具の使い方が上手いと、
高速に

　コピペが！
　汚いコードが！

量産される（苦笑）
0082デフォルトの名無しさん2014/01/14(火) 13:15:40.56
>>61
> d. (可能なかぎり)自動テストが必要で、コードを書く前にテストを書くべき

わかってると思うけど、これはテストファーストの説明であってTDDの説明じゃないよね。
0083デフォルトの名無しさん2014/01/14(火) 14:48:27.16
>>70
> プログラマ個人がやる習慣としてのテストではないかと
それユニットテストじゃないの？
0084デフォルトの名無しさん2014/01/14(火) 20:03:24.86
夜中の一時や二時に二チャンネルなんかしてるからテストが必要になるんだろ。
休み明けくらい早く寝ればいいのにな。
無職ならいいけどさ。
0085デフォルトの名無しさん2014/01/14(火) 20:15:10.57
他人の尻拭いを考えなくていい立場ってうらやましいな
0086デフォルトの名無しさん2014/01/14(火) 22:40:46.77
>>82
少なくとも商業では、労働時間単位のタイピング数を最少化するというバイアスがあるので、テストを先に書くことを義務づけるなら、自然にTDDになる
0087デフォルトの名無しさん2014/01/14(火) 22:41:34.94
>>83
プログラマがエディタを保存した直後に行う動作確認はユニットテストだけではない
0088デフォルトの名無しさん2014/01/14(火) 22:56:35.87
javaでもcでもそうだけどさ、少しの外部ライブラリだけで作れるロジック層にめちゃくちゃインクルードし過ぎなんだよな
あれさえやめればテスト可能性が上がるよな
0089デフォルトの名無しさん2014/01/14(火) 23:54:13.97
プログラマ個人がTDDやってたら、まわりからみたらサボリ、理解がある人からみても生産性が悪い人の烙印が押されるわけだけど
その辺の整合性はどうつけてんの？
0090デフォルトの名無しさん2014/01/14(火) 23:54:31.16
王将は結局、中華料理は中国の利権ってことで殺されたんでしょ？
これ他の中華料理店は大丈夫なのかな？
0091デフォルトの名無しさん2014/01/15(水) 00:19:51.83
>>89
調査・設計に比べたらテストコードも含めてコーディングにかかる時間なんて誤差程度。
単にバグを出さない人扱いだよ。
0092デフォルトの名無しさん2014/01/15(水) 00:27:39.68
それは言えてる。
コーディングは製品全体の1％程度しか占めていないね。
0093デフォルトの名無しさん2014/01/15(水) 01:09:42.25
1%は言いすぎだけど、コーディングは思ったより少ない。
だけど、コーディングは最重要視しなければいけない。
なぜならば時間がかかっているのがリーディングとテストだから。

新規開発でもなければ、何か修正しようした時コードを読んで理解しないといけない
その時コードの量が多ければそれだけ時間がかかるし
複雑だともっと時間がかかる。

バグ修正を例にすればもっとわかりやすいと思う。
修正するコードはたかだか数行ってことはよくある。
でもそれを修正するまでに読まなければいけないコードはその何倍にもなる。

テストもそう。テスト時間を短くするにはやはりモジュールを疎結合にして
自動化出来るようにする必要がある。
それはコーディングに時間をかけることでしか達成できない。

パレートの法則みたいなもんだよ。ほんの僅かな時間しかかからないコーディングが
その他の作業にかかる時間を大きく左右する。
0094デフォルトの名無しさん2014/01/15(水) 01:25:49.96
コーディング能力ゼロ(つまり納品不可能)でも、なんだかんだいってお金持ってこれる人がいるという不思議な世界です
0095デフォルトの名無しさん2014/01/15(水) 07:02:23.82
>>89
リファクタリングすればするほど行数減るから肩身狭いわ
残業する奴の評価と実際の仕事の効率の関係に似てるよな
技能の価値はその道を知るものにしかわからない
0096デフォルトの名無しさん2014/01/15(水) 10:59:15.56
>>86
> テストを先に書くことを義務づけるなら、自然にTDDになる
ならねーよ
0097デフォルトの名無しさん2014/01/15(水) 18:56:06.24
おまえら話がちょっとおかしいよ
TDDはテストを先に書くわけじゃないよ
テストとコードを交互に書いていくんだよ
テストを全て書き終わってからコードを書くわけじゃない
おまえら単体テストのテストコードを先に書いてるだけだろ
0098デフォルトの名無しさん2014/01/15(水) 21:44:18.89
いいや？
テストなんて書いたことないけど？
0099デフォルトの名無しさん2014/01/15(水) 23:08:59.90
>>97
コード書く前に、今から書くコードのテストを用意するのがTDDですよ
0100デフォルトの名無しさん2014/01/15(水) 23:54:28.39
正直自分にはTDD無理ぽ。
仕様のかっちり決まったロジックを書くならともかく、たいていは油絵みたいに最初は大まかに描いて後で細部をキッチリって感じで書いてるからやりようがない。
だいたい後からキワいとこだけテストハーネス仕込んでるわ。
おまいらそんな最初からテストがきっちりかけるようなもの作ってんの？
0101デフォルトの名無しさん2014/01/15(水) 23:58:04.67
>>100
コード書いた後にやる確認作業用のコードを、そのコードを書く前に書けばいいだけの話
0102デフォルトの名無しさん2014/01/16(木) 00:09:28.51
>>101
だからそれは仕様がはっきり決まってる場合だろ？
0103デフォルトの名無しさん2014/01/16(木) 00:10:27.27
大まかに描いてテストを書いて細部をキッチリ書け
0104デフォルトの名無しさん2014/01/16(木) 00:21:19.36
>>102
コード書いた後に確認作業しないの？
0105デフォルトの名無しさん2014/01/16(木) 00:37:06.09
みんなわかってないの？

> コード書いた後にやる確認作業用のコードを、そのコードを書く前に書けばいいだけの話

このコードを書く前に書くといった、確認作業用のコード
この確認作業用のコードはTDDでは原則として捨てるからね。

これはあくまでコード書くために書く（テスト）コードであって
ユニットテスト用のコードまたは別に作る。
0106デフォルトの名無しさん2014/01/16(木) 00:38:10.34
この確認作業用のコードっていうのは
単にコードを書き始めるための道具でしか無い。

だから作りこむようなものではなく、書捨てで良い。
0107デフォルトの名無しさん2014/01/16(木) 00:43:07.51
ユニットテストのテストは資産として残すからきっちり作らなければいけない。
ちゃんと仕様通りのテストを書いて、カバレッジ100%を目指すわけではないが
それなりに高い数値を目指すもの。

でもTDDは適当でいい。コードを書くのに必要最小限のコードを書けばいいだけ。
0108デフォルトの名無しさん2014/01/16(木) 01:01:56.08
こんなスレですらTDDが流行ってないんだから
もう流行る要素ないだろｗ
0109デフォルトの名無しさん2014/01/16(木) 01:33:28.75
>>104
ものによる。書いた後ちょっと動かして確認すればいいものはそれですますし、ちょっと複雑なロジックなんかはテストで確認とかする。
まぁテストカバレッジ率は低いと思う

コードを書き始めるためのテストコードの必要性がわからん(´･_･`)
0110デフォルトの名無しさん2014/01/16(木) 01:35:33.03
malloc失敗時の処理もちゃんと書いてるんだけど
その部分のカバレッジがあげられない
どうやって失敗させりゃいいんだ
0111デフォルトの名無しさん2014/01/16(木) 01:59:48.02
プロジェクトのテスト行程のコードと、プログラマ個人の習慣としてのテストのコードを、一緒に考えてる人がいる気がする
流用するやり方もあるけど、基本的に別物です
0112デフォルトの名無しさん2014/01/16(木) 02:04:32.49
>>110
mallocで1TB確保すればいい
0113デフォルトの名無しさん2014/01/16(木) 02:43:47.18
malloc はsizeof(構造体)*デカい値で呼出すか、ヒープを全部1で埋めてから呼び出す
free はfreeを2回続けて呼出す
0114デフォルトの名無しさん2014/01/16(木) 06:35:19.81
>>107
> でもTDDは適当でいい。コードを書くのに必要最小限のコードを書けばいいだけ。
つまり、ゼロでもいいと。
0115デフォルトの名無しさん2014/01/16(木) 06:39:59.11
>>101
コードを書いている間に、コードを書く前の想定と仕様が変わることはよくあるし、
無理してコードを書く前の仕様に合わせるのは本末転倒だし。
0116デフォルトの名無しさん2014/01/16(木) 06:51:49.59
>>106
書き捨てなら、結局作業量が増えるだけでは。
捨てる作業も含めるとさらに。
0117デフォルトの名無しさん2014/01/16(木) 08:59:02.01
>>115
仕様が変わるからこそテストを書くべき
突然以前のコードが動かなくなったら嫌だろ？
0118デフォルトの名無しさん2014/01/16(木) 11:37:51.89
>>117
だからそれはコード書く初期の段階じゃなくある程度固まってからでいいと思うんだが。
0119デフォルトの名無しさん2014/01/16(木) 12:47:21.58
ある程度固まるのを促進するためにテストを書け
0120デフォルトの名無しさん2014/01/16(木) 13:40:05.79
>>115
まず、以下のようなテストを書いたとする。

Foo f = new Foo()
assertEquals(10, f.bar(1, 2))

で、おもむろにFooクラスのbar()メソッドを書き始めるわけだが、bar()のコードを書く前には仕様は変わらんだろ。
上のテストが通るようなbar()実装後に、bar()の仕様を変える必要がでてきたら、そのときはテストを帰れば良い。
0121デフォルトの名無しさん2014/01/16(木) 13:58:09.22
>>118
ある程度固まるまでのコードをテストするテストコードを、ある程度固まるまでのコードを書く前に書けって言ってるんだが。
0122デフォルトの名無しさん2014/01/16(木) 14:26:16.52
TDDに興味がある人むけ。

TDD Advent Calendar 2013
http://qiita.com/advent-calendar/2013/tddadventjp

TDD Advent Calendar jp: 2012
http://atnd.org/events/33846

TDD Advent Calendar jp: 2011
http://atnd.org/events/22027
0123デフォルトの名無しさん2014/01/16(木) 14:29:53.43
ついでに、Advent Calendarを電子書籍に変換してくれるサービス。
http://advent-calendar2readlists.herokuapp.com/
0124デフォルトの名無しさん2014/01/16(木) 14:31:38.64
2012年のAdvent Calendarを変換してみた。
http://readlists.com/00130d19/
0125デフォルトの名無しさん2014/01/16(木) 14:40:52.61
>>123
TDD関係ないけど、これスゲーな
0126デフォルトの名無しさん2014/01/16(木) 16:29:54.95
本当に困るバグなんていつも予想もつかないところから出てくるじゃないですか。
あと設計自体のミスとかさ。

TDDをやったら自動的に品質が上がるわけではないのは
最近のGoogle Chromeが実証してしまっている。

開発者たちが明かすGoogle Chromeが目指すものとは｜【Tech総研】
http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002245

> Google Chromeでは、開発プロセスの改善はほぼすべて自動化されています。従来のソフトウェア開発では、
> 誰かが何かを書き、専任のテスト担当者がテストを行い、バグが見つかったら直し、というのを何度も繰り
> 返していたわけです。それによって、ソフトウェア品質を向上させていた。
> しかし、Google Chromeではそういうことはなく、あるコードを書いた人は、テストも同時に行わないと
> いけない。このとき、テストは自動化されているんです。ほかの人が別の機能を足したときも、自動的に
> テストが入るので、元のものに影響を与えるようなものは受け入れられない。

これで、「マウスホイールが効かん」というすげーバグが安定版に入り込んでるんだから世話ないわ。

Chrome 32 スクロールの問題 まとめ - Google プロダクト フォーラム
http://productforums.google.com/forum/#!topic/chrome-ja/I05Ixft9UF8

あと俺ゲーム系だしな。モジュール単位ではもちろんテスト書くが
マスターアップ直前まで仕様がコロコロ変わるし、ゲームシステムや3Dの挙動のテストなぞ書けんよｗ
人間のテスターから１発でスクリーンショットとログとメモリダンプ届くとかそういう効率化はするけどな。

で、テストができないならせめて静的型言語を使ったりコードの静的解析をかけようと
ここが動的言語大好きなウェブの連中がおそらく100年経っても理解できないであろうところだ。

ま、どんな技術や方法論にも適用範囲と限界があるよね。
テストを書かないのはまともなプログラマじゃないみたいな視野狭窄な言説を見かけると
鼻で笑っちゃいますね。
0127デフォルトの名無しさん2014/01/16(木) 17:44:34.40
>>126
全然論理的じゃないなぁ
どんな方法であれ大きなバグが混入するのは避けられないだろう
その中でもバグの混入率をどれだけ下げられたのかが論点なのであって、
「大きなバグが入ったからこの方法は無意味！論破完了！」なんて子供の議論でしかないよん
0128デフォルトの名無しさん2014/01/16(木) 17:58:33.53
>>126
TDDと関係ないだろ
0129デフォルトの名無しさん2014/01/16(木) 18:15:09.19
>>126
ひょっとして、静的解析って動的言語だとできないとでも思ってるんだろうか
0130デフォルトの名無しさん2014/01/16(木) 20:06:56.77
ハイ、できません。
0131デフォルトの名無しさん2014/01/16(木) 20:48:09.11
まともな人材がWebプログラマなんかになるとでも思っているんだろうか
0132デフォルトの名無しさん2014/01/16(木) 22:34:38.89
>>120
bar書いてる途中で、引数は配列にしようとか、そもそもbar関数要らないやと
仕様変更入ったらそのテストコード意味なくなるよね。

一度もOKになることのないテストコードは書かなくてもよくね？
0133デフォルトの名無しさん2014/01/16(木) 22:51:47.23
>>127
うん、結局は実証が必要になるね。
厳密な数学的証明でもできれば別だけどさ。
そういう実証的な話題には乗りにくいんだろう、この話は。なぜなら
0134デフォルトの名無しさん2014/01/16(木) 23:34:48.06
>>115
無理してコードを書く前の仕様に合わせるのがTDDだよ
無理して仕様を書いた後のコードに合わせてはいけない
0135デフォルトの名無しさん2014/01/16(木) 23:41:35.01
>>119
テストを書くことで何がどう促進されるん？

>>121
それを書いたところで何のメリットがあるんだ？ってことを聞いてるんだが。
テストハーネスは何かが壊れたことを検知するために仕込むと思うけどこれから変わるだろうものに仕込んでどうする？
書いてる途中でロジックが正常かどうかは多くの場合簡単にデバッグプリントすれば分かる。
それで進めて固まってきたらテストを仕込めばいい。

>>134
ネタか(´･_･`)
0136デフォルトの名無しさん2014/01/17(金) 00:01:34.37
>>135
テスト書く前というか、キーボードを叩く前に脳みそを動かせってことでしょ
0137デフォルトの名無しさん2014/01/17(金) 00:10:44.29
プログラムを書いてる最中には極度の記憶障害を引き起こすからテストがないとダメ
0138デフォルトの名無しさん2014/01/17(金) 00:15:14.61
逆に言うと、短期記憶に収まらないような長さのプロシージャや、事前に書いたテストが後で変更されるような複雑なブロックを書くなということではなかろうか
0139デフォルトの名無しさん2014/01/17(金) 00:20:01.08
>>136
もちろん書く前はいろいろ考えてその後に書くよ。
ポンチ絵とか懸念点とかアウトラインに箇条書きにして考えた結果を最終的にコードに落とす。
そう言ったことをさせるためにテストをかけって言ってるなら多少わからんでもないけどそれでもテストとしてそのメモ書きを書く必要のメリットが分からんよ
0140デフォルトの名無しさん2014/01/17(金) 00:21:58.86
ツールの支援できもちよくなれるよ
0141デフォルトの名無しさん2014/01/17(金) 00:36:51.53
>>139
テストはメモではない
先に箱の形と大きさを決めて、書きながら余計な機能を追加しないためにテストを書く

コーディングのために特別なアウトラインやメモが必要なほど大きな塊を書くなってことでしょう
0142デフォルトの名無しさん2014/01/17(金) 00:51:38.34
>>141
だーかーらー、そういった仕様がっちり最初から固まるものもあれば上のゲームの人みたいに粘土をこねて形にするものもあって、ここではその後者の話してると思うんだけど。

別に一つの塊のために絵を描くわけじゃないぞ？森見て木を見てまた森を見て全体を思い浮かべながら木を描くためだぞ？
0143デフォルトの名無しさん2014/01/17(金) 01:02:04.44
たとえ話はいらない。
0144デフォルトの名無しさん2014/01/17(金) 01:05:10.61
仕様が多少かわっても、書いたテストって使いまわすよね
0145デフォルトの名無しさん2014/01/17(金) 01:10:25.88
書いた後捨てるといったり使いまわすといったりあてにならん
0146デフォルトの名無しさん2014/01/17(金) 01:12:34.12
何言ってるんだ？

お前だって、
だいた後捨てたり使いましたりするだろ。
場合によりけりだよ。
0147デフォルトの名無しさん2014/01/17(金) 01:13:22.58
間違った。

×何言ってるんだ？
○何を言ってるんだ？
0148デフォルトの名無しさん2014/01/17(金) 01:23:11.93
>>142
粘土をこねて形にするのはいいけど、粘土をどんどん付け足して視界の外からはみ出るほど大きくするのはやめろってことでしょう
0149デフォルトの名無しさん2014/01/17(金) 01:24:56.72
突っ込まれると主張が変わってあてにならん
0150デフォルトの名無しさん2014/01/17(金) 01:32:01.85
そもそも、コーディングの出来にあわせて仕様を変更するって、他の開発プロセスでもOKなの？
0151デフォルトの名無しさん2014/01/17(金) 01:32:27.46
しょせん、「合理的な掃除のやり方とは」レベルの話だってことさ。
0152デフォルトの名無しさん2014/01/17(金) 01:33:09.89
>>148
それは全体を考えた上でうまく全体を疎結合にすればいいだけの話であって、テストとはあまり関係ないだろ。

テストを最初から書くことのメリットとしてテストをかけるようにすることで各部分を他にあまり依存しない小さなロジックで書くことを促されるのがあると思う。
けどそれはテスト書かなくても気をつけていればいいだけであって関数型で書いてたりすれば自ずとそんな感じになる。

最初からテストをかけと言ってる人はただの教条主義に陥ってないか？
0153デフォルトの名無しさん2014/01/17(金) 01:36:29.89
>>146
>だいた後捨てたり使いましたりするだろ。
脳内妄想もたいがいにしろ童貞
0154デフォルトの名無しさん2014/01/17(金) 01:48:43.56
>>152
テストを最初から書くことのメリットは、粒度を疎にすることと、
インターフェイスをコーディングの始めからトイレで席を立って帰ってきてエディタを保存するまでの間一貫させておくことと、
コードの長さをプロジェクトの了解の外にあるプログラマ個人の思い付きによる機能追加で長くしないことがある

関数型で書くときこそテストを先に書く必要がある理由は、関数型はドメインが陽にコードに現れないから
ポイントフリープログラミングなんかその典型
0155デフォルトの名無しさん2014/01/17(金) 03:33:03.87
>>154
前段は疎にする以外はテストを書くことによりそれが得られる理由がわからん。

後段はドメインが出てこないとは何を指して言ってるんだ？
0156デフォルトの名無しさん2014/01/17(金) 03:52:31.04
>>154
つまり、質の悪いプログラマを使わざるをえないプロジェクト向けということでおk？
普通はテストなんか無くても自然とやってることだらけじゃん。
0157デフォルトの名無しさん2014/01/17(金) 05:47:10.62
>>126
３Dの挙動ぐらいテストできるだろ
毎回同じ表示がされればいいだけなんだから
0158デフォルトの名無しさん2014/01/17(金) 08:07:30.81
>>132
どうせ仕様変更入るから仕様書なんて書かなくてもいいよね

まあ趣味ならそれもあり。
0159デフォルトの名無しさん2014/01/17(金) 10:17:12.49
>>132
> bar書いてる途中で、引数は配列にしようとか、そもそもbar関数要らないやと
> 仕様変更入ったらそのテストコード意味なくなるよね。
それ、仕様変更じゃなくて設計変更じゃないの、というのはおいといて。

引数を配列にしたくなったら、テストをそのように変えればいいし、bar()がいらなくなったら、テストを削除すればいいだけだよね。

> 一度もOKになることのないテストコードは書かなくてもよくね？

そうじゃなくて、TDDでは一度OKにするんだよ。
class Foo { // 仮想言語
　　public int bar(int i, int j)
　　{
　　　　return 10;
　　}
}
こう書いて、ビルドしてテスト実行。
0160デフォルトの名無しさん2014/01/17(金) 12:58:54.95
>>130
それ本気で言ってんの？
0161デフォルトの名無しさん2014/01/17(金) 15:54:05.17
BDDと、どっちが強いの？
0162デフォルトの名無しさん2014/01/17(金) 19:23:42.69
ハイ、本気です。
0163デフォルトの名無しさん2014/01/17(金) 19:29:17.69
小ミスをコンパイルエラーを直すような感覚で発見・修正できる
それで十分
0164デフォルトの名無しさん2014/01/17(金) 19:32:44.88
JUnit,CppUnixtの存在意義って？
0165デフォルトの名無しさん2014/01/17(金) 19:43:27.77
>>158
テストコード書くのは仕様が決まってからでいいんじゃないかと。
仕様が決まってない状態でテストコード書いても意味ないだろう。
0166デフォルトの名無しさん2014/01/17(金) 19:45:10.81
ありませんね。
0167デフォルトの名無しさん2014/01/17(金) 22:22:53.61
>>165
そんなことは仕様も決まってないのにコード書いてる >>132 に言ってくれよ (w
0168デフォルトの名無しさん2014/01/17(金) 22:35:46.81
コード書きながら仕様を決めていくことはよくあることだし。
0169デフォルトの名無しさん2014/01/17(金) 22:40:31.19
ドキュメントを書きながら仕様を決めるのと
コードを書きながら仕様を決めるのと
なにも書かずに頭の中で仕様を決めるとでは
どれが一番無駄がなく短い時間で出来ますか？
0170デフォルトの名無しさん2014/01/17(金) 22:54:27.62
>>154
テストを先に書くと、コーディング途中で「本来なら事前に予想もできなかった複雑なことを、さも簡単なことのように何食わぬ顔でコードに書き足していくこと」が難しくなる

ドメインとは、引数の型と、その引数がとりうる範囲
関数型はこれが分かりにくいので、結局テストで明示されることになる
0171デフォルトの名無しさん2014/01/17(金) 22:57:42.14
>>169
> ドキュメントを書きながら仕様を決めるのと
仕様はけして決まらない

> コードを書きながら仕様を決めるのと
仕様はけして決まらない

> なにも書かずに頭の中で仕様を決めるとでは
仕様はけして決まらない

> どれが一番無駄がなく短い時間で出来ますか？
時間を浪費して頭がハゲるだけ
0172デフォルトの名無しさん2014/01/17(金) 23:06:17.61
>>171
「私はエディタに向かっていったい何を書きたかったのだろうか」 は、いつ決まりますか？
0173デフォルトの名無しさん2014/01/17(金) 23:33:39.18
>>172
「Save Asノ 」ではなく「Save」できたときだ
0174デフォルトの名無しさん2014/01/18(土) 00:02:55.09
今日のクロスでもテストを書きまくることは自分の足を銃で打つみたいなことだとか誰か言ってたな(´･_･`)
0175デフォルトの名無しさん2014/01/18(土) 00:09:20.08
>>171
えと、順位を決めてくださいという話です。
0176デフォルトの名無しさん2014/01/18(土) 00:11:01.37
プロジェクトでコーディングする場合、一番必要なのは不自由さだ
自由を一切認めず、ただ黙々と単調で枠にはまった定番のコードを書き続けるよろし

独創性を発揮する連中は足でも撃っておとなしくさせるべき
0177デフォルトの名無しさん2014/01/18(土) 00:15:17.42
>>176
半分正解で半分間違い。
0178デフォルトの名無しさん2014/01/18(土) 00:17:08.68
そうだね。簡単にいえば、

独創性を発揮して、単調で型にはまった定番のコードにしていく

ってことかな。
0179デフォルトの名無しさん2014/01/18(土) 00:23:39.71
まずね、初期の段階は各人がそれぞれ技術レベルの違う
コードを好き勝手書いてる段階になると思う。

これは良くない。

で、単調で型にはまった定番コードにみんな足並みそろえるわけだけど、
その単調なコードというのを作るのには、独創性が必要になる。

あたりまえだけど、単調でも冗長なコードはだめ、無駄が多いからね。
だから単調かつ短いコードにしなきゃいけないんだけど、
それには高い技術力と独創性が必要になる。

そうすると一連のコードが、独創性が必要な汎用性が高いが
一度作れば終わりのコードと、単調だけど短いコードに分かれていく。
この作業をどんどんつき進めていって、単調なコードをどんどん短くしていく。

単調なコードを短くするには、独創性が高いコードを単調なコードから抜き出していく作業。
だから単調で型にはまった定番のコードを作るために独創性が必要になる。
0180デフォルトの名無しさん2014/01/18(土) 00:30:12.12
単調なコードを作るのに必要なのは独創性ではない
必要なのは　「ここ分かりにくいと思います」　と口にする勇気だけだ
0181デフォルトの名無しさん2014/01/18(土) 00:31:02.58
>>179
おまえuyだろ
0182デフォルトの名無しさん2014/01/18(土) 00:32:35.87
>>171
アジャイルって、どのタイミングで仕様かためるんだ？
0183デフォルトの名無しさん2014/01/18(土) 00:34:14.72
仕様というか、今から書こうと思ってるコードの動作確認の方法が事前に分かってないというのはダメだと思うんだ
0184デフォルトの名無しさん2014/01/18(土) 00:37:42.51
>>180
「わかりにくいと思います」じゃただ口に出しているだけ。

じゃあどうすればいいかという答えが出なければ
なにも変わらない。

その、どうすればいいかという答えをだすのに
独創性が必要になるんだよ。もちろん技術力もね。
0185デフォルトの名無しさん2014/01/18(土) 00:54:07.39
独創性の排除、没個性化、簡潔化ほど評価されるんじゃないのか
簡潔にならない独創性なんて、闇の力に魅入られた中学生ぐらいだろ
0186デフォルトの名無しさん2014/01/18(土) 00:58:02.74
単純な独創性の排除は、
やる気が失われることになるので
生産性が下がるんだよ。

それに、改善は一度やれば終わりではなく
ずっと繰り返しやり続けること。

つまり次はどんな改善を行うか？ という発想が
常に必要ってことだよ。
何も考えない脳ではできない作業
0187デフォルトの名無しさん2014/01/18(土) 01:08:02.31
>>184
どうすればいいかは、定番のきまりきった答えがあります
車輪の再発明はしないでください

万が一、定番の答えが存在しない問題にであった場合は、一旦作業を止めて、グループの中で一番独創性がない人に合せて、みんなでコーディングについて同意をとってください
あなたが独創性を発揮して解決しても、他の人が同じ答えにたどりつかず、プロジェクト全体でコーディング規則の不統一や保守性の低下をもたらします
0188デフォルトの名無しさん2014/01/18(土) 01:13:47.13
>>186
単純な独創性の排除は、人間性が失われることになるので、自動化可能な範囲や能力が低い派遣での置き換え可能性が広がり、生産性が上がる
やる気は、自動化の方向や、あなたの仕事を削除する方向に回してください
0189デフォルトの名無しさん2014/01/18(土) 01:16:01.87
>>187
定番の答えでできるレベルの、その先の話だよ。
定番でできる範囲を超えた更にその先、もしかしたら
誰もやったことにないことをやるのだから
高い技術力と独創性が必要になるわけ。
0190デフォルトの名無しさん2014/01/18(土) 01:17:50.59
>>187
> グループの中で一番独創性がない人に合せて

それはやらない方がいい。

ようは他の人が足を引っ張られてるってことだから。


足を引っ張られてもそれを補うぐらいの、コスト（人を沢山使える）
ならばやっていいと思うよ。

でも大多数に少人数かいはつでは、足を引っ張られたらおしまい。
0191デフォルトの名無しさん2014/01/18(土) 01:18:48.23
>>188
> やる気は、自動化の方向や、あなたの仕事を削除する方向に回してください

だから自動化をするのにも独創性と技術が必要になるんだよ。
0192デフォルトの名無しさん2014/01/18(土) 01:19:11.16
>>189
もっとはっきりと「誰もやったことにないことをやるな」と言えばお分かりいただけるでしょうか…
0193デフォルトの名無しさん2014/01/18(土) 01:20:49.70
>>192
誰もやったことがないことをやるなって、
AmazonやGoogleに言ってみるといいよ。

負け犬の遠吠えに見えるだろうね。
0194デフォルトの名無しさん2014/01/18(土) 01:22:43.62
Amazonとか独創性をもって
自動化を進めてきた企業の一つだろうね。
商品ピッキングシステムとかAWSとか
0195デフォルトの名無しさん2014/01/18(土) 01:23:01.89
>>190
他の人の足を引っ張るのは、独創性がない人ではなく、3ヶ月後の自分ですら読むことのできない独創的なコードを書くバカ

>>191
その独創性は、コードには出さないでね
0196デフォルトの名無しさん2014/01/18(土) 01:25:22.55
>>195
お前、独創的と、汚いコードをごっちゃにしてるぞ。
お前が言ってるのは単なる汚いコードだ。

違うというのなら、その汚くない独創的なコードの
例を出してみろよ。出せないだろう？
それが答えだよ。
0197デフォルトの名無しさん2014/01/18(土) 01:29:37.61
>>193-194
AmazonやGoogleで使ってるプログラムの、コードの各ブロックに独創性があると思いますか？
100万円かけろと言われれば、「ありません」の方にかけます

AmazonやGoogleの独創性は、コーディングよりももっと上のシステムで議論するときに発揮されています
0198デフォルトの名無しさん2014/01/18(土) 01:33:56.91
>>196
もっとはっきりと「あなたが低いIQでしぼりだした独創的なコード＝世界のプログラマが定番にしなかった汚いコード」 と言えばおわかりいただけるでしょうか…
0199デフォルトの名無しさん2014/01/18(土) 01:38:00.20
c++の式テンプレート使ってるublasなんて独創的で綺麗だけど読めない
0200デフォルトの名無しさん2014/01/18(土) 01:39:14.33
>>197
さっき書いたでしょ？

コードは独創的な部分とそうではない部分に分かれるって。

一連のコードを二つに分けるんだよ。
独創的な部分（ライブラリだったりフレームワークだったり）を頑張って作り、
そして、つまらない単調なコードをどんどん減らしていく。

AWSのおかげでつまらない単調なサーバーメンテナンスから解放されて
より高度なサーバー管理システムと呼べるようなことができるようになったよ。

これが改善なんだよ。単に流れ作業をしている人にはできないこと。
0201デフォルトの名無しさん2014/01/18(土) 01:39:15.43
おまえらはboostコミュニティの書いた生成物を読むべき
わたしはCやJava、PHPをつかう。
0202デフォルトの名無しさん2014/01/18(土) 01:40:05.91
>>199
技術力が低い人が読めないのは
単に技術力が低いだけだから・・・。
0203デフォルトの名無しさん2014/01/18(土) 01:41:51.66
独創性や技術力があっても金になるとは限らない
むしろ、人類の共有文化にすべきといった価値観が広まっている
0204デフォルトの名無しさん2014/01/18(土) 01:44:14.97
> 独創性や技術力があっても金になるとは限らない
それは当たり前だろｗ

高い技術を持っているはずの技術研究機関が
儲かる商売だと思っている人はいないよ。
0205デフォルトの名無しさん2014/01/18(土) 01:49:50.14
結局のところ、技術力が高かろうが低かろうが商売になる
金にならないのは技術者以外の誰かがボンクラなのだ
0206デフォルトの名無しさん2014/01/18(土) 01:59:24.31
Web脳の奴って、本当にアホで
サーバーの自動化とフレームワークぐらいしか想像力が働かない
そういう連中が宣う技術力とは何なのか。ただの雑用ではないのか。
PHPで、歯でも磨いてろよ
0207デフォルトの名無しさん2014/01/18(土) 02:09:43.68
>>206
別に俺は他のものも思いつくけど、

実はお前が思いつかないから、
それだけしか言えないんじゃないの？

サーバーの自動化とフレームワーク以外の物を
言ってみなよ。
0208デフォルトの名無しさん2014/01/18(土) 02:40:36.53
>>207
そんなものいくらでも思い付くが、だからどうした
Web脳のアホ連中が新しいフレームワークと
サーバーの自動化を追い続けること技術力だとか
アホの子みたいに繰り返している事実が変わるの？
0209デフォルトの名無しさん2014/01/18(土) 02:42:06.49
いや、お前がそういうことにしたいってだけだろう？
0210デフォルトの名無しさん2014/01/18(土) 02:44:58.90
なら、おまえは反例をあげろ
0211デフォルトの名無しさん2014/01/18(土) 02:55:08.72
いや、その前に、お前が質問に答えろよ。

そもそも、なにかいいたいのなら
最初に証明するのはそっちの仕事だし。

いいよ別に答えなくて。
どうせ会話する価値の無い人間だってわかってるから。
0212デフォルトの名無しさん2014/01/18(土) 02:57:53.01
>>211
会話する価値がないならなんでレスしてたの？おまえ、バカだろ
0213デフォルトの名無しさん2014/01/18(土) 03:00:23.24
暇つぶしだけど？
0214デフォルトの名無しさん2014/01/18(土) 03:01:12.60
つまり暇つぶしの相手としての価値は
あるってことじゃないですかー
0215デフォルトの名無しさん2014/01/18(土) 03:01:24.01
>>213
自分の価値のなさを認めて、死ね
0216デフォルトの名無しさん2014/01/18(土) 03:02:28.69
未だにWeb脳とか言って引きこもってる奴いるんだな
よく生きてられんねｗ
0217デフォルトの名無しさん2014/01/18(土) 03:04:18.16
あれだろ？ 自分はまだましなんだみたいな。
0218デフォルトの名無しさん2014/01/18(土) 03:06:23.67
何？今のトレンドって、鍬持って畑耕すこと？
0219デフォルトの名無しさん2014/01/18(土) 03:10:36.15
ノマドがnodeへ行き農奴になったと
0220デフォルトの名無しさん2014/01/18(土) 03:12:00.39
解説おつ
0221デフォルトの名無しさん2014/01/18(土) 03:17:29.25
すみません。どなたか畑を耕すgemを存じないでしょうか？
0222デフォルトの名無しさん2014/01/18(土) 03:21:01.59
>>221
つ http://www.megahobby.jp/products/item/1129/
0223デフォルトの名無しさん2014/01/18(土) 03:30:39.70
OSSの耕耘機のURL貼って自演しようとしてたんだから邪魔するな厨房
ttp://www.ted.com/talks/marcin_jakubowski.html
こういうのが技術力だアホカスども。
0224デフォルトの名無しさん2014/01/18(土) 09:37:16.88
昔、ブラックSIerの代表NTTとSRAが絡んだプロジェクトに入ったことが
あるのだが...

そこで提示されたC/C++のコーディング規約が、

マクロは使ってはいけない。.......... ハァ？
テンプレートは使ってはいけない。.......... ハァ？
0225デフォルトの名無しさん2014/01/18(土) 09:46:12.85
俺は理由が書いていないルールは禁止
というルールを持っているんだけど、
マクロやテンプレートを使ってはいけないルールには
理由が書いてあった？


なお、理由が書いていないルールは禁止いうルールにも
もちろん理由は書いてある。
0226デフォルトの名無しさん2014/01/18(土) 10:11:53.18
>>225
確か理由は、コードが追いづらい、読みにくいだったかと。(w

ちなみに、NTTによると統計上平均100行に1つのバグがあるので、
コード行数に対してバグレポート数がそれ以下の数だと、コード
レビューやテストが足らんらしい。

足らないのはNTTのエンジニアのスキルだろと思うたYO。
0227デフォルトの名無しさん2014/01/18(土) 10:39:24.94
自動車の自動安全停止装置への反応とかを見てると、
テスト自動化することによって100件中99件の不具合が未然に防止されたとしても、
残り1件が発生したら鬼の首を取ったかのように叩かれるんだろうな。
0228デフォルトの名無しさん2014/01/18(土) 10:39:47.24
マクロ使うな。コードが追いづらくなるから。
→よーし、いっちょやってやるか

テンプレート使うな。コードが追いづらくなるから。
→ハア？やってらんねーよ！

>>226データじゃなくて？
0229デフォルトの名無しさん2014/01/18(土) 10:44:31.79
マクロ使うなテンプレート使うなって、もちろん新規に作るなって意味だよね？
0230デフォルトの名無しさん2014/01/18(土) 10:50:26.25
OSSのハードウェア開発なんてmolphy oneの事が頭に浮かんでくるので、
胡散臭さしか無いなぁ。
0231デフォルトの名無しさん2014/01/18(土) 12:09:19.48
C++ ならマクロは禁止も有りかな
テンプレートも組織によってはメリットよりデメリットの方が大きいし
NTT 系ならあり得る話
0232デフォルトの名無しさん2014/01/18(土) 13:07:44.83
未熟なエンジニアを排除せずきちんと仕事を与えることが出来るすばらしい企業じゃないか
0233デフォルトの名無しさん2014/01/18(土) 13:24:02.00
>>226
漏れは、最初からあまりバグを出さないから、
テストでバグの件数を満たすため、
いつもわざとバグを作っている

これが結構疲れる。しかもこのルールのせいで、
本当にバグが増えるw

ほんまに、くだらんルールだよ
バグの数には、個人差があるのに
0234デフォルトの名無しさん2014/01/18(土) 13:34:28.96
>>233
もともとQAの元になる数字は公式的に導き出した数字じゃなくて統計的に出た
数字っていうのを知らない、理解できないって人が多いのが第一の不幸で、
そもそも統計って何？的な文系の人間が大量にいるのが第二の不幸だよな。
統計的に出た数字は絶対的な指標になんてなりえないのに。
0235デフォルトの名無しさん2014/01/18(土) 13:46:11.68
まね〜じゃ〜などという中途半端な役職を作ったもんだから
それが仕事してるフリをするために必要なんだよ
0236デフォルトの名無しさん2014/01/18(土) 15:56:18.31
全体レビュー会でバグ収束曲線についてしたり顔で語ってた役員
いまどこでどうしてるかなあ
0237デフォルトの名無しさん2014/01/18(土) 16:21:14.03
動的言語だとメソッド名変更ですら
手作業でやる必要があるから
ユニットテストは必要

静的言語なら不要
0238デフォルトの名無しさん2014/01/18(土) 18:06:30.65
boostは危険だよなー。
0239デフォルトの名無しさん2014/01/18(土) 18:27:35.71
同僚が無能だと感じるのは心が弱いから
コーディング規約が無意味だと感じるのも心が弱いから
単体テストが不要だと感じるのも心が弱いから
boostが危険なのはboostに心を許した己の心の弱さから。
結局、すべては心の問題。
ttp://wired.jp/2013/12/29/enlightenment-engineers-vol9/4/
0240デフォルトの名無しさん2014/01/18(土) 18:32:22.96
テストは心の弱い人がすることですよ。

テストを通したから大丈夫なんだって安心したいだけなんですよ。
無意味だって事は判っているんですホントは。
心の弱さなんですよね。
0241デフォルトの名無しさん2014/01/18(土) 18:54:11.88
同僚が無能だと感じるのは心が弱いから .......... 単体テストが実行されていません
コーディング規約が無意味だと感じるのも心が弱いから .......... 単体テストが実行されていません
単体テストが不要だと感じるのも心が弱いから .......... 単体テストが実行されていません
boostが危険なのはboostに心を許した己の心の弱さから。 .......... 単体テストが実行されていません
結局、すべては心の問題。 .......... 単体テストが実行されていません

まず、テストコードを書いてください。
0242デフォルトの名無しさん2014/01/18(土) 19:02:20.68
強い心があればテストなんて必要ない。
0243デフォルトの名無しさん2014/01/18(土) 20:27:44.98
強い心で仕様だと言い張ればバグではない
0244デフォルトの名無しさん2014/01/18(土) 21:29:08.62
顧客を打ち負かす勇気！
0245デフォルトの名無しさん2014/01/18(土) 21:36:02.90
私が神です
0246デフォルトの名無しさん2014/01/18(土) 21:41:44.09
発注したことを誤りと認め悔い改めよ
0247デフォルトの名無しさん2014/01/18(土) 21:50:05.02
食いあらためよ。
0248デフォルトの名無しさん2014/01/18(土) 21:56:20.80
神は全てのバグを許されるでしょう
0249デフォルトの名無しさん2014/01/18(土) 22:02:32.96
髪はどこへ行った？
0250デフォルトの名無しさん2014/01/18(土) 22:06:59.92
髪は全てのハゲを見放すでしょう
0251デフォルトの名無しさん2014/01/18(土) 22:15:01.67
強い心で仕様だと言い張ればハゲではない
0252デフォルトの名無しさん2014/01/18(土) 22:16:05.89
全体レビュー会でハゲ収束曲線についてしたり顔で語ってた役員
いまどこでどうしてるかなあ
0253デフォルトの名無しさん2014/01/18(土) 22:16:42.93
漏れは、最初からあまりハゲを出さないから、
テストでハゲの件数を満たすため、
いつもわざとハゲを作っている

これが結構疲れる。しかもこのルールのせいで、
本当にハゲが増えるw

ほんまに、くだらんルールだよ
ハゲの数には、個人差があるのに
0254デフォルトの名無しさん2014/01/18(土) 22:36:33.08
俺も一球入魂すればバグゼロなんだけど、バグを修正するミッションのために
わざとバグを混入させている。
0255デフォルトの名無しさん2014/01/18(土) 22:38:10.65
毛根だな？ 毛根って言わせたいんだな？
0256デフォルトの名無しさん2014/01/18(土) 22:41:18.41
毛根でイイヨもう。
一級毛根！
0257デフォルトの名無しさん2014/01/18(土) 23:20:53.20
ム板のバグが吸い寄せられるスレ
0258デフォルトの名無しさん2014/01/18(土) 23:39:12.89
虫は苦手
0259デフォルトの名無しさん2014/01/18(土) 23:49:34.85
吸い寄せられたんだ？
0260デフォルトの名無しさん2014/01/21(火) 07:38:46.54
なんだこのくだらない流れは
0261デフォルトの名無しさん2014/01/21(火) 07:57:08.84
USUGE MAN
0262デフォルトの名無しさん2014/01/26(日) 12:30:23.35
テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。
0263デフォルトの名無しさん2014/01/26(日) 12:54:01.67
OSSの場合、テスト駆動のテストって公開するものなの？
開発者の手元には残ってるかもしれないけど、破棄する（コミットしない）もんだと思ってた
0264デフォルトの名無しさん2014/01/26(日) 13:00:10.34
>>262
テスト駆動開発とテストコードを書くっていうのは別の事象ってことをまだ理解してないのか(´・ω・｀)
0265デフォルトの名無しさん2014/01/26(日) 14:20:25.89
>>262
きちんと統制が取れてても、意図しないデグレートは起こるし、
デグレを検知するためのテストコードは有用。
0266デフォルトの名無しさん2014/01/26(日) 14:33:48.78
テスト駆動開発って通常の何倍もコードを書くことになるけど
そのコストはどこで圧縮されるわけ？
0267デフォルトの名無しさん2014/01/26(日) 14:39:04.41
そもそもデグレートって何だよ、ドイツ人か
自演か？
0268デフォルトの名無しさん2014/01/26(日) 15:04:07.92
>>266
そもそもコードを「書く」コストは少ないんだよ。

たいていは、コードの設計を考えるとか、
コードをテストするとかコードを読むとか、
コードを実行して確認するとか、そういった所にコストが掛かってる。

だってコードを書く＝タイピングスピードでしょ？
考える時間を除いたタイピング速度を5文字/秒として
1時間で18,000文字だよ。
0269デフォルトの名無しさん2014/01/26(日) 15:07:41.40
degradieren!
0270デフォルトの名無しさん2014/01/26(日) 15:15:40.61
>>266
コーディングとテストにかかるコスト。
0271デフォルトの名無しさん2014/01/26(日) 18:13:29.18
バグの多くは、設計で生じる
TDDでは、設計してすぐ直すから、
覚えている間に修正するので、速いし正確

ウォーターフォールだと、
かなり前にさかのぼるから、大変

ペアプログラミングでも、なぜ低コストなのか、
わからない人が多いが、
製品のライフサイクルなど、長い期間でみると、
リコールが少なくて、客離れが起きないなど、
長期視点、トータルコスト、省エネが重要
0272デフォルトの名無しさん2014/01/26(日) 21:09:01.54
もうちょっと実証的に書いてくれ。
またはそういう結果が示されているソースを。
0273デフォルトの名無しさん2014/01/26(日) 21:14:39.38
パッケージで販売する製品にはあまり向いてない気がするが
02742712014/01/26(日) 23:41:50.42
バグが起きる段階
設計、57-78%
仕様、3-14%
以下、言語(コーディング)、要求は、
それぞれ数%程度

NASAのソフトについて、1985年のD.M. Weissの論文
ttp://www.computer.org/csdl/trans/ts/1985/02/01701983-abs.html
0275デフォルトの名無しさん2014/01/26(日) 23:56:36.18
UIとDBのテストがやっぱりめんどくさいんだよねぇ。
テスト自動化する上での鬼門ですが、業務系プログラムだとこの2つが核になるからなぁ
0276デフォルトの名無しさん2014/01/27(月) 12:55:48.16
>>275
それTDD関係ないし
0277デフォルトの名無しさん2014/01/27(月) 13:40:02.31
DBのテストのどこがめんどくさいのかわからん
0278デフォルトの名無しさん2014/01/27(月) 17:06:54.88
非同期でアクセスするところじゃないの
0279デフォルトの名無しさん2014/01/27(月) 18:08:06.88
ん？アクセスする本体部分は非同期じゃないでしょ
0280デフォルトの名無しさん2014/01/27(月) 22:59:33.58
DBMSそのものをテストしようとしてるんだろうなｗ
0281デフォルトの名無しさん2014/01/28(火) 00:01:40.63
>>277
稼働中でもきちんと動くことを確認したいんだけど、DBMSが実用稼働中は、例えば、
select * from table;
という単純なクエリですら、結果が変わり続けてるから
0282デフォルトの名無しさん2014/01/28(火) 00:46:33.57
データ足りてるかどうかのテストからするのかしら
回帰テストの自動化うまくいった？
0283デフォルトの名無しさん2014/01/28(火) 00:55:34.88
テーブルが壊れたときの動作も確認しなくちゃいけないし
DBMSが落ちてるときの動作も確認しなくちゃいけないし
リザルトセットが大きくてレスポンスが遅いときに一貫性が壊れないことも確認しなくちゃいけないし

場合によっては、複数のDMBSで同じ動作をすることを確認させられる
0284デフォルトの名無しさん2014/01/28(火) 07:21:50.73
それＴＤＤじゃないと言い張るだけで、
何がＴＤＤすら説明がないスレだからな
このスレのテストケースはどこだよ
0285デフォルトの名無しさん2014/01/28(火) 09:39:31.03
UI、DBテストが面倒になるのは設計・実装のせい
ほら、TDD必要でしょ？
0286デフォルトの名無しさん2014/01/28(火) 11:08:14.32
>>281
TDD（あるいは単体テスト）用に本番と同じスキーマのデータベースを用意すればいいじゃん。

>>285
できるとこだけTDDでやれば？
0287デフォルトの名無しさん2014/01/28(火) 12:44:51.12
データ件数や統計情報の有無によって、フルスキャンになって遅くなったりもするしね。
後、テスト環境といいつつ、複数の開発者が共用しなきゃいけなくって、
他のプログラマが勝手に値を書き換えて正しくテストができなかったり。
0288デフォルトの名無しさん2014/01/28(火) 13:46:50.11
>>287
> データ件数や統計情報の有無によって、フルスキャンになって遅くなったりもするしね。
そういうのはTDDの範囲外

> 後、テスト環境といいつつ、複数の開発者が共用しなきゃいけなくって、
> 他のプログラマが勝手に値を書き換えて正しくテストができなかったり。
commitすんなよ
0289デフォルトの名無しさん2014/01/28(火) 13:49:34.39
あと、ローカルでもVMでもいいから、自分用にDB立ち上げればいいじゃん
0290デフォルトの名無しさん2014/01/28(火) 20:24:10.87
分散処理はTDDが難しいのではなく、テストそのものが難しい
TDDとは別の次元の話
0291デフォルトの名無しさん2014/01/28(火) 22:57:30.02
>>281
それで何をテストすんの？
DBMSがその部分の機能は担保してるんじゃねーの？
0292デフォルトの名無しさん2014/01/28(火) 23:32:43.68
TDD関係ないじゃん
0293デフォルトの名無しさん2014/01/29(水) 01:22:00.06
>>291
DBMSは結果をこっちに返すだけやぞ
0294デフォルトの名無しさん2014/01/29(水) 05:12:26.48
>>281
実用稼働中のシステムに対してテスト実施するバカはいないだろ。

> select * from table;
> という単純なクエリですら、結果が変わり続けてるから
結果が予想できるDBを作って検証すればいい。
0295デフォルトの名無しさん2014/01/29(水) 23:04:01.38
>>294
テスト用のミラーサーバでもいいけど、普通は、実用稼働中と同じ頻度で更新するDBMSに対して動作確認するんだけど
0296デフォルトの名無しさん2014/01/29(水) 23:11:27.48
「普通は」
0297デフォルトの名無しさん2014/01/29(水) 23:24:46.21
稼働状態を反映していないDBで何をテストするの
0298デフォルトの名無しさん2014/01/29(水) 23:37:33.69
トランザクションがなければ、本番稼働中のヤツ相手でもどんどんテストするけどね
0299デフォルトの名無しさん2014/01/29(水) 23:39:34.37
>>295
稼働中と同じ頻度で更新される、
全く別のテストデータベースを用意すればいいだけの話
実データ、実サーバーでテストする奴はアホ。
0300デフォルトの名無しさん2014/01/29(水) 23:43:51.72
>>299
だから、稼働中でもきちんと動くことを確認するんだよね？
0301デフォルトの名無しさん2014/01/30(木) 00:14:42.38
>>298
そのサーバーにセカンドサーバと名付けよう
0302デフォルトの名無しさん2014/01/30(木) 01:13:52.27
>>297
OSのテストはしないのに、DBMSのてすとはするのか。
0303デフォルトの名無しさん2014/01/30(木) 01:57:28.69
DBMSそのものをテストする意味がわからん
SQLのテストしろよ
0304デフォルトの名無しさん2014/01/30(木) 02:54:21.75
>>303
DBMSそのものをテストじゃない
DBMSに一切の不具合がなくても、かえってくるリザルトセットのサイズでパフォーマンスやらメモリ関係やらの挙動がまったく異なるのがデータベース関係のプログラムなんだから
0305デフォルトの名無しさん2014/01/30(木) 03:12:27.98
>>304
毎日負荷テストしてまだ大丈夫まだ大丈夫なんてやってるのかよ
実機の負荷とクエリ見てスケールさせるスケジュール立てろ
0306デフォルトの名無しさん2014/01/30(木) 04:09:42.09
>>304
お好みのリザルトセット返すテスト用DBつくれば？
0307デフォルトの名無しさん2014/01/30(木) 09:48:34.21
想定される挙動は運用前にテストしておこうよ。。。
0308デフォルトの名無しさん2014/01/30(木) 10:02:12.29
>>304
いつまでTDDと関係ない話続ける気？
いい加減に気づけよ。
0309デフォルトの名無しさん2014/01/30(木) 10:05:09.93
>>308が一番ウザい 職場でも原理厨馬鹿だと思われてるだろ
0310デフォルトの名無しさん2014/01/30(木) 10:33:57.27
>>309
お前が一番うざいわ
0311デフォルトの名無しさん2014/01/30(木) 10:43:07.85
>>309
「TDDが流行らなかった理由」じゃなくても、TDDに関連した話題なら文句言わないよ。
いつまでもTDDにすら関係ない話を続けるからコメントしたまで。

TDD自体の話をしたいのなら、こっちのスレがある。
【TDD】テスト駆動開発【TestFirst】
http://toro.2ch.net/test/read.cgi/tech/1284899172/

テスト困難に関する話題はこっちね。
テストしにくいコードをテストする方法教えて下さい
http://toro.2ch.net/test/read.cgi/tech/1334408391/
0312デフォルトの名無しさん2014/01/30(木) 13:07:11.02
ここまでの流れは意外と核心なのでは？
>>308は自分の中だけで結論が出ちゃってるんだろうけど
0313デフォルトの名無しさん2014/01/30(木) 13:24:04.13
>>312
何の核心？
0314デフォルトの名無しさん2014/01/30(木) 13:33:58.57
>>312
お前TDDが何なのかわかってないだろ？
0315デフォルトの名無しさん2014/01/30(木) 15:21:29.23
>>312
ソフトウェアテストを基礎から勉強しなおしたら？
0316デフォルトの名無しさん2014/01/30(木) 21:04:45.03
>>312
運用が開発の核心だって？
0317デフォルトの名無しさん2014/01/30(木) 22:42:29.97
>>305
DBだから分かりにくいか

yahooから株価の情報取ってくるアプリなら、テストでもyahooにアクセスするでしょ
0318デフォルトの名無しさん2014/01/30(木) 23:04:44.70
>>317
小出し後出しで説明しなきゃならんなら最初から黙ってろ
0319デフォルトの名無しさん2014/01/30(木) 23:10:52.45
>>318
小出し後出しで説明してあげないと理解できないんだから、はじめから「分かりません」と言え
0320デフォルトの名無しさん2014/01/30(木) 23:45:10.95
これだけ袋叩きにされてもまだ自分を疑わないキチガイがテストとは笑えない冗談だ
0321デフォルトの名無しさん2014/01/30(木) 23:53:52.99
自己紹介乙
0322デフォルトの名無しさん2014/01/30(木) 23:55:54.41
運用駆動開発
0323デフォルトの名無しさん2014/01/31(金) 00:01:49.27
DBテストがTDDの核心だと信じてるおバカさんの話はお腹いっぱいです
0324デフォルトの名無しさん2014/01/31(金) 00:14:54.90
>>323
逆
DBはテストが必要だけど、TDDには向いてないと言ってるのに、その理由を全然理解しないから延々と説明してるのだが

分散処理は、コーディング前にテストを構築しようとすると、特別なツールとシステムを導入しないといけないので、TDDには向いていないと何度言ったら分かるんだよ…
0325デフォルトの名無しさん2014/01/31(金) 00:29:49.65
脳のテストが必要な奴に説明するだけ無駄でしょ
0326デフォルトの名無しさん2014/01/31(金) 01:44:36.46
つまり、OracleにSQL投げて負荷テストしてから仕様書書こうぜってことだな？
0327デフォルトの名無しさん2014/01/31(金) 03:34:06.26
>>326
テストしたいのは負荷じゃなくて、コネクション使いまわすときのメモリまわりなんだよね
javaとかならそんなことないけど、受け取るリザルトセットを双方向リンクで表現するタイプだと、動いてるプログラムを修正するのが怖い
0328デフォルトの名無しさん2014/01/31(金) 09:26:34.92
>>326
だな。
脳内でもいいから、まず負荷テストをしてから仕様書書いてね
0329デフォルトの名無しさん2014/01/31(金) 11:44:21.67
>>327
> 動いてるプログラムを修正するのが怖い

という不安を解消するのも、TDDの目的の一つなのだが
0330デフォルトの名無しさん2014/01/31(金) 13:48:21.50
>>317
> yahooから株価の情報取ってくるアプリなら、テストでもyahooにアクセスするでしょ
コード全体で見れば、実際にYahooにアクセスする部分は1%かそこらだろ。
0331デフォルトの名無しさん2014/01/31(金) 17:33:52.62
開発環境の複雑さとTDDは全く違うテーマなのになぜ混同するのか
0332デフォルトの名無しさん2014/01/31(金) 17:49:43.42
開発環境が複雑だからTDDは使えないって言いたいんだと思うよ
0333デフォルトの名無しさん2014/01/31(金) 18:11:59.08
ならスレタイにあってるじゃないか
0334デフォルトの名無しさん2014/01/31(金) 18:31:32.97
TDDというか、自動テストというか、もっといえばテストそのものの知識が欠けてる発言多い
0335デフォルトの名無しさん2014/01/31(金) 21:32:05.59
DBに項目出し入れするだけのバッチプログラムや、
外部APIを叩くだけのツール等でTDDを実践するのは無謀ですかね
0336デフォルトの名無しさん2014/01/31(金) 23:39:45.90
>>331
プロジェクトでは最終的にはテストを作る
そのテストを作る順番を変えて「特別な教育とツールとシステムの導入なしに」再利用できる形で記述するのがTDD

ツールそろえるコストと教育する労力もかけていいなら、TDDに固執する必要はない

だから開発環境の複雑さこそがTDDの議論の中心になる
0337デフォルトの名無しさん2014/01/31(金) 23:49:09.51
どうせ、最後に動作確認をするんなら、少し手間を掛けて、
最初に xUnit を書いておいたらどうですか？
プログラムを起動して、処理結果を確認する Shell プログラムでも可

とにかく、
1. どうなったら完成と「見なす」のかをプログラムを始める前に決める
2. 1 を自動的に判別する仕組みを作る
事が重要。

プログラムの開発をしながら、2 の「テスト」を何度も動かすことで、
その都度、どこまで完成に近づいていて、直近どんな機能を実現
しなければいけないのかが明確になる。
「テスト」によって「開発」を「駆動」するのが、「テスト・駆動・開発」
それ以上でも以下でもない。
0338デフォルトの名無しさん2014/01/31(金) 23:57:27.02
> 1. どうなったら完成と「見なす」のかをプログラムを始める前に決める

それができるのは、関数ぐらいだよ。
関数ではなく単なる処理の場合、
どうなったら完成になるかは最初にわからない。

具体的に言うとだね。たとえばブログシステムはどうなったら完成？
いくつかの機能はあってもなくてもいい。

機能はあってもそれが使いやすかどうかは別問題。
実際に作ってみなければ問題点はわからない。
だから仕様変更は当然のように起きる

関数は仕様を満たせば完成だろうが、
システムにおいては完成というものがないんだよ。
0339デフォルトの名無しさん2014/02/01(土) 00:14:49.22
>>337-338
完成形は分かってなくても、今からエディタに向かって自分が何を書きたいのかと、それの動作をどう確認するかは、は書く前に分かってないといけない

例外は分散処理
分散処理は、そもそも動作確認手法が確立してないから
03403372014/02/01(土) 00:15:50.73
337 は、>>335 への返信です。
----
複雑なテストの話ですが、冪等性（何度やっても必ず同じ結果になる）
のないような事象については、別途考えればいいんじゃないですか？

たとえば、最終的に高負荷での安定性が必要な DB 処理でも、
最初は、1多重で一貫した処理ができることを目的に作って問題ない。

[1多重で一貫して動く] ∈ [高負荷でも安定して動く]
なので、[高負荷でも安定して動く] を頂上とすれば、
[1多重で一貫して動く] はそれにアタックするためのベースキャンプになる。
0341デフォルトの名無しさん2014/02/01(土) 00:29:19.50
今、安定して動いてるDBMSから人名を取得するだけの関数
関数の中のselect文のwhere節の「住所="愛知"」を「住所="愛知県"」に変更する

こんな簡単な修正ですら、きちっとした関数のテスト手法が確立していないという
0342デフォルトの名無しさん2014/02/01(土) 10:29:19.57
>>341
普通はその部分はプリペアドSQLを使って変数になるからテストなんて
いらないんだけどな。 それとも変数部分を含めてSQL文をプログラムで
作っちゃてる低能なのかな。
0343デフォルトの名無しさん2014/02/01(土) 10:42:27.40
もう、SQLなんて、当然ハードコーディングね
0344デフォルトの名無しさん2014/02/01(土) 10:52:11.78
>>339
> 完成形は分かってなくても、今からエディタに向かって自分が何を書きたいのかと、それの動作をどう確認するかは、は書く前に分かってないといけない

それじゃ時間かかるだろ？

完成形がわからないシステムがあったとして、
それを構成する個々の関数。

個々の関数を全部仕上げてないと、システムは作れないが
システム全体を見ないと、どういう関数が必要になるかわからない。

だけどシステムは完成形ではないから、個々の関数を5割ぐらいの実装で終わらせて
システム全体を作る。バグはあるがシステム全体がうっすらと形ができて
ようやく必要な関数がわかるんだ。

そこでやっと、どんなテストが必要かもわかるんだよ。
そんな仕様であるか以前に、必要かどうかもわからない関数の
テストなんか作っていたら時間がかかりすぎる。
0345デフォルトの名無しさん2014/02/01(土) 14:38:57.89
>テストコードが書きづらい部分（GUIやウェブUI等）
に対して統一的なルールを示さないことから割れ窓ックに崩壊していくのではないか

・スタブを必ず用意しろ
・何が何でもテストを書け
・テストを書かない場合は関数ごとに申請書もしくは専用のテンプレートを使え
0346デフォルトの名無しさん2014/02/01(土) 17:53:56.54
>>345
>>345
>>345

guiの職務経験ないんだろうなあ
03473372014/02/01(土) 18:39:18.76
>>344
>完成形がわからないシステムがあったとして、

そういうカウボーイコーディングは、もうやめようよ
何人も死人が出てるんだし。

ただ、どうしてもやりたければ、好きにしたらいいん
じゃないですか。関わりあうのは御免被りたいけど...
03483372014/02/01(土) 18:49:32.39
>>345
UIの自動テストは現状では難しいですな。フリーの
Selenium や似たような商用テストスイートをいくつか
試したけど、自動テストの作成コストは高過ぎる。

ウチでは、GUI の自動テストは、早々に諦めました。
そこで、まず、設計段階で
(人手でテストする必要のある = テストのコストが高い) GUI 層を薄く、
(自動テスト可能な = テストのコストが安い) 業務処理層を厚くしてます。

その上で、業務処理層は C0 カバレッジ 90% 以上必須にしてます .
0349デフォルトの名無しさん2014/02/01(土) 18:57:34.61
>>347
何を批判しているのかわからん。

たとえばGoogleのサービス。
あれは完成形だと思ってるのか？

完成なんてものはない。
常に変化していくものだ。
0350デフォルトの名無しさん2014/02/01(土) 19:22:19.35
完成形に対するイメージがずれてないか。
347は「こうなったらリリース」という形を完成形と呼んでいる
気がするが、349にはそれすらないのか？
ないとしたら好きにしてくださいとしかいいようがないが・・。
0351デフォルトの名無しさん2014/02/01(土) 19:30:52.05
>>349
例えが悪い。仕様変更と更新を混同するな。

自分らが触れないコードの完成形が分からない
ってことはよくあるけどな。
0352デフォルトの名無しさん2014/02/01(土) 19:51:08.93
>>344
それは日曜プログラマさんがやってください

仕事でチームでやるときにそんなやり方やられても困る
0353デフォルトの名無しさん2014/02/01(土) 19:53:35.82
>>349
Googleの下請けのプログラマなら、今から自分がエディタに向かって、どこをどう変更したいかは、キーボードをたたく前に分かってる

そのことと、今のGoogleのサービスが完成形かどうかは関係ない
0354デフォルトの名無しさん2014/02/01(土) 20:20:19.47
なんか条件が合ってないっぽいな

誰かから何かミッションを受けてやってる仕事なの？
それともどういう機能を付けるかの選択を含やら設計なんかを自分で決めていく仕事なの？
0355デフォルトの名無しさん2014/02/01(土) 20:50:22.10
もしかして、例えば数値計算のプログラム作るときには、キーボード叩きながら、ここはプラスにしようかマイナスにしようか考えてるってこと？
0356デフォルトの名無しさん2014/02/01(土) 22:15:10.17
数値計算のプログラムの場合は引数の与え方が考えどころだろうな。
0357デフォルトの名無しさん2014/02/01(土) 22:35:37.58
それキーボード叩きながら考えるとこ？
0358デフォルトの名無しさん2014/02/01(土) 22:53:39.20
TDDなら考えながらコード書いても大丈夫！
0359デフォルトの名無しさん2014/02/01(土) 22:54:36.75
>>353
Googleのことは全然知らんが、どこをどう変更すべきかキーボードをたたく前に分かるなんて、理想論過ぎるだろ。
そんなことはあまりないと思う。
機能追加とか変更とかは妥協の産物だからだ。
やりたいことは明確でも、「大幅な変更なく、なるべく複雑にせず」とか考えれば、コードを見ながら手を動かすしかない。
0360デフォルトの名無しさん2014/02/01(土) 22:58:06.10
>>359
おいおい
下請けのプログラマがキーボード叩きながらGoogleの仕様を変更するわけないでしょ

機能なんて大きなレベルのモノを決める決定権はプログラマにはない
0361デフォルトの名無しさん2014/02/01(土) 23:08:29.18
>>360
だから条件が合ってないって言ってるだろ？
ここでの話題は「Googleの仕事」とも「下請けのプログラマ」とも決まってないよな？
機能を決めるのも自分の仕事なのか、言われたことをやるのが仕事なのか。
それをはっきりさせずにどう議論すんだよ。
前者なら書いては消し、書いては消しの連続だよ。
0362デフォルトの名無しさん2014/02/01(土) 23:13:25.35
>>361
自分ひとりで完結する日曜プログラマなら、テストをするしないも自由で、そもそも開発プロセスにこだわる必要はないので別のスレに行くべきかと…
0363デフォルトの名無しさん2014/02/01(土) 23:18:24.87
>>362
おまえの脳内では
仕様を決めるプログラマ　＝　趣味でやってる日曜プログラマ
みたいだけど、そういう解釈でよろしいか？
0364デフォルトの名無しさん2014/02/01(土) 23:21:20.80
>>363
キーボードでコードを叩きながらシステムの仕様を決めるプログラマは、趣味でやってる日曜プログラマです
0365デフォルトの名無しさん2014/02/01(土) 23:23:16.94
>>364
おまえ受託側のプログラマだろ？
委託する方の世界は全く知らないと見えるな。
0366デフォルトの名無しさん2014/02/01(土) 23:25:01.34
場所にもよるけど新規環境だったらプロトタイピングで設計のほうが捗るけどな。コンパイル時間かかるなら別だが
0367デフォルトの名無しさん2014/02/01(土) 23:37:49.73
>>366
それはテスト作らなくてもいいコードだから、コーディングとは別の話じゃないの
パワーポイントの資料と同じカテゴリのモノでしょ？
0368デフォルトの名無しさん2014/02/01(土) 23:47:06.32
>>364
ユーザー向けAPIの説明に、「このクラスはスレッドセーフです」と書けるかどうか、いろいろ試行錯誤しないとわからないわけよ。
結果的に「別スレッドで使用する場合はこの部分をロックしてください。」となるかもしれない。
「この部分」てのをなるべく狭くしたいとか、それこをコードを叩きながらじゃないとやれないだろ。
0369デフォルトの名無しさん2014/02/01(土) 23:53:48.88
×それこを
○それこそ
0370デフォルトの名無しさん2014/02/01(土) 23:58:37.54
>>368
いやだから、「この部分を+から*に変更するといいかもしれない」の「この部分」をこれから*に変更する前に、「この部分」の変更で目的を達成するか確認するテストを書けってことなんだが

「いいかもしれない」状態がどういう状態かとか、「+から*に変更しよう」とかが、これからキーボード叩く前に分かってない人は、ちょっと怖いので一人でプログラミングしなさい、と
0371デフォルトの名無しさん2014/02/02(日) 00:05:37.11
どういう状態になればいいか分からなくても、とにかく叩け

それが父の教えです
0372デフォルトの名無しさん2014/02/02(日) 00:10:19.94
>>370
「テストを先に」って技術の話だと思っていたけど、そうじゃなくて心構えの話なのかな？
0373デフォルトの名無しさん2014/02/02(日) 00:13:26.83
>>372
TDDの文脈では心構えの話だと思うけど、
技術の話ってどういうこと？
0374デフォルトの名無しさん2014/02/02(日) 00:18:47.80
>>373
最終的に必要な提出物の数を変化させずに、特別な教育とツールとシステムの導入なしに、バグを少なくするトリック
0375デフォルトの名無しさん2014/02/02(日) 00:33:34.81
>>373
テストを先に書くことによる効果をトータルで評価したいんだよ。
これまでこのスレを見てきて「テストの重要性を理解しろ理解しろ」っていう主張はあるけど、なにを理解しろってんだ？
理解する対象の理論が全然提示されてないんだよ。
技術だったら根拠理論があるんだろう。

条件や環境、効果、必要なアクティビティ。メリットとデメリット。
特に条件について出来る限り厳密に評価したいんだ。
なんにでも当てはまる手法なんて無いと思ってるからね。
0376デフォルトの名無しさん2014/02/02(日) 00:35:11.08
>>368
「このクラスはスレッドセーフです」と仕様書に書いてあるべき
そして、書いてあるならTDDでスレッドセーフをテストするべき

と言うことは
書いてないなら、スレッドセーフではないことをテストするべきか？（笑）
0377デフォルトの名無しさん2014/02/02(日) 00:51:33.21
>>368
仕様としてスレッドセーフにしたいからスレッドセーフに作るのであって
コードがスレッドセーフになっているから仕様として書くわけではない。
「コードが仕様書です」といっているお前のやり方とかみ合わないのは
TDD がある意味では「仕様書を元にコードを書け」ということだから。
0378デフォルトの名無しさん2014/02/02(日) 01:07:26.26
>>348
自動テストが難しい場合、手動テストも難しいよね
「なんとなくテスターがそれらしい事をしたのでOK」が手動テストの正体
自動テストと違って万能に見えるのは、曖昧さを認めてるから
0379デフォルトの名無しさん2014/02/02(日) 01:07:29.12
376
スレッドセーフにできるか無理か判断できるのはプログラマだし、判断結果を仕様書に反映させる「義務」もあるわけだ。
もちろんできるか否かはいろいろな条件に依存するがな。それを勘案しての判断だ。
>>377
スレッドセーフが当初要件だったらそうだけど、潜在要望だったら仕様書が先にあるとは限らないだろ？
0380デフォルトの名無しさん2014/02/02(日) 01:08:30.52
だが現実は、そんなに良く出来た仕様書を書ける人間は少ない
結果、コードとコメントが仕様書になるわけだ
0381デフォルトの名無しさん2014/02/02(日) 01:14:59.69
メーカー子会社SEと、WEB系ITベンチャーPGが会話するとこんな感じになるんだろうなーっていうレスの応酬だね
メーカー系は今はどこも設計ちゃんとしてるでしょ。
0382デフォルトの名無しさん2014/02/02(日) 01:19:07.38
>>381
どっちがどっちなんだ？
0383デフォルトの名無しさん2014/02/02(日) 01:41:46.71
>>370
キーボード叩く前に具体的に何ができるのさ？
「こういうクラスを作って、これを経由すれば解決するかも？こんなインタフェースかな？いやこうかな？」
ってのをいろいろ書いてみることすらしない？？？
もしそれが、「紙に書いた方がいい」とか、「ホワイトボードに書いた方がいい」とかだったら単なるスタイルの違いだし、
テストプログラムの作成が先だっていうんなら、その効用を定量的に示すべき。
0384デフォルトの名無しさん2014/02/02(日) 02:16:14.97
>>375
どの開発プロセスでも最後にはテストを作るんだから、テストの重要性を理解してるのは大前提
TDDは、特別な教育やツールを導入する必要がない限りにおいて、それを先に作れってだけなんだが

テストそのものが重要かどうかは、そもそもTDDとは別のスレで議論すべきじゃないのか？
0385デフォルトの名無しさん2014/02/02(日) 02:19:42.44
ハローワールド書くときに
「何を表示するプログラムかわかんないけどとりあえず書き始めるよ！」
とはならないと思うが、おまえらそういうレベルで仕事してんの？
0386デフォルトの名無しさん2014/02/02(日) 02:23:17.99
>>383
「こういうクラス」の「こういう」はキーボードを叩く前に分かってるんですよね？
だったら、コード修正したら本当に「こういう」になるかどうかの確認コードを先に書けってだけの話なんだが

それすらも分かってないなら、「何の目的もないけどとにかくクラスを作れば、何かを経由して何かが起きるかも」でキーボードを叩いてるんだから、ひきこもってひとりでやってくださいとしか…
0387デフォルトの名無しさん2014/02/02(日) 02:37:06.41
実装方法は何一つ思いつかないけど、中でゴチャゴチャやって最終的に足し算の結果が出るコードを書きたい

なら、まず先に、結果が足し算になったときにTrueになるテストコードを書こう
関数名を変更したいなら、まず先にテストの中の関数名を変更してから、コードの関数名を変更しよう

ただそれだけの話なんだけど
0388デフォルトの名無しさん2014/02/02(日) 02:52:59.72
結局何の話だっけ？
0389デフォルトの名無しさん2014/02/02(日) 05:58:26.31
>>387
足し算なんて簡単な例を使うから
お前は理解できんのだ。

> なら、まず先に、結果が足し算になったときにTrueになるテストコードを書こう
そのテストコードがたくさんある。

> 関数名を変更したいなら、まず先にテストの中の関数名を変更してから、コードの関数名を変更しよう
関数を使っている箇所がたくさんある。

どうだ？ やる気を無くすだろう？
0390デフォルトの名無しさん2014/02/02(日) 08:07:41.67
>>386
＞確認コードを先に書けってだけの話なんだが
>>387
＞ただそれだけの話なんだけど

その主張は散々聞いたよｗ
俺は「先にテストを書いた方が後で書くよりいい」ということの厳密な証明が欲しいって言ってるだけなんだよ。
こんだけ議論があるんだから、ちゃんとしろよ。
0391デフォルトの名無しさん2014/02/02(日) 08:25:32.50
>>386
＞「こういう」はキーボードを叩く前に分かってるんですよね？
わかんねーよｗ

＞「何の目的もないけどとにかく
おまえが言うのは、「用意、撃て！」じゃなくて「用意、狙え、撃て！」にしろって事だろ？
そんな事はわかってるよ。
問題は、狙う ＝　先にテストコードを書く　が常に成り立つかってことだ。
そいつをちゃんと証明しろや。
0392デフォルトの名無しさん2014/02/02(日) 08:50:41.62
>>390が言っていることを分かりやすく説明すると、

「テスト→コーディング」 VS 「コーディング→テスト」

のどちらが良いかってこと。

決してコーディングだけしてテスト書かないとは言ってないのだよ。
0393デフォルトの名無しさん2014/02/02(日) 08:52:46.17
TDDでコーディングより先に書くテストっていうのは
ちゃんとしたテストじゃないんだ。
本番用のテストとして使えるものもあるが、使い捨てのテストも多い。
だから本番用のテストは別にちゃんと書かないといけない。

つまりこういうことなんだ。

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」
0394デフォルトの名無しさん2014/02/02(日) 09:05:59.07
この論争の着地点どこよ
0395デフォルトの名無しさん2014/02/02(日) 09:10:37.96
先にテストを書くことで、本番コードを書く時の心構えが変わる。
TDDは技術とか証明とかそういう高レベルな話じゃないと理解している。
0396デフォルトの名無しさん2014/02/02(日) 09:14:20.15
>>390
元発言者じゃないけど、
TDDの根本は、仕様を自然言語で書くのをやめてテストコードで書こうということだと思う。

実装が先かテストが先かってのは、実装が先か仕様が先かという議論と同じ。
現場だと、仕様がわからないまま実装に突き進むってのもよくあることだが。

TDDでも、開発中に仕様変更が入ればテストを書き直さなきゃいけない。
それは当たり前。仕様＝テストだから。
仕様変更が頻繁に発生すれば、TDDではテストケースの書き直しが頻繁に発生する。
確かに手間。仕様書の変更が頻繁に発生するのと同じこと。

この手間が無駄だからテストを書かないって判断もあると思う。
どうせ仕様変更になるから一々仕様書を改訂せず口頭でいいだろって判断がよくあるのと同じ。
0397デフォルトの名無しさん2014/02/02(日) 09:21:24.77
テストしにくいコードを書いたら自分の首を絞めることになるぞという脅迫
0398デフォルトの名無しさん2014/02/02(日) 09:29:26.89
あと、TDDで書くテストの粒度は案件や立場ごとに違っていいというのが自分の考え。
つまり、まずは、仕様書に書く粒度のことをホワイトボックステストとして書けばいいと思う。

>>387, >>399 あたりの議論については、
詳細設計レベルの下請け関数一つ一つTDDでやるか？という意見の食い違いじゃないかと。
自分は、それはどっちでもいいという立場。
詳細設計書を書く案件なら、それをテストにすればいいし、
そもそも詳細設計書なんて作らずプログラマにざっくり権限委譲するような案件なら
そこをTDDでやるもやらないも各プログラマの自由。

多少複雑な関数なら、詳細設計書がなくてもプログラマが個人メモレベルのチラ裏設計すると思う。
そういうのはTDDにすればいい。逆に、悩むこともなく一瞬で書けるような関数全部TDDでやるのは時間の無駄。
TDDでなくても、そういう簡単な関数は後から単体テスト書くのも無駄だと思うけど。
0399デフォルトの名無しさん2014/02/02(日) 09:35:52.93
仕様書なんて飾りです
うちのテスト舞台に任せてもらえば問題ありません(実話)
0400デフォルトの名無しさん2014/02/02(日) 09:44:10.58
>>395
技術の話じゃなく心構えの話であって、なおかつちゃんとした証明とかが無いにもかかわらず、
「テストファーストしない人間とは関わりたくない」などと発言をする。
こういうのが信者っぽいんだよ。感覚的な結論が先にありきでさ。
0401デフォルトの名無しさん2014/02/02(日) 09:51:21.84
>>400
「○○しない人と関わりたくない」ってのは

○○が新しい技術なら何でもいいってのがミソ。
プログラマの世界だと新しい技術を積極的に取り入れる人は総じて技術レベルも高いから、
○○の良し悪しとは無関係に、○○を使ってみている人は無関心な人より仕事ができる可能性が高い。

試しに○○に古いものを入れてみる。
「コーディング前に詳細設計書も書かない人間とは関わりたくない」

言っていることはテストファーストと似ているはずなのに、なぜかロートル臭がプンプンしてくる不思議。
0402デフォルトの名無しさん2014/02/02(日) 11:10:29.07
最初にちょこっとコードを書いて実行してうまくいったら続きを書くだろ？
それを制度化したのがTDD
0403デフォルトの名無しさん2014/02/02(日) 11:53:49.21
TDDを、

　聞いたこともない人
　無関心な人
　関心ある人／試してみたた人
　　・・・
　この間にいろんな層
　　・・・
　信者
0404デフォルトの名無しさん2014/02/02(日) 12:03:39.76
まあ上２つは仕事できない人のレッテルを貼られてもしかたないね。

俺は証明とかは要らんけど成功事例・失敗事例が出そろってほしい。
ちゃんと社名やプロジェクト名がわかるやつ。
トヨタ生産方式とかいろんな事例があって参考になるよ。
0405デフォルトの名無しさん2014/02/02(日) 12:30:26.89
>>391
＞「用意、撃て！」じゃなくて「用意、狙え、撃て！」にしろ

そのフレーズ、どっかで見たんだけど思い出せない・・・
0406デフォルトの名無しさん2014/02/02(日) 12:36:34.96
これか？
http://mag.executive.itmedia.co.jp/executive/articles/1010/20/news009.html
0407デフォルトの名無しさん2014/02/02(日) 12:41:33.64
>>404
失敗学の学としての失敗というのがあってな
事例では根源を見つけることができないんだよ
0408デフォルトの名無しさん2014/02/02(日) 12:43:44.13
>>406
それだと構え、撃て、狙えになってるな
撃ってから狙ってどうすんだよｗ
0409デフォルトの名無しさん2014/02/02(日) 12:44:18.75
>>408
ようするにまずは行動してあとから考えろってことだろ
0410デフォルトの名無しさん2014/02/02(日) 12:44:25.31
>>406
それ見たら「狙う前に撃て」って書いてあるじゃんｗ
TDDとは逆なような
0411デフォルトの名無しさん2014/02/02(日) 12:45:16.13
>>410
いや、どっかで見た、というのに対してコレかな？っというだけの話。
TDDと関係ない話をしてしまって申し訳ありませんでした
0412デフォルトの名無しさん2014/02/02(日) 14:31:30.74
事前に大量のトレーニングが無ければ弾がどういう軌道で飛ぶかもわからん
まず的に向かって一発撃ってそれから軌道修正
これは正しい

それに対して
TDD：
撃つ前にまず的をセットし、それから的に当たるように撃つ
それ以外の何か：
先に撃ってそれに当たるように的をセットする　←　！？
0413デフォルトの名無しさん2014/02/02(日) 14:37:23.87
>>412
そう考えるとなんか筋が通ってるな
0414デフォルトの名無しさん2014/02/02(日) 14:48:35.81
本番でトレーニングするなって話だよな
0415デフォルトの名無しさん2014/02/02(日) 17:47:37.86
どちらも命中したか確認がないな
0416デフォルトの名無しさん2014/02/02(日) 18:09:58.33
>>405
迷著「アンチパターン」にそんなのがあったような
0417デフォルトの名無しさん2014/02/02(日) 18:13:11.12
>>412
的ってのが文字通り目的を表しているなら、TDDだろうが「それ以外の何か」であろうが先に設定するだろうなあ。
いずれにしてもそんなたとえ話はもうおなかいっぱい。

>>407
理論も事例もないって、そう言ってるの？そう捉えていい？
0418デフォルトの名無しさん2014/02/02(日) 20:18:46.66
>>417
ちがう、技術はパラダイムシフトで変わっていくのに
失敗の解釈と対策はインクリメンタルに貯まる
これはパラダイムシフトは前のやりかたで説明がつくことに由来する
理屈と膏薬はどこへでもつくかのごとく、穿った解釈と実効性のない対策が闊歩するのだよ
だからパラダイムシフトが多い領域では失敗を蓄積するより事前のリスク回避のほうが効果的
エンジンの開発などパラダイムを操作できる立場なら別だけとこのスレに何人いるか
0419デフォルトの名無しさん2014/02/02(日) 22:34:15.06
>>418
話がずれてる。
パラダイムシフト後のTDDの事例を求めている。その集積が必要だと。
0420デフォルトの名無しさん2014/02/02(日) 22:53:40.21
>>409
変更が必要なコードが量産されるのが目に見えている
動く前に脳みそ使えとしか…
0421デフォルトの名無しさん2014/02/02(日) 23:39:21.03
>>407
失敗学の失敗のことなんか関係ないし知らん。
根拠理論と事例を両方とも出せ。技術において当たり前のことだ。
事例で根源を見つけることができないんだったら何によって見つけるのかも示せ。
それもできないんだったらよく言っても「実験」に過ぎない。
悪く言えば何かの宣伝活動だ。
0422デフォルトの名無しさん2014/02/02(日) 23:53:13.92
事例なんて他人が聞く程度にまとまってる資料には
本当の事なんてかかれてない
0423デフォルトの名無しさん2014/02/02(日) 23:55:29.76
じゃあ自分の事例を出せばいいｗ
0424デフォルトの名無しさん2014/02/03(月) 00:04:19.80
>>421
単純な思考実験でも見つかるだろ…
0425デフォルトの名無しさん2014/02/03(月) 00:08:50.97
>>424
実験段階の技術じゃあるまいに、何言ってるんだかｗ
0426デフォルトの名無しさん2014/02/03(月) 00:19:22.54
>>425
そもそも技術じゃなくて、作業の順序を変えるだけのただの心意気の話だし…

逆に技術やツールが必要なら、従来通りの手順を変えてはいけないわけだし
0427デフォルトの名無しさん2014/02/03(月) 00:31:14.41
とりあえずTDDはこうだっていう共通認識がないよな
0428デフォルトの名無しさん2014/02/03(月) 00:41:43.75
今になって「技術の話じゃありません、心意気の話です」なんていうやつがいたらぶん殴ってやれよｗ
0429デフォルトの名無しさん2014/02/03(月) 02:07:15.49
>>428
「指動かす前に脳ミソ使え」「ピーマンは先に食え」は心意気の話でしょ？
0430デフォルトの名無しさん2014/02/03(月) 02:10:22.75
>>427
特別な教育やツールを導入する必要がない限りにおいて、コードを入力する前に、これから入力しようとするコードのテストを先に作成する開発スタイル、あるいはコーディング慣習のこと
0431デフォルトの名無しさん2014/02/03(月) 02:13:03.21
>>428
「技術の話」ってのは具体的に何を指すわけ
0432デフォルトの名無しさん2014/02/03(月) 08:09:50.07
かんたんにいうと、このスレですぐＴＤＤじゃないとか言って話を狭める奴がいるが、ああいうのがパラダイムシフトに取り残されるタイプなんだよな
垂直思考しかできないうえ、コンテキストが理解ができない
ドクターとしては決して食っていけないタイプ
0433デフォルトの名無しさん2014/02/03(月) 15:14:57.86
パラダイムシフトやら垂直思考やらコンテキストやら
仲間内だけでしか通じない単語で煙に巻く人間もいるけどなｗ
0434デフォルトの名無しさん2014/02/03(月) 15:19:50.02
>>375
> テストを先に書くことによる効果をトータルで評価したいんだよ。
> これまでこのスレを見てきて「テストの重要性を理解しろ理解しろ」っていう主張はあるけど、なにを理解しろってんだ？
> 理解する対象の理論が全然提示されてないんだよ。

吐き気がするほどのクレクレ君。
プログラマーに向いてないんじゃないの？
0435デフォルトの名無しさん2014/02/03(月) 19:42:21.59
>>434
ほんとにそうだよな。
無い物ねだりもいいかげんにしろっての。
0436デフォルトの名無しさん2014/02/03(月) 21:27:26.58
あいたた
0437デフォルトの名無しさん2014/02/03(月) 21:46:23.48
>>429
指動かす前に脳ミソ使うってのはやるべきだよな。
やっぱ走りながらよりいったん落ち着いて考える方がいいアイデアが浮かんできやすい。
ピーマンの話はよくわからん。オレはおかずは交互に食う。

で、TDDと何の関係が？
0438デフォルトの名無しさん2014/02/03(月) 21:55:32.20
おかずを交互に食うのは太りやすいよ
0439デフォルトの名無しさん2014/02/03(月) 22:01:29.78
ピーマンは鰹節と醤油
0440デフォルトの名無しさん2014/02/03(月) 23:27:28.49
プログラマーに向いてないんじゃないの？
0441デフォルトの名無しさん2014/02/03(月) 23:48:10.84
極論するが、プログラマがアイデアを出すな
0442デフォルトの名無しさん2014/02/03(月) 23:54:35.33
極論なんだろ？
0443デフォルトの名無しさん2014/02/04(火) 00:02:28.56
大工があなたの家を建てている最中に、金槌で釘を叩きながらひらめいたアイデアを実践してよいだろうか？
答えはNoです

歯医者があなたの前歯を削っている最中に、ドリルの先端を付け替えながらひらめいたアイデアを実践してよいだろうか？
答えはNoです

プログラマは、キーボードを叩きながらひらめいたアイデアをどんどん実戦していきます

世界がつぎはぎだらけで崩壊寸前である理由もご理解いただけるのではないかと
0444デフォルトの名無しさん2014/02/04(火) 00:06:46.38
ソフトウェア開発は製造行為だろうか？それとも文字通り開発だろうか？
0445デフォルトの名無しさん2014/02/04(火) 00:10:34.19
>>443
たとえ話はお腹いっぱいなのです。
下手なコンサルとおんなじなのです。
0446デフォルトの名無しさん2014/02/04(火) 00:13:10.79
>>444
プログラマが叩き込むコードはソフトウェアだろうか？ それともコードよりも上の抽象概念としての設計がソフトウェアだろうか？
0447デフォルトの名無しさん2014/02/04(火) 00:16:43.87
給料のベースアップですべてが解決するんじゃね？
いま流行ってるみたいだし。みたいな。
0448デフォルトの名無しさん2014/02/04(火) 07:02:55.40
>>375
お前は "TDD paper" でぐぐることすらできないのか？
クレクレ君と言われても仕方ないよな

http://stackoverflow.com/questions/540622/looking-for-papers-studies-on-tdd-effectivness
0449デフォルトの名無しさん2014/02/04(火) 18:04:08.46
>>448
paperって紙だろ！
ぐらいの認識でしょ
0450デフォルトの名無しさん2014/02/04(火) 20:56:06.47
TDDの話はなるべくしないでもらえる？
客先でつらい目にあうだけだから
0451デフォルトの名無しさん2014/02/04(火) 21:47:23.16
>>450
なにがあったの？
0452デフォルトの名無しさん2014/02/04(火) 22:09:27.93
議論をふっかけられて・・・負ける
0453デフォルトの名無しさん2014/02/04(火) 22:52:19.41
テストコードを見て
仕様を思い出すか推測する
0454デフォルトの名無しさん2014/02/05(水) 03:08:41.99
テストコードを見て
そのプログラマがどれだけバグを出さないかを推測する
0455デフォルトの名無しさん2014/02/05(水) 14:02:13.38
テストコードを見て仕様を解析する。
そしてテストコードが充分でないことに気づく。
0456デフォルトの名無しさん2014/02/05(水) 14:10:40.04
そのテストコードがあることによって仕様を誤認するレベルでなければよい
0457デフォルトの名無しさん2014/02/05(水) 21:39:24.69
動作を保証するテストと、仕様を決めるテストと全く違うのに
テスト駆動＝先に動作保証する　みたいに思うから、できるわけない
テストファーストしたら、あとでテスト書かなくていいみたいに思ってるやつばかりだし
0458デフォルトの名無しさん2014/02/05(水) 23:06:32.37
はい、つまりこういうことですよね？

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」
0459デフォルトの名無しさん2014/02/06(木) 00:14:02.48
単体や結合のテストなんていらないだろ
動作確認すりゃいいよ
0460デフォルトの名無しさん2014/02/06(木) 00:54:09.39
コード片を書いてエディタを保存した直後に動作確認するんだけど、
その動作確認のテストをコード片よりも先に書けってことだよ

システムのテストも先に書けばいいけど、それはまた別の話
0461デフォルトの名無しさん2014/02/06(木) 10:49:51.95
その動作確認のテストを書けるように関数を区切れってことだよ
0462デフォルトの名無しさん2014/02/06(木) 23:32:39.75
うちのプロジェクトではいまいちな結果になった。
かなり期待外れ。
ケーススタディにはなるのかも。
0463デフォルトの名無しさん2014/02/06(木) 23:59:01.60
プロジェクトで導入するモノか
プログラマ個人の慣習として行うモノか
0464デフォルトの名無しさん2014/02/07(金) 00:43:56.38
頻繁に修正するものならテスト作らないと死んじゃう
サードパーティのソース付きゴミ屑ライブラリとかな
0465デフォルトの名無しさん2014/02/07(金) 01:18:43.29
テスト駆動とテストって別ですよね
0466デフォルトの名無しさん2014/02/07(金) 11:58:18.67
>>460
つまり、目で確認する時間 ＜ コードを書く時間
の場合には役に立たないってこと？
0467デフォルトの名無しさん2014/02/07(金) 12:24:16.77
>>465
バグを見つけるのは早ければ早いほうがいいという説と
テストは最後にするものだという説がある

どちらかを否定しないと、テスト駆動とテストは両方とも必須になる
0468デフォルトの名無しさん2014/02/07(金) 12:34:51.49
なんでこの人達TDDが何なのかを知ろうとしないんだろうか
0469デフォルトの名無しさん2014/02/07(金) 13:03:32.99
他人が定義した用語を使って失敗したらその人を恨むことになるから
自己責任なら人それぞれ自分の言葉でTDDを定義するしかない
0470デフォルトの名無しさん2014/02/07(金) 14:31:36.70
>>462
何を期待してたんだ？
0471デフォルトの名無しさん2014/02/07(金) 18:40:42.51
あっちのスレから転記
「TDD のこころ @ OSH2014」
http://www.slideshare.net/t_wada/osh2014-sprit-of-tdd

心理的なメリットが大きいらしい
0472デフォルトの名無しさん2014/02/07(金) 21:03:47.07
>>467
テストは必須。テスト駆動は習慣
0473デフォルトの名無しさん2014/02/07(金) 21:04:29.26
>>468
ググったけどまともに解説してるところがない
このスレでも簡単にググった結果に満足して書き込んでるだけの奴らばかり
0474デフォルトの名無しさん2014/02/07(金) 21:13:25.37
どうやら技術じゃなくてスタイルらしいからな
0475デフォルトの名無しさん2014/02/07(金) 21:22:13.89
結局、「小さくつくって大きく育てる」っていう思想の一つだな
少しずつ拡張してそのたびにテスト
そりゃテストの回数が多いんだからバグは減るよな
その段階でじっくりバグを潰すのと、後からまとめてバグ探しするのは
どちらが効率いいのかわからんけど
0476デフォルトの名無しさん2014/02/07(金) 23:40:21.84
>>466
目で確認できるという妄想はそろそろ捨てたらどうだ？
0477デフォルトの名無しさん2014/02/08(土) 00:20:07.80
>>475
ウォータフォールモデル自体、手戻りが大きくなるとコストも大きくなるから
不具合は早い段階で発見するように推奨されているんだけどな。ただし、
あっちはバグ曲線なる統計学の悪魔がいるから各工程でバグを出すことを
義務付けられるというジレンマに陥っている。

どっちにしろプログラムにかぎらず不具合や不都合を先送りすると時間辺りの
コストは指数的に増えていくから後回しにしないほうがいい。
0478デフォルトの名無しさん2014/02/08(土) 04:08:04.26
しかし、ルールに従ってタスクを分けて作業に応じた給料を払うことを考えるとウォータフォールモデル以外にないというオチ
0479デフォルトの名無しさん2014/02/08(土) 07:07:08.80
少数精鋭チームならまだしも、無能含めた大所帯チームになるとウォーターフォールで回すしか無くなるらしいね
0480デフォルトの名無しさん2014/02/08(土) 08:49:10.80
TDDはウォーターフォール無能所帯でも適用できるのではないだろうか？
0481デフォルトの名無しさん2014/02/08(土) 08:57:49.27
予算と意思決定、人員配置がウォーターフォールで果たしてTDD的な価値があるだろうか
システムデザインとIF設計でコーディングの義務がないならさっさと机上設計して作業終わらせるぜ。デザインバグはいくらでももみ消せるからな
0482デフォルトの名無しさん2014/02/08(土) 09:19:21.57
大所帯ならテスト作成とコード作成で役割をわけたらいいんじゃね
と思ったが、それはもはやTDDではないな
0483デフォルトの名無しさん2014/02/08(土) 11:01:33.22
テスト駆動って名前が悪い
ただのアサートデバッグじゃん
Cから入ったプログラマなら無意識にやってることだし
0484デフォルトの名無しさん2014/02/08(土) 11:49:25.72
いや全然違うやろ・・・
0485デフォルトの名無しさん2014/02/08(土) 13:00:55.98
>>483は無意識にやっていないということが
見事に証明されたなｗ
0486デフォルトの名無しさん2014/02/08(土) 13:08:44.66
>>483
底辺PG乙
0487デフォルトの名無しさん2014/02/08(土) 13:42:20.69
>>480
TDDをプログラマ個人の慣習としてとらえるなら、どの開発プロセスでも適用可能
特別な教育とツールの導入が必要ない限りにおいて、テストを先に書くわけだから
0488デフォルトの名無しさん2014/02/08(土) 13:46:13.34
>>482
勘違いしているが、今のところ、どの開発プロセスでも、コードのバグのなさに責任を持つのは、あくまでもコードをエディタに打ち込んだプログラマ本人だけ
テスターは、ブックボックステストや、コード作成者の1/100以下の時間でコードを一覧することしか許されてないので、ある決まった種類の明らかで致命的バグを見つけることしかできない
0489デフォルトの名無しさん2014/02/08(土) 17:25:52.67
>>488
プログラマー本人が責任を持つなんて、そんな恐ろしい開発プロセスは嫌だ
0490デフォルトの名無しさん2014/02/08(土) 17:30:14.88
>>489
責任をもつだけの権限と報酬があればオレは喜んで引く受けるけどね。
実際は責任だけ負わされて潰そうとしてくるところの方が圧倒的に多いけど。
0491デフォルトの名無しさん2014/02/08(土) 18:13:39.24
>>489
逆に考えろ
少ない労力でバグを取り除くためのチャンスと情報を一番多く持っているのは、プロジェクトの中では誰なのかと
0492デフォルトの名無しさん2014/02/08(土) 18:14:39.09
>>490
バグを混入することに責任なんかないのに、なぜその責任だけは無償で果たそうとするのか…
0493デフォルトの名無しさん2014/02/08(土) 18:18:16.78
俺がミスをしてプロジェクトを破壊しないことについての責任をもつだけの権限と報酬があればオレは喜んで引く受けるけどね。
実際は俺がミスをしてプロジェクトを破壊したら責任だけ負わされて潰そうとしてくるところの方が圧倒的に多いけど。


プログラマがいかに無責任かが分かる
0494デフォルトの名無しさん2014/02/08(土) 18:19:37.02
責任というと政治的な話が絡むからな・・・
責務というなら同意
0495デフォルトの名無しさん2014/02/08(土) 20:59:36.74
逆にもっと政治的に考えればいいと思う
テストが法律だとすると、テストで見つからないバグは無罪
0496デフォルトの名無しさん2014/02/08(土) 22:13:07.98
個人で負える責任なんて限界が低すぎてダメでしょ
0497デフォルトの名無しさん2014/02/09(日) 02:35:29.44
仕様のミス以外は、わざわざプログラマが混入させてるわけだから
バグ混入は、食品会社でいうと従業員の毒物混入と一緒

食品会社で、「俺が毒入れたけど、検査がスルーしたから、俺は無罪」って言ってるようなもん
0498デフォルトの名無しさん2014/02/09(日) 09:15:03.67
役員とかが割とマジでそんなふうに思ってたりして
0499デフォルトの名無しさん2014/02/09(日) 09:33:28.27
仕様書通りに作って問題があった場合でもプログラマが文句言われるんだけどな。
日本の設計と製造が分離されてる体制だったら、SEがテストプログラム書いて、
PGにプログラム書かせて、テストプログラムでテストするのがいいんじゃないか？
PGはSEの書いたテストプログラムが通った、って責任逃れできるし、
SEはPGがおかしな動きのコード書いてないか、テストプログラムでテストできるし。
0500デフォルトの名無しさん2014/02/09(日) 10:41:07.45
SEはコード読めないんだから
それは不可能な話だ。

だからNTTはソースコードから日本語に戻すツールを
作れとか頭の悪いこと言ってるわけさ。
ソースコードそのまま読めばいいのにｗ

NTTデータ ソースコードが設計図と認める
http://kohada.2ch.net/test/read.cgi/prog/1390309568/

もしくはちゃんと使える設計書を作っておけよ。
SEは自分が作ったものが使えないといってるような話だよな。
0501デフォルトの名無しさん2014/02/09(日) 11:08:29.94
なでしこで書けば仕様書がソースコードになるよ
0502デフォルトの名無しさん2014/02/09(日) 11:20:04.78
>>498
役員っていうか、ソースを読めない人間は皆そんな風に考えている。
バグを埋め込んでるとかそんな被害者妄想を垂れ流すくらいならソースを自分で
読んでみればいいだろって思うよ。同じプロジェクトをしてる人に見せれない理由
なんて無いから、頼まれればいくらでも見せますよ。ただ、数百数千数万ある
ソースファイルの細部まで事細かに覚えている、理解しているわけじゃないから
質問されても答えられないことの方が多いけど。
0503デフォルトの名無しさん2014/02/09(日) 12:17:04.04
被害妄想でプロジェクトに支障をきたすのはもう病気だから
病人を批判しても意味がないよ
0504デフォルトの名無しさん2014/02/09(日) 14:43:30.19
>>499
それは当然
建築会社で釘打ってた土方が「これ製図通りに建てたら倒れるわ」と思ったら上司に報告して、その場で上司に責任をなすりつけた上で作業を続けるのは社会人として当然の態度
0505デフォルトの名無しさん2014/02/09(日) 14:48:50.11
>>499
そのコードをコーディングしてない人がテストできるバグは限られている
テストプログラムが通ったは、建築でいうと、「目隠しして実際に1日住んでみました」程度の意味しかない

テスターにバグ除去の責任を押し付けたいなら、そのコードについて、コーディングにかけた時間と同じ時間をテストのために用意しなければならない
0506デフォルトの名無しさん2014/02/09(日) 14:55:32.39
>>502
仕様のミスを無視すると、プログラマがバグを埋め込んでるのは事実なのだが
0507デフォルトの名無しさん2014/02/09(日) 21:35:48.72
大渕先生かわいい
0508デフォルトの名無しさん2014/02/09(日) 23:11:45.49
>>505
どれだけ適当なテストをしてるんだよｗ
0509デフォルトの名無しさん2014/02/09(日) 23:32:46.68
弊社ではテスト段階の終盤で基幹ライブラリのバグが見つかった場合
修正を加えてもテストのやり直しはしません
これは日本のIT業界では一般的なのでしょうか？
基幹ライブラリに手を入れたら今迄のテストは台無しになるのではないでしょうか？
0510デフォルトの名無しさん2014/02/09(日) 23:35:47.80
関連がありそうな部分だけ再テスト（関連性はベテランの勘で判断）
理屈でいえば全部再テストだけどな
そもそも、バグを全部直さずに出荷なんて当たり前の世界
0511デフォルトの名無しさん2014/02/10(月) 01:28:00.80
勘てｗ
影響範囲調査するでしょ普通は
0512デフォルトの名無しさん2014/02/10(月) 02:02:58.36
コアな部分で変更があるとほぼ全てになるから調査の工数が無駄
全部やるか目を逸らすか職人のカンであたりを付けるしかない
0513デフォルトの名無しさん2014/02/10(月) 02:14:28.72
お前はゼロかイチかしか決められないのかｗ
0514デフォルトの名無しさん2014/02/10(月) 02:23:16.21
職人のカンはデジタルじゃない
オカルトの領域だから未熟なエンジニアにはピンとこないかな
0515デフォルトの名無しさん2014/02/10(月) 07:12:01.34
否定したいが、あのカン馬鹿にできん
0516デフォルトの名無しさん2014/02/10(月) 09:07:43.72
勘を経験と言い換えると、何となく許せる気がするｗ
0517デフォルトの名無しさん2014/02/10(月) 09:34:57.13
お、達人プログラマーの話か？(スレ違い)
0518デフォルトの名無しさん2014/02/10(月) 10:04:57.95
経験だけ積んでる勘の鈍い爺がいるからねぇ (w
0519デフォルトの名無しさん2014/02/11(火) 03:42:52.87
深層意識下でのデータマイニングにより得られた一定の信頼度を持つ解析結果
0520デフォルトの名無しさん2014/02/15(土) 12:05:53.85
http://kohada.2ch.net/test/read.cgi/prog/1190866177/816
　　↑　　↑　　　↑　　↑　　　↑　　↑
0521デフォルトの名無しさん2014/02/15(土) 18:30:22.98
機械学習の1分野は脳を模倣しているんだから、やっぱり経験と勘で十分だろ
0522デフォルトの名無しさん2014/02/15(土) 20:12:21.49
Ｑ．その経験と勘がどれほど当てになるかを判断するには？

Ａ．経験と勘で判断する
0523デフォルトの名無しさん2014/02/15(土) 21:05:57.85
リリンもやっと真実に近づいたようだね
0524デフォルトの名無しさん2014/02/16(日) 22:58:38.20
Ｑ．カーリングの石を円の中心に持っていく技術はどうテストしたらいいの
Ａ．経験と勘で判断する
Ｑ．あれはスポーツなのか判断するにはどうテストしたらいいの
Ａ．経験と勘で判断する
Ｑ．なんで半そでで平気なの
Ａ．経験と勘で判断する
0525デフォルトの名無しさん2014/02/17(月) 07:05:10.72
ウェブ屋に多いが、TDDマンセーしてる連中がなぜか動的型言語を使ってるの見ると笑える
コードを著しく堅牢にする手段がもう一つあるのにそっちも使わないというのは
その程度の意識の低さ、あるいは視野の狭さってことっしょ
0526デフォルトの名無しさん2014/02/17(月) 11:19:18.75
目的と手段を取り違えるってヤツじゃね
0527デフォルトの名無しさん2014/02/17(月) 22:24:50.54
言語を選択できるという前提がある時点でアマチュア
0528デフォルトの名無しさん2014/02/17(月) 23:49:25.93
わざわざ毒を入れないという手段と、忘れずに薬を入れるという手段があると思う
前者は意識が低い
後者は意識が高いけど高くなるのは意識だけではない
0529デフォルトの名無しさん2014/02/18(火) 01:20:20.07
目の前に、ある小さな関数が80%まで書かれています
どんな技術レベルの誰が書いたか知りません
とりあえずパッと見た感じはバグはなさそうです

さぁ、どうします？
0530デフォルトの名無しさん2014/02/18(火) 01:23:23.26
それをどうこうしないといけない場面が思いつかない
0531デフォルトの名無しさん2014/02/18(火) 01:26:01.34
答えはGPLの可能性があるので無視して自分でコードを組む
小さな関数ということから80L程度だろう
0532デフォルトの名無しさん2014/02/18(火) 01:32:55.19
アホな統合開発環境のせいで、他人が書きちらした(書いてある部分まではほぼ正しいと自己主張されてる)コードを押し付けられる経験が常態でない人はアマチュア
0533デフォルトの名無しさん2014/02/18(火) 01:33:43.12
奴隷の鎖自慢が始まった
0534デフォルトの名無しさん2014/02/18(火) 01:39:48.32
明示された開発プロセスが必要なのは奴隷だけですよ
日曜プログラマは好き勝手にコード書いた方がいいですよ
0535デフォルトの名無しさん2014/02/18(火) 07:35:01.60
誰が書いたかわからないコードとか回されるのは底辺だけでおすし
長年の無計画な運用で腐りきった何万行のレガシーコードを渡されることがあっても、小さな関数なんて無視しても一緒だろ
0536デフォルトの名無しさん2014/02/18(火) 11:00:33.62
コードが80%なら無視するけど、できれば仕様書が125%でコードが100%の状況を作りたい
0537デフォルトの名無しさん2014/02/19(水) 01:14:22.73
現実はコードと内容が違う意味の無い仕様書200%だ
0538デフォルトの名無しさん2014/02/19(水) 01:19:04.11
現実は仕様も引き継ぎもなく客先に送り込まれ
金切り声で罵るPMに半日頭を下げてコーディングする時間もない状況だ
0539デフォルトの名無しさん2014/02/19(水) 01:52:12.40
単体テスト通過した時点でバグなんて出ないんだよ
動きが仕様と違うとかは話聞いてなかったり忘れてたりするだけ
つまり人間の方にバグがあるんだから仕方ない
0540デフォルトの名無しさん2014/02/20(木) 14:28:11.54
人間はミスをするからテストが必要
　　　　　↓
人間の方にバグがあるんだから仕方ない

どうしてこうなった･･･
0541デフォルトの名無しさん2014/02/21(金) 08:14:01.38
もともとだからしょうがない
そもそもお前もお前のオトンとオカンの過ち... (w
0542デフォルトの名無しさん2014/02/25(火) 01:01:31.44
仕様に対する差異をバグと呼ぶ
しかし、仕様そのものが間違っている場合がよくある
0543デフォルトの名無しさん2014/02/25(火) 12:59:23.13
製作者の意図と異なるものをバグと呼ぶ
ゆえにプログラマーがバ○スを唱えるとバグは完全に消滅する
0544デフォルトの名無しさん2014/02/25(火) 23:40:03.07
テストメソッドにもデバッグが必要だし
値を見て満足できるほど悟れない
やっぱそれなりの出力が欲しい

アジャイルとテスト駆動開発はジャップは無理
0545デフォルトの名無しさん2014/02/26(水) 19:27:31.81
製作者の意図を仕様書と言います。
0546デフォルトの名無しさん2014/02/26(水) 20:27:51.87
>>545
時系列的にもプログラム作成後に生まれた意図のことも多いよね
0547デフォルトの名無しさん2014/02/27(木) 02:09:14.20
>>545
製作者が仕様書を書くわけじゃないし・・・
0548デフォルトの名無しさん2014/02/27(木) 02:24:15.08
>>547
意図しろ、と強制はされているよね
0549デフォルトの名無しさん2014/02/27(木) 22:19:38.45
プログラムは書かれた通りに正しく動くだけだ
作った人間が全て悪いのだ
0550デフォルトの名無しさん2014/02/27(木) 22:58:04.77
プログラムに自分にバグがないことを証明させるプログラムを作ろう
0551デフォルトの名無しさん2014/02/27(木) 23:02:29.27
作るのは人間なのだし
それイコール人間にバグがないことを証明させるプログラムなのだよ
0552デフォルトの名無しさん2014/02/27(木) 23:21:08.64
>>550
そもそも、「プログラムにバグがないことを証明できない」
という理論に反証しようとしてできたのがコンピュータ

反証には失敗したが、その過程の思考実験でコンピュータ
というもののアイデアが生まれた。
0553デフォルトの名無しさん2014/02/27(木) 23:22:07.89
不完全性定理をネタにしたジョークなのに
0554デフォルトの名無しさん2014/02/27(木) 23:24:27.27
最終的にはデバッグが人間に残された最後の仕事なんですわ
0555デフォルトの名無しさん2014/02/27(木) 23:30:24.08
まだ幸福になる仕事が残ってますよ
0556デフォルトの名無しさん2014/02/27(木) 23:49:45.62
デバッグの大半は自動化できる
自動化しない理由は「人間の操作ミスによってバグが発見される可能性があるから」
0557デフォルトの名無しさん2014/02/28(金) 00:51:14.34
バグも仕様も人から生み出されたものだというのに
なぜ争うのか
0558デフォルトの名無しさん2014/02/28(金) 01:06:47.48
不完全性定理はメモリが無限にある場合の話
なぜ無限かというと、有限の場合は自明だから
有限なら全部テストすればいいだけ
0559デフォルトの名無しさん2014/02/28(金) 06:39:59.21
だけとつけるだけで強くなれる気がした15の夜
0560デフォルトの名無しさん2014/02/28(金) 12:43:22.18
自分ではなにもしない (できない) 50 過ぎのじじいも、やるだけだろ、なんでやってねーんだ？
って、簡単におっしゃりますがなにか？
0561デフォルトの名無しさん2014/02/28(金) 19:56:04.53
いつからだ、言ってみろ
いつから貴様らはTDDの話をしなくなったのだ
0562デフォルトの名無しさん2014/02/28(金) 20:26:07.71
静的な証明を研究している人は動的なテストを見下しているから
0563デフォルトの名無しさん2014/02/28(金) 20:56:03.29
>>558
納期は無限じゃない
0564デフォルトの名無しさん2014/02/28(金) 20:56:35.52
>>561
組み込み系でもTDDって利用できる？
0565デフォルトの名無しさん2014/02/28(金) 23:28:25.33
>いつか>>558が無限ループを検出するpgを書いてチューリング賞を取ると聞いて
0566デフォルトの名無しさん2014/03/01(土) 00:03:45.82
すべての無限ループの検出ができないだけで、無限ループの検出はlint類でもできますよ
0567デフォルトの名無しさん2014/03/01(土) 01:21:06.66
ゴミカスライブラリの使用を強制されてるとユニットテストのありがたさが身に沁みる
ライブラリ修正のたびにテストなんて手作業じゃ出来ないよ
0568デフォルトの名無しさん2014/03/01(土) 06:29:20.44
おまえらが使うライブラリなんてどうせグラフィック系が多いんだから
テストの自動化なんてできない
0569デフォルトの名無しさん2014/03/01(土) 12:34:24.49
グラフィック系=画面と勘違いしてる自称PGって多いよね。
0570デフォルトの名無しさん2014/03/01(土) 14:15:24.15
お前さんの文章否定ばかりで中身ないからつまらん
0571デフォルトの名無しさん2014/03/01(土) 14:45:42.94
中身がないのは０だからネガティブではない
なぜ０をネガティブだと思ったのか
興味深い
0572デフォルトの名無しさん2014/03/02(日) 09:44:54.51
>>571
何でこの板にいながらにして
否定(ネガティブ)をマイナス扱いしてんの？
そっちの方が興味あるわ
0573デフォルトの名無しさん2014/03/02(日) 11:47:41.53
流行らない理由がまた一つ明らかになった
最初に中身のないソースコードをテストするから
0574デフォルトの名無しさん2014/03/02(日) 12:07:30.41
>>573
なぜいまさらそんなものを持ち出すの？
0575デフォルトの名無しさん2014/03/03(月) 12:04:16.83
理想的な自分を思い描き、それを実現する

考え方は嫌いじゃないんだけどな
0576デフォルトの名無しさん2014/03/03(月) 21:51:20.86
テストよりコードを書くほうが楽しいから

これが最終的な答え
0577デフォルトの名無しさん2014/03/04(火) 01:27:05.03
流行らせたいならテスト書く奴とコード書く奴を別々にしろ
仕様はテストの形で渡せ
0578デフォルトの名無しさん2014/03/04(火) 16:01:02.69
>>577
プログラマの習慣としてのテストと、ソフト開発の一工程としてのテストは別物なんだ
0579デフォルトの名無しさん2014/03/04(火) 21:08:31.99
>>577
テストさえ通ればいいというようなコードであふれることになる
0580デフォルトの名無しさん2014/03/04(火) 22:07:49.99
AIがコードを書けるようになったら、AIはテストを通すことしか考えないだろうね
人間のほうが優秀
0581デフォルトの名無しさん2014/03/04(火) 22:14:27.75
>>579
テスト通れば仕様満たしてるんだから何も問題はないな
0582デフォルトの名無しさん2014/03/04(火) 22:25:27.05
>>579
ザルテストすら通らないコードが溢れかえってますが、なにか？
0583デフォルトの名無しさん2014/03/04(火) 22:29:06.11
>>581
>>582
せめてテストコードは隠しておかないと意味ないぞ
0584デフォルトの名無しさん2014/03/04(火) 22:58:51.81
>>583
誰から隠すの？
なぜ隠すの？
0585デフォルトの名無しさん2014/03/04(火) 23:32:11.55
>>583
なんかのゲームでもやってんのか？ (w
0586デフォルトの名無しさん2014/03/05(水) 16:50:46.49
>>584
隠すというか、テストの情報を小出しにして何回も繰り返すんじゃないの
情報が来るまでコードを書かないので、テストされてないコードの在庫が0になる方式
0587デフォルトの名無しさん2014/03/05(水) 22:10:19.13
>>584
中国人から隠すんだよ
0588デフォルトの名無しさん2014/03/05(水) 22:16:47.64
受け入れテストか
0589デフォルトの名無しさん2014/03/05(水) 22:26:58.47
中国人の不正に対する情熱は異常
普通にやったほうが楽じゃねーのってレベル
0590デフォルトの名無しさん2014/03/06(木) 00:17:49.94
共依存か
0591デフォルトの名無しさん2014/03/06(木) 06:32:16.94
テスト隠すて…
期末テストと区別ついてない系
0592デフォルトの名無しさん2014/03/06(木) 09:16:56.14
ttp://www.atmarkit.co.jp/ait/articles/1403/05/news035.html
いまさら聞けない
0593デフォルトの名無しさん2014/03/06(木) 23:55:17.38
>>589
仕様:閏年判定。入力年=2000の場合、返り値=1とする。
出来上がってきたコードは、
return 1;
0594デフォルトの名無しさん2014/03/07(金) 00:05:40.30
>>593
そりゃテストを書いた方もアタマ悪い.
0595デフォルトの名無しさん2014/03/07(金) 00:08:19.98
休日判定プログラム（日本限定）だったらどういうテストコードが適してるかな？
0596デフォルトの名無しさん2014/03/07(金) 02:26:00.23
>>595
休日は毎年のように変わるからどうしようもないだろう
特に年によって実施日が変わってしまうような類の祝日などは
それぞれテストするしかない
0597デフォルトの名無しさん2014/03/07(金) 08:11:35.41
>>595
return false;
0598デフォルトの名無しさん2014/03/07(金) 09:21:28.00
>>597
節子それテストやない
0599デフォルトの名無しさん2014/03/07(金) 13:46:57.99
>>598
「プログラマの休日判定」 ならこれで正解
0600デフォルトの名無しさん2014/03/07(金) 15:15:29.95
for i in range(1, 366):
　　assert(is_holiday(i) == false)
0601デフォルトの名無しさん2014/03/07(金) 16:19:25.22
実装は不可能、と断言すると冷たい感じがするので
実装は可能だが残念ながらテストが不可能と言って遠回しに否定する
0602デフォルトの名無しさん2014/03/07(金) 20:11:14.03
むしろテストは積極的に読ませて仕様共有の手助けとすべき
どうせ結合テストや自動化できない項目は残るんだから
そこではじけば問題ない

一部だけ担当してトンズラこく悪質業者のことは知らん
0603デフォルトの名無しさん2014/03/08(土) 01:07:40.24
遺伝的アルゴリズムのユニットテストはどう書けばいいんだ？
0604デフォルトの名無しさん2014/03/08(土) 01:11:34.12
は？交差とか淘汰の処理が正しく動いてるかを書くだけだろ
0605デフォルトの名無しさん2014/03/08(土) 01:14:38.09
>>604
どううごいたら正しいんだよ
正しい突然変異って神様にでもなったつもりか
0606デフォルトの名無しさん2014/03/08(土) 01:14:48.74
つか遺伝的アルゴリズム自体はライブラリつかえば？
したら評価関数だけテストすればいいじゃん
0607デフォルトの名無しさん2014/03/08(土) 01:28:56.56
>>605
問題を分割できない馬鹿の言いそうなことだこと。
突然変異という処理を小さく分ければいいだろ。
確率分布に従ってサンプリングする処理、ビットごとに値を変える処理、・・・
ユニットテストってそういうもんだけどなあ。
お前の想像してる粒度がでかすぎんだよ。
0608デフォルトの名無しさん2014/03/08(土) 08:17:00.42
ランダム関数を固定化するだろjk
0609デフォルトの名無しさん2014/03/08(土) 11:07:22.33
>>606
ライブラリもテストするだろ普通
評価関数だけテストしても無駄
0610デフォルトの名無しさん2014/03/08(土) 11:59:00.39
二つ作って結果が一致するかテストする
後で書いた方が正式版なら、先に書いたのはテストコードだったことになる
0611デフォルトの名無しさん2014/03/08(土) 16:06:01.78
お客さんでも作れるように説明してしまうとやばいのは小学生にも判るよね
だから書かないんだよ
0612デフォルトの名無しさん2014/03/08(土) 16:32:08.42
典型的な反知性主義だね
どっちに転んでもやばいね
0613デフォルトの名無しさん2014/03/08(土) 17:06:45.86
そういう意味では学校の授業でプログラミングを教えるようになるのはよいこと
なんだよな。 早い段階できちんとしたプログラムを作るのがどれだけしんどいか
分かるってことがさ。 車の運転は誰でも出来ます。ただ免許を持っていないと
運転してはいけません。免許を持ってるからといって、良いドライバーとは限り
ません。 車に限らずたいていの物事はこんな感じなんだけど、自分の専門の
分野と違うと理解できないもんなんだよな。
0614デフォルトの名無しさん2014/03/08(土) 22:58:59.06
>>595
制度変更の前後にまたがってテストするしかないね。
0615デフォルトの名無しさん2014/03/08(土) 23:18:09.56
>>611
客先が書く可能性があるって下請けもいいところだなぁ
0616デフォルトの名無しさん2014/03/08(土) 23:29:01.91
逆だろ。常駐。
0617デフォルトの名無しさん2014/03/09(日) 03:00:11.78
現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/
0618デフォルトの名無しさん2014/03/10(月) 13:41:49.11
お客さんサイドのCOBOLerやVBAerがプログラマーでございと侵食してくるのがヤバイ

というか業務分野ごとにそれに適したDSLを使えない"汎用"プログラマーの方がやばいのか？
0619デフォルトの名無しさん2014/03/10(月) 16:15:32.09
浸食されると危機感を覚える程度の技術レベルしかない>>618の将来がヤバイ
0620デフォルトの名無しさん2014/03/10(月) 19:50:13.72
VBAだと何かまずいの？
0621デフォルトの名無しさん2014/03/10(月) 22:45:11.97
テスト駆動開発って
1.テスト書く→それが通るコード書く
2.テスト書く→それが通るコード書く
3.リファクタリングする
これの繰り返しなんだよね？
0622デフォルトの名無しさん2014/03/10(月) 22:53:21.87
主語が無い
06236212014/03/10(月) 23:02:51.56
すいません、大事なとこ抜かしてました
1.俺がテスト書く→それが通るコード書く
2.俺がテスト書く→それが通るコード書く
3.俺がリファクタリングする
これの繰り返しなんだよね？
0624デフォルトの名無しさん2014/03/11(火) 07:51:22.69
ﾜﾛﾀwwww
0625デフォルトの名無しさん2014/03/11(火) 21:32:20.50
>>620
数千万円もらってた仕事が
実はパソコンオタク社員が鼻くそほじりながらつくったスクリプトと
大差ないとバレる
0626デフォルトの名無しさん2014/03/12(水) 01:58:18.16ID:PmsDk2kY
結局ばれるのが小ワインだろ
小ワイン
ソースよこせが怖いんだろ
オープンソースなんて論外なんだよ
0627デフォルトの名無しさん2014/03/12(水) 13:29:02.98ID:xw7xwyT9
？
0628デフォルトの名無しさん2014/03/12(水) 23:37:47.59ID:sK4uUGye
サードパーティが信用出来ないけど使わないとダメな場合はテスト自動化は頼りになるね
0629デフォルトの名無しさん2014/03/13(木) 00:54:34.87ID:2t1VyOIj
で、なぜはやならなかったんだ？
0630デフォルトの名無しさん2014/03/13(木) 01:11:56.97ID:EP1oXvO4
流行ったら仕事を失う労働者が沢山いるから
0631デフォルトの名無しさん2014/03/13(木) 01:19:58.68ID:FW3mCw9Q
>>629
2chでたった3行程度の自分のレスの誤字脱字ですら確認しない人がたくさんいるのを見れば分かるのではなかろうか…
0632デフォルトの名無しさん2014/03/13(木) 13:12:51.82ID:8C61XcI9
>>630
公務員脳だな。
0633デフォルトの名無しさん2014/03/13(木) 22:00:44.18ID:rV9SiEZO
人間はあえて完全なものを作れないようにできている
今ならなぜだか判る
0634デフォルトの名無しさん2014/03/28(金) 01:24:44.61ID:NM8p3urQ
懐かしいな、10年くらい前に、2年くらいテストファーストでやってたわ
0635デフォルトの名無しさん2014/03/31(月) 21:46:06.08ID:0et95UJG
さて、そろそろヲタでも放置するか
0636デフォルトの名無しさん2014/05/06(火) 14:50:52.69ID:jFURd3DY
>>400
> 技術の話じゃなく心構えの話であって、なおかつちゃんとした証明とかが無いにもかかわらず、
> 「テストファーストしない人間とは関わりたくない」などと発言をする。
> こういうのが信者っぽいんだよ。感覚的な結論が先にありきでさ。

うむ。ちょっと前の HTML5 もそうだったが、
そういう態度を示すやつが現れたら死亡フラグだと思ってる
ポイントは、一定の（無視できない数と妥当性を持った）批判があることと、
それに耳を閉ざして同好の徒だけで駄サイクルを作っていることかな。コケる確率が上がろうってもんだ。

>>401
> プログラマの世界だと新しい技術を積極的に取り入れる人は総じて技術レベルも高いから、
> ○○の良し悪しとは無関係に、○○を使ってみている人は無関心な人より仕事ができる可能性が高い。

どうかねぇ。単に流行追ってるだけのスイーツって可能性もあるんだぜ？

> 試しに○○に古いものを入れてみる。
> 「コーディング前に詳細設計書も書かない人間とは関わりたくない」

正直、10 年後に今のテスト駆動開発がそういう扱いになってる予感しかしない
コードを書くよりも作法・しきたりを守らせることを優先するという点では
テストも詳細設計書も何も違わないし。
ウォーターフォールだのだって昔は cool と見なされて導入されたんだよ？

10 年後には TDD が負の遺産になっていて、こんなもん推進した馬鹿はどいつだってなるのに賭けるわ。
俺は戦犯にはなりたくないから距離を置いてるｗ

つか「最先端の技法を追っている」んじゃなくて
エンプラ化・おっさん化してるだけだと思うよ・・・
0637デフォルトの名無しさん2014/05/06(火) 15:07:29.74ID:Fr+PW76D
TDDはテスト駆動開発であって
テストを開発しているわけじゃない。

最終的にテストとして使えるコードを
書くこともあるが、それは必須ではない。

テストとして使えないテストコードは
開発するためだけのもので後で捨てる。

ならば捨てるテストの代わりに
手動でテストしても一緒。
0638デフォルトの名無しさん2014/05/06(火) 19:08:35.12ID:wWugdkdR
>>636
TDDは設計手法と言えるけど、TDDでのテストはサンプルコードに近い性質を持つ
「詳細設計書と何も違わない」というのは同意しかねる
0639デフォルトの名無しさん2014/05/07(水) 18:17:39.24ID:MZ01fZnX
>>638
ほーん で？ いちいち同意求めんなカス
0640デフォルトの名無しさん2014/05/07(水) 21:35:41.52ID:7EESg6Ug
>>639
日本語はちゃんと学んだ方がいいよ
もしもそちらにとって難しい言い回しを使っていたならすまんな

別にこちらは同意を求めてない
お前の言ってることは間違ってるよ、ってだけ。
0641デフォルトの名無しさん2014/05/08(木) 11:52:45.58ID:7mqxxUyE
テストって、大抵はプロジェクトが大きくなったり長期化して
あまりにもバグやリグレッションが頻発するようになって、
こらチェックを自動化しないとあかんって導入されてきた経緯があっただろ。

そういう、必要に迫られての自動テストは（当然ながら）効果を発揮するし、
そもそもそういう風にプロジェクトが危なくなる前に仕組みを作っておかないといかんよねって
話になった。自動テストは素晴らしい。いいね。

ここまでは良い。

が、いくらなんでもテストファーストだのTDDだのは極端に走りすぎですよ。

最初からテスト・テストじゃ普通に身動き取れんだろうが。
お前らそこまでしょっぱなから仕様のガッチリしたものを組んでるのかよ・・・
スーパーハカーなどは絵を描くようにコード書けなどと言ってるというのに

もちろんモノにもよって、例えばミドルウェアだのコアなライブラリだの、
仕様が早期に固定化されるものをしっかり安定させておきたいなら、
最初から厳格な自動テストが必要だろう。
メインのコードとテスト、一緒に書いて、正常動作していることを機械的に確認・保証する。
そこまでならまだ解る。当然のことだ。いわば、家を建てるときに支柱を入れるようなもんだな。
強度を見積もると、倒壊しないためにはこのくらいの補助は必要だってな。

が、テスト「ファースト」だのテスト「駆動」だのはおかしいわ。まずメインの柱立てることを考えろよｗ

家建てろ言われて、元気一杯で支柱をドカドカ入れ始めるやるがあるか。普通にクルクルパーだろｗ
そもそも目的を見失っているし、工数、建材のコスト、設計が変わったときのこと、
リフォームするときのこと等々、何もかも計算に入ってへんやん。
特にカバレッジとかアホの概念だろ。目的もなく支柱をいくら入れたか自慢かよ。


ビョーキですよ、普通に。
0642デフォルトの名無しさん2014/05/08(木) 12:46:10.04ID:9RHm5PfU
意味が無いと思うならやらなきゃいいだけなのに、なんで必死なんですかね
0643デフォルトの名無しさん2014/05/08(木) 13:06:10.59ID:kcoEiu4H
TDDが権利なら使わないという選択肢もあるが義務なら身動きが取れなくなる
権利は健康
義務は病気
0644デフォルトの名無しさん2014/05/08(木) 13:14:45.39ID:9RHm5PfU
TDDが義務だという開発体制が想像できないんだが
0645デフォルトの名無しさん2014/05/08(木) 22:50:13.49ID:kJ063xCN
UIなど自動テストがしにくい、できてもコストが高いと
いう分野が有ることは誰も否定しないだろう。

故にTDDが割にあわない分野もあるってことになるんだよ。
0646デフォルトの名無しさん2014/05/09(金) 00:32:50.71ID:utjU+QGd
自動化のためにGUIを否定したり
逆にGUIが自動化を否定するのはわかる
しかし自動化とGUIの争いにTDDを巻き込むことで一体何のコストが安くなるのか
0647デフォルトの名無しさん2014/05/09(金) 03:10:39.23ID:Kz50EFWR
まんこ
0648デフォルトの名無しさん2014/05/09(金) 07:01:16.35ID:fBe/MBgK
>>646
ラボや個人と営利組織の運用で注目される点が違うことがわかるので重要な話だね
tddが宗教であって技術でないという信念を持つ人にとっては無意味な話に見えるだろう
0649デフォルトの名無しさん2014/05/09(金) 10:52:35.09ID:VdfmJhjs
おれはテストセカンドという手法で開発してる
0650デフォルトの名無しさん2014/05/09(金) 13:13:16.56ID:e8QohjKI
じゃあボクはテストラストで！
0651デフォルトの名無しさん2014/05/09(金) 22:08:33.75ID:IRQ9/IYX
スニペットや関数単位で実行できるエディタやIDEを使って
頻繁に実行して結果を確認しながら
開発するスタイルはTDDになりますか？
0652デフォルトの名無しさん2014/05/10(土) 11:14:55.79ID:i8wKz9lz
確認というのが目視なら TDD とは違うかな。
目視で確認できる程度って知れてるし、間違ってても
意外と気づかないので当てにならない。
0653デフォルトの名無しさん2014/05/10(土) 12:19:44.22ID:m9xHqVTZ
TDDの効果が高い所が少ないんだよな。

完成してからテストを書いて
回帰テストをするっていうのはいみあるんだけど、

テスト書きながら開発するのがメリット少ない。
なぜなら開発の初期段階では仕様が固まってないから
テストのほうまで何度も修正する必要がある。

また、逆に仕様がすぐに固まるような、
簡単な関数では目視で十分。ケアレスミスはするけど
論理的なバグっていうのは少ないからね。

だからリファクタリングする必要が出てきた時にテストを書けばいい。
0654デフォルトの名無しさん2014/05/10(土) 13:19:05.40ID:6YF+GXG1
仕事早い奴の適当コードやサンプル流用をそのまま本チャン環境に入れるような輩には無用の長物さね

あと、新規ライブラリの利用とか、新言語習いたての時にはTDDは向かないな
0655デフォルトの名無しさん2014/05/10(土) 13:27:02.84ID:m9xHqVTZ
> 仕事早い奴の適当コードやサンプル流用をそのまま本チャン環境に入れるような輩には無用の長物さね

なんで？ まったく無関係の話しないでよ。
0656デフォルトの名無しさん2014/05/10(土) 13:40:45.75ID:1/ia6KrF
> テスト書きながら開発するのがメリット少ない。
> なぜなら開発の初期段階では仕様が固まってないから
> テストのほうまで何度も修正する必要がある。

俺も同意なんだけど、ぜひTDD賛同者側の見解を聞きたい。


> また、逆に仕様がすぐに固まるような、
> 簡単な関数では目視で十分。ケアレスミスはするけど
> 論理的なバグっていうのは少ないからね。
> だからリファクタリングする必要が出てきた時にテストを書けばいい。

これは同意しかねる。
0657デフォルトの名無しさん2014/05/10(土) 14:17:42.95ID:0zZ9Lb2b
>656
>> テスト書きながら開発するのがメリット少ない。
>> なぜなら開発の初期段階では仕様が固まってないから
>> テストのほうまで何度も修正する必要がある。
>
>俺も同意なんだけど、ぜひTDD賛同者側の見解を聞きたい。

仕様を決めてから実装を始めようよというのが、TDD の方針

「契約」が絶対の社会なら上手くハマるんじゃないでしょうか。
おそらく、普通のシステム開発なら、TDD のほうがみんな幸せ
になれるはず。
06586572014/05/10(土) 14:27:38.27ID:0zZ9Lb2b
ただ、現実的には、
>>651
で良いんじゃないですか？

もうちょっと頑張って、
「頻繁に実行して結果を確認」の代わりに Unit Test を書いて、
CI (jenkins) で深夜の毎日全テストができるようにすれば必要十分。

単体 (Unit) テストが、少なくとも 全行網羅(最低90%) していれば、
安心して結合テストを始められるし、
結合テストで出た障害の修正をしてもほぼデグレーションを防げる
0659デフォルトの名無しさん2014/05/10(土) 14:34:59.99ID:m9xHqVTZ
>>657
> 仕様を決めてから実装を始めようよというのが、TDD の方針

そうも行かないんだよね。

あとから初期段階では決まっていなかった
引数が追加になったりする

そもそもライブラリを作っているのでもなければ、
関数型言語的な意味の関数ではなくて
副作用が主なものを作ることが多い

たとえば関数を実行したらデータベースに書き込む処理とかね。
その時のデータベースに書き込むテーブルやカラムは
後から追加されることがたびたびある。
0660デフォルトの名無しさん2014/05/10(土) 14:38:53.55ID:m9xHqVTZ
>>658
> 「頻繁に実行して結果を確認」の代わりに Unit Test を書いて、
> CI (jenkins) で深夜の毎日全テストができるようにすれば必要十分。

それはTDDではない。

TDDはあくまで開発。テスト作成作業ではない。
UnitTestやCIであれば「テストを後から書く」ことで問題ない。

TDDやってるときに、開発する前にテストをたくさん書いたら
それは違うって言われるよ。開発を始めるまでに時間がかかってしまう。

TDDは最小限のテストとコードを使って開発するものだ。
TDDであってもその後にちゃんとしたテストを別に作成する。

で、開発さえ出来るならどうでもいいので、別に目視確認でもいいだろう。
どうせ必要ならテストはあとでちゃんと書くんだから
0661デフォルトの名無しさん2014/05/11(日) 02:03:19.34ID:ycF5cRDn
>>659
> あとから初期段階では決まっていなかった
> 引数が追加になったりする
それは初期段階で仕様は決まっていたがあとで変更になっただけじゃないか。
初期段階の仕様でテストを作成し、あとで変更すればいいだけ
0662デフォルトの名無しさん2014/05/11(日) 16:06:00.66ID:5ukecUuP
tdd is deadだっけ
ま、>>1に書いてある事は正しいと思うよ
理想的な条件が揃った案件ならtddも良いんだろうけど
0663デフォルトの名無しさん2014/05/12(月) 14:06:17.89ID:ZtmTFQ/l
そもそもガンガン変更のかかるところでこそテストファーストは生きる
対象コードを小単位に区切って合わなくなった部分だけを捨てて作り直す（そのほうが早い）
それができないなら設計が悪い
テストしやすい設計いい設計
0664デフォルトの名無しさん2014/05/12(月) 21:07:26.87ID:gfHEQtpm
> そもそもガンガン変更のかかるところでこそテストファーストは生きる

関数のインターフェースやクラス構造がガンガン変更がかかる所では死ぬ。
ユーザーインターフェースがガンガン変更がかかる所では死ぬ。
実験でいろんなものを試してガンガン変更がかかるところでは死ぬ。
0665デフォルトの名無しさん2014/05/12(月) 21:36:58.27ID:4d3ePR/I
>>664
まったくだ まったくだよ
0666デフォルトの名無しさん2014/05/12(月) 21:55:59.11ID:M1pM5qng
TDDよりも、コメント駆動開発のほうがよくないか？

まず最初にコメントを書く。

そして全体の構造を把握したら、コードに置き換えていく。
0667デフォルトの名無しさん2014/05/12(月) 22:04:21.73ID:mSkc1DAY
コメントだけ書ききったソースを「仕様書」と呼んで終了
0668デフォルトの名無しさん2014/05/12(月) 22:10:54.58ID:M1pM5qng
コメント”駆動”なので、ここから
開発するんですよ。
0669デフォルトの名無しさん2014/05/12(月) 23:01:50.95ID:8a4bU2a3
変更の度にソースコードとコメントをメンテするのか。
0670デフォルトの名無しさん2014/05/12(月) 23:19:28.90ID:M1pM5qng
いいえ？ 不要になれば消せばいいのです。
開発を始めるための道具でしかありません。
0671デフォルトの名無しさん2014/05/12(月) 23:24:50.88ID:xScDRvbM
一周回って書いたコードはテストしましょうでええんちゃう
0672デフォルトの名無しさん2014/05/13(火) 10:16:56.07ID:CL8NKXMA
なんつーか、設計を変更しながらコードを書いていくってのが、頭がついていかない。
設計を先に作っておいて、機能を実装、リファクタリングしていくのならなんとかなるけど。
0673デフォルトの名無しさん2014/05/13(火) 11:39:40.98ID:dZPvmt+0
>>672
つーか設計が変更になったらふりだしにもどってやり直すだけで、
> 設計を先に作っておいて、機能を実装、リファクタリング
という流れは変らないと思うけど。
そうじゃないとテストファーストにならない。
0674デフォルトの名無しさん2014/05/13(火) 12:24:24.65ID:TWFU3uu9
設計ファーストを全否定しても良いし
部分的に肯定するなら仕様書駆動を否定してテスト駆動を肯定すれば良いんだろ
全肯定はありえないことが判明しただけでも良かったよね
0675デフォルトの名無しさん2014/05/13(火) 21:03:33.01ID:8hwDbhT0
>>673
テストファーストが使えないというのは、
テストファーストが出来ないという意味ではなくて
コストのほうが高いっていう意味。

だから振り出しに戻ってやり直すから
やったテストが無駄になるのでコストがかかって
テストファーストが使えないということ。
0676デフォルトの名無しさん2014/05/14(水) 01:42:41.81ID:ToGrq+HN
>>675
どのフェーズや規模感で作り直し/やり直しを言ってるのか分かってないからざっくりとした反論しかできんのだがすまんな

テストファーストだろうがテストセカンドだろうが、テストは変更になりうる。
そうするとテストラストしか選択肢がなくなるのだが
開発途中でテスト作らない方針だと、かなり不安な中でコーディングし続けるハメにならんか？

開発途中に変更が起こった場合、変更箇所のテストは確かに無駄になるが
変更箇所以外のテストは、変更時に安全性を担保するのに役立つ。
また変更の度合いによっては、設計の変更→既存のテストの変更という形で再利用しやすい場合もある。

つまり変更の可能性がある→テストが全くの無駄ということではなく、コストを払う価値は見いだせると思う
(この辺りはTDDに限らずテスト一般の話だが、テスト＝無駄と言われるとこれ以降の話が続かないので)

そういう開発中の不安を抑える為に、多少のコストを払ってそこそこの安心や品質を得るのがコーディングとセットのテスト作成。
テストセカンドだと、実装→テスト作成という流れで、テスト作成の工数自体はテストファーストよりも抑えられるのだが
「あれ、このインターフェース使いづらいぞ」とか「この設計だとテストしづらいわ」みたいなのが
実装完了してテスト作ってみて初めて分かる、というリスクがあるので設計手法としてはテストファーストよりも劣る
使いやすく・テストしやすく作っていくようなアプローチをとれる設計手法がTDDの大きなメリット


振り出しに戻ってやり直すっていうのは
そもそもプロトタイプ＝変更しまくりが前提の話なら、たぶんテストファーストしないほうがコスト低い
プロトタイプなら作って捨てるから。
(作って使いまわす前提のE2E→拡張サイクリングな開発ならテスト作った方がよいかも)

そしてプロトタイプでもないのに莫大な変更が頻繁に求められるんだとしたら
そのプロジェクトはもうTDDとか言ってる場合じゃないような気がするぞ・・・
0677デフォルトの名無しさん2014/05/14(水) 02:54:12.82ID:LFlUnuUg
>>676
> 開発途中でテスト作らない方針だと、かなり不安な中でコーディングし続けるハメにならんか？

テスト"駆動"をしないだけで、テストは書く。

不安なときにだけテストを書けばいいでしょ？
物によっては最初にテストを書くこともあるけど、
後からテストを書けばいいし、リファクタリングする前に
テストが足りなければ追加すれば良い。
0678デフォルトの名無しさん2014/05/14(水) 03:02:35.41ID:TJ8LcHmI
テストを書くときはコードに合うようにテストだけいじる。
コードを書くときはテストに合うようにコードだけいじる。

だけ守ってたら大抵幸せ。
テストを絶対いじっちゃいけないものだと勘違いしてる人は、
先人のありがたい教訓「動いたものには触るな」レジームから脱却してないだけ。
コードがテストに置き換わっただけ。
0679デフォルトの名無しさん2014/05/14(水) 05:58:04.41ID:sd+oycz/
Vs2012にguiのテストツールがあったと思うけど使い物にならない？
0680デフォルトの名無しさん2014/05/15(木) 00:43:31.33ID:WsB3lCbj
>>677
バグの切り分けにも役に立つから先にテストを書くんじゃないかと僕は思うなあ。バグが出るたびに（または不安がでるたびに）テストを書くのは、思考を切り替えるコンテクストスイッチのコストが高いんだと思う。
0681デフォルトの名無しさん2014/05/15(木) 23:26:46.81ID:SyWQx43e
てすてす。
0682デフォルトの名無しさん2014/05/18(日) 00:15:38.76ID:zMZanzv2
まぁプログラムにバグ混入しまくる現代の
オブジェクト指向とかC#,JAVAが最適解であるわけもなく
正しいものとか殆ど出来上がってないから無駄な議論
ハスケル推す気はないけど副作用のオンオフ出来ない言語って。。。
0683デフォルトの名無しさん2014/05/18(日) 01:59:35.09ID:xRvInDCX
> まぁプログラムにバグ混入しまくる現代の

過去にバグが混入しまくらなかった時代はないですが？
未来はこうなってるんだ〜みたいな話をしてるの？
0684デフォルトの名無しさん2014/05/18(日) 16:44:55.48ID:Am+ZFISx
>>683
きっと682が10行程度のVBAスクリプトを書いてた時代の話なんだよ。


VBAじゃ10行でもバグ無しは無理か。
0685デフォルトの名無しさん2014/05/18(日) 19:28:44.94ID:2kdDjA0I
> まぁプログラムにバグ混入しまくる現代の
> オブジェクト指向とか

オブジェクト指向関係ねぇぇ
0686デフォルトの名無しさん2014/05/18(日) 19:47:19.66ID:C9yMB7Be
関係ある。
俺はオブジェクト指向が嫌いだ。
あんなわからんものを使ったから
バグが出た。
0687デフォルトの名無しさん2014/05/18(日) 19:52:32.85ID:2kdDjA0I
そんなエサでこの俺が
0688デフォルトの名無しさん2014/05/19(月) 23:42:10.67ID:Ya0Xx/0T
ゴミは黙って死ぬまでオブジェクト指向やってりゃいいんだよ
余計なものを見ようとするなゴミ
0689デフォルトの名無しさん2014/05/20(火) 01:11:20.60ID:BLzVJP6i
そんなエサでこの俺が
0690デフォルトの名無しさん2014/07/09(水) 04:07:40.08ID:AbJxGlA9
新人こねえ、老人勉強しねえ
0691デフォルトの名無しさん2014/08/15(金) 08:05:23.56ID:UGZaG54l
TDDが馴染まないのは
プログラム書くとき、main から順に下に向かって必要な関数を書くよね？
プログラムを読むときも、読み解きたい呼び出し元から下に向かって読む
でも、TDDでは
一番下の関数のテストを書くところが始まりで、全体を見渡して始められない
同じことやったことがあれば、上がわかってるから、下から始められるけど
そうでなければ、テストかコードにダミーをたくさん作らないとTDDできない
それか、必要なモジュールやインターフェイス設計できてるか
0692デフォルトの名無しさん2014/08/15(金) 10:46:38.91ID:xWfNVD54
>>691
> 一番下の関数のテストを書くところが始まりで
そんなことない
0693デフォルトの名無しさん2014/08/15(金) 12:29:14.22ID:EgVSDQDB
>>691
一度、実践テスト駆動開発(GOOS本)読むといいよ
ボトムアップだけでなくトップダウンのテスト(end to end test)が解説されてるから。
0694デフォルトの名無しさん2014/08/15(金) 12:31:16.26ID:Yv/H2Jww
いべんとどんぶり
0695デフォルトの名無しさん2014/08/15(金) 18:20:42.14ID:4ECeDEW3
テストが必要そうなところのテストだけでも書くとよいよね
0696デフォルトの名無しさん2014/08/16(土) 01:54:58.16ID:rUIBv51N
>>693
本に書いてある。じゃなくて、実際どうやってるの
E2EテストでTDDするって、突き詰めていったら、
画面の設計もないのに、ボタンクリックしてこの表示がでるっていうテストを先に作ることになるよ
設計ができてるから、そういうE2Eテストが作れるんじゃないの
途中のAPIのテストを先に書くのは簡単だけど、それは下から作っていくことだと思う
0697デフォルトの名無しさん2014/08/17(日) 14:30:12.51ID:PHQzH28y
工事現場で足場組んだりするのも
無駄だからやるなって言い出しそうだな
0698デフォルトの名無しさん2014/08/17(日) 16:22:26.54ID:W/wWGkFr
>>697
宙に浮いてやればいいじゃん(迫真)
0699デフォルトの名無しさん2014/08/18(月) 13:37:54.98ID:FRp9W7WN
工事現場の足場は建築物のテストなんか？
0700デフォルトの名無しさん2014/08/19(火) 23:59:32.76ID:dXNr+R/q
テスト駆動は設計手法ってのを知らない人が何をいっても説得力が...
0701デフォルトの名無しさん2014/08/20(水) 00:02:44.88ID:dXNr+R/q
まーつまり、最初に設計してしまう日本SI的ウォーターフォールとは相性最悪だわな
0702デフォルトの名無しさん2014/08/20(水) 20:41:37.71ID:pB9nhskw
>>696の言う設計とは何なんだ
画面デザインの話？
それともHTMLみたいな画面の実装のこと？
それとももっと前のアーキテクチャとか？
設計じゃなくて要求？

どれを当てはめてみてもピンとこない
0703デフォルトの名無しさん2014/08/23(土) 09:25:18.67ID:P1R2bDm7
TDDってJavadocに書くような内容をコードで書くだけ。

メソッドの内部実装に入る前にin,outをJavadocに書くような開発をしていれば、そのまま自然にTDDを適用できる
コードを書いた後でなければJavadocを書けないようなプログラマにはTDD無理
0704デフォルトの名無しさん2014/08/23(土) 09:40:03.50ID:xMD8sMaI
そうやって何度もムダにコンパイルさせる手法でC++プログラマが救えると思っているのかァッ
0705デフォルトの名無しさん2014/08/23(土) 09:54:00.81ID:VzEIcDK4
>>702
> 画面デザイン
それは仕様だろう。
0706デフォルトの名無しさん2014/08/23(土) 11:09:26.71ID:CC5Cm+20
TDDで記述したいのは設計や要求や仕様ではなく「未実装」だろう

仕様が満たされたことを証明するには大量のテストが必要
だが未実装な箇所を一つだけ指摘するテストはすぐに書ける
証明より反例の方が簡単ということ
0707デフォルトの名無しさん2014/08/23(土) 11:26:02.64ID:3qxK8v5g
テストの自動化なんかしたらテストのテストしなきゃいけないじゃないか
0708デフォルトの名無しさん2014/08/23(土) 12:47:22.90ID:xMD8sMaI
電子レンジでフランス料理のフルコースが作れないからといって不良品だと騒ぐのか？
0709デフォルトの名無しさん2014/08/23(土) 13:48:03.40ID:WYvsIxCv
テストファーストの話を聞いた時、
最初に見せられたテストケースの例が
加算と乗算の実装に先立ってテストを作成する、
というものだったのだが、
(3 + 4) * 2 が 14 になることを確認する
ってのだったんだよね。
これって「加算と乗算をテレコで実装しちゃった！」
っていうバグを見逃すんだよね。（3*4)+2 も 14 だろ。
見事すぎだろテストファーストw
って思ったね。
0710デフォルトの名無しさん2014/08/23(土) 13:50:37.30ID:wmqLPypi
愚者は経験に学ぶ
って言葉の重みがよく伝わるレスだな。
0711デフォルトの名無しさん2014/08/23(土) 14:04:30.55ID:3qxK8v5g
教科書より経験のほうが正しいって絶対
0712デフォルトの名無しさん2014/08/23(土) 14:08:02.30ID:5cJG04Dw
常に疑え。
0713デフォルトの名無しさん2014/08/23(土) 14:13:33.81ID:xMD8sMaI
教科書に書かれたコンテンツをインスタンス化する環境とパラメータに誤りがある
0714デフォルトの名無しさん2014/08/23(土) 16:59:20.08ID:VzEIcDK4
>>709
見逃しても何の問題もないだろ。
そもそも、何かの計算をして値を返す関数は
return 14; だけのコードでもテストは通るんだよ。
で、これで問題ない。

そもそも「書いたテスト」というのは完璧であることは絶対に証明できない。
つまり、テストにミスが有ることは当たり前の話。
人間がやったって、テストでミスをしてバグを見逃すことがある。

テスト駆動開発というのは、最初14を返すコードを書いておき。
そしてその後14を返す正しいコードに書きなおしていく。
これがテスト駆動開発。違いは実行結果が14になっているかな？という
確認をprintでもして目視でやるか、コンピュータでやるかの違い。

で、これは「開発」作業であり、テストではない。
テストは開発中（または開発後）につけたしていく。
これも手動でやってもいいし、コードで書いてもいい。

開発もテストも、手動でやる方法もあるし、コードでやる方法もある。
コードで書くと何度も実行できるというメリットがある。
その反面コードを書くための時間が必要になる。
どちらがいいかは場合によって変わる。

テストコードを書くのは時間がかかるので、全てにテストコードを書くべきだとは思わない。
重要な部分とか、修正があった時に影響範囲が大きくなりそうな所はテストを書くが、
コードが十分シンプルで仮にバグが入るとしたら記述漏れ程度。動かしてみて動かなけれ
ば修正して数分で作業完了。みたいな所はテストは不要。

テスト駆動開発でも、最初に書いたreturn 14と、最終的なコードに大きく差があるのであれば
テスト駆動開発した方がいいが、return (3*4)*2みたいに処理がシンプルなものはテスト駆動開発の意味が無い。
俺が書くコードは、大部分がシンプルなコードばかりなので、テストコードを書く時間がペイしない。
0715デフォルトの名無しさん2014/08/23(土) 17:27:55.06ID:xMD8sMaI
テストが無駄にならないように関数I/Fを切っていくと自然に良い設計になる
0716デフォルトの名無しさん2014/08/23(土) 22:32:16.97ID:Jwg/Lhcu
>>715
テストを前提にしなければモジュール間結合度の低いコード設計ができない、
そんな技術レベルのプログラマにはTDDが適している、ってことね
0717デフォルトの名無しさん2014/08/23(土) 23:04:06.83ID:xMD8sMaI
いや、まともな論理的思考のできない奴はプログラマに向いてない
0718デフォルトの名無しさん2014/08/25(月) 18:08:20.28ID:WgdLBA0+
テスト駆動って、作っては動かし、直しては動かしを繰り返す、論理思考のできない人のためのメソッドでしょ？
頭で十分、論理思考できていれば、早々テストに失敗することがないので、テスト駆動が不要
0719デフォルトの名無しさん2014/08/25(月) 18:45:24.99ID:Aif44Mkk
そういう絵空事言うやつのために作られたんだよ
0720デフォルトの名無しさん2014/08/25(月) 19:04:00.08ID:clHBdfGA
今日から教習所を出て公道での実習に進みます
0721デフォルトの名無しさん2014/08/25(月) 19:33:21.63ID:fQ2cskxs
printfみたいなのを作ろうとするときは
テスト駆動がいいんだよね。

printfは複雑で条件分岐やループがあるはずだから作りながら
リファクタリングを繰り返していくことになるはず。

だけど、abs関数みたいなのは動きもほぼ一直線で処理も単純。
こういう場合にテスト駆動でやると、時間がかかるんだよ。

いい悪いではなくて、時間の問題。どっちが時間がかからないかという話。
0722デフォルトの名無しさん2014/08/25(月) 20:22:35.35ID:o3Iqlg8X
別にテスト駆動だからといって、全部の関数に対して書くわけじゃないですし
0723デフォルトの名無しさん2014/08/25(月) 20:30:41.98ID:fQ2cskxs
テスト"駆動開発" っていう名前にしたのが悪い。

テスト駆動開発っていうのはプロジェクトに
導入するものではない

悪い例 「今回のプロジェクトはテスト駆動開発を導入する」

開発者個人が関数を作る時にテストファーストで
作っていくかどうか、関数ごとに選択するもの。

テスト駆動開発という名前をなくして、
残すならテストファーストにして、対義語として
テストラストって言葉も作ったほうがいいな。
0724デフォルトの名無しさん2014/08/25(月) 20:56:07.68ID:UaEEVYk5
abs関数みたいなもので時間がかかる、って
たんにやり方知らんだけなんじゃ・・・
0725デフォルトの名無しさん2014/08/25(月) 21:13:18.88ID:zkRvpYjm
カバレッジの上げ方は2通りしかない
コードに合わせてテストを増やすかテストに合わせてコードを減らすか
0726デフォルトの名無しさん2014/08/25(月) 22:58:59.07ID:vwMZpBcP
コードっていうか条件分岐な
0727デフォルトの名無しさん2014/08/25(月) 23:26:48.06ID:clHBdfGA
異常系がスカスカな高品質コードの出来上がり
0728デフォルトの名無しさん2014/08/25(月) 23:37:41.48ID:fQ2cskxs
>>724
テストを書かないって話をしてるんじゃないよ。

さっさとコードを書いて、その後テストを
書いたほうがいいって話。
0729デフォルトの名無しさん2014/08/25(月) 23:59:12.20ID:9zG1fAHJ
受け入れテストから書くのが大体のテスト駆動において普通だと思うんだが

そりゃ粒度低いところまでテスト書くなら、先に書こうが後に書こうがめんどくさいのは代わりないっしょ

シンプルな関数にさえも、テストを先に書くことを強制するのがテスト駆動じゃないっす
0730デフォルトの名無しさん2014/08/26(火) 11:44:45.36ID:vdVtuZFs
× テスト駆動開発
○ テスト駆動コーディング
0731デフォルトの名無しさん2014/08/26(火) 12:03:02.61ID:HrT/idVN
テストしやすい単位に切り分ける設計も含むだろ
0732デフォルトの名無しさん2014/08/26(火) 12:22:12.77ID:vdVtuZFs
>>731
勝手に関数作らないでください
0733デフォルトの名無しさん2014/08/26(火) 17:06:09.66ID:bX+RdUeX
コーディングルールとして、javadocレベルで、コードと同時に開発していくなら、受け入れられる
でも、テスト「駆動」でテストを先に作れって後ろ向きに歩きながら前進しろと言われてるようでダメ
嫌いなもの先に食べるみたいに、最初にテスト書いたら、あとでテストしなくていいなら、まだいいけど
最後にも、やっぱりテストが、待っていて、またテスト開発することになって、非効率
0734デフォルトの名無しさん2014/08/26(火) 19:20:26.06ID:LNyDRwAI
>>733
それは反復型の手法そのものが非効率だという立場だろ
たしかにミスしなければウォーターフォールが最も効率が良い
0735デフォルトの名無しさん2014/08/26(火) 19:22:34.52ID:IPwBXJgH
テスト駆動開発を厳密にテストを書いてからコードを書く
という流れしかやってはいけないものとする。

たとえば四捨五入の関数を作る。

0.5を引数にしたら1になること。というテストを書く。
それが失敗するのを確認した後コードを書く。

ここまではテスト駆動である。

だがもしかしたら間違えて銀行型まるめになっているかもしれない。
（端数がちょうど0.5なら切り捨てと切り上げのうち結果が偶数となる方へ丸める）

確認のためにテストを追加する。
しかし問題がなければコードを書かない。

※テスト駆動開発になっていない。
0736デフォルトの名無しさん2014/08/26(火) 19:23:32.61ID:IPwBXJgH
つまり、テスト駆動開発の流れは
このようになっているということ。


一部のテストを書く → テスト駆動開発 → 残りのテストを書く
0737デフォルトの名無しさん2014/08/26(火) 19:26:43.73ID:IPwBXJgH
テスト駆動開発でも結局、開発した後に
足りないテストを書くのだから

・　一部のテストを書く → テスト駆動開発 → 残りのテストを書く
・　　　　　　　　　　　　　　　通常の開発 → テストを書く（一部のテスト含む）


こうでもいいではないか？

この場合開発の量とテストの量はどちらも変わらない。
0738デフォルトの名無しさん2014/08/26(火) 19:32:51.87ID:IPwBXJgH
テスト駆動では先にテストを書く。ということは
開発で何かしらの問題が出て仕様が変わった時
先に書いたテストが無駄になるというメリットがある。
0739デフォルトの名無しさん2014/08/26(火) 19:33:17.90ID:IPwBXJgH
×メリット
○デメリット
0740デフォルトの名無しさん2014/08/26(火) 19:39:53.07ID:gwgSiSgh
つまりコードが安定しない初期段階では
テスト駆動はデメリットが大きいということになる。

だが初期段階を過ぎると、コードが洗練され
量産的なコードは、凄くシンプルになる。
難しいコードは共通関数部分に隠蔽されるから。

共通関数ほどテストは重要であるが、
変化が大きいためにそういう関数ほどテスト駆動のメリットが少なく
（テスト駆動しないだけでテストは書きますよ）

反対に量産的なコードはテストそのものの価値が少ない。
（コードというより定義ファイルレベルになってしまうから）
0741デフォルトの名無しさん2014/08/26(火) 21:57:31.21ID:LNyDRwAI
不安定なコードを人に見せるのは無駄どころか迷惑だ
最初に書くのはなんでもいいけど最初に見せるのはテストが良い
0742デフォルトの名無しさん2014/08/26(火) 23:14:17.34ID:3+0a9yno
>>740
>>734
0743デフォルトの名無しさん2014/08/26(火) 23:20:42.74ID:FPD+nRe0
なんでそもそも、関数がテストの単位なんだ...
最近のspec系のフレームワークなら、機能単位のテストが先やろ
0744デフォルトの名無しさん2014/08/27(水) 00:07:37.72ID:H4UioQzk
振舞駆動が振動駆動に見える
0745デフォルトの名無しさん2014/08/27(水) 09:04:29.64ID:D1kHPcdG
進藤×工藤
0746デフォルトの名無しさん2014/08/27(水) 19:25:57.01ID:YlHm9xBL
>>743
テスト駆動はユニットテストでもspecでもない。
0747デフォルトの名無しさん2014/08/28(木) 16:14:35.63ID:cWf/NZ2v
でもユニットテストにも使えないテストを、コード書くために、書き捨てるなんて効率悪すぎ
0748デフォルトの名無しさん2014/08/28(木) 18:29:08.79ID:z9uMTwZv
でも捨てたデータが多いほど開発が捗ってるんだよな
捨てたデータを保存して解析すれば色々分かるかもしれない
0749デフォルトの名無しさん2014/08/28(木) 18:47:38.64ID:5uTBO9xo
何だその珍説は
0750デフォルトの名無しさん2014/08/29(金) 01:40:42.04ID:h1bgB9ga
>>747
向き不向きがあるんじゃね
例えば稼働中の Web システムが定期的なセキュリティ診断で引っかかったとか、
動いてるシステムの動作を変えずに根深い部分の実装を改修するときは、
TDD は適合性が高いと思う
逆に新規プロジェクトで立ち上げから TDD でやろうとするといろいろ問題があるわな
0751デフォルトの名無しさん2014/08/29(金) 12:28:35.29ID:w9uKf29m
うんこ
0752デフォルトの名無しさん2014/08/29(金) 14:14:40.00ID:gqrcAKYi
>>750
それTDDじゃねーからｗｗ
0753デフォルトの名無しさん2014/08/29(金) 17:59:42.98ID:qvYCvJvM
>>750
直感的には逆だな
機能の追加は簡単だが機能を変えない改修 (リファクタリング) は難しい
TDDの胡散臭さの半分以上はリファクタリングのせいだ
0754デフォルトの名無しさん2014/08/29(金) 18:27:40.92ID:qvYCvJvM
改修とは削除と追加を同時にすることだから単なる追加より難しい
0755デフォルトの名無しさん2014/08/29(金) 23:32:48.64ID:9OWc8ATu
>>753
言ってることが対称になってないぞｗ

・機能の追加は簡単
・機能を変える改修（変更）
・機能の削除

違いを比べるならまずこれだよな？

追加は簡単・変更と削除は難しい。
ここまでOKだろ？

で、変更は機能の追加と削除が同時に行われるため。
変更は一般的に難しいが、リファクタリングに限って言えば
機能の追加も削除も行わない（単なるコードの場所移動）のため簡単。

これであってるよね？
0756デフォルトの名無しさん2014/08/29(金) 23:35:57.34ID:9OWc8ATu
ちなみにTDDでやってるのはリファクタリングではない。

なぜなら、テストコードを失敗される→コードを書く
という行為は、テストに通らないコードから
テストに通るコードに機能が変わっているから。

たとえば関数に新しいオプションを追加する
機能拡張をTDDで行ったと考えてみよう。

機能拡張はリファクタリングか？
一発で違うってわかるよな？
0757デフォルトの名無しさん2014/08/29(金) 23:53:54.80ID:49gCfOM1
お前、TDD知らないだろ
0758デフォルトの名無しさん2014/08/30(土) 02:39:08.23ID:Y3aOlWd0
まあテストは必要だが、Chromiumなどの大規模プロジェクトをウォッチしてると
テストだけではダメだということが確信できるよ

・たくさんのテストが失敗している状態が常態化していて、最早まったく気にかけられない
・致命的で、緊急性の高い不具合が報告されても、「誰かテストケースくれ」と調べようともしない
・あらかじめ予測できない（当然テストも存在しない）斜め上の不具合が次から次へと無限に湧いてくる

銀の弾丸ではないの一言で済む話ではあるけどな
0759デフォルトの名無しさん2014/08/30(土) 09:50:01.45ID:36lVqRoI
大規模プロジェクトは基本何やっても駄目
0760デフォルトの名無しさん2014/08/30(土) 10:59:04.70ID:27ULfS3N
Chrome37の悲惨な状況もそうだけど、GitHub眺めてても、テスト書いてないプロジェクト多いし
新しめのプログラミング本でも、テストは最後に、数ページあるだけだし、テスト駆動は、掛け声だけと思う
0761デフォルトの名無しさん2014/08/30(土) 11:16:36.21ID:ZWIpt6n5
外から押し寄せるエイリアン的な何かではなく
便利に使える道具・習慣
0762デフォルトの名無しさん2014/08/30(土) 12:13:26.81ID:yDZGZz9U
>>757
お前はTDDもプログラミングも人生も何も知らないだろ。


（このレスは、知らないだろというだけで理由を言わないのなら
誰だってなんだって言えることの実例ですｗ）
0763デフォルトの名無しさん2014/08/30(土) 13:02:02.31ID:eS6LHcvr
最初は小さなモジュールでTDDやってそれを積み重ねてシステムするのがいいんだろうけど
仕事が来るのは緊急度高く結合度の高いものばかり
レガシーコード改善ガイドを一部やるので精一杯
0764デフォルトの名無しさん2014/09/03(水) 00:52:44.68ID:jrX5bhg9
最初はできても、途中から、それどころじゃなくなる
0765デフォルトの名無しさん2014/09/03(水) 06:24:38.13ID:tooOFXPg
それどころじゃなくなった所で撤退するのが理想
現実はギャンブル中毒のように大損するまでやめられない
0766デフォルトの名無しさん2014/09/07(日) 16:16:13.23ID:2nNDq8Bj
テスト駆動はコードを打ち込む人が慣習として行うことであって、テスタとかプロジェクトとかを用意して仰々しく行うことではないので、撤退とかそういうのはないから
0767デフォルトの名無しさん2014/09/07(日) 17:21:34.06ID:LA1JcmO8
>>766
えーそうなの？
末端ほど仕様コロコロ変わるから難しくないか？
0768デフォルトの名無しさん2014/09/07(日) 18:01:28.55ID:Jj7RgHk6
>>758
>・あらかじめ予測できない（当然テストも存在しない）斜め上の不具合が次から次へと無限に湧いてくる

まさに本質ってこれじゃね？
最初からテスト書いているということは要するに分かってることやっているだけだ
から、「丁寧にコーディングする」のとレベル的に同じなんだよね。

で、実際にプログラムでの本当の困難はそういう想定できないところ意外のバグにあるわけだから

効果が全くないわけじゃないけど、テスト駆動は過大評価させられすぎ
大して効果がないのに、手間がかかるデメリットも多い
これを無条件に習慣づけるべき良いこと、なんて言われると違和感ありすぎ
0769デフォルトの名無しさん2014/09/07(日) 19:02:37.29ID:JJ1m+vUL
むしろ変更の被害を減らすためにテストするんだ
0770デフォルトの名無しさん2014/09/07(日) 19:08:54.14ID:7I9u/spB
不具合の原因は2通り
・正しくないコードを書いたから ←バグ
・テストに関係ないコードを書いてないから ←未完成
テスト駆動で作ると完成度は低いがバグは少ない
0771デフォルトの名無しさん2014/09/07(日) 20:50:18.39ID:2nNDq8Bj
コードを打つ前にどうテストできるか(コードの正しさをどう確認できるか)を理解しなくてはならない
バグが出てきた後でそれを考えても二度手間
0772デフォルトの名無しさん2014/09/08(月) 19:07:14.96ID:NP5eQWMU
テストを書かずに、最後までコードがバグらないのは、奇跡だけど
テスト駆動で、最後までコードを書けるのも、奇跡の環境だと思うよ
大抵の会社やプロジェクトなら、
テスト書く時間がないくらい、仕様変更、追加、おまけに原因不明のバグがやってくる
0773デフォルトの名無しさん2014/09/08(月) 22:19:05.17ID:WRBqI71e
だから、テストとテスト駆動は違うから。

テスト駆動をしなくてもテストを書く。
だから「テスト」に関してはどっちも同じ。

テスト駆動をしたらテストも完ぺきにできると思ったら
それは間違い。テストの一部分ができるに過ぎない。
だからテスト駆動をしたとしても追加のテストを書く必要がある。

内訳はこんな感じ

マニュアル駆動開発 （50%）＋ テスト（50%） ＝ 完成
テスト駆動開発（50%＋25%）＋残りテスト（25%）＝完成

理論的にはこうなる。ただしこれはバグが含まれない場合。
バグが有る場合、マニュアル駆動開発では修正にテスト駆動の数倍かかる（回帰テストが出来ないから）
だからテスト駆動開発のほうが優れていると言われるが、マニュアル駆動開発ではテストを省ける。
テストを省くとこうなる。

マニュアル駆動開発 （50%） ＝ 完成（50%）
テスト駆動開発（50%＋25%）＝完成（75%）

テストを省くとはとんでもない！と思うかもしれないが、マニュアル駆動開発では
テストコードを書かないだけで、目視でテストをしている。

これって技術力が高い人がシンプルなモジュールを作る場合はそれだけで十分な品質になる。
客観的な証明はできないんだが、バグがないか軽微なバグで終わることが事実としてある。

そしてテストコード必要ならば後から追加すれば良い。
テストコードを含めたら50%の完成であっても問題なく使えるのならいいわけで
時間的余裕があった時にテストコードを追加するという戦略が取れる。
0774デフォルトの名無しさん2014/09/08(月) 22:39:36.40ID:7g2N52pA
だから、
テスト駆動はテストの手法じゃなくて、
どちらかといえば設計手法なんですがががが
0775デフォルトの名無しさん2014/09/08(月) 22:48:39.54ID:AyVNnGAs
>>772
コーディングする人が、自分の打ち込んだコードに対する責任としての慣習なんだから、会社もプロジェクトも関係ない
0776デフォルトの名無しさん2014/09/08(月) 23:02:27.01ID:yNweFT3r
お客さんがテスト工数を嫌ったからだよ
0777デフォルトの名無しさん2014/09/08(月) 23:03:22.47ID:7g2N52pA
自分で設計して自分で書くってことができない日本の大部分のプログラマには関係ない話ですます

SEって職種があるとこにはそもそもお門違いの話なんだから流行るわけがない
0778デフォルトの名無しさん2014/09/08(月) 23:09:56.75ID:AyVNnGAs
テスト　＝　コーディングとは別の工程で、コードを書いた人とは別の人が担当することが多い
テスト駆動　＝　コーディングする人がそのコードを書く際に行う慣習　(エディタはこまめに保存しろ、とかと同じレベルの慣習)
0779デフォルトの名無しさん2014/09/08(月) 23:32:16.19ID:nnXcaq6b
コードを書く際にテストを書く時間があるなら、
その時間を(コーディング前の)設計に費やほうが前向きだと思う
たとえばUMLクラス図や状態遷移図/表を描いてみるとかね
特に最近は Alloy Analyzer や SPIN のように、
設計そのもののバグ摘出を支援するツールが手軽に使える訳だから

テストは：
・設計に対して正しく実装(コード化)されているか？
・改造やバグ対策時にデグレードしていないか？（リグレッション）
の為に必要であって、設計時には不要な存在
0780デフォルトの名無しさん2014/09/08(月) 23:36:08.75ID:AyVNnGAs
建物が水平に建てる方法は知っているが、目の前の床が水平かどうか確認する道具を用意しない人がビル建設に関わってはいけない
0781デフォルトの名無しさん2014/09/08(月) 23:47:54.62ID:I1j4dToZ
>>779
ドッグフーディング
0782デフォルトの名無しさん2014/09/08(月) 23:54:58.04ID:2BYBRDtu
結合試験以降の工程は試験（テスト）じゃなくてリハーサルとでも呼んだほうが
いいんじゃないかと思う今日このごろ。
0783デフォルトの名無しさん2014/09/08(月) 23:59:30.09ID:7g2N52pA
>>779
テスト駆動は設計手法です
設計を先にやるのであれば、テストを実装前に書こうとも、それはテスト駆動ではないです
0784デフォルトの名無しさん2014/09/09(火) 00:03:28.92ID:gE54p7sq
コードを打ってる最中には、そのコードの正しさを確認するスクリプトを用意されてないという人が多いということにカルチャーショックを覚えたり
0785デフォルトの名無しさん2014/09/09(火) 00:08:59.98ID:u4pMEKRn
>>783
> それはテスト駆動ではないです

もちろん、その通りだよ
自分は TDD 否定派だからね

ついでに言えば、ラティショナルうんたらかんたらとか
エクストリームむにゃむにゃとかアジャイルふがふがみたいな、
中身の無い精神論に基づく設計手法にも否定的だ
0786デフォルトの名無しさん2014/09/09(火) 00:09:53.88ID:egYedAa7
本当にできるプログラマはテスト駆動開発なんてしない
そういうのに強制されないとできない凡庸なプログラマには役に立つのかもしれんが
0787デフォルトの名無しさん2014/09/09(火) 00:12:09.90ID:gE54p7sq
本当にできるプログラマは、自分の正しさに疑いを持てるプログラマです
0788デフォルトの名無しさん2014/09/09(火) 00:16:52.67ID:jCyK5G6Y
プログラムのバグのほとんどは、コーディングではなく、
設計のミスから生じるので、それらを減らすための設計手法

人は抽象的なものを理解できないので、
問題を具体化し、それを人に突き付けることで、
考えさせたり、見直しの機会を与える

先に入力画面・戦闘画面などを作ると、仕事がはかどるのと同じ
0789デフォルトの名無しさん2014/09/09(火) 00:19:18.37ID:0xzWguT1
>>785
なるほど

とはいえ、先に全部設計して実装ユニットテスト結合テストまでやるウォーターフォールではうまくいかないと感じる人が多いから、アジャイルやらTDDの考えが出てきてるわけで

TDDよりベターであるなら、そもそもTDDは生まれなかったんではないですか
0790デフォルトの名無しさん2014/09/09(火) 00:20:38.42ID:kIMuAYU9
>>787
いいこと言うじゃないか
0791デフォルトの名無しさん2014/09/09(火) 00:28:42.39ID:T7NoFdsA
>>786
「それはテスト駆動ではない」とか言うのは強制だけど
「どっちでもいいよ」って言えば強制じゃないから
テスト駆動の定義を狭くするのをやめればいい
0792デフォルトの名無しさん2014/09/09(火) 00:30:09.68ID:gE54p7sq
>>788
今自分が打ってるコードが、設計通りにコーディングされてることはどう確かめましょうか
少なくとも、確かめるくらいはするんですよね？
0793デフォルトの名無しさん2014/09/09(火) 14:06:41.34ID:kp00Q8e9
>>783
> テスト駆動は設計手法です
> 設計を先にやるのであれば、テストを実装前に書こうとも、それはテスト駆動ではないです

設計ってどこまでのことを言ってるんだろう。
完全にとまでは行かなくても、設計がある程度頭の中にでも出来てないと、
テストは書けないと思うんだけど。
0794デフォルトの名無しさん2014/09/10(水) 01:20:01.79ID:84u7ItZR
Java以外の言語だとMavenやJenkinsみたいな環境ないから大変だろうな
Javaは進化が遅いとか言われるが環境構築技術だけは伸びてるな
0795デフォルトの名無しさん2014/09/10(水) 07:47:05.60ID:taL9Fgui
随分とでかい釣り針だな
0796デフォルトの名無しさん2014/09/10(水) 21:25:34.21ID:MIzNsnl2
>>789
遅レスになったけど....

まず「テスト駆動は設計手法です(>>783)」と言うのなら、
ウォーターフォール型開発プロセスにも適用できるはず
構造設計工程の後半から単体テスト工程までをTDDに入れ替えればいい
TDDが設計手法であれば、何の問題も無いハズだろ？

次にアジャイルについて、おそらくウォーターフォールとの対比として
アジャイルという用語を選んだのだと思うけど、
設計/実装/テスト/評価という一連のステップを小刻みに反復する
インクリメンタルとかスパイラルとか呼ばれる新しい開発プロセスは、
少なくとも1990年代には世の中で知られるようになっている
アジャイルに固有な新しい特徴は、開発プロセスにエンドユーザを巻き込む点だけ

だからアジャイルとTDDとは無関係だし、TDDが存在していない
1990年代でもスパイラルな開発プロセスは知られていたのだから、
これらはTDDの有効性を主張する根拠には成り得ない

最後に、TDDが生まれた背景はこちらが聞きたいくらいだね
設計ができない人でも設計できた気分になれるアイデアにしか思えない
言い換えると「動いているコードが仕様です」という、
「人月の神話」の時代よりさらに以前の遺物的発想に見える
0797デフォルトの名無しさん2014/09/10(水) 22:08:20.52ID:nyQ2OFq5
>>796
テストされていないコードを在庫にたとえると
在庫は最小化したいという発想に見える
遺物的には見えない
0798デフォルトの名無しさん2014/09/11(木) 00:59:57.82ID:vleFyoUy
>>796
TDDは反復手法が前提
とはいえウォーターフォールにも使えるけどね
0799デフォルトの名無しさん2014/09/11(木) 01:20:17.03ID:rnoUsVZ3
>>796

あれ、その流れであっててなんで関係ないのか分からないです

スパイラル→TDD→アジャイル

って発展してきている認識なんだけど、TDDとアジャイルは関係ないの？

あともういっこ、
ウォーターフォールの標準的な工程にリファクタリングの文字が含まれているのか(反語

リファクタリングを矯正するのもTDDの利点だと思いまする
0800デフォルトの名無しさん2014/09/11(木) 05:19:24.37ID:c+/7MXMA
プログラミングが今ほど民主化されてなくて、一部の専門職だった頃は、
テストは少なく、バグも少なかったけど、ソフトウェアの仕事が爆発的に増えて、
そこらじゅうの、ソフトに向かない人まで、入門書片手に、プログラミングするようになり
バグが増えまくり、ソフト開発が、あちこちで、破綻するようになった
テストもやりきれなくなり、自分が作ったものくらい、自分で保証しろ、となってきて
都合のいい、テスト駆動、という名前と、手法が始まったと思ってる

本質的に、仕様の間違いやバグは、自分で見つけられないから、
テスト駆動は、テストの名前を借りた、別のものでしかないと思う
設計なんかではなくて、ていよく、開発者を矯正するような何か
0801デフォルトの名無しさん2014/09/11(木) 08:52:13.94ID:SUJSLbWq
コードは書ききれるがテストはやりきれない

商品を大量に仕入れたら売れ残って破綻したと言ってるのと同じ
08027932014/09/11(木) 14:40:24.82ID:UA4rAEmE
テスト駆動というかアジャイルの入門書を立ち読みしてきたけど（だから浅い理解だろうけど）、
テストを先に書くというのは、実際にコードを書く前にそのコードの使い方を書いてみて、
コードの使いやすさや設計を確かめるという役割があるのかなと理解した。
わら半紙に絵のラフをとりあえず描いてみるみたいな。
もちろん、テストの役割も兼ねているから、好き勝手に試し書きをしても良いという訳ではなくて、
それなりの節度をもってテストを書くべきなんだろうけど。

テスト駆動が設計手法というのは少し言い過ぎな気がしないでもないけど、
設計の助けにもなるという意味で、
テストを先に書いてみるというのは、開発にある程度有効なのかなと思った。
0803デフォルトの名無しさん2014/09/11(木) 16:37:34.29ID:qRcLUhhX
テスト（実際に呼び出すコード）を何パターンか書いてみて、初めて気づく何かというのもあるからね。
逆に言うと、コードを書く前に細部まで全てもれなく設計されているというのは、設計のやりすぎな気がする。
0804デフォルトの名無しさん2014/09/11(木) 20:00:47.63ID:WdQgW6yP
>>797
テストの目的やその定義によりけりだね

もし「テストコードを書いて、それがすべてパスすること」をもって
「テストした」とするなら、その(>>797)解釈でも不思議は無い

自分のテストの目的は >>779 の後段に書いた
これらの目的を達成するには(テスト対象のコードと同様に)
テスト仕様/テストケース/テストコードも長期間の保守に耐えられる必要がある
言い換えると、適切に「テスト設計」して「文書化」することが前提になる
つまり「動いているコードが仕様です(>>796)」と同様に、
「動いているテストコードがテスト仕様です」という発想も否定する
0805デフォルトの名無しさん2014/09/11(木) 21:04:23.04ID:WdQgW6yP
>>799
>って発展してきている認識なんだけど、TDDとアジャイルは関係ないの？

アジャイルは(>>796で書いたように)開発プロセスにエンドユーザを巻き込む手法だから、
TDDとは関係ない


>ウォーターフォールの標準的な工程にリファクタリングの文字が含まれているのか(反語

古典的なウォーターフォールでは含まれていない
ただし、(同じく>>796で書いた)1990年代に知られていたスパイラルでは、
リファクタリングに対応する用語として「制御された再作業(controlled reworking)」がある
たとえば「動くプログラムを開発する」という目的で最初のスパイラルを廻し、
次に「品質改善」を目的とする２回目のスパイラルを廻す、という開発プロセスを認めている

ウォーターフォールへの問題を改善する手法としてプロトタイピングが考案されたのが1980年代、
その後に開発プロセスという概念が生まれ、そこからインクリメンタルやスパイラルといった
(ウォーターフォールに代わる)新しい開発プロセスが1990年代に登場するという歴史を経ている


>リファクタリングを矯正するのもTDDの利点だと思いまする

テストを前提にしなければリファクタリング(=コードの品質改善)ができないプログラマであれば、
TDDに頼るのも「しかたがない」のかもしれない
0806デフォルトの名無しさん2014/09/11(木) 21:45:18.34ID:pBD/TCdZ
1970年に発表されたオリジナルのウォーターフォールにはリファクタリングはあった。

というか、上位工程に誤りがあるのは所与の問題で、誤りが発見されても現工程から
1 工程分しか差し戻しをしなくていいようにするには、どういうふうに設計・実装・テスト
をおこなったらいいかというのがオリジナルのウォーターフォールの主旨

1975年に米国防総省が、ソフトウェアの開発体型を作った時に、オリジナルの
ウォーターフォールを劣化コピーして、工程の差し戻しという概念を削ってしまった。
誤りが起きるのは実装工程のみというマッチョな思想に基づく。

そして現在に至る
0807デフォルトの名無しさん2014/09/11(木) 22:00:56.27ID:RRfo7wHo
>テストを前提にしなければリファクタリング(=コードの品質改善)ができないプログラマであれば、
>TDDに頼るのも「しかたがない」のかもしれない

なんだこれ
TDDとか一切関係なく「テストがあればリファクタリングがより安全に素早く行える」ってのは割と普遍的な事実だと思うんだが

別にTDDが正しいとか押し付けたいわけじゃなくて
TDD嫌いが昂じすぎて色々見誤ってやせんか？
08088062014/09/11(木) 22:02:28.83ID:pBD/TCdZ
なんか、藁人形論争のループになっている感じがする。

「テスト駆動推進派は、コーディング前にC1相当のテストを作れと言っている、
そんなの無理」
「テスト駆動否定派は、コーディング前に設計書のドライランもやらないって
言っている。それではまともな開発なんて無理」

少なくとも実装前に正常系のシナリオを何パターンか明確にしてから実装に入る。
少し手間だけどそいつらテスト仕様書 (可能なら自動テストコード) に起こしてから
コードを書く。
ぐらいの緩めからテスト駆動って呼んじゃダメ？

そしたら、みんなテスト駆動開発推進派。
0809デフォルトの名無しさん2014/09/11(木) 22:43:23.38ID:WdQgW6yP
>>806
いろいろと間違っているなぁ

まず、バグ対策とリファクタリング(=品質改善)は異なる概念を指す用語だよ
リファクタリングとは、テストが全件パスした(=すべてのバグを摘出した)後に、
機能(または外部インターフェイス仕様)を変更せずに内部の設計(または実装)だけを
改善するもの
設計段階のレビュー等で発見されたバグ、あるいはテスト段階で摘出されたバグ、
それらを前工程にフィードバックすることは、当然ながらウォーターフォール手法の一部だ

対して、前工程へのフィードバックが存在しない(魔法のような)開発手法はクリーンルーム法になる
魔法の種明かしは、形式的設計手法を前提にすることによって検証によりバグを0にする発想にある
当然、形式的設計手法を使いこなせるプログラマは少数だから、
クリーンルーム法は理想論として現場で普及することなく歴史の流れに埋もれていった

そして形式主義(formalizm)なクリーンルーム法よりも、実践主義(pragmatism)な
プロトタイピングが現場では歓迎されて普及していき、現在に到る(までを>>805 で書いた)
0810デフォルトの名無しさん2014/09/11(木) 23:12:49.59ID:vleFyoUy
>>808
いいんじゃね
新規ではBDDで正常ルート固めてから異常ルートのテストを後半にすることもあり、
既存機能を残す改修でテストがなかったらC1レベルのテストから固めることもある
メリットが活かせるように、仕事に合わせてやりやすいようにアレンジすりゃええのよ
0811デフォルトの名無しさん2014/09/11(木) 23:28:46.10ID:ohJ+TO5U
>>808
> ぐらいの緩めからテスト駆動って呼んじゃダメ？

駄目だろさすがに。
テスト駆動ってのは、テストが中心になって開発しないと。
0812デフォルトの名無しさん2014/09/11(木) 23:33:37.18ID:WdQgW6yP
>>808
その定義であれば、それをテスト駆動開発と呼んで
「個人の開発プロセス」に組み込むことは否定しないよ
一個人に割り当てられる(=品質に責任を負う)モジュールの規模は数Kから10数Kステップにもおよぶ
それをサブモジュール(たとえばJavaならパッケージ/クラス/インターフェイス)へと
適切に分解して定義していくプロセスには、常に試行錯誤が伴うものだ
むしろ、その「個人の(試行錯誤の)開発プロセス」を効率化するために
そうしたテストファースト的な手法の導入を考える発想は、
力任せに突き進むアプローチよりもずっと好ましいと思う

個人的には(>>779 で書いたように)時間をテストより設計へ費やすべきと思うけど、
個人が負う責任の範囲内であれば、つまり担当モジュール内部のコード設計であれば、
(リスクを含めて)個々が好む開発手法を選ぶ権利はあるはずだからね

対して明確に否定するのは、(個人の開発プロセスではなく)プロジェクトの開発プロセスを対象に
TDD をソフトウェア設計の方法論として捉える姿勢だ
アジャイルやらエクストリームとやらも同じ理由で否定する(>>785)
0813デフォルトの名無しさん2014/09/12(金) 00:04:27.90ID:D+NK/ExM
アジャイルが設計手法・・・？
なんでそうなったんだ
もしかして空想でものを語ってるんだろうか

顧客を巻き込んだチームの作り方であったり
開発における様々な変化を受け入れられる文化・環境の作り方であったり
強いていうなら開発手法の集合体みたいなものを指すと思うが
0814デフォルトの名無しさん2014/09/12(金) 00:13:17.20ID:DoZOHl3s
別チームが顧客を巻き込めないのにアジャイルして苦情いただく事案があったわ
TDDもそうだがフロントローディングは負荷が高いのかもしれん
0815デフォルトの名無しさん2014/09/12(金) 00:13:21.75ID:3yhh+IPH
>>813
失礼、>>812を訂正する

X：アジャイルやらエクストリームとやらも同じ理由で否定する
O：同様に、アジャイルやらエクストリームとやらを
　ソフトウェア開発の方法論として捉える姿勢も否定する
0816デフォルトの名無しさん2014/09/12(金) 00:42:04.60ID:Dld6l5to
１００人前の料理が欲しいとなった時に、１００人分の材料を用意して一気に作るのと、
１人前の料理を１００回作るので、どちらが効率的かと１００人前を一気に作る方だな。
ただ要求ってのは最初に決めたら絶対的に変わらないものでもない。 １００人前と
言ったけど、やっぱ１０人前でいいやとか、別のものも作ってよとかいう風に変わる
場合もある。 まとめて作るほうが効率はいいのだが、要求の変更や、作り終えた
時の周りの状況の変化に弱かったりする。 要求を小さく大量にさばこうとすると
オーバーヘッドが増えるが、変更による弱さを減らせる。 アジャイルってのは後者に
あたるんだけど、安いとか手間がかからないとか勘違いする人が後をたたなかった
りする。
0817デフォルトの名無しさん2014/09/12(金) 00:57:15.08ID:37/5+rHI
>>813
アジャイルの話が出てから話題が拡散しちゃってるな
>>814
TDDが必ずフロントヘビーになるってことはないんじゃないか
最初から GUI を絡めたフォーム全体に手を付けるより
ビジネスオブジェクトをBDDやTDDで手早く作るのが自分には合ってる
TDDとアジャイルはどちらも依存関係がないと考えたほうがしっくりくる
0818デフォルトの名無しさん2014/09/12(金) 10:34:13.52ID:YBqp6ci2
>>779
> ・設計に対して正しく実装(コード化)されているか？
> ・改造やバグ対策時にデグレードしていないか？（リグレッション）
> の為に必要であって、設計時には不要な存在

その「設計」の中に、テスト容易性は含まれてる？
0819デフォルトの名無しさん2014/09/12(金) 10:40:33.53ID:YBqp6ci2
ちょっとググってよさげなページを抜き出したからまあちょっと読んでみてよ。

テストの容易性を高める設計
http://msdn.microsoft.com/ja-jp/magazine/dd263069.aspx

これであなたもテスト駆動開発マスター！？
https://codeiq.jp/magazine/2013/11/1475/

TDDとテスト容易性(試験性)の関係
http://goyoki.hatenablog.com/entry/20100331/1270047115
0820デフォルトの名無しさん2014/09/12(金) 22:10:19.33ID:XcTB9vyQ
工程としては、テストではなくコーディングの話題なんだけどね
慣習の話なんだから
0821デフォルトの名無しさん2014/09/12(金) 23:32:32.75ID:3yhh+IPH
>>818
「含まれている」部分と「含まれていない」部分がある

まず「含まれている」部分」について、>>819の先頭記事
「テストの容易性を高める設計」の冒頭では、テスト容易性を以下のように説明している：
　　具体的には、関心の分離、凝集度、および結合度という古典的な設計品質、
　　要するに一般的に必要とされるようなことに関して、留意するということです。

おそらく古典的な設計というのは1970年代に始まった「複合/構造化設計」における
モジュールの独立性を高める「モジュール強度」と「モジュール結合度」という
２つの概念を指しているのだと思う
モジュールという言葉をクラスやメソッドに言い換えれば、
こうした古典的な設計品質の重要性はOOPが全盛な今の時代でも変わりはしない

次に「含まれていない」部分についてだけど、テスト容易性を達成する手段を解説した
二番目の記事「これであなたもテスト駆動開発マスター！？」に対する姿勢は全く異なる
この記事では、時間という不確定要因を含むコードについて、TDDを用いて正しい設計を
導く手法を具体的に解説しており、TDD支持者にとっては推薦されうる優れた内容なのだろう

しかし、自分の考えは全く異なる
先にも書いたようにモジュールの独立性を高めることの重要性は1970年代から知られている
そんな常識的な指針がテストを実行しなければ認知できない(=気付けない)ことが問題だ
この記事が対象とする問題の本質は「状態」という概念にある
状態は「外部状態」と「内部状態」に分類され、外部状態は時間だけでなく、
たとえば乱数発生器やキーやマウス/ネットワーク/ファイルなどからの入力イベントがあり、
「内部状態」はプログラム自身の振る舞いを決定する複数の状態変数から構成される
こうした問題の本質を理解していれば、次にはモジュールの独立性を高めるために
プログラムを状態に依存するモジュールと依存しないモジュールに分割するという、
「正しい設計」への道に歩を進めることができる

（長いので続く）
0822デフォルトの名無しさん2014/09/12(金) 23:50:04.08ID:DjgrfMg6
3行
0823デフォルトの名無しさん2014/09/12(金) 23:53:19.02ID:o47xIZ9t
せめて続きが書かれるまで待とうよ(^^;
0824デフォルトの名無しさん2014/09/13(土) 00:00:52.79ID:FW2AVG6W
（>>821の続き）

もちろんテスト駆動によって設計の改善を図ることはできる
ただし、それをするには(テスト手法の改善で終わらせず)発生したバグという問題に対して、
バグが生まれた原因を直接原因/間接原因/背景要因/根本原因へと深く追求することによって
再発防止策を考え、それを設計へ反映(フィードバック)させるという姿勢が重要になる
これをQA(品質保証)では「(設計による)品質の作り込み」と言う
残念ながら、この記事は問題追求と反映という考察のレベルがあまりにも浅はかすぎる

この記事を書いた和田氏がQAの基本すら知らずに記事を書いたのなら哀れではあるがしかたがない
しかし、もしQAの基本を知った上で記事を書いたのなら、悪意があると言わざるをえない
この記事で和田氏は設計について以下のように解説している：
　　設計は終わりのない世界です。そして、設計について考えすぎると、終わりがない世界に
　　踏み込んでいることに気づきにくくなります。このようなとき、テストの結果/ゴール/具体例から
　　考えることで「あれもできる、これもできるかも、ああいうやりかたもあるな」という
　　フワフワとした状態から、ピントのあった状態に戻ることができます。

つまり和田氏は「どうせおまえらには無理なんだから設計について深く追求するな、思考停止しろ、
それよりテストを動かしたほうが楽になれる、頭よりも手と目を動かせ、汗水流して働け」と
語りかけている（いくらか誇張が含まれているかも....）
まあ、もし本人がこんな誘いに喜んで乗りたいのなら、他人がとやかく言うべくじゃ無いだろな
でも、もしオマイラが学部卒以上であれば、知性とは真理の探求であることを学んできたんじゃないの？

（更に続くが、次で終わる）
0825デフォルトの名無しさん2014/09/13(土) 00:05:30.28ID:3NR6JoCg
そういうスレでやれ
0826デフォルトの名無しさん2014/09/13(土) 00:23:32.04ID:FW2AVG6W
（>>824 の続き）

最後に、>>819 の三番目の記事「TDDとテスト容易性(試験性)の関係」だけど、
これは良いマトメになっているね
この記事ではソフトウェアの品質確保について「設計のブレークダウン」と
「インサイドアウトのTDD」という二通りのアプローチがあると定義している
自分の考え方は、前者になる

特に、TDDのデメリットとして挙げられた：
「テストコードと上流仕様とのトレーサビリティを保証するプロセスが通常考慮されない。」
ことが大きな問題だと捉える
つまり、TDDによるモジュール開発(=単体テスト工程)が終わったとしても、
次の結合テストでも品質が安定するのかそれともバグが多発するのか「予測できない」ことが問題だ
つまりモジュールの設計品質を保証できないというリスクを抱えてしまう
0827デフォルトの名無しさん2014/09/13(土) 00:26:35.56ID:VE/fbqWK
「品質王に俺はなる！」まで読んだ
0828デフォルトの名無しさん2014/09/13(土) 02:10:58.98ID:UwoYLUrN
前提がおかしいことに突っ込んどくと、TDDなんかはアジャイル系統の考えから生まれてるんだから、そういう大規模開発にはそもそも有用じゃないでしょう

TDDを有効に用いるのであれば、
・少数精鋭チーム
・軽量言語
・多くの仕様変更
・頻繁なリリース
・ツール等が十分導入されている
・個々のエンジニアがコードすべての責任を持つ

などの前提があって、初めて成り立つんじゃないすか

ウォーターフォールには相性悪いのに、それで糞だというのはなんか違う気が
0829デフォルトの名無しさん2014/09/13(土) 03:05:36.49ID:VE/fbqWK
個人的な意見だということと、あなたの書いた主旨から横道にそれてしまうことを前置きしておくよ

あなたが列挙した前提は、アジャイル開発のセオリーだよね
TDD がアジャイル系統から生まれたという背景は否定しないけれども、
誕生した背景と実用の実態が必ずしも合致しないことはままあることだし、
「TDD が大規模開発やウォーターフォールに向いてない」 というのには違和感を思える

話を元に戻すと、ウォーターフォールでも反復手法でも TDD は成立すると考える
だから、TDD にしろ BDD にしろ、過小評価されていると思う
0830デフォルトの名無しさん2014/09/13(土) 03:41:31.15ID:WOkelzJA
TDDの反対は、開発してからテストコードを書くであってますか？
0831デフォルトの名無しさん2014/09/13(土) 03:51:40.22ID:e8cPYDi5
理論上はウォータフォールでもTDDは成立するけど、
現実としては成立しないよ。

なぜならウォータフォールでは、
少数の技術力が高い開発者＋多数の技術力が低い開発者から構成される。
多数の技術力が低い開発者はTDDができない。

ウォータフォールでは技術力をあげようとしない。
人海戦術ができるように技術力が低い状態で回すことが求められる。

高度な機能を使って無駄のない開発ではなく、コピペで重複するコードが
大量にできる方をとる。というか技術力が低い開発者を多数に投入して
並行で作業をやらせるそうしようと思わなくてもと結果にそうなる。
0832デフォルトの名無しさん2014/09/13(土) 05:23:17.73ID:oPYhG5tJ
　
0833デフォルトの名無しさん2014/09/13(土) 05:53:46.82ID:YMKS8boW
>>831
ウォータフォール恐ろしいな
こんなので製品完成するの？
素朴に疑問だ
0834デフォルトの名無しさん2014/09/13(土) 06:19:43.74ID:WU+mcApI
>>821
お、グローバル変数に匹敵する「状態」概念が出てきたね。
0835デフォルトの名無しさん2014/09/13(土) 10:47:27.94ID:3NR6JoCg
>>830
違う

TDDは、開発サイクルの改善手法
Red→Green→Refactoring の小さなサイクルをリズムよく素早く回すのが大事

最初にテストをするのが最重要なんじゃない
極端な話、最初に延々と長期間テストを作り続けて、その後機能が完成するまで実装を続けて最後にまとめてリファクタリング
とかやっても、それはTDDじゃない

最初にちょっとだけ実装して、テストを作って、リファクタリング
というのを練習方法としてオススメしてる人もいる。これはテストを後から作ってるけど結構TDDサイクルに近い


結論としてTDDの反対は、そもそもサイクルを持たない開発・・・なんじゃないかと思う
後工程からのフィードバックが前工程で一切得られない、改善のしようがない開発サイクル(そもそもサイクルになってない)
アジャイルに対するウォーターフォールのような感じ
0836デフォルトの名無しさん2014/09/13(土) 10:59:24.46ID:cu8Gt3Lf
>>835
お前が言ってるのは、スパイラルモデルな
0837デフォルトの名無しさん2014/09/13(土) 10:59:45.73ID:dGFUkkE8
信頼性と生産性の向上←テストの自動化←テストの容易性・信頼性←それに見合った設計←TDDという習慣
0838デフォルトの名無しさん2014/09/13(土) 11:39:42.46ID:YZYULf7g
テスト=>実装=>リファクタリング(+仕様変更)
または
実装=>テスト=>リファクタリング(+仕様変更)

数時間から数日のサイクルでこのテスト済みかつ再テストの容易なブロックを作って
積み上げていくというのは感覚的にわかりやすい
0839デフォルトの名無しさん2014/09/13(土) 11:43:55.91ID:JUTGZGvm
あー、いまやっとTDDの問題点とどうすればいいか閃いたよ。

TDDはプライベートメソッドに対してやればいいんだ。

どういうことかというとTDDは、小さくRed→Greenを繰り返すわけだけど、
その小さい開発サイクルに対してパブリックメソッドのテストでは量が多すぎるんだ。

パブリックメソッドの多くはさらに小さいプライベートメソッドを沢山呼んでいる。
それはパブリックメソッドが複雑だから、それをさらに小さい部分に分けてシンプルにするため。
いきなりパブリックメソッドを作るわけじゃなくて、プライベートメソッドから作る。

その小さいプライベートメソッドを開発してる時に、Red→Greenしないの？
いや、これこそがTDDでするべきことでしょ？

でもユニットテストの考え方ではプライベートメソッドのテストをしないから、
パブリックメソッドにしないとある程度できないとテストがかけない。

TDDを使わない方法、たとえばprintデバッグによる目視ではこのプライベートメソッドの
動作確認をよくやってる。実行する時に、プライベートメソッドへの引数に直接数値を入れて
そして戻り値をprintする。これはまさにプライベートメソッドのテストそのもの。

そうTDDに本当に必要なのはプライベートメソッドのテストなんだよ。
パブリックメソッドのテストでは範囲が広すぎてテストが書けるようになるまでタイムラグが出来る。

パブリックメソッドのテストを書こうとしている。これがTDDができない根本的な原因。
0840デフォルトの名無しさん2014/09/13(土) 11:44:33.50ID:JUTGZGvm
そしてユニットテストとの違いはリファクタリングで
テストコードが変わったりなくなったりするということ。

ユニットテストではパブリックメソッドそのものの仕様が変わらない限りテストコードは変わらないが、
プライベートメソッドは頻繁に仕様が変わったりなくなったりするのだから当然の話。

そしてTDDによる"１つの"開発が終わる時というのは、パブリックメソッドができあがるまで。
パブリックメソッドできあがったとき、プライベートメソッドのテストとは別に
パブリックメソッドのテストもできているのが理想的だが、必ずしもそうはならないだろう。

多くのプライベートメソッドのテストがあって、プライベートメソッドを呼び出してるだけの
単純なパブリックメソッドのテストコードは無いか少ないことが多い。

この後プライベートメソッドのテストは、変更を加えてパブリックメソッドのテストに変更してもいい。

ユニットテスト的にはプライベートメソッドのテストはしないのだから破棄しても構わないが、
将来の修正に備えて残しておくのもいいだろう。

ユニットテストのテストは外部のインターフェースに対するテスト、
TDDとは内部の開発を行うためのテスト（というより動作確認に近い）
0841デフォルトの名無しさん2014/09/13(土) 11:50:51.07ID:JUTGZGvm
さて、どうやってプライベートメソッドのテストを書くかだけど、
これはユニットテストのフレームワークの機能を使わないほうがいいだろうね。

フレームワークによってはプライベートメソッドのテスト機能があるが
それを使わない。

代わりにクラスにtest()とかなんでもいいんで1個メソッドを用意する。
このメソッドは別にユニットテストでテストするわけじゃない。
引数を返したり、特定の機能を提供するものじゃない。
単に外部から呼び出すためだけのもの。

そしてクラスのtest()メソッドの中で、
プライベートメソッドを直接読んで、戻り値を確認確認は単純にifとかでいいよ。
なんだっていいどうせ破棄してもいいものなんだから。

もちろん将来に備えて綺麗に整理しておくとか、ユニットテストに
変更しやすいような命令を使うとかはありかもしれないが、
それはTDDとは直接関係のない話。
0842デフォルトの名無しさん2014/09/13(土) 11:53:51.98ID:KYJA+u1Q
そういうのはPythonのdoctestに書いてるわ
これTDDだったのか
0843デフォルトの名無しさん2014/09/13(土) 12:00:50.55ID:JUTGZGvm
>>842

http://docs.python.jp/2/library/doctest.html
> そこで Python 2.4 では doctest の Tester クラスを廃止し、モジュールや doctest の
> 入ったテキストファイルから unittest テストスイートを作成できるような
> 二つの関数を doctest 側で提供するようにしました。

って書いてあるように、doctestはユニットテストを含む
テストを生成するための機能だしね。
0844デフォルトの名無しさん2014/09/13(土) 12:15:44.43ID:NqTsLZky
>>841
プライベートメソッドのテストが必要な時点で、クラス(モジュール)の規模が大きくなりすぎているように思える。

少し視点を変え、テストのしづらい大きなクラスの場合、APIクラスとハンドラクラスに分けるとよいのではと考えている。

APIクラスのメソッドはハンドラクラスのメソッドを組み合わせて構成させる。

ハンドラクラスは、もともとプライベートメソッドだったもの。

これらの構成に分けた上でAPIクラスは振る舞いを軸にテストし、ハンドラクラスはメソッド単位でユニットテストする。

ハンドラクラスは基本すべてクラス外からアクセス可能となるパブリックメソッド。もしくはJavaのようなパッケージプライベートあればそれでも可。
0845デフォルトの名無しさん2014/09/13(土) 12:19:53.66ID:JUTGZGvm
今日は頭が冴えてるｗ

ユニットテストではやりにくくて
printデバッグでやりやすいのにこのようなテストがある

function foo(a, b) {
　 aとbをいろいろ計算してcに代入
　if (cが○○なら) {
　　_hoge();
　} else {
　　_hage();
　}
}

こんな感じのコードで、a, bにとある値を入れた時
_hoge()が呼び出されるか？ という確認。

これはprintデバッグをすれば簡単に確認できることだが
テストコードでは気軽にできない。モックを使えって話になるだろうが
プライベートメソッドのモック？？？ 継承してプライベートメソッドを
オーバーライド？？？ 言語によっては出来ないし。

これさ、よくデバッグログを有効にしたらログを出力する機能ってあるじゃん？
そのログを解析すればいいんじゃないか？

_hoge()実行前、もしくは_hoge()の中でデバッグログを出力するようにしておいて
そのログを解析してテスト。（もちろんログは解析しやすい構造にしておくのがベター）

やってることはprintデバッグと同じなんだけどね。
デバッグログとしてモジュールがもってる公式な機能とすることで自動テスト可能にする。
ユニットテストでも使える技だと思う。
0846デフォルトの名無しさん2014/09/13(土) 12:20:42.66ID:NqTsLZky
>>844
これは別に目新しいものではなく、よくあるクラスを細分化して階層化する手法をてきようしただけ。

通常のクラスのレイヤー化とは違い、状態を持たない/持たせないのであれば、すべてstaticメソッドでも構わないと思ってる。
0847デフォルトの名無しさん2014/09/13(土) 12:28:38.72ID:JUTGZGvm
>>844
> プライベートメソッドのテストが必要な時点で、クラス(モジュール)の規模が大きくなりすぎているように思える。

プライベートメソッドの存在否定をしているわけじゃないでしょ？

まず事実としてプライベートメソッドはできる。
そりゃ単純なユーティリティクラスとかならいらないだろう。
そういうユーティリティクラスはテスト簡単で、それなら俺もテストもTDDもできる。

問題は少し複雑になったもの。

複雑なものはプライベートメソッドは絶対にできる。
その規模になったとたん、TDDがしづらくなるのが現実。

プライベートメソッドをパブリックメソッドにして別モジュールにするのはいいアイデアだよ？
最終的にはそうすることになるかもしれない。でも今は最終的な話をしてるんじゃない。
作ってる初期段階の話なんだ。TDDは初期段階からRed→Greenをするものなんだから。

開発中に小さな単位で作ってる時に、プライベートメソッドができたからってすぐに
別クラスを作ろうっていうのは間違った考え方。
小さなプライベートメソッドごときで、クラスに分けるか？
なんて責務を持ったクラスしよう？などと考えるのはやり過ぎだろう。
最初は小さく作って、それから大きくしていくのがいい。大きくなったら
別クラスに分けるのもありだし実際俺もそうしてる。
0848デフォルトの名無しさん2014/09/13(土) 12:30:58.32ID:4lGfw+8/
使い捨てのプライベートテストを計画量の何倍も書くなんてやってられるか
どんだけコストかけるつもりだ
0849デフォルトの名無しさん2014/09/13(土) 12:32:32.50ID:JUTGZGvm
>>844
あと、

> プライベートメソッドのテストが必要な時点で

これおかしな言い方だよね？

まるでプライベートメソッドはテストをしなくていいような言い方。

「プライベートメソッドは "ユニット" テストをしなくていい。」
ならば賛成だが、TDDにおけるRed→Greenは
プライベートメソッドでもやるべきだろう？

むしろプライベートメソッドこそやるべきことだろう？

じゃないと小さくRed→Greenなんてできないよ。
0850デフォルトの名無しさん2014/09/13(土) 12:37:23.42ID:CEzP+lKU
ウォータウォールだとリグレッションテストの機会が少ないから
TDDというかユニットテストツールの導入によるメリットが減るのかな
0851デフォルトの名無しさん2014/09/13(土) 12:39:11.42ID:JUTGZGvm
>>848
> 使い捨てのプライベートテストを計画量の何倍も書くなんてやってられるか
> どんだけコストかけるつもりだ

その考え方の間違いが、TDDできない原因なの。

プライベートメソッドは絶対にできるし、無駄になるからそのテストコードを書かない。
→だからパブリックメソッドのテストしか書きません。
→プライベートメソッド単位で小さくRed→Greenしません。

開発時はプライベートメソッドでも目視で動作確認している。
TDDはこれをコードに置き換えただけ。
単純な1作業だからこそ破棄しても良くなる。（そもそも目視＝使い捨て）

小さくRed→Greenをするために、TDDのテストコードと
ユニットテストコードは別のライフサイクルであつかわないといけない。
0852デフォルトの名無しさん2014/09/13(土) 12:49:00.56ID:JUTGZGvm
閃きの後いろいろ考えてるけど、デバッグログを使ったテストはいいアイデアかも。

デバッグログを使わなくてもアスペクト指向的に
メソッドの前後に処理を割りこませることが出来るのは知ってる。
もちろん動的言語だったらメソッドを動的に入れ替えたりとかできる。

でもこれらの欠点は、メソッド単位でしかやれないってこと。
あとそれをやるためのコードがいちいち面倒くさい。

デバッグログならたった一行書くだけで任意の時点でその時の状態を表示できる。
コードの途中で確認したいと思った内容を自由に制御可能になる。

ようするにprintデバッグは偉大だってことｗ
0853デフォルトの名無しさん2014/09/13(土) 13:54:21.21ID:VE/fbqWK
>>845
俺ならメソッドの設計を変える
１） a と b を引数にして c を返す function foo()
２） c を引数にして _hoge() と _hage() を呼び分ける function foo2() ←仮称

こうすると、テストが必要になるのは
・function foo(a, b)
・function foo2(c)
・function _hoge()
・function _hage()

の４つになって、foo2(c) の結果が c 次第で _hoge() か _hage() と同じになればいい

メソッドを通るか通らないかは、アクセッサを使えばいい話で、
わざわざ出力を人の目で追う（＝人為的ミスの混入の余地がある方法に頼る）必要はないよ
0854デフォルトの名無しさん2014/09/13(土) 14:14:31.94ID:JUTGZGvm
>>853
ただの簡単な例にそんなに必死にならなくてもｗ

ね、たったこれだけなのに大きくなりすぎでしょ。
最初はシンプルに作ろうぜ。
0855デフォルトの名無しさん2014/09/13(土) 14:22:24.36ID:JUTGZGvm
実際に開発していればわかるけど、
複雑なコードというのは最初から複雑なのではなくて
シンプルなコードに変更を加えていって複雑になる。

ここからもTDDはプライベートメソッド対して
行うものでテストは使い捨て同然だってことがわかるよね。

コードが長くなっていく。じゃあ分割しよう。
よし別クラスのパブリックメソッドに変更だ！

いきなりこうする奴はいない。
コードが長くなれば、同じクラスのプライベートメソッドにする。

じゃあテストはどうなる？
テストもプライベートメソッド用に分割し変更しないといけない。

TDDでは小さい単位でRed→Greenを繰り返すわけで頻繁に変更が入る。
ユニットテストのようなモジュール単位でのテストでは
開発に対しては粒度が大きすぎるんだよ。
0856デフォルトの名無しさん2014/09/13(土) 14:32:49.34ID:WNOSyncO
その場の思い付きでスレ私物化して公式見解のように騙るな
ブログでやってろ
0857デフォルトの名無しさん2014/09/13(土) 14:59:02.52ID:JUTGZGvm
反論さえ言わない人に興味はないな。
0858デフォルトの名無しさん2014/09/13(土) 14:59:25.59ID:VE/fbqWK
>>854
ご心配ありがとう、「必死」でも「本気」でもないから大丈夫だよ
インスタンスを obj とすると、自分だったら最初からこう書く

obj.foo(a, b).handleIfInvalid().execute();

それぞれの中身はスタブを作って後から書く
個々のメソッドの内容は、最初柔らかかったり、ユーザー調整で変わったりするからね
0859デフォルトの名無しさん2014/09/13(土) 15:20:49.51ID:JUTGZGvm
>>858
だからなんで自分の都合のいい例で
過剰な設計してるの？
0860デフォルトの名無しさん2014/09/13(土) 15:45:34.10ID:WNOSyncO
いい加減わかっただろ
NGID:JUTGZGvm
0861デフォルトの名無しさん2014/09/13(土) 15:47:33.17ID:VE/fbqWK
>>859

＞ようするにprintデバッグは偉大だってことｗ

この言葉に違和感を感じたから、俺なりの意見を書いてみた
抽象的な言葉を使うとわかりづらくなるだろうから、具体例をあげてみたんだ
0862デフォルトの名無しさん2014/09/13(土) 15:49:45.67ID:VE/fbqWK
>>860
ありがとう、そういうことか
気づくのが遅かったよ・・・
0863デフォルトの名無しさん2014/09/13(土) 16:03:41.33ID:WNOSyncO
>>862
寝起きで公開オナニーしてるただのいかれポンチだからな
ご愁傷様
0864デフォルトの名無しさん2014/09/13(土) 16:26:16.40ID:YMKS8boW
おもしろい議論ができるかもしれんのに
相手の考え方をただ突き放すんじゃなくて
技術的な観点から反論した方が有益では
0865デフォルトの名無しさん2014/09/13(土) 16:51:35.11ID:T0lKiW3+
そんな議論した奴がわざわざ２ｃｈに来ると思うか？
0866デフォルトの名無しさん2014/09/13(土) 16:58:55.39ID:HpsOFySp
議論でなく俺すげーしたいだけなので使いようがない
0867デフォルトの名無しさん2014/09/13(土) 18:10:44.31ID:WU+mcApI
それは宿題スレで十分だ‥
0868デフォルトの名無しさん2014/09/13(土) 19:22:04.50ID:YMKS8boW
彼の言い方にも問題はあったかもしれないけど
privateメソッドのテストはどうするんだという指摘は気になったけどなあ
0869デフォルトの名無しさん2014/09/13(土) 20:24:45.01ID:n3+TUlp4
>>850
運用というか、よくある運用しながら機能追加を続けるようなプロジェクトなんかだと
デグレを発見しやすくなる、減らすって意味でもテストツールの導入のメリットは
少なくないよ。 ただ、人が多い人の入れ替えが頻繁に発生するとかだとツールで
作ったテストの品質の担保が出来なくなって破綻するってのが簡単に想像できる
パティーンだね。
0870デフォルトの名無しさん2014/09/14(日) 14:00:48.25ID:6ldmPVQO
テスト駆動はプロジェクト工程の一部だという人と、
テスト駆動はファイルをこまめに保存するのと同じ個人の慣習だという人
がいて議論が混乱してるようですな

私は後者です
0871デフォルトの名無しさん2014/09/14(日) 21:48:34.19ID:eBrPaPVH
>>870
それは間違い。

テスト駆動は「開発手法」の一つです。
08728212014/09/14(日) 22:16:03.85ID:VLz5e6gt
>>828
もしそれらがTDD導入の前提条件であるなら、
まさしくそれがスレタイ「TDDはなぜ流行らなかったのか」に対する答えだね
つまり極めて限定された案件でしか適用できないのだから、
TDDが普及しなかったのはしごく当たり前の話だと言える
0873デフォルトの名無しさん2014/09/14(日) 22:20:22.35ID:eBrPaPVH
いや、828の前提は間違えてる。
08748212014/09/14(日) 22:34:55.94ID:VLz5e6gt
>>829
> だから、TDD にしろ BDD にしろ、過小評価されていると思う

>>826 で書いたように、TDD は一般的なQA(品質保証)の考え方へ
適合できていない事が、過小評価と開発現場で普及しない原因になっていると思う
現状だと TDD は開発手法や開発方法論の一つというよりも、
>>808(>>812,815) および >>870の後者のように
プログラマ個人レベルのノウハウ/設計テクニック/慣習であると
捉えるほうが適切だと思う（実際に開発手法として普及していないのだから....）

ただし、>>819 の三番目の記事「TDDとテスト容易性(試験性)の関係」(>>826)にあるように
現状では「設計のブレークダウン」と「インサイドアウトのTDD」との両立は現実的ではないけれど、
かといって対立するものと考えて TDD を排除するのも惜しい
おそらく今後はプログラマ達が自由に TDD を使いこなしてモジュール開発を効率的に進める一方で、
同時にシステム全体の品質も確保していけるような品質管理手法や支援技術が必要になるだろう
0875デフォルトの名無しさん2014/09/14(日) 22:40:09.03ID:eBrPaPVH
>>874
意味がわからない。
流行っていないから言葉の定義を変えるべきだって主張？
08768212014/09/14(日) 23:05:53.59ID:VLz5e6gt
>>831
そのTDDを使う技術力の高い開発者とやらは、>>819 の二番目の記事
「これであなたもテスト駆動開発マスター！？」を指しているのかな？

自分はそうは考えないね
本当に技術力の高い開発者であれば、発見した一つのバグ(=現象)から
発生原因を追求して他の隠れた(=潜在的な)類似バグを机上で摘出し、
その再発防止策を設計へフィードバックできるはずだ(>>821,824)

>>819 の記事にあるような「時間に依存」というバグの対策だけで満足し、
テスト駆動設計マンセーとする姿は手足を素早く動かせる「お猿さん」に見える
08778212014/09/14(日) 23:19:37.96ID:VLz5e6gt
>>834
あぁそういえばグローバル変数がモジュール結合度を強める要因だとよく知られているけど、
今時のオブジェクト指向設計だと、対応するのは「共有された可変オブジェクト」になるね

>>821 では欠けていたから、「外部状態」の一つとして追加しておく
0878デフォルトの名無しさん2014/09/14(日) 23:27:33.43ID:xGAHyC6K
>>874,876
＞>>826 で書いたように、TDD は一般的なQA(品質保証)の考え方へ
＞適合できていない事が、過小評価と開発現場で普及しない原因になっていると思う

一般論としてはそうかもしれないが、適合できるかどうかは手法の「使い方」によると思う

＞プログラマ個人レベルのノウハウ/設計テクニック/慣習であると
＞捉えるほうが適切だと思う（実際に開発手法として普及していないのだから....）

最後のカッコ内は別として、この意見には同意する
「テスト駆動＜設計＞」は難しい、フロントヘビーで破たんするケースが多くなると予想くる

＞おそらく今後はプログラマ達が自由に TDD を使いこなしてモジュール開発を効率的に進める一方で、
＞同時にシステム全体の品質も確保していけるような品質管理手法や支援技術が必要になるだろう

ここもほぼ同意だ、上に書いた「使い方」がカギになると思うんだ

＞本当に技術力の高い開発者であれば、発見した一つのバグ(=現象)から
＞発生原因を追求して他の隠れた(=潜在的な)類似バグを机上で摘出し、
＞その再発防止策を設計へフィードバックできるはずだ(>>821,824)

その期待値を One of them の開発者にも求めるのが方法論
このとき、机上で行うと人の能力に左右されやすいので、自動化するのがいいはずだ
0879デフォルトの名無しさん2014/09/14(日) 23:45:56.29ID:HSV2qzsF
久しぶりに議論が白熱してて良い良い良い(残響音)

個人的には開発の多様性がでかすぎることが議論のまとまりを得ないことだと思ってる。
組み込み畑の人間としては昔は自前主義から専用ツールの使いこなしこそが熟練工の証だったし、最近はフレームワークが決定権を握ってるが、その組み込み系FWの多くがまだTDDと繋がっていないから、存在を知ってても踏み出さない。
組み込みでもスマートフォンのアプリ界隈はなんとかなり出したけど、web界隈の速度には全くついてけない。なんだよyeomanって

開発手法で先頭を走ってるのはweb界隈だと思うし、そこで何らかの開発手法が本格化しても、組み込みまで来るのに10年ぐらいかかりそうなんだよね。で、組み込みが使いだした時にweb屋はもっと先のことをやってる。永遠に話が噛み合いません
0880デフォルトの名無しさん2014/09/14(日) 23:52:15.85ID:eBrPaPVH
白熱なんてしていない。よく読め。

自分で言葉の定義を変えて自画自賛してるだけ。
まったくこのスレの趣旨とは関係のない事をだらだら書いてるだけ。
0881デフォルトの名無しさん2014/09/15(月) 00:22:34.44ID:jSabMZv+
>>879
＞個人的には開発の多様性がでかすぎることが議論のまとまりを得ないことだと思ってる。

完全同意、開発形態は OOP だけじゃないし

＞最近はフレームワークが決定権を握ってるが、その組み込み系FWの多くがまだTDDと繋がっていないから、
＞存在を知ってても踏み出さない。

これはしんどいな・・・
確かに、フレームワークやツール機能としてテスト環境がなければ、話の前提が変わってくる
スタブ生成、テスト設定、テストリスト等々の実践的の機能がないわけだから・・・

＞組み込みが使いだした時にweb屋はもっと先のことをやってる。永遠に話が噛み合いません

でも、アセンブラや C が主戦場だった時代でも、定数やプリプロセッサを使って、
テストを主軸に置いたアプリケーションの反復開発のノウハウはあった
開発環境のテスト機能が手厚いかどうかの話はおいといて、基本的な考え方は同じだと思う
0882デフォルトの名無しさん2014/09/15(月) 03:01:54.90ID:fTMJwK7z
TL;DR

そもそもここで議論(？)してる人たちのうちどれくらいが
Red-Green-Refactoring やったことあるんだろうか
0883デフォルトの名無しさん2014/09/15(月) 11:11:12.39ID:pNNQiIbO
テスト駆動開発とか
パターンと同じでさ、セオリーやメソッドじゃない、ちょっとしたコツの集積だろ

オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

そういう商売に乗せられているだけなのに、さも学術的な根拠があるものとして「勉強」したりするのが
偉いと思っている奴はどっかオツムが弱いとしか言いようがないw
0884デフォルトの名無しさん2014/09/15(月) 12:21:47.43ID:B9NqCL8r
そうやって弱い者と対話するのは情弱相手に商売するのと殆ど同じだから
弱者は放っておいて元締めを直接攻撃した方が良い
0885デフォルトの名無しさん2014/09/15(月) 13:05:34.49ID:c5wSz+yy
飲み屋で周りの客に「俺の若い頃はなぁ！」と
絡んでくるのんだくれと同じか
自分に酔い潰れてらっしゃる
0886デフォルトの名無しさん2014/09/15(月) 18:39:38.47ID:upNhnkM6
>>871
個人の慣習としての開発手法ですよ
0887デフォルトの名無しさん2014/09/16(火) 04:27:18.32ID:1lKEIB+1
>>883
そしてそのレスはコピペだろ？ｗ
08888182014/09/16(火) 10:29:06.27ID:JKk7MwEx
>>821
> 「含まれている」部分と「含まれていない」部分がある
以下全て、テスト容易性を担保するという観点では、「あなたが設計するときはそうする」という話であって、
メソドロジーの話ではないよね。

TDDはメソドロジーの話。
このメソドロジーが気に入れば使えばいいし、気に入らなければ無視しておけばいいだけ。
0889デフォルトの名無しさん2014/09/16(火) 10:34:39.32ID:JKk7MwEx
>>824
> 　　設計は終わりのない世界です。そして、設計について考えすぎると、終わりがない世界に
> 　　踏み込んでいることに気づきにくくなります。このようなとき、テストの結果/ゴール/具体例から
> 　　考えることで「あれもできる、これもできるかも、ああいうやりかたもあるな」という
> 　　フワフワとした状態から、ピントのあった状態に戻ることができます。
>
> つまり和田氏は「どうせおまえらには無理なんだから設計について深く追求するな、思考停止しろ、
> それよりテストを動かしたほうが楽になれる、頭よりも手と目を動かせ、汗水流して働け」と

なんという悪意。t_wadaに恨みでもあるの？
先にテストを書くことで見えてくるものがあるよってことでしょ。
0890デフォルトの名無しさん2014/09/16(火) 10:50:55.87ID:JKk7MwEx
>>876
> >>819 の記事にあるような「時間に依存」というバグの対策だけで満足し、

うーん、やっぱ色眼鏡であの記事を読んでるんじゃないの？
あの記事は、バグの話じゃなくて、

> class Greeter
> 　　def greet(time=nil)
> 　　　　time ||= Time.now
> 　　　　hour = time.hour
> 　　　　return 'おはようございます' if 5<=hour && hour<12
> 　　　　return 'こんにちは' if 12<=hour && hour<18
> 　　　　return 'こんばんは'
> 　　end
> end

というコードでいいの？って話なんだけど。
0891デフォルトの名無しさん2014/09/16(火) 15:37:15.11ID:EbNafOtn
話題とは直接関係ないが、
elseルートに「こんばんは」が入っているのに違和感。
日本語的にも、フェイルセーフ的にも
　朝ならおはようございます
　夜ならこんばんは
　それ以外ならこんにちは
とコーディングするのが自然だろう。
0892デフォルトの名無しさん2014/09/16(火) 21:17:00.56ID:Zss/iCB4
>>891
いや、それが本題だ‥
0893デフォルトの名無しさん2014/09/16(火) 21:35:17.75ID:1lKEIB+1
テスト駆動の説明でよくある間違いに気づいた。

最初にテストに失敗させる。
その後テストが通るように修正する

↑これをリファクタリングと言ってる人がいるけど、
これリファクタリングじゃない。
なぜなら機能が変わっているから。

テスト駆動開発中にリファクタリングすることはあるけど
開発そのものはリファクタリングじゃない。

テスト作成 → レッド →（リファクタリング）→ 開発 → グリーン→（リファクタリング）→最初に戻る

※リファクタリングは必須ではない

http://www.infoq.com/jp/news/2014/03/fowler-workflows-refactoring
> 「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を取り
> 替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」

マーティン・ファウラー氏がいうように、リファクタリングと開発は分けて考えないといけない。
0894デフォルトの名無しさん2014/09/16(火) 21:40:19.03ID:PVbEy2qP
一番の間違いは、これをプロジェクトの工程として取り込む場合と、個人の慣習として取り込む場合をごっちゃにして議論しようとする点ではなかろうかと
0895デフォルトの名無しさん2014/09/16(火) 21:47:40.13ID:1lKEIB+1
> テスト作成 → レッド →（リファクタリング）→ 開発 → グリーン→（リファクタリング）→最初に戻る

やっぱこれ訂正する

リファクタリングはテストに通っているものを、
修正してもテストに通ることでリファクタリングが正しいことを
担保するものだったはずだ。

テスト作成 → レッド → 開発 → グリーン→（リファクタリング）→最初に戻る

こうでなければならない。
0896デフォルトの名無しさん2014/09/16(火) 22:27:03.96ID:1OTf5N0/
そういう間違い方の説明は見たことないな・・・
どっかの記事にあったの？


>テスト作成 → レッド → 開発 → グリーン→（リファクタリング）→最初に戻る
これ粒度が違うものが同じ高さに並んでてよくない

レッド(テスト作成) → グリーン(実装/開発) → リファクタリング
これならまだ・・・
やっぱり三角形書いた方がよいな。プレーンテキストだとイマイチ
0897デフォルトの名無しさん2014/09/17(水) 10:34:23.26ID:lCf5WlHq
>>893
> ↑これをリファクタリングと言ってる人がいるけど、
いたとしたら、それは間違い。

> テスト駆動開発中にリファクタリングすることはあるけど
> 開発そのものはリファクタリングじゃない。
ん？リファクタリングも開発でしょ？

> テスト作成 → レッド →（リファクタリング）→ 開発 → グリーン→（リファクタリング）→最初に戻る
俺用語とか謎の括弧が満載だけど、ＴＤＤの定義はred/green/refactor。
0898デフォルトの名無しさん2014/09/17(水) 17:52:59.30ID:axdkvC1X
習慣としての開発手法なら、まだ環境が十分じゃないな
エディタでスペルミスを見つけてくれるのと、同じレベルで使えないなら、使えない開発手法だよ

コード書きながら、自動コンパイルして、下線で間違いを指摘するエディタのように、
メソッドの期待値をコメントにでも書いておけば、いまコーディングしてるメソッドを自動に把握して
バックグラウンドでテストコード作って実行して、レッド、グリーンとリアルタイムに
結果表示するエディタがあれば習慣として成立する
0899デフォルトの名無しさん2014/09/17(水) 18:19:32.67ID:9lFjDeRp
そんなもんあったら企業にバカ売れだよ
0900デフォルトの名無しさん2014/09/17(水) 18:54:08.07ID:LBQjPFEK
メールのようなターン制を否定して
電話のようなリアルタイムにこだわるメリットがわからない
0901デフォルトの名無しさん2014/09/17(水) 19:47:16.44ID:9lFjDeRp
チェックのサイクルを短くして手戻りを減らしたいんだよ
しかしまあカバレッジをエディタに重ねて表示みたいなのはいずれは実現してほしい機能ではある
0902デフォルトの名無しさん2014/09/17(水) 19:49:47.39ID:ji0sMMym
カバレッジ見るときはテストコード側弄ってるもんじゃないの？
Webリンクで充分な気が
0903デフォルトの名無しさん2014/09/17(水) 20:56:07.51ID:2WfHlgOC
>>898
コードを書く前に書くべきテストは、そのコードを書く人にしかわかりません
0904デフォルトの名無しさん2014/09/17(水) 20:58:18.00ID:LBQjPFEK
>>901
TDDのサイクルの長さは何秒かかったかじゃなくてテストの範囲の広さだろ
秒単位で管理するものじゃない
0905デフォルトの名無しさん2014/09/17(水) 21:09:26.99ID:YTtw5Lif
>カバレッジをエディタに重ねて表示
できますよ。そう、D言語ならね
0906デフォルトの名無しさん2014/09/18(木) 21:50:22.08ID:ESbaNubE
>>903
メソッドが入力に対して、どんな値を返すかの期待値を書いておけば、テストどころか、それを使うコードだって、他人に書けるだろ
0907デフォルトの名無しさん2014/09/19(金) 01:44:50.06ID:1/1de/H5
>>906
関数型的なアプローチで全てが完結できる世界ならそれで良いのかもしれんけどな
0908デフォルトの名無しさん2014/09/19(金) 10:53:04.12ID:VKWv7B4z
>>906
> メソッドが入力に対して、どんな値を返すかの期待値を書いておけば、テストどころか、それを使うコードだって、他人に書けるだろ
そのレベルの簡単なテストなら、10秒で書けるだろ
0909デフォルトの名無しさん2014/09/19(金) 11:36:09.89ID:iHgvKusj
>>907-908
だからそれが出来ないクソ設計なら出来るように見直そうぜって話じゃないか
スタート地点から間違ってる
0910デフォルトの名無しさん2014/09/19(金) 11:50:58.00ID:n7oIFaex
関数を返す関数とか、Objectを返すFactoryとか
「どんな値を返すかの期待値」を書くこと自体がけっこう難しい
0911デフォルトの名無しさん2014/09/19(金) 12:47:57.61ID:VKWv7B4z
>>909
「それが出来ない」のそれが何を指しているのかあやふやだが、俺が言ってるのは、
> メソッドが入力に対して、どんな値を返すかの期待値を書いておけば、テストどころか、それを使うコードだって、他人に書けるだ
レベルの話なら、この話題の元レス>>898の「〜するエディタ」なんかなくても10秒でテスト書かけるだろってこと。
0912デフォルトの名無しさん2014/09/19(金) 23:26:45.26ID:8TBQk5yL
>>906
その期待値は何に書くんですか？
0913デフォルトの名無しさん2014/09/20(土) 11:47:43.67ID:JSFBishN
>>912
そんなもん、エディタの仕様で決めたらいいんでは？
コメントでも、マニフェストぽいものでも

今のTDDが習慣なら、コメント書くようなものと同じなんだろうけど
エディタなり、環境の補助が、ほとんど何もないのは、環境が足りてないってことじゃない？
なぜ流行らないってスレタイの議論からして
0914デフォルトの名無しさん2014/09/20(土) 18:29:49.59ID:jy6HF+Ft
doctest 的なものかと思ったら
IDEの機能を想定してるのか？
0915デフォルトの名無しさん2014/09/20(土) 19:33:30.77ID:IAeZgJbV
ドカタにとってはIDEの機能が全てだからな
0916デフォルトの名無しさん2014/09/20(土) 20:30:27.20ID:U9SdVMdG
>>913
「エディタはこまめに保存しよう」もそれほど流行ってないしな…
0917デフォルトの名無しさん2014/09/20(土) 21:45:50.87ID:JSFBishN
今時、素の vi で、開発してる人なんて、ほとんどいないでしょ
TDD だって、Specとか何かのフレームワークと、その外側では Jenkins みたいな CIで、自動化依存なわけでしょ？
エディタだけ、手技にこだわる理由があるの？
0918デフォルトの名無しさん2014/09/20(土) 21:54:40.71ID:U9SdVMdG
>>917
・テストやスケルトンは自作ツールで半分自動生成するから
・たとえ便利であっても、自分が意図しないconfigを作ったりいじってほしくないから
・細かい設定の度にいちいちマウスに手を伸ばすのが面倒くさいから
・Write onece, Debug everywhereだから
・というか、emacsはIDEでしょ
0919デフォルトの名無しさん2014/09/22(月) 10:36:36.30ID:jUlJm5b9
>>913
> 今のTDDが習慣なら、コメント書くようなものと同じなんだろうけど
TDDどころか、テストコードによる自動テストすらまともにやったことない奴の戯れ言だな
0920デフォルトの名無しさん2014/09/22(月) 18:55:21.87ID:Q6VO7Vt5
TDDが習慣だとして、その習慣を身につけるまでのモチベが続かないんだろう
それなら、IDEなどの補助で、面倒なことを環境がやってくれたらいいと思う
ところが、IDEで自動でやるのは、必要ないみたいな話で、チマチマ手作業で、テスト書いて実行しろ、とか
自動でなんかできるわけないから、苦行をしないやつは、半端者みたいな、精神論になるね
およそ、ソフト開発者ぽくない感じ
0921デフォルトの名無しさん2014/09/22(月) 20:27:56.42ID:Jl1JL1CI
まず、手作業と自動は互換性があるべき
bashとshのように
それと、手作業で使うのがbashで自動はshだから、手作業を見下すべきではない
0922デフォルトの名無しさん2014/09/22(月) 21:45:12.22ID:SZGmUYqv
よく分からんが、IDE使ったこと無いんだろうか…
0923デフォルトの名無しさん2014/09/22(月) 22:41:49.11ID:Jl1JL1CI
IDEの設計を知り尽くすのが先で使うのは後という方法と
設計はほどほどにいきなり使ってみる方法があるらしい
どちらが良いかな
0924デフォルトの名無しさん2014/09/22(月) 22:49:19.38ID:vh/Af1aB
設計を勉強しなければならないIDEに存在理由はあるのだろうか…
0925デフォルトの名無しさん2014/09/22(月) 22:51:56.76ID:BRLO2XpR
なんでIDEの設計を知り尽くす必要があるの？

だいたい知り尽くす必要ないし、
普通に使えばいいだけだろ。

設計の意味間違ってるなｗ
0926デフォルトの名無しさん2014/09/23(火) 04:40:15.02ID:h+L05RM4
俺が作ったIDE使ったこと無いの？普通に使えばいいだけだろ
と開発者がユーザーを圧迫するところまでがユーザーエクスペリエンスデザインです
0927デフォルトの名無しさん2014/09/24(水) 10:32:01.65ID:pulkGZ2z
>>920
> それなら、IDEなどの補助で、面倒なことを環境がやってくれたらいいと思う
別にそれは否定しないし、現にテストをサポートしてくれるIDEとかも存在する。Visual Studioとか。

> チマチマ手作業で、テスト書いて実行しろ、とか
テストを書いたことないか書き慣れてないからそんなこと言うんだろう。

> 自動でなんかできるわけないから、苦行をしないやつは、半端者みたいな、精神論になるね
被害妄想激しいな。
簡単なアノテーションレベルで自動生成されるレベルのテストだったらすぐに書けるんだから、自分で書けよってことだよ。
0928デフォルトの名無しさん2014/09/24(水) 22:06:10.37ID:2iRKCzum
勘違いしてる人が多いけど、「面倒だから」は基本的に別の話だから
バグを少なくする慣習なんだから面倒かどうかは関係ない

強いて言うなら、3ヶ月後のデバッグの面倒を減らすのがTDDという慣習
0929デフォルトの名無しさん2014/09/24(水) 22:13:03.77ID:7Xf6EsR4
>>928
慣習じゃないだろ。なに言ってんだ？
0930デフォルトの名無しさん2014/09/24(水) 22:33:07.12ID:2iRKCzum
>>929
実質的にも本質的にもコーダーがコード打ち込む前にテスト書くなんてのは工程として存在しないんだから、TDDは個人が好き勝手に行う慣習でしかない
0931デフォルトの名無しさん2014/09/24(水) 23:38:41.86ID:HYHBSSFj
開発者と別の人が、開発後に他人がやる意味のわけのわからないテストじゃなくて
テストしてしっかり動きますって言い切るまでが開発なのだから
テストは開発者が開発中にやるものなんだよ。

テスト工程なんてのがわかれているのがそもそも考え方としておかしい訳で、
それがない前提の文化でTDDは出来たのだから、
単に開発と同時に行われるテストのやり方を決めたのがTDD

TDDは開発工程で行われる開発の手順であり、完成後に行われるテスト工程でやるものではない。
0932デフォルトの名無しさん2014/09/24(水) 23:47:27.55ID:2iRKCzum
>>931
開発工程のテストと、TDDのテストはまったく別の概念で目的も違う
開発工程のテストは基本的にブラックボックステストで、時間と余裕があればコーダーとは別の人が行う性質のもの
理想的には、バグを発見することではなく、バグがないことを確認するのが目的

TDDはコーダー本人の趣味と責任において実施するもので、時間と余裕があってもコーダー本人がやるべきもの

開発工程にテストがあってもなくても、コーダーが勝手にTDDをやればいいという種類のもの
ゆえにTDDは慣習
0933デフォルトの名無しさん2014/09/24(水) 23:50:47.05ID:7Xf6EsR4
>>930
は？
かなり無能の意見だな・・・
お前は開発やったこと無いのか？
0934デフォルトの名無しさん2014/09/24(水) 23:56:30.70ID:4ATryfYH
>>932
ほう
各々の概念の出典を教えてくれないか
0935デフォルトの名無しさん2014/09/24(水) 23:58:54.84ID:2iRKCzum
>>933
開発工程としてTDDを工程の中に組み込んでるプロジェクトは見たことがない
一方、TDDを行う人は、どんな工程であろうが個人の趣味としてTDDを行っている
0936デフォルトの名無しさん2014/09/25(木) 00:00:31.00ID:2iRKCzum
>>934
開発工程のテストについては、Writing solid code あたりを読めばいいのではなかろうか
TDDについては言及してないが、TDDと開発工程のテストがまったく別モノだと分かる
0937デフォルトの名無しさん2014/09/25(木) 00:01:49.28ID:5/lLb9tL
>>935
「個人の趣味としてTDDを行っている」なんてのが論外だって言ってんだが
ひょっとしてこんな基本的なことも理解できない？
0938デフォルトの名無しさん2014/09/25(木) 00:06:31.19ID:I35fUU7V
>>937
TDDを行う人は、「完全に」個人の趣味で行なうのであり、その個人にとってはただの慣習ですよ
「一息ついたらエディタを保存する」と同じレベルの趣味であり、慣習
0939デフォルトの名無しさん2014/09/25(木) 00:25:53.42ID:5/lLb9tL
>>938
そんなものはTDDとは到底呼べない

と書いたら理解できる？
0940デフォルトの名無しさん2014/09/25(木) 00:35:41.57ID:HNZsBDsf
>>936
Solid code の実践について TDD が活用できるという論調があるが
おまえの中にはなにかの根拠があって、双方の親和性を否定するということだよな？
その根拠になった TDD の理解の出所は？
0941デフォルトの名無しさん2014/09/25(木) 00:59:17.50ID:/kwrJ5S1
TDDは、贖宥状やトクホや世界遺産のように「認定」された工程ではない

しかしそういう認定証を偶像のように崇拝することにメリットがあるとも思えないし
慣習でいいんじゃないか
0942デフォルトの名無しさん2014/09/25(木) 01:55:50.81ID:HNZsBDsf
>>941
環境や仕事の状況もさまざまだから、そういう考え方があるのは同意できるし拒絶もしない

一方で、俺はこれまで何度か 「手法」 としての TDD の恩恵に与っている自覚があるので
>>932 のように頭ごなしに 「慣習！異論は認めない！」 みたいに言われると違和感を感じる
0943デフォルトの名無しさん2014/09/25(木) 11:48:21.15ID:u2ir+1nD
>>932
> 開発工程のテストは基本的にブラックボックステストで、時間と余裕があればコーダーとは別の人が行う性質のもの
という定義をするとき、「開発工程のテスト」以外のテストは

> コーダー本人の趣味と責任において実施するもので、時間と余裕があってもコーダー本人がやるべきもの
という主張？

となると、ホワイトボックステストの位置づけは？
0944デフォルトの名無しさん2014/09/25(木) 12:48:01.79ID:fB0UYRRr
どうもTDDを理解できない人がいるようだな。

分かりやすく説明してあげよう。

たとえばアプリやモジュールを作るとしよう。
どんなに小さくとも、普通は仕事の単位として
一つの関数だけを作ることはまず無い。
（プライベート関数も一つと数える）

最低でも一つの（パブリック）関数と
そこから呼び出されるプライベート関数
（またはパブリック関数）を作ることになる。

その時だよ、関数をトップダウンで作っていく？
それともボトムアップで作っていく？

TDDを使うっていうのは、トップダウンで作る？ それともボトムアップ
動作の確認はデバッグプリントして目視でやる？ それともテストコード書いてチェックする？

このぐらいの話なんだよ。

どの方法を使うかは開発者個人がが決める話で、人によっては全部ボトムアップで
作る人もいれば、違う人もいる。場合によってどちらで作るか変えても良い。

「うちの開発は全部ボトムアップでやると決めている」などと言う会社がないように
TDDは開発者個人が勝手に決めることなんだよ。
0945デフォルトの名無しさん2014/09/25(木) 12:57:31.96ID:u2ir+1nD
>>944
> このぐらいの話なんだよ。
と思っているお前が

> どうもTDDを理解できない人がいるようだな。
なんだが。
0946デフォルトの名無しさん2014/09/25(木) 13:01:13.96ID:V7k0k9/o
>>945
言いたいことがあるなら、ちゃんと言い返せよｗ
全く無能だな。
0947デフォルトの名無しさん2014/09/25(木) 13:03:55.51ID:u2ir+1nD
TDDが「このぐらいの話」と思ってるお前こそがTDDを理解してない奴だと言ってるんだが、わからんかったか。
0948デフォルトの名無しさん2014/09/25(木) 13:07:58.42ID:V7k0k9/o
理解してないやつだと言うだけの奴に対しては
お前のほうが理解してないやつだ、で十分な反論になる。

なぜ理由を何も書いてないのにこれで十分な反論になるのかって？
だってそもそも相手が理由を書いてないからｗ
0949デフォルトの名無しさん2014/09/25(木) 13:09:16.19ID:V7k0k9/o
ということで、理解してないのはID:u2ir+1nDの方でしたってことで
先に進もうぜｗ
0950デフォルトの名無しさん2014/09/25(木) 13:13:27.38ID:u2ir+1nD
どうぞ先に進んでくださいな。
俺はお前がTDDを理解してようがしてなかろうが、何も困らん。
0951デフォルトの名無しさん2014/09/25(木) 13:16:20.09ID:V7k0k9/o
ID:u2ir+1nDがTDDを理解してなかろうが何も困らん。

少なくとも、ID:u2ir+1nDはいいたいことが有るくせに
何も言い返せなかったって事実があるだけのことだ。

この言い返せないという事実のままで、俺は困らんｗ
0952デフォルトの名無しさん2014/09/25(木) 13:22:50.50ID:u2ir+1nD
まぁ、よそでも「TDDがこれぐらいの話」論を展開して、恥かけばいいよ。
0953デフォルトの名無しさん2014/09/25(木) 13:29:03.76ID:V7k0k9/o
恥かいてないけどなｗ

だって言い返したい奴が、何も言い返せないでいて、
それ以外の言い返すレスが何一つないのだからｗ

この状況で俺は困らんｗ
0954デフォルトの名無しさん2014/09/25(木) 13:33:49.50ID:u2ir+1nD
なんか勘違いしてるが、俺は「TDDとはこういうものだ」的な話はここでは一切やりたくないぞ。
ただ単にお前がTDDを理解していないという事実を指摘したまでだ。
0955デフォルトの名無しさん2014/09/25(木) 13:38:00.34ID:V7k0k9/o
指摘の内容が「わかってない！（理由はなし）」だから
お前は何も言ってないって言われてるんだよ。

なんでレスするのさ？
この状況で俺は困ってないんだから
お前も困ってないなら、レスする必要なくね？ｗ
0956デフォルトの名無しさん2014/09/25(木) 13:42:55.75ID:u2ir+1nD
まぁお前が本気で>>944のTDDの説明が正しいと信じているなら、それはそれでいいじゃないか。

ただ、>>944の説明は間違っていると言いたいだけだ。
0957デフォルトの名無しさん2014/09/25(木) 13:52:27.25ID:5/lLb9tL
>>944
全く理解できてないな。

「TDD」がなんの略称か考えてみろ。
で、それぞれの言葉の意味を考えろ。
0958デフォルトの名無しさん2014/09/25(木) 13:56:55.51ID:5/lLb9tL
>>955
ID:V7k0k9/oが本当に馬鹿なんだと思うが一応指摘しておくと、

結局>>944ではTDDの内容について一切触れていない。
だから、TDDを理解できていないと指摘されている。
理解できていると主張するなら、少なくともTDDについて言及する必要がある。
0959デフォルトの名無しさん2014/09/25(木) 20:04:14.25ID:aCIY3SmK
このようにゴールを決めずにダラダラ話を進むのを防ぐために
最初に達成目標を簡単にでも定義しておくことが大切という実例
0960デフォルトの名無しさん2014/09/25(木) 20:32:05.34ID:IYWLXPmn
読み飛ばしました
0961デフォルトの名無しさん2014/09/25(木) 23:15:25.41ID:I35fUU7V
>>939
ということは、日曜プログラマは「絶対に」TDDを実践できないということですね
0962デフォルトの名無しさん2014/09/25(木) 23:27:10.55ID:I35fUU7V
>>942-943
頭ごなしに 「慣習！異論は認めない！」 と言わなければならない理由は、TDDでは、どのレベルでどんなテストを書くかをコーダー本人が「勝手に」決めなければならないから

これから自分が打つコードがちゃんと打たれるのか確認するためのテストなんだから
0963デフォルトの名無しさん2014/09/25(木) 23:27:28.39ID:5/lLb9tL
>>961
なんで？
0964デフォルトの名無しさん2014/09/25(木) 23:28:18.96ID:5/lLb9tL
>>962
だからお前は
TDDが理解できていないって言われてるんだが・・・
0965デフォルトの名無しさん2014/09/25(木) 23:47:17.12ID:I35fUU7V
>>963
TDDは、どの定義にも書いてあるけど、自分が打ち込むコードの正しさに「コーダー本人が」確信を得るためのもの
しかし、この定義まで否定するとなると、コーダー一人で完結する環境ではTDDは実践できない
0966デフォルトの名無しさん2014/09/26(金) 01:54:41.41ID:h5xYqq51
>>944 と >>962 で
議論が時間の無駄になることだけはわかったよ・・・
0967デフォルトの名無しさん2014/09/26(金) 08:28:44.20ID:fTKEl0JO
導入以前の定義でモメるんだから、スレタイどおりの事例じゃないか。
0968デフォルトの名無しさん2014/09/26(金) 12:28:46.36ID:nl3/PMyh
普通に「プログラマー」と言わずに「コーダー」って言う奴にろくな奴が居ないの法則
0969デフォルトの名無しさん2014/09/26(金) 12:50:06.15ID:8tItaSRz
工程をはっきりしろと繰り返す一方で
用語を細かく使い分けると謎の被害者妄想が始まる
0970デフォルトの名無しさん2014/09/26(金) 13:10:27.74ID:6H6eMXnu
まあこの流れぐらいは理解しておきましょうね。

http://gihyo.jp/dev/serial/01/tdd/0002

テスト駆動開発は，小さなステップを繰り返してプログラムの設計と開発を行っていく
ソフトウェア開発手法です。テスト駆動開発は次の3ステップから構成されています。

テスト駆動開発の3ステップ
ステップ1：これから書く機能に対するテストを1つ書き，テストが失敗することを確認する（レッド）
ステップ2：ステップ1のテストを通す最低限のコードを実装する（グリーン）
ステップ3：リファクタリングを行う（リファクタリング）

ステップ1：これから書く機能に対するテストを1つ書き，テストが失敗することを確認する

テスト駆動開発では，まず1ステップ目として，これから書く機能のテストを1つ書きます。
「テストを書く」と簡単に言っていますが，ここでの「テスト」とは，開発者が自分で書く，
プログラムの形で書かれたテスト（テストコード）のことです。

ステップ2では，ステップ1で書いたテストを通す最低限の実装を書きます。
機能が動作するところまで持っていくのがこのステップ2です。

ステップ3：リファクタリングを行う

ステップ2では，テストを通すために最もシンプルなコードを書くことを選択しました。
すると，ステップ2で最低限の実装を書いた時点では，コードに無駄があったり愚直過ぎる
コードだったりと，いくつか直したい点があると思います。たとえばコードの重複です。
0971デフォルトの名無しさん2014/09/26(金) 13:11:50.64ID:6H6eMXnu
で、聞きたいのは、「工程」って何のことを言ってるんですか？

やる作業は実装なんですから「開発工程」の中で
やることに決まっていると思いますが、
なんで工程なんか気にするんですか？
0972デフォルトの名無しさん2014/09/26(金) 14:03:42.89ID:IYT310Ai
>>970-971
おまえは変なところの資料を拠り所にして変な解釈してるだけ。
もう少しまともな資料見つけて来い。
0973デフォルトの名無しさん2014/09/26(金) 14:24:41.53ID:nl3/PMyh
またアンチt_wadaか
0974デフォルトの名無しさん2014/09/26(金) 14:29:00.79ID:n33Pkj/x
流行るというのは数が多いってことだよね
線で囲まれた中に人がたくさん入っている
線が見えなければ人を数えることはできない
逆に線が見えすぎるとみんなSingletonのようになって数が無意味になる

でも開発自体には全く支障はない
流行ってることを確認したいという開発と関係ない作業のところで揉めてるだけ
0975デフォルトの名無しさん2014/09/26(金) 14:49:11.97ID:nl3/PMyh
流行ってるかどうかは誰も揉めてないんじゃないの？
（もちろん流行ってない）
0976デフォルトの名無しさん2014/09/26(金) 15:13:34.34ID:6H6eMXnu
>>972
お前が見つけてこいよーｗ

見つけられないから
わーわー喚いてるんだろーｗ
0977デフォルトの名無しさん2014/09/26(金) 22:51:50.40ID:gXbCnOyX
>>970
ステップ1 と ステップ2 の順序が前後しても問題ないんですよね‥
0978デフォルトの名無しさん2014/09/26(金) 22:52:03.22ID:zO2qKBmh
>>970
> テスト駆動開発は，小さなステップを繰り返してプログラムの設計と開発を行っていく
> ソフトウェア開発手法です。

TDDは小さなステップを繰り返して設計と開発を行っていく手法なので、
ウォーターフォールのように設計フェーズと開発フェーズが分かれていると
本人の趣味と責任において勝手に実施しようとしても無理
0979デフォルトの名無しさん2014/09/26(金) 23:23:12.88ID:R93KpJTK
>>970
肝心の目的を書いてくれないとこまる
0980デフォルトの名無しさん2014/09/26(金) 23:26:54.67ID:R93KpJTK
>>971
ソフトウェア開発工程
0981デフォルトの名無しさん2014/09/26(金) 23:35:16.04ID:6UoHfY/b
>>978
お前ばかなの？

TDDは開発フェーズ内でやるものだって
みんな言ってるだろ。
0982デフォルトの名無しさん2014/09/26(金) 23:39:39.80ID:zO2qKBmh
>>981
お前ばかなの？

アジャイルじゃなかったら開発フェーズで設計できないだろ
0983デフォルトの名無しさん2014/09/26(金) 23:54:20.60ID:R93KpJTK
>>981
TDDは、開発工程の中であろうが、開発工程とは無関係であろうが、コーダーの趣味で好きなように行う慣習
こまめなエディタの保存と同じ位置づけ

TDDが開発工程の一部ではないという一番の根拠が、TDDで作るテストは定められた成果物なのかどうか
結論としては、emacsの~ファイルと同様の、コーダーの趣味で勝手に入れたり消したりする類のもの
0984デフォルトの名無しさん2014/09/26(金) 23:57:40.29ID:zO2qKBmh
コーダーに設計する権利なんてないでしょ
最初にテスト書いたって設計に一切反映されないならTDDじゃないよ
0985デフォルトの名無しさん2014/09/27(土) 00:00:42.53ID:AEoQ5euz
>>984
TDDのテストは、自分がこれから打ち込むコードが自分の意図したとおりのものなのか「本人が安心するために」書くものだから、基本的に設計とは関係ない
0986デフォルトの名無しさん2014/09/27(土) 00:04:34.04ID:0IvxL3Y7
>>985
>>970の引用一行目に「設計」って書いてあるの読める？
もし異論があるなら否定するソースを持って来てね
0987デフォルトの名無しさん2014/09/27(土) 00:17:57.47ID:T5Eliw4A
>>986
その引用元が間違ってる
そもそもの、TDDを行う目的の記述がないから

ちなみに 普段はトンデモなwikipediaにすら
TDD encourages simple designs and inspires confidence.
ときちんと「コーダーの確信のために」と書いてあり、これを読むと、むしろコーディングの最中に設計を行わないためにTDDが役立つように書いてある
0988デフォルトの名無しさん2014/09/27(土) 00:21:48.99ID:0IvxL3Y7
>>987
その短い文章の中でさえdesignsに言及されてる件
0989デフォルトの名無しさん2014/09/27(土) 00:25:19.35ID:T5Eliw4A
>>988
wikipediaを読むと、「simple design」は「TDDでテストを書くことによってデザインしないこと」の意味にとれるが
0990デフォルトの名無しさん2014/09/27(土) 00:57:28.42ID:0IvxL3Y7
>>989
そのWikipediaから引用

> By focusing on writing only the code necessary to pass tests, designs can often be cleaner and clearer than is achieved by other methods.

> Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program.

TDDによってプログラムのデザインが綺麗になるとか書かれてますけど
いったいどこを読んでるの？
0991デフォルトの名無しさん2014/09/27(土) 01:10:06.48ID:T5Eliw4A
>>990
There are various aspects to using test-driven development, for example the principles of "keep it simple stupid" (KISS) and "You aren't gonna need it" (YAGNI).
という「設計する」とは逆のことを目指した結果、
By focusing on writing only the code necessary to pass tests, designs can often be cleaner and clearer than is achieved by other methods.
となり、
Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program.
という利益が得られると書いてある

だから、TDDはKent Beckの主張するとおり、
TDD 「encourages」 simple designs and 「inspires」 confidence.
というコーダーの心の問題の解決を目指すものであり、ゆえに、工程や設計とは別の場所に位置する趣味であり慣習
0992デフォルトの名無しさん2014/09/27(土) 01:17:00.70ID:0IvxL3Y7
KISSやYAGNIが設計するのとは逆を目指す？
何言ってんだお前
0993デフォルトの名無しさん2014/09/27(土) 01:17:47.38ID:Mq6zBLm5
コーダーの趣味や慣習でしかないものを採用する企業がどこにあるんですかね
0994デフォルトの名無しさん2014/09/27(土) 01:19:28.64ID:T5Eliw4A
>>992
keep it simple stupid.
馬鹿でいろ

You aren't gonna need it.
よけいなことすんな
0995デフォルトの名無しさん2014/09/27(土) 01:20:26.49ID:T5Eliw4A
>>993
「エディタをこまめに保存する」はコーダーの趣味や慣習でしかないけど、これを採用していない企業があったら知りたい
0996デフォルトの名無しさん2014/09/27(土) 01:27:04.36ID:z3mF+ujQ
>>995
そういうのはきょうびのエディターなら自動でしてくれる‥
0997デフォルトの名無しさん2014/09/27(土) 01:27:25.24ID:Mq6zBLm5
>>995
業務工程に何ら変化を与えずコストもリスクもない行為を比較対象に並べられるお前の神経を疑う
0998デフォルトの名無しさん2014/09/27(土) 01:28:31.61ID:0IvxL3Y7
>>991>>994
普通に考えれば、

テストが書きやすいコードはシンプルな設計であることが多いことから、
テストを最初に書く事でシンプルな設計になり（KISS）、
また開発しながら設計するから実際に使わない機能は追加されない（YAGNI）

という話だと読めるだろ


じゃあ訊くが、TDDが仮にコーダーの心の問題の解決を解決する趣味だとして、
それでどうして設計が改善するわけ？
0999デフォルトの名無しさん2014/09/27(土) 01:36:03.61ID:Zga4OGJt
>>994
ドカタの世界の話を持ち込むなよ
1000デフォルトの名無しさん2014/09/27(土) 01:39:24.26ID:Zga4OGJt
コーダーと表現する奴の99%は無能なSEモドキで
Excel方眼紙を埋めるのを設計だと思ってるからな

そりゃTDDやってもExcel方眼紙は変化しない罠
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。