5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2013/12/22(日) 16:04:07.02
一度は挑戦するけれど、
みんなやらなくなりますよね。

2 :デフォルトの名無しさん:2013/12/22(日) 17:24:49.21
最初にわざと一度間違えるというのが直感的でなく、ストレス
そこを省いたりミスしたりすると意味がなくなる

3 :デフォルトの名無しさん:2013/12/22(日) 23:08:52.06
というか、テスト駆動は、、技術ないとむりよ?

4 :デフォルトの名無しさん:2013/12/22(日) 23:34:32.48
ある程度経験つむと簡単な機能ではバグ出さなくなるからテスト作るだけ無駄
クラス毎とかでテスト作ってるプロジェクトって馬鹿でしょ

5 :デフォルトの名無しさん:2013/12/22(日) 23:42:29.06
変更が多いとかほかへの依存度が高いとか
挙動の隅々まで外から見えにくいとか
そういうのはテストつけとくと安心

6 :デフォルトの名無しさん:2013/12/23(月) 00:33:43.02
>>5
それは別に後からテストつければいいでしょ?

システムってのは、画面周りのような単純だけど数が多い部分と、
画面に配置するようなパーツみたいに複雑だけど作るのは一回の部分とに分かれる。

単純で数が多い部分は、こう書いたんだからこう動くに決まってるやん?って言うぐらい単純になる。
例えば言えばSQLでorder by書いたんだからその順に並ぶの当たり前じゃんみたいな。
そんなものに対して、データ用意してこの順番に出力される。みたいなテストを書くのは意味が無い。
だいたいなんのテストしてるのかわからんし。

複雑だけど作るのは一回みたいな部分は、複雑だから試行錯誤しないといけない。
それなのにテストを書いたら、テストを何度も書き直さないといけなくなる。

テスト駆動ではなく、作りながらテストを書くほうが効率がいい。

7 :デフォルトの名無しさん:2013/12/23(月) 00:47:14.92
まともな仕様書書かないくせに、上から目線で丸投げするから。
責任も現場に丸投げ。

8 :デフォルトの名無しさん:2013/12/23(月) 01:52:33.36
流行るもなにも、昔からプログラミングは普通にテスト駆動開発ですよ
特徴的なテストデータを用意して動くかどうか確認しながら作るなんて、演習の大学生でもやってる

スケルトン用意してユニットテストのコード埋めたりするような大げさなやり方が流行ってないからといって、テスト駆動開発が流行ってないと言うのはいかがなものか

正確には、「テスト駆動開発は、巨大なシステムも大学の演習の10行コードも、なぜ同じようなやり方が流行っているのか」ではなかろうか

9 :デフォルトの名無しさん:2013/12/23(月) 01:55:43.59
>>4
そう思ってたら、javaのバージョンアップでやられた

10 :デフォルトの名無しさん:2013/12/23(月) 02:09:17.21
>>8
演習に大学生ぐらいしかやらないの間違いだろ?

そりゃ演習なら、準備して何度も同じものを多くの人にやらせるわけだから
最初に出題と答えを用意できるだろうさ。

11 :デフォルトの名無しさん:2013/12/23(月) 02:11:01.01
あと大学生の場合、勉強のために
回り道してでも時間をかけてやるってのが違う所だな。

12 :デフォルトの名無しさん:2013/12/23(月) 03:09:27.98
要はデザパタと同じでデジドカ共のスキルを平準化するために明文化しただけでしょ
お前らみたいなスーパープログラマには無用の長物

13 :デフォルトの名無しさん:2013/12/23(月) 03:12:31.87
あーいるいる、そういう偏見と思い込みばかり持ってる無能w

14 :デフォルトの名無しさん:2013/12/23(月) 03:12:45.26
プログラマ←派遣
スーパープログラマ←無職

15 :デフォルトの名無しさん:2013/12/23(月) 03:31:40.30
どんな場合にもテストが必要なわけじゃない。
だけど、テスト駆動ではテストを書かないとプログラムが作れない。
必要がないようなテストを省くとテスト駆動にはならなくなる。

16 :デフォルトの名無しさん:2013/12/23(月) 04:00:59.07
例えばHello Worldとかさ、テスト駆動にする意味あるの?って話だよ。
一体何をテストするのか? Hello Worldと書いたのだから
Hello Worldと表示するのは当たり前だろ?と。

極端な例と思うかもしれないが、--helpってやったらヘルプが
表示されるテストとかさ、なんのテストを先に書けばいいのかわからない。
テストにヘルプ内容書いて、それをまたコードに同じこと書くのか?

年月を入力して2月の末日が何日かを求めるコードのテスト駆動は書く意味があるだろう。
でも2月以外の末日はどうなんだ? テストコードに2月以外の末日を月と日付の
ハッシュテーブルで書いておいてそれをコードにコピペするのか?

すべての場合においてテストが必要とは限らないのに、
テストがなければコードが書けないというのが無理あるんだよ。

17 :デフォルトの名無しさん:2013/12/23(月) 05:34:50.22
>>16
アホみたいなプログラムもテストがあるとありがたいというのは、既存コードを携帯に移植するときに思い知らされたわ
ユニットテストは、コードのテストだけではなく、環境と基本ライブラリとコンパイラのテストでもある

18 :デフォルトの名無しさん:2013/12/23(月) 05:37:16.25
Cのmain関数ですら書式が変わってたり。

19 :デフォルトの名無しさん:2013/12/23(月) 07:06:10.70
テストデータ自体の検証も必要で以下ループとか
仕様書がうんこでテストデータ作成すら無理ゲーとか

いろいろあるよね…

20 :デフォルトの名無しさん:2013/12/23(月) 07:55:59.52
mainのテストなんかそもそも書かんわ
TDDのやり方分かってねえだろ

21 :デフォルトの名無しさん:2013/12/23(月) 12:43:34.50
>>16
組み込みだとメモリ足りなくてスタックオーバーフローとかあるわ

22 :デフォルトの名無しさん:2013/12/23(月) 13:25:55.23
移植するかもわからない携帯のためというのは
YAGNIである。

23 :デフォルトの名無しさん:2013/12/23(月) 13:44:00.29
はあ?
最初から組み込み向けの話だろ
YAGNIって何だよ、カスが

24 :デフォルトの名無しさん:2013/12/23(月) 13:59:39.54
>>23
携帯に移植って書いてるのが読めないの?

25 :デフォルトの名無しさん:2013/12/23(月) 14:58:11.02
携帯のためじゃないと単体テストやらんのか
へえ

26 :デフォルトの名無しさん:2013/12/23(月) 17:47:42.00
テストというのは仕様を満たしているか確認する為のもの
仕様が変わるとテストも変わる
次々と変わる仕様に対応してテストも次々と変更していくのは工数の無駄でしかないと思うの

27 :デフォルトの名無しさん:2013/12/23(月) 17:59:41.44
じゃあ仕様なんか変えなきゃいい

28 :デフォルトの名無しさん:2013/12/23(月) 19:02:24.23
変わりやすい部分と変わってはいけない部分がある
首根っこを押さえれば被害は少ない

29 :デフォルトの名無しさん:2013/12/23(月) 20:49:42.25
そもそも仕様変更のためにテスト書くもんじゃないのか
テストを変更仕様へ・失敗→ソース変更・成功みたいな順で

30 :デフォルトの名無しさん:2013/12/23(月) 21:01:15.80
誰もユニットテストがだめとは言ってないんだよ。
テスト"駆動"がだめという話。

テストはアプリを正しく作る上で必須のものではない。
省略しても正しく動くアプリは作れる。

だけどテスト駆動開発だと、テストを最初に書かないといけない。
これが大きなネックになる。

テスト駆動はコードの書き方の一つ
一つの開発の中で、この関数(クラス)はテスト駆動で作ったが
こっちはテストそのものがないみたいに、バランスよく使うもの

31 :デフォルトの名無しさん:2013/12/23(月) 21:12:35.30
>>29
> テストを変更仕様へ・失敗→ソース変更・成功みたいな順で

それ、意味があるのか?ってことになるか、
大変すぎるかのどちらかになることが多い。

意味があるのか?っていうのは簡単な修正の場合。
色が赤から青になりました。みたいな場合、
テストで色を青に変えて、コードでも青に変える。
単に変更する箇所が二つになっただけにしか思えない。

大変すぎる例は、変更の影響範囲が広い場合。
ある関数を変更するとして、その関数に依存している部分がたくさんある時、
そのすべてのテストを正しくを変えるのは難しい。どうしてもコードを変えた後に
通らなくなったテストを修正することになる。

32 :デフォルトの名無しさん:2013/12/23(月) 22:02:16.80
テスト駆動だと外注しやすくなると思うじゃん?
逆に中国人はテストさえすり抜ければ何でもいいという風になるんだよ

33 :デフォルトの名無しさん:2013/12/23(月) 22:10:15.70
というか、プログラム書くときには絶対に1度はコンパイルしてテストするでしょ?
そのテスト用のデータを再利用できるように保存するかどうかの話だと思うのだが

かたくなにテスト書かないって言ってる人はプログラムのコード書いて使わないの?

34 :デフォルトの名無しさん:2013/12/24(火) 00:47:50.31
>>32
ユニットテストと受け入れテストの混同

35 :デフォルトの名無しさん:2013/12/24(火) 00:58:19.58
>>33
コンパイル通ったらコーディング完了で、
テストフェーズになるまで一切動かさないという人はよくいる。

36 :デフォルトの名無しさん:2013/12/24(火) 01:08:47.48
とりあえず都合のよい理想的なデータでもいいから、コンパイルしたらその場で1度くらいは何かが動くことくらいは確認しようよ

37 :デフォルトの名無しさん:2013/12/24(火) 01:24:01.21
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

38 :デフォルトの名無しさん:2013/12/24(火) 01:26:21.27
>>33
少し書き足すごとにアプリを起動して動作確認できるような規模の話じゃないんだよ

39 :デフォルトの名無しさん:2013/12/24(火) 06:07:50.17
>>38
というか、その少し書き足した分がそれなりに正しいかをその場で確認しないの?
どんな規模の開発でも、それくらい確認するでしょう

40 :デフォルトの名無しさん:2013/12/24(火) 13:35:36.75
目視で見つかるレベルの多数のミスを直そうとしたら
テストフェーズで検出ゼロになるとマズイと止められた
あの夏の記憶

41 :デフォルトの名無しさん:2013/12/24(火) 14:53:58.83
>>39
そこそこ規模の大きい開発だとコーディングしたプログラマがコンパイルやテストをする事はないよ

42 :デフォルトの名無しさん:2013/12/24(火) 15:01:02.18
>>41
> そこそこ規模の大きい開発だとコーディングしたプログラマがコンパイルやテストをする事はないよ

相当特殊な環境ならそういうこともあるかもしれないが、普通はどんなに大規模なプロジェクトでも開発者テストは行われる。

また、今時VCSを使わない大規模プロジェクトは考えにくいが、VCSを使うなら、コンパイル不可なコードをコミットするのは
犯罪行為とも言える。すなわち、少なくとも開発者自身がコンパイルOKなのを確認する。
そして大抵は、開発者テスト済みでなければコミット不可というルールを付けているはずだ。

43 :デフォルトの名無しさん:2013/12/24(火) 16:19:59.63
LINTみたいなのは最低限使えるのかな
なかったら悪夢

それでも作成者本人が動作を見れば一瞬で気づくレベルのミスまで
毎回別担当者が再現手順をしぼりこんで〜とかやってられん

44 :デフォルトの名無しさん:2013/12/24(火) 16:44:56.07
>>31
> ある関数を変更するとして、その関数に依存している部分がたくさんある時、

それは設計が悪いのではないだろうか。

45 :デフォルトの名無しさん:2013/12/24(火) 19:36:06.47
レガシーコードはしょうがないね
ビルド通るまで気合でスタブ書くしか

46 :デフォルトの名無しさん:2013/12/24(火) 22:19:47.79
組み込みだと、実機が無い状態でプログラムだけ書くというのはよくある。
ちゃんとしたプロジェクトならPC上でモジュールの動作確認できるような仕組みを作るけど、
世の中にはちゃんとしてないプロジェクトの方が多いからね。

47 :デフォルトの名無しさん:2013/12/25(水) 00:13:17.77
>>44
多くの場合、"関数"は"使いまわす"ものなので、
仕様変更で関数を変更したら、修正しなければ
いけないところは複数ありますよ。


※「仕様変更したという前提の話です(>>29)」って
書いておかないと的はずれなレスしてきそうなので書いときます。

48 :デフォルトの名無しさん:2013/12/25(水) 00:15:27.88
>>41
100歩ゆずってリンクはしないとしても、コンパイルくらいはするでしょ

49 :デフォルトの名無しさん:2013/12/25(水) 00:22:50.40
>>47
そもそも仕様変更するのが前提なのがソフトウェアだから、断り書きは必要ないですよ

50 :デフォルトの名無しさん:2013/12/25(水) 00:35:25.98
>>48
コンパイルってなんですかぁ? by Ruby使い

51 :デフォルトの名無しさん:2013/12/25(水) 00:46:42.90
ぷよぷよ作った会社

52 :デフォルトの名無しさん:2013/12/25(水) 00:54:07.22
>>50
Rubyならなおさら、書いた直後になにかしらの確認をしないという状況が思い付かないのだが

53 :デフォルトの名無しさん:2013/12/25(水) 01:48:57.09
>>47
設計が悪いような気がしてならない。

> ある関数を変更するとして、その関数に依存している部分がたくさんある時
ある関数を変更しても、その関数に依存している部分の仕様は変わらない
→機械的にリグレッションテストが実行できる
のが普通ではなかろうか。

54 :デフォルトの名無しさん:2013/12/25(水) 01:57:59.97
×ある関数を変更しても、その関数に依存している部分の仕様は変わらない
○ある関数を変更しても、その関数に依存している部分の仕様は変わらないように修正しないといけない

そのため>>31で書いたように

> そのすべてのテストを正しくを変えるのは難しい。どうしてもコードを変えた後に
> 通らなくなったテストを修正することになる。

55 :デフォルトの名無しさん:2013/12/25(水) 01:59:40.41
言っとくけど、テスト駆動の話だからね。

56 :デフォルトの名無しさん:2013/12/25(水) 02:12:24.81
何かを動かそうという要求が先にあってプログラムを作るんだから、すべてのプログラミングはテスト駆動です
その要求を自動で検証できる形で明示的に残さなくてもテスト駆動です

57 :デフォルトの名無しさん:2013/12/25(水) 02:30:12.03
>>54
関数aをモジュールA,B,Cで参照している場合、関数aを変更してもモジュールA,B,Cの仕様は変わらない(ように調整する)
ならば、モジュールA,B,CのテストTA, TB, TCは変更しなくても済むのではないか?

58 :デフォルトの名無しさん:2013/12/25(水) 02:39:04.70
>>57
変更するのはテストじゃないよ。

関数aを変更した時、モジュールABCの仕様を変わらないようにするために
モジュールABCに含まれる関数aの呼び出し部分を修正する必要がある。

テスト駆動というのであれば、先にモジュールABCの関数a呼び出し部分を
修正しなければいけないが、関数aを使用しているモジュールABCの存在が、
特に動的言語の場合はテストを実行するまでわかりづらいから
関数aを修正した後にテストコードを実行して失敗したテストを修正することになる。

>>29が言っているような、仕様変更の際に
「テストを変更仕様へ・失敗→ソース変更・成功」という
流れは現実的ではない。

59 :デフォルトの名無しさん:2013/12/25(水) 08:16:10.93
なんで現実的でないかというと、無能だから

60 :デフォルトの名無しさん:2013/12/25(水) 10:27:21.95
テスト駆動はひとりでやるもんなの?て気分になる
答えわかってるしイテレーティブの気持ちいい流れを害される気分
他の人が仕様の代わりにテストを作ってくれてその正解コードを書くっていうなら気持ちよくできるけど

61 :デフォルトの名無しさん:2013/12/25(水) 10:40:28.97
>>58
> 関数aを変更した時、モジュールABCの仕様を変わらないようにするために
> モジュールABCに含まれる関数aの呼び出し部分を修正する必要がある。
関数aが変更された時に、関数aの呼び出し部分を修正する必要があるような設計が
駄目なんじゃないのって言われてるのわかってる?

> 関数aを修正した後にテストコードを実行して失敗したテストを修正することになる。
考え方が逆だよ。
関数aの変更が、モジュールABCのテストに影響を及ぼすとしたら、まずテストをリファクタリングする
必要があるかを考慮する。

どうしても関数aの変更の影響をモジュールABCのテストから断ち切れない場合は、まずそのテストが
そのままで良いかどうかをチェックする。
そうしないと、「本来は期待値が変わるはずだったのに変わっていない」というバグを検知できない。

まずテストを実行してみて、失敗したテストを修正するというのは下の下の策。

62 :デフォルトの名無しさん:2013/12/25(水) 10:47:06.00
テストは関数の仕様が決まった後の「内部実装」の品質を保証するための手段だから。
関数の仕様が変更されたら云々ってのは全く意味を持たない議論。

63 :デフォルトの名無しさん:2013/12/25(水) 11:20:39.09
>>62
> テストは関数の仕様が決まった後の「内部実装」の品質を保証するための手段だから。
ここTDDスレなんですが。

64 :デフォルトの名無しさん:2013/12/25(水) 11:26:18.74
>>62
> テストは関数の仕様が決まった後の「内部実装」の品質を保証するための手段だから。
> 関数の仕様が変更されたら云々ってのは全く意味を持たない議論。

意味がわからん。
変更後の仕様が決まったら、その「「内部実装」の品質を保証するための手段」じゃないの?

65 :デフォルトの名無しさん:2013/12/25(水) 21:16:34.62
>>61
> 関数aが変更された時に、関数aの呼び出し部分を修正する必要があるような設計が
> 駄目なんじゃないのって言われてるのわかってる?

ほらな。

> ※「仕様変更したという前提の話です(>>29)」って
> 書いておかないと的はずれなレスしてきそうなので書いときます。

って書いたのにこんなこと言い出す。

仕様変更でモジュール内部で使用している定数が、ファイルからの読み込みだったのが
データベースからの読み込みに変わったがそのモジュールはデータベース
コネクションオブジェクトを持っていなかったから渡さないといけない。
このモジュールを使っている全てのコードを修正する必要がある
とかあんだろ。

66 :65:2013/12/25(水) 21:18:58.16
こういう場合、先にテストを修正してからコードを修正するのではなく、
コードを修正してから落ちたテストを直すほうが正確で速い。

67 :デフォルトの名無しさん:2013/12/25(水) 21:39:20.67
>>65
でも、テストは書き換えなくてもいいよね?
あるモジュールがファイルを使うかDBを使うかで、
そのモジュールを使ってるコードの仕様が変わるのはおかしいわけだし。

68 :デフォルトの名無しさん:2013/12/25(水) 22:00:06.34
テストだけが全ての先を見通して書けるのにどうしてコードをそうできないのかっていいたいな。
先を見通してコードがかけないから修正がいるわけだしテストも同様にそうなるよ。

69 :デフォルトの名無しさん:2013/12/26(木) 00:39:09.52
数学でいうと、テストを先に記述するの集合の外延表記
テストではなくコードを中心にすえるのは内包表記

内包で数学が大コケしたのを知ってれば、テストを先に書く大切さが分かる

70 :デフォルトの名無しさん:2013/12/26(木) 12:50:25.07
>>65
> このモジュールを使っている全てのコードを修正する必要がある

という設計が駄目だって言われてるのがまだわからんのか

71 :デフォルトの名無しさん:2013/12/26(木) 13:58:40.19
TDDはアジャイルの流れでインタフェース偏重だべ
ストレージだかテーブルだかを介するように直しておくのが手順だべ

72 :デフォルトの名無しさん:2013/12/26(木) 15:42:56.89
>>65
直交性とか凝集度と結合度についてググれ

73 :デフォルトの名無しさん:2013/12/26(木) 18:52:41.98
メソッド名をリファクタリングで変更しただけで
テストがぶっこわれる動的言語でTDDは無茶です。

74 :デフォルトの名無しさん:2013/12/26(木) 19:22:19.98
>>73
壊れる場所をきちん検出できることは利点じゃないのか…

逆に言うと、メソッド名の変更で不具合が出る場所を何で検出するの?

75 :デフォルトの名無しさん:2013/12/26(木) 20:32:31.28
>>1
まともな仕様が書けないのに、テスト方法が決められるわけはないわな。(w

76 :デフォルトの名無しさん:2013/12/26(木) 20:41:12.43
>>75
書くべきモノは分からなくても、書いてるつもりのモノは分かるから、仕様は書けなくてもテストは書ける

77 :デフォルトの名無しさん:2013/12/26(木) 21:52:20.20
静的言語というか、例えばJavaとかならメソッド名が変わったらコンパイラやIDEがエラーを吐いてくれるけど、
動的言語ではそれができないからTDDが必要なんじゃないの?

78 :デフォルトの名無しさん:2013/12/26(木) 22:00:12.92
>>77
コンパイラが見つけることができるエラーは限られている

79 :デフォルトの名無しさん:2013/12/27(金) 02:01:41.93
>>42
1.プログラマが製造
2.テスターがテスト
3.プログラマが修正(2へ戻る)

これのうち1と3は同じ人間がやってもいいけど、2が同じ人間じゃまずいだろ
それにプログラマがコンパイルまでやってたら生産性落ちる

80 :デフォルトの名無しさん:2013/12/27(金) 02:05:09.19
テスト駆動はリファクタリングを正当化する為の詭弁ではないか?

81 :デフォルトの名無しさん:2013/12/27(金) 02:22:01.03
>>79
テストをする義務があるのは、そのコードを書いたプログラマ
理由は、書いた直後が一番バグを見つけるのが簡単だから
バグのないコードを作るのが目的なら、プログラマは、時間がゆるす限り、できるテストは書いたその場ですべてやる義務がある

テスターがやることができるのは、ブラックボックスをつついて奇跡的にたまたま出るエラーを待つだけだから、そもそも能力的に義務をおう立場にない
すべてを知ってる人間とは違う視点から確認するだけ
だから、
1.プログラマが製造
2.プログラマがありとあらゆるテスト
3.プログラマが修正(2へ戻る)
4.テスターがブラックボックステスト(プログラマが盲点にしていた視点を指摘して3へ戻る)
5.納品

82 :デフォルトの名無しさん:2013/12/27(金) 08:00:46.03
自分のコードのバグを見つけられるなんて幻想だよ
正常条件で動くテストと実装を優先するテスト駆動は特にそうなる
だからこそコードレビューが重要なんだから

83 :デフォルトの名無しさん:2013/12/27(金) 08:05:02.82
>>76
× 仕様は書けなくてもテストは書ける
○ 仕様は書けなくてもテストのつもりのコードは書ける

84 :デフォルトの名無しさん:2013/12/27(金) 16:11:30.27
>>82
> 自分のコードのバグを見つけられるなんて幻想だよ
> 正常条件で動くテストと実装を優先するテスト駆動は特にそうなる
お前だけだよ

85 :デフォルトの名無しさん:2013/12/27(金) 17:46:22.29
上司に「何をオマエはテストしたんだ」って言われたら
「俺が作って俺がテストしたから大丈夫」とか言うわけ?

86 :デフォルトの名無しさん:2013/12/27(金) 17:49:25.72
>>85
話が飛躍しすぎ。
最後まで開発者テストだけしかしないなんて誰も言ってない。

87 :デフォルトの名無しさん:2013/12/27(金) 17:51:01.59
すまん読んでなかった

88 :デフォルトの名無しさん:2013/12/27(金) 17:53:46.47
PGは行数で評価されるんだよ
コンパイルして修正してそれで行数増えるのか?

89 :デフォルトの名無しさん:2013/12/27(金) 17:59:55.11
ブラック企業ではそうなの

90 :デフォルトの名無しさん:2013/12/27(金) 22:45:02.96
>>88
増えるよ?

91 :デフォルトの名無しさん:2013/12/27(金) 22:50:08.89
>>67
> でも、テストは書き換えなくてもいいよね?
> あるモジュールがファイルを使うかDBを使うかで、
> そのモジュールを使ってるコードの仕様が変わるのはおかしいわけだし。

書き換える必要あるぞ。

あるモジュールがファイルを使っていたが、
それがデータベースを使うようになったら
コネクションオブジェクトが必要になる。
そのコネクションオブジェクトは内部で作るわけではなく外部から渡される。
(当たり前。一つのアプリでいくつもコネクション接続するな)

そしてモジュールは外部から渡されるコネクションに依存したコードになるから
テストコードは、そのモジュールにコネクション(のモック)を渡すように修正しないといけない。

92 :デフォルトの名無しさん:2013/12/27(金) 22:52:28.35
>>70
> という設計が駄目だって言われてるのがまだわからんのか

じゃあ、

(質問1) >>91の例をどうすればいいのか?

(質問2) 問題があるコードを修正するのがリファクタリングの目的の一つだが、
問題のあるコードがすでにある場合はどうするのか?

最初から間違いをしなければいいという回答は
ありえないので間違った回答だる。

93 :デフォルトの名無しさん:2013/12/27(金) 23:08:05.89
俺だったら、DBコネクションを管理するオブジェクトからDBコネクションをもらうようにするかな。

94 :デフォルトの名無しさん:2013/12/27(金) 23:09:23.76
>>82
> 自分のコードのバグを見つけられるなんて幻想だよ

自分のコードのバグを他人が見つけられるってのも幻想だよ。

そもそもバグが入り込む原因の一つはコードが不必要に複雑ってのがある。
複雑なコードを他人がコードレビューした所で、時間がかかるだけで実りがない。

優れたレビューアなら、コードが複雑だからという理由で、読まずに突き返すことが出来るだろうが、
それは、コードを書く人の技術力 < レビューする人の技術力 というのが前提になる
これは、ホワイトボックスなやりかただが、ブラックボックスだとさらに問題が大きい

ブラックボックスだと、コードのクラス・関数レベルの詳細仕様は存在しないのが普通
現実として正常系程度しか書かれていない仕様がほとんどでアプリの仕様には詳細な動作は記述されない。
そうすると何をテストすればいいのかわからない。

例えば、項目A(3パターン)、項目B(3パターン)、項目C(3パターン)、があるとき、
9パターンをテストすればいいのか27パターンテストすればいいのかわからない。
仕様からは9パターンと読めても、コードがコピペされ27パターン相当になってるかもしれない。

こういうのは実際にコードを書いた人が指示をだすしかないが、そうするとコードを書いた人が
テストすべきと思ったことしか書かないので、結局自分でテストしているのと同じになる。

だから理想としては、ホワイトボックスできる力を持ったテスターがブラックボックステストをするのがいいが、
テスターの技術力は、コードを書くよりも高い技術力が必要だねってことになる。
これは正しい事実であるが、現実としてはなぜかテスターは簡単な単純作業ということになり優秀な人はアサインされない。

95 :デフォルトの名無しさん:2013/12/27(金) 23:19:03.56
ホワイトボックスできる力を持ったテスター=テストコード

96 :デフォルトの名無しさん:2013/12/27(金) 23:29:56.71
おまえらVBでDBに接続するようなソフトを想定してない?
俺は1日に1度すらビルドされないような大規模なの想定してたんだけど

97 :デフォルトの名無しさん:2013/12/27(金) 23:32:00.90
俺の想定のシステムでは〜と
都合のいい例しか想定しないw

98 :デフォルトの名無しさん:2013/12/27(金) 23:34:09.33
>>82
そのコードを書いた直後でそういう類のコードでどういうミスをしやすいか熟知している自分と、コーディングの仕様書以外一切しらされずにある日いきなりコードだけつきつけられる赤の他人と、コードのバグを「見つけやすい」のはどっちでしょうかね

99 :デフォルトの名無しさん:2013/12/27(金) 23:36:37.56
>>96
それは大規模だからではない。
ビルドが困難だから一日に一度すらビルドしないんだ。

テスト駆動の話とは無関係に
少ない修正を重ねて開発するという方向に
世の中はシフトしている。

ビルドもテストも自動化され
修正をマージするたびにコードはビルドされる。
それは一日になんども行われる。
ビルドとテストの回数を増やすことが品質の向上につながる。

訂正
× 俺は1日に1度すらビルドされないような大規模なの想定してたんだけど
○ 俺は1日に1度すらビルドされないような古臭い未熟な開発を想定してたんだけど
といってるようにしか見えません。

100 :デフォルトの名無しさん:2013/12/27(金) 23:37:18.19
>>85
「俺が作って俺がテストしたから俺がこの時間内と技術で見つけられるバグはすべて見つけた。嘘だと思ったらそのテストコードがあるからあんたもそのテストを再現できます」と言えばいい

101 :デフォルトの名無しさん:2013/12/27(金) 23:39:38.83
>>98
学生の頃プログラマのバイトをして最初の仕事がそれだったわ。
(当時趣味でプログラム書いていて、プログラミングはできて)

仕様も何もわかっていない。
いきなりテストしてと言われて
「一体何をテストすればいいの?」ってなった。
当然まともな仕様書もなかった。

キーボードバンバン叩いてテストしましたよ。
それだけで落ちたりしたのでテストになりましたけど:P

102 :デフォルトの名無しさん:2013/12/27(金) 23:39:58.53
>>96
例えば、ビルドを年に1回しかしなくて、そのビルドを失敗したら1年間の給料ゼロだと言われても、あなたはコード片ごとにテストしませんか?

103 :デフォルトの名無しさん:2013/12/27(金) 23:41:13.35
>>100
上司「俺がプログラムなんか読めるわけがないだろ!エビデンス(キャプチャ画像)持ってこい!」

104 :デフォルトの名無しさん:2013/12/27(金) 23:47:26.19
>>103
上司の目の前でテストのスクリプト実行すればいい

105 :デフォルトの名無しさん:2013/12/27(金) 23:49:42.84
>>102
そんな条件で仕事を引き受ける奴はいない
バカじゃないの

106 :デフォルトの名無しさん:2013/12/27(金) 23:56:41.32
>>105
実機がまだ完成してないとか、保守でシステム止められる日が年に1日しかないとか、インフラ系は普通にそういう仕事がありますよ

107 :デフォルトの名無しさん:2013/12/27(金) 23:57:00.65
>>96
大規模だったら何がどう変わるんだ?

108 :デフォルトの名無しさん:2013/12/28(土) 00:12:35.81
>>107
大規模だったら、全体を把握しにくくなって、バグが混入したときに見つけるのが不可能になるから、細かくて執拗なテストが必須になると思うのは俺だけか…

109 :デフォルトの名無しさん:2013/12/28(土) 00:25:37.59
ほらな、極端な例を出すと本筋と関係なくなっちゃう

110 :デフォルトの名無しさん:2013/12/28(土) 00:30:11.40
>>109
バグを防ぐのが目的なら、極端な例でも普通の例でもテストがあった方がよいのは変わらないと思うが

111 :デフォルトの名無しさん:2013/12/28(土) 01:03:28.22
もともと Java+アジャイルの流れで出てきたスタイルだから
ビルドできなくて〜というのは本筋ではない

112 :デフォルトの名無しさん:2013/12/28(土) 01:08:27.89
>>111
テスト駆動の実態は60年前からある
言語の構文そのものや標準APIにテストのバッチをしやすい仕組みを入れたのが最近で、それに「テスト駆動」という名前を付けたのが最近というだけの話

113 :デフォルトの名無しさん:2013/12/28(土) 01:09:27.58
>>112
> 言語の構文そのものや標準APIにテストのバッチをしやすい仕組みを入れたのが最近で

それはテスト(ユニットテスト?)であって
テスト駆動ではない

114 :デフォルトの名無しさん:2013/12/28(土) 01:17:20.86
>>113
XPが流行った時に、スケルトン作ってテストしながらコード埋めてくスタイルが悪くないスタイルだと明文化されて、
それと時を同じくして、コードの真横に特別な環境を用意することなくテストコードを付ける仕組みが出てきた

ということなので、最近のテストしやすい言語仕様とテスト駆動とセットだよ

115 :デフォルトの名無しさん:2013/12/28(土) 01:18:15.82
テスト駆動って、ただテストを作ってからコードを書くっていう順番の話なの?

116 :デフォルトの名無しさん:2013/12/28(土) 01:23:55.96
>>115
「テストコードを書いてからコードを書く」で定義してる人もいる
「書いたコードの正しさをすぐにテストによって確認する」という定義でも問題ないかと

117 :デフォルトの名無しさん:2013/12/28(土) 01:29:24.17
> それと時を同じくして、コードの真横に特別な環境を用意することなくテストコードを付ける仕組みが出てきた

それなんのことだよ?

言語名と、その仕組の名前を言ってみ。
そうすりゃ時代がわかるからさ。

118 :デフォルトの名無しさん:2013/12/28(土) 01:40:54.73
>>117
smalltalk以外の普通の言語が、QuickCheckとかxUnitを仕様や標準APIに取り入れたことだよ

javaのassertTrueとかアノテーションまで入れるなら、Cのassertも入れたくなるので、この場合はC言語よりもっと前の60年前までさかのぼることになる

119 :デフォルトの名無しさん:2013/12/28(土) 01:52:42.99
> XPが流行った時に、スケルトン作ってテストしながらコード埋めてくスタイルが悪くないスタイルだと明文化されて、
> それと時を同じくして、コードの真横に特別な環境を用意することなくテストコードを付ける仕組みが出てきた
> smalltalk以外の普通の言語が、QuickCheckとかxUnitを仕様や標準APIに取り入れたことだよ


はっきりさせよう。

jUnitが 1998年のはじめにリリースされて
そのあとの1999年にXPが発表された
テスト駆動の発表はその3年後、jUnitの登場からは5年後の2002年である。

120 :デフォルトの名無しさん:2013/12/28(土) 03:16:55.65
>>119
テスト駆動の発表が2002年というのには異和感がある
1946年説を支持する

ちなみにJUnitはいまだにjavaの仕様や標準APIじゃないでしょう

121 :デフォルトの名無しさん:2013/12/28(土) 03:27:24.37
指示以前に、1946年に合ったという証拠がない。

122 :デフォルトの名無しさん:2013/12/28(土) 03:28:02.71
>>119
全部同じ時期じゃん。

123 :デフォルトの名無しさん:2013/12/28(土) 03:33:23.17
>>121
まずアサート書いてコードを埋めていくという発想が1946年 by チューリング

124 :デフォルトの名無しさん:2013/12/28(土) 03:43:42.82
>>123
それはどの資料の話ですか?
無理矢理なこじつけは要りません。

125 :デフォルトの名無しさん:2013/12/28(土) 03:53:57.18
>>124
まずアサート書いてコードを埋めていくのはテスト駆動開発じゃないという方がこじつけのような気が…

126 :デフォルトの名無しさん:2013/12/28(土) 04:49:45.43
「アサート書いてコードを埋めていく」って話は
一体どこから出てきたんですか?

その考えが普及したのは、テスト駆動ということが生まれたつい最近の話。

127 :デフォルトの名無しさん:2013/12/28(土) 06:47:50.52
>>126
つい最近までは、アサートはいつコードの中に書いていたのだろうか…

128 :デフォルトの名無しさん:2013/12/28(土) 09:22:37.07
>>118
この書き方だとQuickCheckがSmalltalkで生まれたかのように見えるけど
実際はHaskell由来
こういう数理的アプローチはダサイSmalltalkからは出てこない

129 :デフォルトの名無しさん:2013/12/28(土) 09:52:28.06
>>127
アサートは実行コードの中に
エラーだったら止まるものとして
書く物のはずだが?

130 :デフォルトの名無しさん:2013/12/28(土) 10:15:06.91
アザース

131 :デフォルトの名無しさん:2013/12/28(土) 13:59:40.03
>>123
softwareより前の時代の話はいらんよ

132 :デフォルトの名無しさん:2013/12/28(土) 14:35:43.97
>>129
まず大前提として、アサートは納品時には無視されてコンパイルされるので、例外処理のようなエラー検出装置ではない
開発してる最中に、あり得ないエラーのときにそれを検出するモノ
つまりテスト

133 :デフォルトの名無しさん:2013/12/28(土) 16:16:59.44
理屈はわかるが、アサートを外して納品する事なんてないけど・・・

134 :デフォルトの名無しさん:2013/12/28(土) 16:26:52.69
>>133
そういう場合は、他に作ったテストコードも納品するよね

135 :デフォルトの名無しさん:2013/12/28(土) 17:32:29.55
>>98
どんなミスするかわかってるならテストなんて必要なくて最初から完璧なコード書けばいいじゃん

仕様もしらず読み解けないほどの分量のコードをいきなりテスターに任せる事自体間違ってるわ
バグをいれたままテストを通り抜けさせようとしてるようなもんだ

136 :デフォルトの名無しさん:2013/12/28(土) 17:44:53.90
>>135
もしかしたら実務経験がない学生かもしれないから言っておくけど、
実は、自分がどんなミスするか分かっていてもそのミスをしてしまうのがプログラマなんだ…

仮に、ミスするのが1000に1回だとしても、10000作ればミスが10個散らばるわけです

137 :デフォルトの名無しさん:2013/12/28(土) 17:47:40.71
理想
 個々が満足いくまで品質をあげてから次の人へ渡す
現実
 時間がないから書いたらすぐコミットしろ
暇な時
 一応、正常終了と異常終了はテストしといた

138 :デフォルトの名無しさん:2013/12/28(土) 18:01:57.63
>>137
ようするに、「テストを書いてから」ってのは、時間とコストの見積もりするときにテストを書く時間を入れろってことなんだよ

その意味で「まずテストを全部書き終わってからコーディング」を業界標準にするように圧力かけてほしいと思う

139 :デフォルトの名無しさん:2013/12/28(土) 18:22:06.61
自動テストする歳に、テストを書く時間を見積りに入れないバカはいないだろう。

140 :デフォルトの名無しさん:2013/12/28(土) 18:24:55.43
テストを書いてからコーディングするっていうのは、仕様書を書いてからコーディングするって事なんだよ
仕様書を書かない現場にテストを書けといっても不可能

そもそも、設計書・仕様書を書く文化すら根付かなかったのに
テストなんて書くわけがない
ほとんどの現場で行われているテストはエクセルシートに書かれた
「値:1234を入力して実行、結果:5678が出力される=○」みたいなレベルでしょ
後追いですらテストコード書かないのに最初に書くなんてありえない

141 :デフォルトの名無しさん:2013/12/28(土) 18:27:46.93
テスト駆動の本当の良さは工数圧縮なんだよ
自動で弾けるところは弾く
どうしても人の手でテストしなきゃいけない所もあるけど
そういう部分をなるべく減らす為の手法

テストを書く暇があれば人の手でテストしたほうが早いと勘違いしてる奴は
それこそコードが修正されない前提でものを言ってる

142 :デフォルトの名無しさん:2013/12/28(土) 18:42:04.57
>>139
そもそもあるレベルより上のプログラマじゃないと自動テストしないから
職場によっては、テストコード書いてるの見つかったら「余計なことで時間潰すな」だから

143 :デフォルトの名無しさん:2013/12/28(土) 18:52:56.46
>>140
設計書・仕様書を書く文化すら根付かなかった理由は、原理的にコーディングする前に仕様書を定義できないから
まず前提として、仕様書を書いて上流から下流まで一直線に建築みたいにコーディングする手法が提唱されていて、それを学校でも教えてた
しかし、それが破たんして、XPとかプロトタイプ開発とか「仕様書すらも」同時に開発していくスタイルが提唱された
(提唱された の意味は、過去に成功したプロジェクトはそうやってたということね)

コーディングする人は、開発途中は常にテストをしている
なので、「プログラマは常にテスをしているが、それが再利用できる形のテストではない」が現状

144 :デフォルトの名無しさん:2013/12/29(日) 01:40:50.94
>>132
いや、それはそうだけど、
そのテストはxUnitともテスト駆動とも
なんの関係もないよね?
何いってんのお前って感じなんだけど。

145 :デフォルトの名無しさん:2013/12/29(日) 01:42:25.53
>>141
> どうしても人の手でテストしなきゃいけない所もあるけど

それが問題でしょ。

どうしても人の手でテストしなきゃならないところは
テスト駆動開発できない。

テストがなければ開発できない手法で、
人の手でテストしなきゃいけないなら、
開発ができないことになる。

146 :デフォルトの名無しさん:2013/12/29(日) 01:49:36.01
>>130
> その意味で「まずテストを全部書き終わってからコーディング」を業界標準にするように圧力かけてほしいと思う

テストを全部書き終わるということが事実用不可能。

まず、全部のテストというのは、すべての条件の組み合わせになる。
当然組み合わせ爆発になるから、テストにかかる時間は何万年にもなりうる。

そこでこの条件でテストしていれば大丈夫だろ?という数のテストに減らす。
だが大丈夫だろ?という判断が正しい保証はない。

つまり、どんなに頑張ってもテストを全部書き終わったつもりで抜けが
ある状態(=バグ)でコーディングすることにしかならない。

それにな、テストがあってもシステムは動かないが
システムのコードがあれば、システムは動くんだよ。

147 :デフォルトの名無しさん:2013/12/29(日) 11:38:22.54
駆逐してやる!は板違いなのでお帰りください

148 :デフォルトの名無しさん:2013/12/29(日) 14:46:41.76
テスト駆動自体は良いけど、
それをするための道具が使いづらい。

RUnitでよかったのに、RSpecとかでてきて、わけわからん文法をようやく覚えたと思ったら、
RSpec2でまた命令が新旧入れ替わったとか。

149 :デフォルトの名無しさん:2013/12/29(日) 16:56:18.61
>>144
アサートの思想は、テストを先に(少なくとも同時に)作るってことでしょう

150 :デフォルトの名無しさん:2013/12/29(日) 17:01:29.51
>>146
全部のテストをやれとは言っていない
限られた時間で、可能な限りのテストをやれと言っている
コストを見積もるときには、そのテストを見積もりに入れろってこと (つまり、できないテストも明らかにするってこと)

というか、テストなしにシステム組もうとするってどこの会社?
関わりたくないんだけど

151 :デフォルトの名無しさん:2013/12/29(日) 17:04:18.74
>>149
分かりにくいなら、納品コードにassert() 入れたコードを、納品コードとは別に作ったテスト用コードとみなせばどうか

152 :デフォルトの名無しさん:2013/12/29(日) 21:12:49.36
>>149
> アサートの思想は、テストを先に(少なくとも同時に)作るってことでしょう

そんな思想無いよ。
テストをするのに使うのにアサートがあるだけ。

”先に作る” 思想とはアサートの機能のどの部分のことかね?
テスト自体には先に作るという思想はないよ。

153 :デフォルトの名無しさん:2013/12/29(日) 21:38:32.30
>>152
いや、assertは設計の一部だから、書き込むのはコードを書きだす最初のときでしょ

154 :デフォルトの名無しさん:2013/12/29(日) 22:12:41.66
>>153
assertが設計の一部なのはなぜ?
設計の一部だったら書き出す最初なのはなぜ?

今度は二つの質問に答えないといけなくなったね。
今度は説得力がある答えを言えるかな?

155 :デフォルトの名無しさん:2013/12/29(日) 22:21:13.87
xUnitのassertと
昔からあるassertは全くの別物だけどね。

156 :デフォルトの名無しさん:2013/12/29(日) 23:07:37.54
網羅性と局所的ブロック

157 :デフォルトの名無しさん:2013/12/30(月) 00:47:44.79
うん、先に作るという話じゃないね。

158 :デフォルトの名無しさん:2013/12/30(月) 04:25:43.40
>>154
assertが設計の一部なのは、assertが仕様の宣言的表現だから
設計の一部だったら書き出すのが最初なのは、書いてる途中も書き終わった後も実行中も修正作業中も満すべき表明が記述してあるから

159 :デフォルトの名無しさん:2013/12/30(月) 04:28:55.35
>>155-156
ドメインの要素の部分集合を網羅したコードがxUnitで、ドメインの補集合の部分集合を内包表記したコードがassert
同じモノですよ

160 :デフォルトの名無しさん:2013/12/30(月) 04:35:09.73
なんか、最近知った言葉を
使っているだけみたいだなw

用語だけ言ってて具体的な説明が何もない。

161 :デフォルトの名無しさん:2013/12/30(月) 09:08:04.41
ひろい意味では同じってこといってるんだろ
ところが使うには別のツールや知識がいる

テスト駆動ありか、なしか、も、どっちもテストがいることは認めてても、
どうしても最初にテストかかせたいやつと、あとでかきたいやつといるってこと

162 :デフォルトの名無しさん:2013/12/30(月) 11:12:22.50
何が同じなのかさっぱりわからない。

テスト駆動(最初にテストを書く)という理由を何一つ言わないで
アサートはテストと同じと繰り返しているだけにしか見えないな。
テストと同じかどうかではなく、最初に書くかどうかって話をしてるのに。

163 :デフォルトの名無しさん:2013/12/30(月) 11:38:55.64
ツールは道具であって手法とは関係ないな。

そもそも「テスト」と称する内容にコモンセンスが存在しないので、

テスト駆動開発ですっ(キリッ と言ったところで、成果物の品質の保証
にはなりえない。 馬鹿に仕様やコードを書かせてはいけないように、
馬鹿にテストをやらせてはいけない。

164 :デフォルトの名無しさん:2013/12/30(月) 12:15:18.80
馬鹿っていうか、技術力が必要って話ね。
テストは高い技術力が必要なんだよ。
単純作業でやっていたらいくら時間が
あっても終わらないから。

165 :デフォルトの名無しさん:2013/12/30(月) 13:53:07.51
>>162
assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ

例えば、整数kの階乗の計算でkと計算結果が整数以外でないことを内包的表現でチェックするのがassert
環境が提供できる整数1000個でチェックするのがxUnit

xUnitでエラーが出た場合、バグがあるコードを書いていたことになる
一方、assertがコケた場合、何を計算していたのか不明なので、何もコーディングしてなかったことになる

166 :デフォルトの名無しさん:2013/12/30(月) 14:30:22.60
assertってテストコード外に書くやつのことを指してるんじゃないのん

167 :デフォルトの名無しさん:2013/12/30(月) 14:33:44.10
>>165
> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ

どの言語のassertの話をしてるの?
それをはっきりしないと、
具体的なものがないということで、
わーわー喚いているように聞こえないよ?

複数の言語があるのなら、
その言語を言えばいい。

168 :デフォルトの名無しさん:2013/12/30(月) 14:35:15.83
>>165
> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
なんで?

169 :デフォルトの名無しさん:2013/12/30(月) 14:36:22.81
>>167
どの言語もassertは一緒
1946年のチューリングが主張するセマンティクスでOK

自分が使ってる言語にassertがなければ作ればいいだけかと

170 :デフォルトの名無しさん:2013/12/30(月) 14:36:50.03
コードの修正が環境を含む全域に及ぶというだけで
最初に書くという理由にはならないし、
assertを書いて不具合が出なければいいだけだし
やっぱり最初に書くという理由がないんだよな。
後から書いていいじゃん。(なぜかしらんけど)修正範囲が大きくなるだけでしょ?

171 :デフォルトの名無しさん:2013/12/30(月) 14:37:26.38
>>169
どの言語でも一緒といったね?

じゃあC言語でも一緒なわけだ。

じゃあ、C言語で書いてみてよ。

172 :デフォルトの名無しさん:2013/12/30(月) 14:38:05.79
assertを途中で追加して、そこでエラー検出できたとしても
どこを直すべきかの特定につながらないと言いたいんだろう たぶん

173 :デフォルトの名無しさん:2013/12/30(月) 14:38:49.52
でもそれは効率が悪いってことにはなるかもしれないが、
最初に書くという根拠にはならないんだよな。

174 :デフォルトの名無しさん:2013/12/30(月) 14:41:05.78
>>168
例えば、c言語でintのつもりでコード書いてたら、intじゃなかったってことだから

175 :デフォルトの名無しさん:2013/12/30(月) 14:49:09.43
>>171
#define assert(t) ((t) ? (void)0 : printf("%s, %d %d %d\n", __func__, __FILE__, __LINE__, #t))

かな?

176 :デフォルトの名無しさん:2013/12/30(月) 14:53:00.40
>>170
assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど
1+1をaに代入するだけのコードを書く方法は、まず a:=1+1 を書くことだと思うけど

177 :デフォルトの名無しさん:2013/12/30(月) 14:57:23.00
>>174
やっぱり、”最初” である理由はないみたいね。
ただのテストの話してただけじゃん。
最初に指摘したとおりだった。

178 :デフォルトの名無しさん:2013/12/30(月) 14:58:25.05
>>176
> assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど

それなら後からassert書けばいいだけだよ。

179 :デフォルトの名無しさん:2013/12/30(月) 15:16:19.95
assertは表明したくなった瞬間に書けばいいのん

180 :デフォルトの名無しさん:2013/12/30(月) 15:34:39.86
先にassert書くのはコードコントラクトや防衛的プログラミングであってテスト駆動じゃないだろ

181 :デフォルトの名無しさん:2013/12/30(月) 16:05:51.76
テストを書くには優秀な人が必要なんでしょ?
それで、優秀な人がまず最初にテストを書いて、優秀じゃない人に
テストを通るコードを書かせるんでしょ?
じゃあなんで最初から優秀な人にコード書かせないの?
優秀だからテストしなくてもいいっしょ。

182 :デフォルトの名無しさん:2013/12/30(月) 16:08:30.80
Javaと同じで工数もりもり作戦かな?
どっちにしろまともに動かなくて納品後も修正に来るんでしょ?
こっちがあきらめて検収するまで直すふりするんでしょ?
なんだか意味ないような気がするよ。

183 :デフォルトの名無しさん:2013/12/30(月) 16:19:35.91
>>181
自分で書けば?

184 :デフォルトの名無しさん:2013/12/30(月) 16:20:50.87
デバッグはプログラムを書く人より三倍ぐらい賢くなければならず、
つまるところプログラマは自分のプログラムをデバッグするほど賢くない。
となれば、プログラマ1人に対してテスターが3人ぐらい必要になるから

185 :デフォルトの名無しさん:2013/12/30(月) 16:24:25.30
受け入れテストとかそういう上位層のものではないと何度言えば

186 :デフォルトの名無しさん:2013/12/30(月) 16:24:31.56
>>180
assertが入ったコードと、assertが抜けたコードがある場合、前者はテストコードですよ

187 :デフォルトの名無しさん:2013/12/30(月) 16:27:02.87
>>183
まさにそれ。
自分たちで書いたのを今運用してんの。
ちなみに単体テストすらしてません。

188 :デフォルトの名無しさん:2013/12/30(月) 16:27:49.27
>>177
正しくは、assertに書くべきモノが最初に「ある」ってことかな
例えば、実機そのものや実機の設計書もコードを書く前に「ある」はずけど、コードを書いた後に作っても問題ないし

189 :デフォルトの名無しさん:2013/12/30(月) 16:29:07.89
>>180
テスト駆動は防衛的プログラミングですよ

190 :デフォルトの名無しさん:2013/12/30(月) 16:32:13.64
プログラマなんて椅子をガンって蹴っ飛ばしてやるのが正しい扱い方なんだって。
目にいっぱい涙をためても手を緩めたらダメ。
あれはそうしろって上から言われてるんだよ。
泣きまねも絶対教育されてる。

191 :デフォルトの名無しさん:2013/12/30(月) 16:34:18.57
>>181
それには、その一切のミスをしない優秀な人が、実機やOSやコンパイルや補助ライブラリも全部作るという前提が必要

ちなみに、実際の現場での優秀な人のイメージは、ミスをしない人ではなく、ミスが少ない人

192 :デフォルトの名無しさん:2013/12/30(月) 16:37:07.20
>>182
相手側に予算と時間があれば、修正せずに別会社で最初からで、おつきあい終わり

193 :デフォルトの名無しさん:2013/12/30(月) 18:33:40.58
テスト駆動なんて、今どきあたりまえだと思っていたけど、
そうでもなんだね

基本設計(UseCaseシナリオ相当)で、運用テストシナリオを作る。
概要設計(Activiti図相当)で、結合テストシナリオを作る。
詳細設計(Sequence図相当)で、単体テストのバリエーションを作る。
それからプログラミングをする。

とやっておけば、まず、テスト作成を通じて、仕様が妥当かのチェック
ができる。(プロジェクト (Iteration/Sprint/...) の前半で!!)

また、プログラミングの目標が具体化される。(仕様を満たす
"完璧" なものを作る必要はなく、妥当な網羅性のあるテストに
合格すればOK)

テスト設計も順を追って詳細化されるので、設計上は、
単体テストに合格していれば、結合テストに合格し、
結合テストが合格なら、運用テストにも合格するはず。

裏を返せば、結合・運用テストでは、本来出てくるべき
不具合 (ちゃんと動くもの同士をつなげても、ちゃんと動かない)
の対処に注力できる。

しかも理論上は、かかる工数は同じ。(どうせテスト仕様は
どこかで作るんでしょ)

テスト駆動にしない理由のほうが見当たらないくらい。

194 :デフォルトの名無しさん:2013/12/30(月) 18:36:51.50
>>4 みたいに勘違い君がTest Drivenを語るのが日本で廃れるひとつ
あとは日本の零細経営者はテスト工数を客に見積もれんとか言い出すしな。

ビル建築でも安全率の負担増加分やエレベータや施設のテストもろもろは
ちゃんと請求してんのにな。

195 :デフォルトの名無しさん:2013/12/30(月) 18:37:15.60
カッコの中は合いの手かな?

196 :デフォルトの名無しさん:2013/12/30(月) 18:38:16.91
>>184
日曜さん?
テストケースは(日本で言う)プログラマが考えるんじゃないんだが。

197 :デフォルトの名無しさん:2013/12/30(月) 18:39:22.51
そういうことはまともに動くものを作ってから言ってください
それまではサンドバッグです

198 :デフォルトの名無しさん:2013/12/30(月) 18:44:08.15
プログラマの派遣先は道場にしたほうが世の中のためになる

199 :デフォルトの名無しさん:2013/12/30(月) 18:54:54.45
板に釘を打ちつけるとき、まず、板にすでに釘が刺さってないことを確認して、板と釘が間違っていないことを確認しながら、釘がまっすぐであることを確認しつつ、釘に金槌を何度かたたきつけ、終わったあとに釘が刺さってることを確認する

プログラマは、釘に金槌を叩きつけるだけ

200 :デフォルトの名無しさん:2013/12/30(月) 18:58:40.61
>>193
ただ単純に、1万行を超えるコードや人月が3ヶ月人を超えるコードを書いたことがないだけだと思う
趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ

201 :デフォルトの名無しさん:2013/12/30(月) 19:13:29.28
Linuxを見れば、テストが無駄ということがわかる。

202 :デフォルトの名無しさん:2013/12/30(月) 19:31:06.80
>>201
インターフェイス共通でレベルの低いディストリをわざとばらまかないと金儲けできないからな…

203 :デフォルトの名無しさん:2013/12/30(月) 19:41:58.21
「玉石混交は活力」みたいな考えなんじゃないの

204 :デフォルトの名無しさん:2013/12/30(月) 19:51:55.71
完璧な人間が完璧なコードを書けばテストなど必要ない。

205 :デフォルトの名無しさん:2013/12/30(月) 19:56:23.72
>>204
残念だが、コードが完璧でも、実機やOSやコンパイラや言語仕様やユーザの要求は完璧じゃないんだ…

206 :デフォルトの名無しさん:2013/12/30(月) 20:14:12.62
人のせいにするのはプログラマとして正しい対応です。

207 :デフォルトの名無しさん:2013/12/30(月) 20:18:50.02
>>193
いまどきはどこも、そんなきれいなV字ウォーターフローやってる暇はないでしょ。

208 :デフォルトの名無しさん:2013/12/30(月) 20:19:54.07
>>206
正確には「人という生物の特性のせい」

209 :デフォルトの名無しさん:2013/12/30(月) 20:20:24.69
あ、ウォーターフォールだった。

210 :デフォルトの名無しさん:2013/12/30(月) 20:24:27.17
>>200
> 趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ

お前がどうするかなんかしらんがなw

日曜プログラマの大半はテストコード書かないだろうってのは
大体想像できる。

211 :デフォルトの名無しさん:2013/12/30(月) 20:27:09.10
プログラマは蹴られてナンボ。
土下座の練習が欠かせない。

212 :デフォルトの名無しさん:2013/12/30(月) 20:28:19.30
そりゃ趣味プログラミングでテスト書く人はいないでしょ。

213 :デフォルトの名無しさん:2013/12/30(月) 20:29:49.66
自分のミスをOSのせいにしてるの見つけたら無言でみぞおちに入れるけどね

214 :デフォルトの名無しさん:2013/12/30(月) 20:30:20.15
テスト駆動開発のテストはテストじゃない

215 :デフォルトの名無しさん:2013/12/30(月) 20:30:30.39
趣味プログラミングでもデグレ予防のためにテストは書く。
テストファーストはしないけど。

216 :デフォルトの名無しさん:2013/12/30(月) 20:31:24.44
>>210-212
プログラミングのタイピングを途中で打ち切ることになって、これまでにどこまで進んだかを覚える必要が出てくるんだけど、次の週までどうやって覚えておくの?

217 :デフォルトの名無しさん:2013/12/30(月) 20:33:20.52
体罰はよくないという人もいるけど、猿は言ってもわからないから
体に教え込まないと無理
10年かかってやっとわかった
プログラマは言って聞かせても無駄
体で覚えさせれば素直に言うこと聞くようになる

218 :デフォルトの名無しさん:2013/12/30(月) 20:33:32.24
どんどん先祖返りしていく

219 :デフォルトの名無しさん:2013/12/30(月) 20:33:36.07
>>216
コード見て思い出せばいいだろ?

なんなら何をやっていたかを
日本語で書いてもいいし。

220 :デフォルトの名無しさん:2013/12/30(月) 20:34:15.51
>>216
チケット。

221 :デフォルトの名無しさん:2013/12/30(月) 20:35:23.51
テストコードを見れば、
先週何をやっていたか
泉のように思い出すのです。
それが愛です。わかりましたか?

222 :デフォルトの名無しさん:2013/12/30(月) 20:35:55.41
などと意味不明なことを語っており

223 :デフォルトの名無しさん:2013/12/30(月) 20:35:55.94
>>219
テストの方が簡単じゃね?

224 :デフォルトの名無しさん:2013/12/30(月) 20:36:38.48
>>223
なんで質問するんだよw

テストの方が先週何をやっていたか
思い出すのに簡単である理由を説明しろよ。

225 :デフォルトの名無しさん:2013/12/30(月) 20:37:28.20
>>221
テストを先に書く習慣の人が自分のテストコードを見れば、何をやろうとしてコード書いてて、何ができてないなかったかが分かる

226 :デフォルトの名無しさん:2013/12/30(月) 20:38:24.95
>>216
それくらい覚えてる。一年後でも。

>>223
テストが簡単なコードだけとは限らないしねー

227 :デフォルトの名無しさん:2013/12/30(月) 20:38:44.19
>>255
テストが全部通った場合はどうなるのさ?

お前が言ってるのは、コンパイルが通らなかったら、
今ここをつくろうとしていたとわかるって
言ってるのと同じだよ。

228 :デフォルトの名無しさん:2013/12/30(月) 20:39:31.76
自分の習慣で決まるんだ
すごいね

229 :デフォルトの名無しさん:2013/12/30(月) 20:40:47.18
これは体罰も必要だわ

230 :デフォルトの名無しさん:2013/12/30(月) 20:41:03.90
テスト関係ねーなw

動的言語でもわざとエラーが起こるようにしておけばいいだけの話だし、
コメントではなくコードの中に日本語を書いておけば、
当然エラーも起きるだろうし、わかりやすい。

231 :デフォルトの名無しさん:2013/12/30(月) 20:43:09.27
「私はテスト駆動開発をする習慣ですのでそうさせてもらいます」

232 :デフォルトの名無しさん:2013/12/30(月) 20:43:17.17
>>224
1. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識

233 :デフォルトの名無しさん:2013/12/30(月) 20:46:26.66
>>232
あほかw

お前の言ってるのは、テストが完璧に書いてあることが前提になってるだろ。

テストに漏れがない。テストに間違いがない。

> 1. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
そのテストに漏れがあったら?
テストを書いている途中だったら?

> 2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
テストが書いていなかったら? テストがなかったら仕様がわからないよ。

> 3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識
テストが間違っていることもある。

234 :デフォルトの名無しさん:2013/12/30(月) 20:46:39.27
>>227
コーディングの前にテストを書く習慣の人が書いたテストが全部通ったら、コーディングの前にやろうとしてたことは終わった

コンパイルが通らなかったら、 今ここをつくろうとしていたとわかる
コンパイルが通ってテストが通らなかったら、今ここをつくろうとしていてスケルトン作って試行錯誤していたことがわかる

235 :デフォルトの名無しさん:2013/12/30(月) 20:48:38.78
このテストコードは
2を入れたら4が返るべきとなっている。

さて3を入れたらなんになるのだろうか?

テストが足りないから何がしたいのかわからん!

236 :デフォルトの名無しさん:2013/12/30(月) 20:49:05.15
>>230
コンパイルが通るコードを書いて実行結果を見て試行錯誤しながらコーディングしてた場合は?

237 :デフォルトの名無しさん:2013/12/30(月) 20:50:14.19
> コーディングの前にテストを書く習慣の人が書いたテストが全部通ったら、コーディングの前にやろうとしてたことは終わった

とは限らない。

なぜならバグを修正しようと思った時、
バグが見つかる前は、”テストが全て通った状態”なのだ。

テストが全て通っていても、
やるべきことが残っていることはよくある話。

238 :デフォルトの名無しさん:2013/12/30(月) 20:52:19.11
道具の使い方がわからなくて発狂するサルを眺めるスレはここですか

239 :デフォルトの名無しさん:2013/12/30(月) 20:52:29.71
テスト駆動では

1.失敗するテストコードを書く
2.テストコードを通る”最低限の”実装を書く

とある

http://www.slideshare.net/KyonMm/jasst

> 30. Definition TDD
> 1. 失敗するテストコードを実装する
> 2. テストが通る最低限の実装をする
> 3. 1と2を繰り返す中で、テストの変更につよ くするための実装をする
> 1 - 3を30secから1minで繰り返す。

つまり、テストコードが通ったとしても、
それは最低限の実装であり、
すべてが終わったとは限らない。

240 :デフォルトの名無しさん:2013/12/30(月) 20:53:05.60
>>216
テスト書かなければ、コーディング終わってたのでは?

あと、テストコード書きは絶対に中断されない前提なのね。

241 :デフォルトの名無しさん:2013/12/30(月) 20:53:20.85
テストは全く効果が無い
じゃなきゃちゃんと動くはず

242 :デフォルトの名無しさん:2013/12/30(月) 20:54:30.20
もしかしてテストコード万能説を否定している俺のほうが
TDDに詳しいのかな?w

243 :デフォルトの名無しさん:2013/12/30(月) 20:55:52.10
ソフトウェアにはトレーサビリティってないんですか?
やっちまった奴はボーナスなし!
このくらいやってもらわないと。

244 :デフォルトの名無しさん:2013/12/30(月) 20:56:11.97
>>233
テストは間違っててもいい
テストかコードのどっちかが間違ってるということが分かるから

大前提として、基本的にテストには漏れがある (= つまり仕様に漏れがある)

245 :デフォルトの名無しさん:2013/12/30(月) 20:56:55.17
解説! トレーサビリティとはコードの変更を検知する
つまり、ソースコード管理ツールのことである!

246 :デフォルトの名無しさん:2013/12/30(月) 20:57:14.62
両方間違ってたらどうするんだ

247 :デフォルトの名無しさん:2013/12/30(月) 20:57:22.20
>>237
それは、次の人に渡すまでに、プログラマ本人が「自分の責任で」テストをするのが前提ですよね?

248 :デフォルトの名無しさん:2013/12/30(月) 20:58:51.76
>>244
> テストは間違っててもいい

話、ちゃんと理解している?

テストコードが間違ってる状態で、
どっちが正しいかをどう判断するのさ?

先週、何やっているかわからなくなっても
テストコードが失敗したら、そこから作業開始するんだろ?

テストコードしか、何をやっているか手がかりがない。
そのテストコードが間違っているのに、
どちらが正しいかどうやって思い出すのさ?

249 :デフォルトの名無しさん:2013/12/30(月) 21:00:09.98
先週何をやっていたかを思い出すのに
テストコードがあれば思い出せるって言ったのだれさ?

自分の言葉に責任持てよ。

250 :デフォルトの名無しさん:2013/12/30(月) 21:01:28.85
プログラマが責任を持つ必要はないでしょ。

251 :デフォルトの名無しさん:2013/12/30(月) 21:02:20.54
>>242 >>246
テストは万能ではない
テストコード先に書いた方が、より「バグが少ないコードを書ける」ってだけ

テストコードもソースコードも間違うことがある
テストが間違っててコードが正しい場合と、コードが間違っててテストが正しい場合と、テストとコードが同時に間違ってて答えが異なる間違い方をしてる場合を検出できるってだけ

テストは「時間が許す限り可能な限りバグを減らす努力」のひとつに過ぎない

252 :デフォルトの名無しさん:2013/12/30(月) 21:02:52.75
プログラマは土下座と泣きまねで充分です。
責任は責任ある立場の人がとります。

253 :デフォルトの名無しさん:2013/12/30(月) 21:03:07.36
まあテストコードがあっても先週何をやっていたか
何をしようとしていたかなんて分かるわけがないよね。

gitとか使っていれば、コミットした分は終わっているとわかるだろうし
作業履歴もコミット履歴としてわかるだろうけど。

こんなのあたりまえだと思う。
テストコードに何を求めているのかと。

254 :デフォルトの名無しさん:2013/12/30(月) 21:04:33.27
>>251
あー、ちみちみ、

今はテストコードがあれば先週何をやっていたか
思い出せると主張している
おバカさんをこてんぱんにしている最中だから。

テストコードの批判なんて
誰もしとらんのだよ?

255 :デフォルトの名無しさん:2013/12/30(月) 21:04:58.41
プログラマのキャリアパスってどうなってるんですか?
プログラマ卒業したら何になるんですか?

256 :デフォルトの名無しさん:2013/12/30(月) 21:06:18.48
>>255
> プログラマ卒業したら何になるんですか?
経営者になります。

どの道も全部同じです。

スポーツ選手も
アーティストも
海賊王も

全部最後には経営者になるのです。

257 :デフォルトの名無しさん:2013/12/30(月) 21:07:32.34
>>248-249
先週、何やっているかわからなくなっても
テストコードが失敗したら、「そこから」作業開始する

他はテストが通ってるから無視してOK

そのときの作業の内容は、
・テストに記述された仕様の宣言的表現を確認する
・テストの間違い方を見る
・「その後で」コードを見る

だから、実は作業内容を思い出す必要もない

258 :デフォルトの名無しさん:2013/12/30(月) 21:09:20.89
>>253
テストコードに求めるモノは、仕様の宣言的表現

259 :デフォルトの名無しさん:2013/12/30(月) 21:09:26.01
取締、執行、監査ですか?
なれねーよ、ばーか!
社会人の方よろしくおねがいします。

260 :デフォルトの名無しさん:2013/12/30(月) 21:09:42.75
俺は最高のギタリストになるんだ

俺には無理だ。だから最高のギタリストを育てることにした


これって勝ち組なのか負け組なのか悩むよね。

261 :デフォルトの名無しさん:2013/12/30(月) 21:13:36.93
>>257
> 先週、何やっているかわからなくなっても
> テストコードが失敗したら、「そこから」作業開始する

じゃあテストが成功したらどうするんだよ。

全てが完成したのか
ある所まで完成したのか
テストを今から書こうとしたのか
テストに通る最低限の実装したのか
どうやって区別するんだよ。

あるところまで完成したとして、
じゃあ次は、どこから作業開始するんだよ。

だいたいテストコードが失敗してる状態で
やめたりしねーよ。

すこしはさ、冷静に考えてみたら?

262 :デフォルトの名無しさん:2013/12/30(月) 21:16:11.95
単純に考えて、次どこからやろうとしたかは
次どこからやるって、一言書いておけば済む話だよね。
git使っていれば、今まで何やったかすぐわかるし。


○○というものを知った人は、
なんでも○○でやろうとする。

テストコードというものを知った人は、
なんでもテストコードでやろうとする。

まあ、これは初心者にありがちな行動。

263 :デフォルトの名無しさん:2013/12/30(月) 21:16:23.27
>>254
まず前提として、紙に書いた文書やエディタで打っている最中のコードは「プログラマが作りたかった機能」じゃないよね?
「プログラマが作りたかった機能」を「プログラマが通したかったテスト」として書く

つまり、やろうとしたかったことを思い出すためには、テスト見れば終わりじゃん

264 :デフォルトの名無しさん:2013/12/30(月) 21:17:42.39
>>263
世の中には、テストコードがあるプロジェクトはたくさんあるけど、
そのテストコード見ても、これからやろうとしていることなんかわからんよ。

265 :デフォルトの名無しさん:2013/12/30(月) 21:18:53.00
>>261
まず、次の人に渡す前までに自分でテストする派なのか、テストせずに次の人に渡す派なのかはっきりしてくさい

266 :デフォルトの名無しさん:2013/12/30(月) 21:20:01.12
>>269
それは、テストコードが失敗している時に中断した場合に限った話だろ。
テストコードが成功した状態でやめたら、
次何をしようとしていたかなんてわからんだろ

267 :デフォルトの名無しさん:2013/12/30(月) 21:20:53.43
>>262
その「一言」が日本語の場合は、前後の文脈を忘れると嘘になる

268 :266:2013/12/30(月) 21:21:14.84
あ、レスが早すぎた。

269 :デフォルトの名無しさん:2013/12/30(月) 21:21:32.49
バグを書く気満々だからテストが必要になるんじゃないの?
一文字一文字気持ちを込めて書けばバグなんか出ないはずです。

270 :デフォルトの名無しさん:2013/12/30(月) 21:21:36.91
わかりやすいわかりやすくないは主観的だから論じるだけ無駄ではー

271 :デフォルトの名無しさん:2013/12/30(月) 21:22:50.40
>>266
テストが全部通ったら終わりじゃん

そのプロジェクトは忘れて、安心して放置するなり、次の人に回すなりすればいいよ

272 :デフォルトの名無しさん:2013/12/30(月) 21:23:20.70
>>267
それで?

もしかして「一言」って
本当に、一言(一ワード、一単語)だと
思った?

273 :デフォルトの名無しさん:2013/12/30(月) 21:24:01.03
>>271ってもしかして、
プロジェクト全ての
テストコードを先に書いてしまうのが
テスト駆動と思ってるんじゃないか?

274 :デフォルトの名無しさん:2013/12/30(月) 21:24:48.24
>>273
あー、なるほどw

だったら今までの意味不明な発言も
なんとなくわかるような気がするなw

275 :デフォルトの名無しさん:2013/12/30(月) 21:26:09.61
>>273
え?違うの?

276 :デフォルトの名無しさん:2013/12/30(月) 21:26:32.25
自演臭がした。

277 :デフォルトの名無しさん:2013/12/30(月) 21:27:17.01
件の人は土日があればすべてのテストコードを書き出せるいうことなんで、天才なんでしょう。
もしくは、ごく小さいプログラムしか作っていないか。

278 :デフォルトの名無しさん:2013/12/30(月) 21:27:18.09
完璧なコードを書けばいいだけ。

279 :デフォルトの名無しさん:2013/12/30(月) 21:30:02.80
TDDってテストが全部通っても
それはテストコードを通る最低限の実装なわけで
そこから最低限ではない、ちゃんとした実装をしたり
リファクタリングをするから
それで終わりじゃ無いんだけど?

やっぱり俺のほうがTDDに詳しいw

280 :デフォルトの名無しさん:2013/12/30(月) 21:31:26.20
>>273-274
まず、「これが通ればプロジェクトは全部終わり」というテストを一つ書いておく
その次に、それよりも多少粒度が細かくてキーとなり機能のテストをいくつか書いておく
それとは別に「今から書こうとするコードのテスト」を書いて、個々の機能のコーディングを進める

最初に全部のテストを書く必要はないよ

281 :デフォルトの名無しさん:2013/12/30(月) 21:31:39.14
コンパイルに通ればプログラム完成。
テストコードに通ればプログラム完成。

そのコードが汚くても関係ない。

282 :デフォルトの名無しさん:2013/12/30(月) 21:31:40.04
>>273
テストコードがなければ、次の週の作業が思い出せないと言っている以上、
土日の間にすべてのテストコードを揃えてしまわないといけないだろう。

283 :266:2013/12/30(月) 21:32:50.41
まず、「これが通ればプロジェクトは全部終わり」というテストを一つ書いておく

このたった一つのテストの内容は、

たとえば、ウェブサーバーだと、


・・・・長い長い物語の始まりですw

284 :デフォルトの名無しさん:2013/12/30(月) 21:33:29.84
>>280
ずいぶんと平坦なプロジェクトだねぇ。
プロジェクトの途中で仕様が変わることなんて考慮しないんだ。

285 :デフォルトの名無しさん:2013/12/30(月) 21:33:59.02
プロジェクトが全部終わりであることを
証明するテストか。

どんなのに鳴るんだろうなw

286 :デフォルトの名無しさん:2013/12/30(月) 21:39:09.22
>>279
TDDはまず仕様のうちコーディングして実現できる宣言的命題をテストコードで表現する
コードを進めるとコードが失敗することによって、テストのバグも発覚して、仕様のミスや未定義な部分が明らかになる

テストコードを通るコードは、最低限の実装ではなく、コーディングする前に考えた宣言的命題を満たす実装

ちなみに、リファクタリングするなら、少なくともそのリファクタリングの前には、そのコードが通るテストがそろってる必要がある

287 :デフォルトの名無しさん:2013/12/30(月) 21:41:11.51
プロジェクトに終わりはないのに、
終わりだと証明するテストか
哲学(笑)だなw

288 :デフォルトの名無しさん:2013/12/30(月) 21:41:28.12
>>282
すべて書かなくても、土日で書ける量の粒度ごとについて一つずつテストを書いておけばいい

289 :デフォルトの名無しさん:2013/12/30(月) 21:44:27.17
>>286
> テストコードを通るコードは、最低限の実装ではなく、コーディングする前に考えた宣言的命題を満たす実装
違うぞ。


http://moguranosenshi.hatenablog.com/entry/2013/12/20/TDD%E3%81%AB%E3%81%84%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%9F

> テストの失敗を確認したら、実装に移ります。
> テストを通すための最低限の実装であるのがポイントです。
> 3が入力されたときのテストのみなので、Fizzを返すだけでOK.
こういうのがTDDのやり方

こんなことも時点で、こいつはTDDを知らんなってわかるよ。

290 :デフォルトの名無しさん:2013/12/30(月) 21:44:32.10
>>283
Webサーバは単純なバッチテストは無理
事前に、シナリオを用意して、そのシナリオ通りにアクセスするテスト用のクライアントプログラムを用意するのが吉

291 :デフォルトの名無しさん:2013/12/30(月) 21:45:31.28
>>288
テスト書かなくても作業を覚えておけるのならね。

292 :デフォルトの名無しさん:2013/12/30(月) 21:45:55.89
>>1
1万行? 10万行じゃなくて? コード量が多ければいいという話でも
ないと思うが、たった1万行くらいを大規模と勘違いしちゃってる時点で
既にアレな気が。

293 :デフォルトの名無しさん:2013/12/30(月) 21:46:50.25
>>285
「あなたが」「これが通ったら終わりでいいや」と思えるテストを書けばいいよ

294 :デフォルトの名無しさん:2013/12/30(月) 21:48:40.64
>>289
そのWebの方が間違ってる
理由は、そのWebを書いた人は、事前に考えた仕様に未定義部分がないことを前提にしているが、そんなプロジェクトはないから

295 :デフォルトの名無しさん:2013/12/30(月) 21:51:58.99
完璧な仕様を考えればいい。

296 :デフォルトの名無しさん:2013/12/30(月) 21:57:06.39
>>295
そろそろ、この世に完璧などないと認めたらいかがですか?
イチローに向かって、毎回ホームラン打てば走る練習しなくていいじゃん って言ってるようなもんですよ

297 :デフォルトの名無しさん:2013/12/30(月) 22:04:22.91
>>294
じゃあ正しいの持ってこいよw

https://www.google.co.jp/search?q=TDD+最低限の実装

このリンクの中からな。

298 :デフォルトの名無しさん:2013/12/30(月) 22:06:11.51
こっちでもいいぞ

https://www.google.co.jp/search?q=テスト駆動 最低限の実装

をテストファーストと言う)、そのテストが動作する必要最低限な実装をとりあえず行った ...

れを成功させる最低限のコードを書く、というステップを繰り返す ... というのも、テ

功する最低限の実装コードを書く4. 実行して成功することを確認する5. テストが通る状

とを確認する( レッド ) ステップ2:ステップ1のテストを通す最低限のコードを実装

299 :デフォルトの名無しさん:2013/12/30(月) 22:45:06.38
>>297
1. 最終的に正しいコード(バグがないコード)を作成することを目的に
2. プログラマがコーディングする前に考えた宣言的命題を「暫定的に」正しい仕様として採用し
3. それをテストコードとしてまず作成し
4. コーディングの目的をそのテストをパスすることに還元し
5. そのテストを通るように本体のコードを作成し
6. テストの結果によってコードのみならずテストの修正も行い
7. テストの修正がある場合は仕様の修正として上流にフィードバックし
8. テストが通るまでコーディングするスタイル

リファクタリングの場合は、
1. 最終的に正しいコード(バグがないコード)である状態を変更しないことを目的に
2. すでに作成されたテストコードを再利用し
3. コーディングの目的をそのテストをパスしつつ、リファクタリングの目的を達成することに還元し
4. そのテストを通るように本体のコードを作成し
5. テストが通り、リファクタリングの目的を達成するようにまでコーディングするスタイル

上記のことが記述してある(2〜3日以内にググれば出てくる)参考URL
http://toro.2ch.net/test/read.cgi/tech/1387695847/l50

300 :デフォルトの名無しさん:2013/12/30(月) 23:05:49.79
ソースは2ちゃんねるw

301 :デフォルトの名無しさん:2013/12/30(月) 23:11:05.18
ロンダリング

302 :デフォルトの名無しさん:2013/12/30(月) 23:16:53.97
>>165
> 例えば、整数kの階乗の計算でkと計算結果が整数以外でないことを内包的表現でチェックするのがassert
> 環境が提供できる整数1000個でチェックするのがxUnit

オマエとオマエの会社を除いて、どこの世界に整数演算で済むのに、わざわざ
浮動小数点にして計算するバカがいるんだよ。

「整数」とは16bitなのか、32bitなのか、64bitなのか、ちゃんと仕様に
明記されているんだよな?

階乗を計算する関数は、結果を値で返すのか、それとも結果を返す変数の
ポインタか参照渡しなのか? 前者の結果を値で返す場合、桁あふれしたら
戻り値は0なのか、それとも例外を投げるのか? 例外に関する規定は仕様に
明記されているんだよな?

NULLポインタが渡された場合の関数の挙動は? それと、引数や戻り値の型が
よもや符号付きだったりしないよな?

303 :デフォルトの名無しさん:2013/12/30(月) 23:19:11.39
もうあんまりイジメないでやってください。

304 :デフォルトの名無しさん:2013/12/30(月) 23:23:04.64
>>302
仕様書の関数のドメインが 「整数の集合」 のつもりでも、実際のドメインが 「整数の集合 ∪ {null}」 のことは普通のあるけど
特にC言語

305 :デフォルトの名無しさん:2013/12/30(月) 23:27:44.03
あるからなんなんだよw

306 :デフォルトの名無しさん:2013/12/30(月) 23:28:59.81
なんでテスト駆動は教科書通りに進まないのかな?

307 :デフォルトの名無しさん:2013/12/30(月) 23:29:15.65
>>305
あるから、テストする

308 :デフォルトの名無しさん:2013/12/30(月) 23:29:47.31
>>306
事前に考えた仕様に未定義部分がないことを前提にしているから

309 :デフォルトの名無しさん:2013/12/30(月) 23:32:23.25
テスト駆動はテストが仕様を表しているとしてコーディングするんだとしたらさ
テストが通らない部分はどうするの
int x = getStatus();
if (x < 0) { ... } else if (x >= 0) { ... } else { throw unstableMemoryException("unstable memory error"); }
例がよくないけど、途中returnみたいなものでもいいけど、通常では Exceptionは、起きるはずがないしテストのしようもない
最低限とか、テストを宣言的命題にして、それをパスするコードを書くとかの意味では、最後んとこは書くべきでない
でも出荷する製品レベルなら、これは、いれとくべき仕様だと思うけど、テスト駆動からは逸脱してる

310 :デフォルトの名無しさん:2013/12/30(月) 23:32:36.16
>>306
いくつかの種類のテストは
テスト困難か、テスト不可能だから

311 :デフォルトの名無しさん:2013/12/30(月) 23:35:12.87
>>306
コードがない状態では
そのコードに対するやらなくてはいけない
完全なテスト内容が予測不可能だから。

312 :デフォルトの名無しさん:2013/12/30(月) 23:36:23.62
>>306
実際にコードを書いて検証しなければ
見えてこないものがあるから

313 :デフォルトの名無しさん:2013/12/30(月) 23:42:28.16
>>306
テスト駆動をするには、
テスト駆動可能なコードを書く技術力が必要だから。

テスト駆動がない所は、テスト駆動可能なコードを書いていない。
その状態でテスト駆動のみを取り入れようとしても
できるわけがない。

314 :デフォルトの名無しさん:2013/12/30(月) 23:43:06.08
>>309
まず、一般的にjavaのExceptionはバグではない
だから、仕様にあるものとして考えるべきだし、テストのときにあえてExceptionを与えることもできるし、テストケースで受けることもできる

テストは、「限られた時間内で可能な限りバグを減らす努力」のひとつだから、時間がないなら例外についてのテストはやらなくていいけど、納期とコストの見積もりのときにはやらないということを共通の認識にすべき

315 :デフォルトの名無しさん:2013/12/30(月) 23:45:38.53
>>313
プログラミングは基本的にすべてテスト駆動
テストすべきモノはすでに頭の中かコンピュータに存在する

それを再利用できる形でコード化するかどうかの違いしかない

316 :デフォルトの名無しさん:2013/12/30(月) 23:45:55.89
>>306
納期とコストの都合上
やらない方がいいテストが存在するから

317 :デフォルトの名無しさん:2013/12/30(月) 23:47:43.37
>>315
だからなんなんだよ?
俺のレスに関係ない話すんなって。

318 :デフォルトの名無しさん:2013/12/30(月) 23:49:05.46
>>314
いやExceptionに限定しないでさ
テストが通らないコード部分ってあってそういう部分のコードを書くのは重要なコードだとしてもテスト駆動から逸脱してるよねって話
時間ないからテストやらなくていいとかそういう話はもうテスト駆動じゃないと思うんだけど

319 :デフォルトの名無しさん:2013/12/30(月) 23:49:40.25
>>317
「テスト駆動を取り入れてない」という認識が間違っている

320 :デフォルトの名無しさん:2013/12/30(月) 23:50:37.19
Exceptionに限らず、多くのバグは境界値や特定値(NULL,0)など、往々にして
仕様には具体的に明記されていない条件下で発生するのだな。

例外を投げること自体はエラーでなくとも、エラー時に正しく例外が投げ
られるかどうか検証しないテストなんぞは、実質的には無意味に近い。

321 :デフォルトの名無しさん:2013/12/30(月) 23:53:09.91
>>318
ただ単に、テスト駆動だけど、自動で再利用できるテストではないだけだと思うが

テストが通らないがテストのしようがないという意味なら、なにをもって正しいと言って納品してるの?

322 :デフォルトの名無しさん:2013/12/30(月) 23:54:48.95
たとえばこんな関数

function pow(x, y) {}

テスト駆動でやるとしたら、実装よりも前にテストコードを
書かないといけないわけだけど、
正常系はかけるだろう。

だけど異常系、たとえばxやyに数字以外を入れた場合のエラーは
実装よりも先に書くのか?という問題がある。

実装を書いてしまえば、当然エラーで落ちるだろう。
その後にテストコードを書いたらテスト駆動にはならないから
先に書くしか無いはずなんだが。

323 :デフォルトの名無しさん:2013/12/30(月) 23:56:53.66
>>321
> テストが通らないがテストのしようがないという意味なら、なにをもって正しいと言って納品してるの?

テストコードが正しいという根拠は?

何を持って正しいのか?なんて話をすると
結局こういうことになるんだけど。

324 :デフォルトの名無しさん:2013/12/30(月) 23:58:32.43
テストコードがあったとしても
実行したテストはわかるが、

実行してないテストがあるかどうか
まではわからないんだよね。

わかり易い例を上げると
失敗したテストを削除してしまえば、
テストは全て通ったことにできる。

325 :デフォルトの名無しさん:2013/12/30(月) 23:59:16.32
>>322
テストは命題が偽であることもチェックできますよ

326 :デフォルトの名無しさん:2013/12/30(月) 23:59:53.51
>>325
だからなんなんだよ?

327 :デフォルトの名無しさん:2013/12/31(火) 00:00:39.47
テスト駆動開発と言ってる連中は、階乗みたいなコンパイラのバグでもない
限り実際には問題にならないような例ではなく、MD5やSHA1といったハッシュ
値を計算のような、処理中にテーブルを参照して計算するプログラムで、
テーブルの値がどこか1bitだけ反転しているケースとか、具体的にどう
やってテストだけで検出するつもりなんだろう?

328 :デフォルトの名無しさん:2013/12/31(火) 00:01:49.96
>>323
「このテストで正しいことを確認しました」 「テストコードは仕様の宣言的命題の羅列だから漏れがあるか確認してください」 「環境も含めてテストしたい場合はこのテストをあなたのマシンで動かしてください」 でいいじゃん

329 :デフォルトの名無しさん:2013/12/31(火) 00:03:18.90
>>327
細かく関数に分解し、すべてテストを書く。

330 :デフォルトの名無しさん:2013/12/31(火) 00:04:42.82
>>328
苦笑w

いや、だからそういうことだろ?


> なにをもって正しいと言って納品してるの?

の答えは、

「漏れがあるか(あんたが)確認してください」

ってことでしょ?

331 :デフォルトの名無しさん:2013/12/31(火) 00:05:43.23
ざっくり言うと、

正しいことを証明しなさい

いやです。あんたが確認しなさい。

332 :デフォルトの名無しさん:2013/12/31(火) 00:05:52.22
>>327
というか、テスト以外でどうやって検出するの?
念力?

333 :デフォルトの名無しさん:2013/12/31(火) 00:08:43.54
普通はデバッガだろうけど、デバッガはアホが使うものだからね。
テストで検出しないとダメ。

334 :デフォルトの名無しさん:2013/12/31(火) 00:11:00.08
>>330-331
「『私の確認を』 あんたが確認してください」 ね

ざっくり言うと 

正しいことを証明しなさい

ドメインの部分集合をテストで確認し暫定的な証明とする

「私がやった正しいことの証明」をあんたも確認してください



335 :デフォルトの名無しさん:2013/12/31(火) 00:11:20.30
テストコードがあったとしても、コードが正しいという証明はできないからな。

たとえば、二乗する関数が合ったとして、
2なら4、3なら9、4なら16、16なら256というテストコードに通っても、

if (n == 2) return 4;
if (n == 3) return 9;
if (n == 4) return 16;
if (n == 16) return 256;

という明らかに間違った実装でも、テストコードは通るんだよ。

336 :デフォルトの名無しさん:2013/12/31(火) 00:12:16.47
>>335
テストのテストを書けばいい。

337 :デフォルトの名無しさん:2013/12/31(火) 00:14:18.82
>>321
テスト駆動とは、仕様を宣言的命題としてテストを書いて、それに従うコードを書くことなんでしょう?
テストに書かれていない、つまりテストできないコードを書く
それも実際には重要になるだろうコードを書くのは、テスト駆動から逸脱じゃないの?

309の例はよくないけど、
言語仕様の取り得る全ての値をチェックして、さらに、どれにも当てはまらない、ありえない場合に
ロジックではないエラーとして例外を投げるとき、テストできるのは、前半の取り得る全ての値のテストだけで
それが通れば正しいコードとして納品できるよね
後半は、ありえないようなハードエラーが起きたときにも、救うべく用意されるコードで、
正しい以上の配慮のコードで、テスト駆動を逸脱しないと書けないと思うんだよね

338 :デフォルトの名無しさん:2013/12/31(火) 00:15:42.40
>>335
そんな実装をする低能を検出して除外するために
採用面接などのテストが存在する

339 :デフォルトの名無しさん:2013/12/31(火) 00:16:47.49
>>337
卵が先です。
常識で考えればわかるはず。
なぜなら、最初の鶏の親は鶏ではなかったのだから。

340 :デフォルトの名無しさん:2013/12/31(火) 00:17:28.61
>>335
ドメインが {2,3,4,16} なら正しいコードですけど

341 :デフォルトの名無しさん:2013/12/31(火) 00:18:27.06
>>335みたいな、コード見ればすぐに分かるような極端な例でなくても

たとえば、読み込んだ設定値を使うべき所を
面倒だから、とりあえず固定値つかって開発しましたみたいなの。

・テストは書いた(でも不足している)
・テストは通った(ただし固定値を使ってしまってる)

こういうのはテストコードがあって、それを実行して
テストコードが通っても正しく動かないコードなんだよね。

人間ミスはだれでもするもので、テストコードを漏れなく書いたつもりでも
漏れてしまうことがある。

テストコードがあっても、正しく動くという証明はできないんだよ。
テストコードで証明できるのは、テストしたことだけ。

コードが正しいこともテストが正しいことも、漏れがないことも証明できない。

342 :デフォルトの名無しさん:2013/12/31(火) 00:19:31.63
>>322
> function pow(x, y) {}
> だけど異常系、たとえばxやyに数字以外を入れた場合のエラーは

記述はC言語の型宣言っぽいけど、C#か何か? VBで書くと

Public Function pow(x As Variant, y As Variant) As Variant
...

Dim X As Variant
Dim Y As Variant
Dim Z As Variant

  X = "abc"
  Y = "def"
  Z = pow(X, Y)

とかってことで桶かな?

343 :デフォルトの名無しさん:2013/12/31(火) 00:20:26.69
>>341
非常にわかりやすく納得しました。
確かにその通りです。
テストする奴はアホです。
これからはデバッガの時代です。
改心しました。

344 :デフォルトの名無しさん:2013/12/31(火) 00:21:28.29
>>336
その「テストのためのテスト」のテストコードは、いつ誰が書くの?

345 :デフォルトの名無しさん:2013/12/31(火) 00:21:38.82
デバッガがバグってないことは誰が証明するの?

346 :デフォルトの名無しさん:2013/12/31(火) 00:22:07.36
>>337
というか、テストできないコードって具体的にどんなのでしょうか

GUIなら自動で再利用できるテストが存在しないというのは分かるけど

347 :デフォルトの名無しさん:2013/12/31(火) 00:23:02.37
テストツールがバグってないことは誰が証明するのか?

348 :デフォルトの名無しさん:2013/12/31(火) 00:23:24.53
>>339
都合が悪くなると、禅問答のような回答をしてw
テスト駆動開発に疑問を持ってる人は、テスト駆動だからといって、今までの仕事が減らないと思ってるからだと思うな。

349 :デフォルトの名無しさん:2013/12/31(火) 00:24:05.98
>>346
ドメインが「すべての整数」であるようなコード
時間は無限ではないのだから
すべての整数でテストは出来ない。

350 :デフォルトの名無しさん:2013/12/31(火) 00:24:14.58
一番確からしいテストは顧客に使ってもらうことですよ。
クレームが来たら何かが間違ってたんですよ。

351 :デフォルトの名無しさん:2013/12/31(火) 00:25:07.49
>>346
だから、よくない例ではあるけど >>309 みたなコード

352 :デフォルトの名無しさん:2013/12/31(火) 00:26:09.98
>>341
命題を外延的表現じゃなくて内包表記で書けばいいんじゃ?

353 :デフォルトの名無しさん:2013/12/31(火) 00:26:56.38
>>351
>>309 はテストできるけど

354 :デフォルトの名無しさん:2013/12/31(火) 00:29:00.53
>>329
話が理解できないなら、SSL関係あたりで、オープンソースのハッシュ計算
プログラムのソースが公開されているから見てみな。

入力する値によってテーブルの参照される場所は変わるし、すべてのテー
ブルは使われないから、参照されないテーブルの場所は検証されない。

355 :デフォルトの名無しさん:2013/12/31(火) 00:29:13.13
>>348
ほぽすべてのプログラマはテスト駆動開発をすでにやっている
テストが自動で再利用できる形でないだけ

356 :デフォルトの名無しさん:2013/12/31(火) 00:29:23.03
>>347
> テストツールがバグってないことは誰が証明するのか?

それも「何を持って正しいと言って納品するか」って話と
同じ話なんだよね。

俺はこれこれという道具を使って、これこれのテストコードで示される
テストしたという証明しか出来ない。

テストしたという証明であって、正しいかどうかの証明は
どうやってもできない。

正しいかどうかは、お前が判断してくれって言うしか無いわけ。
それが、納品先が行う「検収」という作業なわけ。

357 :デフォルトの名無しさん:2013/12/31(火) 00:30:12.97
>>354
それがテストできないという理屈が分からないのだが

358 :デフォルトの名無しさん:2013/12/31(火) 00:30:28.56
>>354
全ての値が使われるまでテストし続けるテストを書く。

359 :デフォルトの名無しさん:2013/12/31(火) 00:32:29.41
>>355
> ほぽすべてのプログラマはテスト駆動開発をすでにやっている
お前が言ってるのは、先にテストを考えるってことだろ?

テスト駆動開発っていうのはちゃんとした手順に従った開発のことで、

・テストコードを書く
・実装がないのでテストコードは失敗する
・テストに通る最低限の実装を書く
・これを繰り返す

という開発方法のことで、単にテストを最初に考えるということではないんだよ。

疑うのなら、テスト駆動開発のやり方を調べてみ。

360 :デフォルトの名無しさん:2013/12/31(火) 00:32:43.11
>>356
のらりくらりかわし続ければ検収するから大丈夫です。
担当者もそんなに暇じゃないですから。
ここは完全にダメだなと思わせれば泥をかぶってくれます。

361 :デフォルトの名無しさん:2013/12/31(火) 00:32:57.55
>>353
最初と次の if で取り得る値全部拾ってるんだから、最後の else には、ふつうのテストでは、到達しないでしょ
309がテストできたとしても、そういうケースのコードがあって、それはテスト駆動の通りには書けないよね

362 :デフォルトの名無しさん:2013/12/31(火) 00:33:16.83
>>356
a. 俺がこのテストコードを xUnit のVer.x でテストして、納品先もそのテストを確認して、検収した
b. 俺はテストせずに、納品先が検収した

バグがより少ないコードはどっちでしょうか?

363 :デフォルトの名無しさん:2013/12/31(火) 00:33:37.75
>>360
だからなんなんだよ?

364 :デフォルトの名無しさん:2013/12/31(火) 00:35:28.43
>>362
「バグがより少ない」と言ってることからもわかるように

テストコードが合っても、バグがないことを証明することは
出来ないってわかってるんだよね。

365 :デフォルトの名無しさん:2013/12/31(火) 00:35:56.55
>>363
担当もそこまで期待していないってこと。
ソフトウェアの製造に携わっている人達、つまり自分より質の劣る人たちです。
こいつらじゃ仕方ないかと思ってくれます。
簡単にあきらめてくれます。

366 :デフォルトの名無しさん:2013/12/31(火) 00:36:11.68
>>359
その定義は間違ってる
理由は、その定義は、事前に考えた仕様に未定義部分がないことを前提にしているが、そんなプロジェクトはないから

367 :デフォルトの名無しさん:2013/12/31(火) 00:37:00.75
>>358
口先だけの馬鹿コンサルは黙ってろ。 MD5でもSHA1でも、実際に全ての
テーブル値が参照されることを保証できるテストコードを書いてから出直し
てこい。

368 :デフォルトの名無しさん:2013/12/31(火) 00:37:39.89
>>355
GitHub眺めてても testはずっと更新されないで src ばかり日付新しくなるの山ほどあるよ。

369 :デフォルトの名無しさん:2013/12/31(火) 00:38:11.13
>>366
俺は「テスト駆動開発」の定義を言っただけで、

そんなプロジェクト無いからとか
明後日のレスをしてる時点で
お前が不利だぞw

370 :デフォルトの名無しさん:2013/12/31(火) 00:38:53.44
テストしたらバグ増えるよ?
完全にテストを行うとかカバレッジがどうのとか事前にしつこく売り込んできたときは
必ず質が悪いから。
経験的にわかってる。
テストをしたらバグが増える。

371 :デフォルトの名無しさん:2013/12/31(火) 00:40:30.49
テストなんて余計な事をしたせいで納期に間に合わなくなって、最後に
悪あがきするから品質が落ちるんだと思ってるけどね。

372 :デフォルトの名無しさん:2013/12/31(火) 00:41:44.84
まじかよ
TDDはともかくテスト自体に対する認識がこれか

373 :デフォルトの名無しさん:2013/12/31(火) 00:42:13.00
>>364
自動で再利用できないだけで、テストはあるでしょう?

374 :デフォルトの名無しさん:2013/12/31(火) 00:44:10.65
>>369
その「テスト駆動開発」の定義が間違ってる

375 :デフォルトの名無しさん:2013/12/31(火) 00:45:18.23
>>373
だからなんなんだよ。
テストコードはバグがないことの証明にはならないって話。

>>374
そうか。じゃあお前のテスト駆動開発の定義ではなく
一般的なテスト駆動開発の定義を引用してくれ。
書かなくていいぞ。引用すれば良い。

376 :デフォルトの名無しさん:2013/12/31(火) 00:46:04.19
正しい定義

1. 最終的に正しいコード(バグがないコード)を作成することを目的に
2. プログラマがコーディングする前に考えた宣言的命題を「暫定的に」正しい仕様として採用し
3. それをテストコードとしてまず作成し
4. コーディングの目的をそのテストをパスすることに還元し
5. そのテストを通るように本体のコードを作成し
6. テストの結果によってコードのみならずテストの修正も行い
7. テストの修正がある場合は仕様の修正として上流にフィードバックし
8. テストが通るまでコーディングするスタイル

リファクタリングの場合は、
1. 最終的に正しいコード(バグがないコード)である状態を変更しないことを目的に
2. すでに作成されたテストコードを再利用し
3. コーディングの目的をそのテストをパスしつつ、リファクタリングの目的を達成することに還元し
4. そのテストを通るように本体のコードを作成し
5. テストが通り、リファクタリングの目的を達成するようにまでコーディングするスタイル

上記のことが記述してある(2〜3日以内にググれば出てくる)参考URL
http://toro.2ch.net/test/read.cgi/tech/1387695847/l50

377 :デフォルトの名無しさん:2013/12/31(火) 00:46:04.97
2ちゃんねるの自分の書き込みを引用すれば、
もしかして説得力でるんじゃないだろうか?って考えてる。

378 :デフォルトの名無しさん:2013/12/31(火) 00:46:39.77
>>376-377

さすがだ。正解>>377

379 :デフォルトの名無しさん:2013/12/31(火) 00:47:26.58
痛いなぁw
2ちゃんねるの自分の書き込みを
引用かよ。

380 :18:2013/12/31(火) 00:47:36.95
>>309
> if (x < 0) { ... } else if (x >= 0) { ... } else { throw unstableMemoryException("unstable memory error"); }

こんなコード書く奴いたら、即刻プロジェクトから退場いただくわ

> でも出荷する製品レベルなら、これは、いれとくべき仕様だと思う

あほか。

if (x < 0) { ... } else { ... }

にしない理由がないだろ。

381 :デフォルトの名無しさん:2013/12/31(火) 00:48:32.66
雑なテイノウ集団に限って手法にこだわりを見せるんだよね。
一文字一文字心を込めて打ち込めばバグなんてなくせるだろ?
テストなんて書いてる暇あったら明鏡止水の心で誠心誠意コードを
打ち込んだほうが良い。

382 :デフォルトの名無しさん:2013/12/31(火) 00:48:49.07
>>375
テストは、目的がバグをなくすことであって、バグがないことを証明するプロセスの一部ではあるが、バグがないことを証明するモノではないしな…

383 :デフォルトの名無しさん:2013/12/31(火) 00:49:30.38
問題の本質は、どんなツールを使ったかではなく、どんなテストをしたのか
なわけなんだが、中身からっぽのテスト駆動馬鹿は、ツールのブランド
だけが頼り。

食品の産地と鮮度、料理の見栄えが頼りの和食と同じだな。

どんなテストツールを使おうが、馬鹿にやらせた仕事は馬鹿なりの出来
にしかならない。これは間違いない。

馬鹿の書いたクラスは部品として再利用できないシロモノである可能性が
高いが、printfデバッグだって、自動で再利用できる。

384 :デフォルトの名無しさん:2013/12/31(火) 00:49:50.73
>>381
イチローに向かって「なんで10割打たないの?」て感じだろうか

385 :デフォルトの名無しさん:2013/12/31(火) 00:50:23.80
クレームが来たら切腹する覚悟で、一文字一文字丁寧にだよ。
これが武士道。

386 :デフォルトの名無しさん:2013/12/31(火) 00:50:29.55
>>380
JavaScriptでxがNaNの場合は、
x < 0 ・・・ false
x >= 0 ・・・ false
だよ。

387 :デフォルトの名無しさん:2013/12/31(火) 00:50:53.90
>>379
納期までによりバグの少ないコードを納品できるテスト駆動開発の定義はどちらでしょうか?

388 :デフォルトの名無しさん:2013/12/31(火) 00:51:50.77
>>384
あほですか?
野球のような肉体の芸術とプログラミングのような今日日小学生でもやるような
雑用と一緒にするんですか?

389 :デフォルトの名無しさん:2013/12/31(火) 00:52:31.77
>>387
それを言うのなら、

納期までによりバグの少ないコードを納品できるのどちらでしょうか?

だろw


テスト駆動開発の定義はググレカス

390 :デフォルトの名無しさん:2013/12/31(火) 00:55:06.19
>>388
> 野球のような肉体の芸術とプログラミングのような今日日小学生でもやるような

磯野ー(小学生)野球やろうぜー(By 小学生)

391 :デフォルトの名無しさん:2013/12/31(火) 00:55:35.09
>>388
プログラミングで重要なのは、人間の生物学的な認知のミスをいかに削減するかという活動だから、肉体の芸術ですよ

392 :18:2013/12/31(火) 00:55:52.95
>>386
int なんて型宣言できる JavaScript があるかどうかは知らんけど、それなら普通にテストできるだろ。

393 :デフォルトの名無しさん:2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ

でも、>>309の例はよくないけど
最初のif と次のifの間に、xのMSBにメモリエラーが起きて、誤判定したら困るようなときにはこういうコードを書く
そしてふつうには、テストできないんだよ

394 :デフォルトの名無しさん:2013/12/31(火) 00:56:21.59
プロ野球選手とプログラマのやることの難易度を同列に考えるとか
クズもいいところだなあ。
自分の出来ることは難易度が高いと主張する人はたいてい何もできない
雑用係です。
一生雑用係なんだろなって感じの人。
逆に、自分のできることは難易度が低く簡単なことと考える人は、たいてい
向上していく人です。
10年後には大きな差が生まれます。

395 :デフォルトの名無しさん:2013/12/31(火) 00:58:14.87
社交辞令の日本人はともかく、ポテンヒットで打率を稼ぐしか能がない
イチローよりは、松井の方が好かれているよね。

将来のIT奴隷として育成するより、テスト駆動を書ける小学生を即戦力
としてスカウトしてくれば解決だね。

396 :デフォルトの名無しさん:2013/12/31(火) 00:58:17.67
>>386
仕様でドメインが整数集合だと思ってたら、実際は整数集合∪{NaN}ってことだよね?
それこそテストの出番だと思うが

397 :デフォルトの名無しさん:2013/12/31(火) 00:58:37.86
393 :デフォルトの名無しさん:2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ

393 :デフォルトの名無しさん:2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ

393 :デフォルトの名無しさん:2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ

398 :デフォルトの名無しさん:2013/12/31(火) 00:58:42.03
JavaScriptみたいなのには NaN とかあったね
>>309 は言語仕様として x に非整数の値を取らないとしてね

399 :デフォルトの名無しさん:2013/12/31(火) 00:59:35.73
>>396
テストの出番なのはわかるが、
テスト駆動じゃなくてもいいだろ?

400 :デフォルトの名無しさん:2013/12/31(火) 01:00:22.26
一球入魂って言葉がある。
一文字一文字に心を入れるんだ。
そうすればバグは無くなる。

401 :デフォルトの名無しさん:2013/12/31(火) 01:00:58.42
JavaScriptでNaNがあることを知らない人は
NaNのテストコードを書かないだろう。

そして実装してみて、バグに気づいて
あとからテストコードを書くだろう。

テスト駆動ではない。

402 :デフォルトの名無しさん:2013/12/31(火) 01:01:26.78
>>393
仮にテストできないとして、そのテストできない事象の対処コードを書いたとする
もしかして、その対処コードを一度も動かさずに納品するってこと?

403 :デフォルトの名無しさん:2013/12/31(火) 01:02:38.36
>>401
>>376の定義では仕様の未定義部分を修正するからテスト駆動ですよ

404 :デフォルトの名無しさん:2013/12/31(火) 01:02:53.65
>>393
ハードエラー(メモリの不良)が起こるような状況なら、そもそもRAM上で走る
プログラムコード自身や、スタック上の一時変数や関数の戻り先が、再現性
なく破壊される可能性があるんだが?

405 :デフォルトの名無しさん:2013/12/31(火) 01:03:20.74
松井やイチローとプログラマである自分を同列だと思うあたりが、
プログラマの質の低さを物語っているわけだけど、
この質の悪いプログラマというものをどう扱うか、そういった学問があれば、
製品の品質は上がることでしょう。

俺は体罰の導入が効果的だと思う。
実際、効果あるし。

406 :デフォルトの名無しさん:2013/12/31(火) 01:03:48.00
>>402
そうではなくて、テスト駆動では書けないよねって話
テスト駆動は、仕様を宣言的命題としてのテストからコードを導出するんだから、>>380 のいうコードになってしまう

407 :デフォルトの名無しさん:2013/12/31(火) 01:05:25.17
>>404
だから>>309 はよくない例といっているんだけど
それでもテストできないけど、防衛しておきたい場所やケースがあるよね

408 :デフォルトの名無しさん:2013/12/31(火) 01:06:22.75
>>394

>>394が単なる自己都合の思い込みではなく、真理であるというテストコード
を書いてみてはくれないかね?(w

409 :デフォルトの名無しさん:2013/12/31(火) 01:06:31.54
>>406
きちんとドメインを 整数集合∪{NaN} として命題を書けばいいのでは?

410 :デフォルトの名無しさん:2013/12/31(火) 01:08:05.40
単純な二分探索ですらバグがないコードが出来るまでに30年かかったというのに…

411 :デフォルトの名無しさん:2013/12/31(火) 01:10:39.97
>>410
数学者が書くなら一週間でバグが取れただろうね。
残念ながらプログラムはプログラマが書くんだ。

412 :18:2013/12/31(火) 01:12:13.29
>>406
ハード障害を考慮すると言う仕様になるだろ
当然そのテストもするし

まあ現実に変数の値がコロコロ変わるなんて環境でまともなソフトが動くとは思えないけど。
そんな環境なら ECC つけろよと言うべき。

413 :デフォルトの名無しさん:2013/12/31(火) 01:12:56.42
>>406
例えば、 >>309 の変数 x が volatile 宣言された大域変数で、関数処理
実行中に外部スレッドや割り込み処理で値が変わる場合があるとかなら
わからなくもない。

こういう組み込みではありがちなケースで、関数単位の静的なテストしか
想定していないテストツールはまず役に立たない。

414 :デフォルトの名無しさん:2013/12/31(火) 01:14:28.90
関数単位の静的なテスト以外も考慮したテストツールを使えばいい。
しかし、大切なのは武士の心得、そして一球入魂。。

415 :デフォルトの名無しさん:2013/12/31(火) 01:14:35.48
>>409
>>309 は NaNを取らない言語の例なんだよ
命題としてとっても、そのテストは、ふつうには書けないから、いや環境まで作ればテストできるけどさ
どんなものもドメインにとれば、テスト駆動できるっていうのは、机上の空論ていうかさ
限度を超えたテストファーストになるようなコードは、テスト駆動では、できないよね

416 :18:2013/12/31(火) 01:16:12.32
>>413
ごめん、排他しろよボケ、としか言えないわ

417 :デフォルトの名無しさん:2013/12/31(火) 01:23:40.49
>>416
排他処理が不完全とか、あちこちでreturnするようなコードを書く馬鹿
だと、ある条件の時だけロックしたまま関数抜けるとか、ありがち。

結局のところ、安易なツールに頼るより、関わる人間を絞って、コード
レビューを徹底した方が確実なのだよ。

418 :デフォルトの名無しさん:2013/12/31(火) 01:30:40.23
ツールに頼るより、バグを出す人間を見極めて定期的に入れ替えるほうが
効率的。
ポイント制にするのもいいかも。
あと5ポイントでクビとか。

419 :デフォルトの名無しさん:2013/12/31(火) 01:40:28.13
ある意味間接的にバグを仕込んでいるに等しい、バグを出す人間を見分け
られない無能な採用者も、連座制で一緒にクビにした方がいいと思うよ。(w

420 :デフォルトの名無しさん:2013/12/31(火) 01:45:54.32
それはダメだと思う。
プログラマと違って取り換えがきかないから。

421 :デフォルトの名無しさん:2013/12/31(火) 01:46:54.21
>>418
いいね。お前をすぐ首にできそうw

422 :18:2013/12/31(火) 01:47:10.63
>>417
それ全然関係ない話だろ。
自分の組織の愚痴ならチラシの裏にでも書いてろよ。

423 :デフォルトの名無しさん:2013/12/31(火) 02:01:14.53
>>442
ありきたりの一般論を言っただけだが、自分の組織の愚痴だと思うなら、
あなたの組織が実際にそうなのでは?

424 :デフォルトの名無しさん:2013/12/31(火) 02:24:14.15
>>420
> プログラマと違って取り換えがきかないから。

実証されていないその仕様のテストはとても簡単だな。

一旦採用者をクビにするなり、交換して開発が滞りなく進んだり、むしろ
以前より捗るようなら、採用者が最大のバグだったということになる。

経験上、実務経験に乏しい大抵のなんちゃってプロマネは、納期1ヶ月前
くらいになると、ソワソワし始めるんだよなぁ。

425 :デフォルトの名無しさん:2013/12/31(火) 02:35:16.97
>>415
限度を超えてなくてもテストは時間とのトレードオフですよ
少なくとも今の技術では、ランダムにドメインから有限個の値を取り出してそれを関数に通して比較してるだけだから

426 :デフォルトの名無しさん:2013/12/31(火) 02:48:05.35
>>417
タイミングでシビアな動作をするコードでxUnitみたいな自動で再利用可能なテストが困難なのはそのとおりだけど、
天才逹によるコードレビューの徹底の方が確実というのには同意しかねる

理由は、コードレビューがやるのは、コードが仕様に沿ってることのチェックで、仕様の未定義部分を検出しないから
仕様が漏らしてるフローの検出のためにも、レビューしてもいいけど、それに加えていくつかテストを実行すべき

ちなみに排他処理用のテストツールはある

427 :デフォルトの名無しさん:2013/12/31(火) 02:57:44.18
SQLインジェクションが発生しないことを
確認するテストってやるの?

やるとしたら、データベースに保存する値すべてに
SQLインジェクションが発生しないことを確認する
テストを書かないといけないってことだよね?

428 :デフォルトの名無しさん:2013/12/31(火) 03:06:48.29
コードレビューのほうが確実っていうのは
ある意味正しいよ。

バグがでるのは、多くの場合コードが複雑だから。
仕様を満たしていないバグよりも、
コードが複雑なため特定の場合においてバグに
なっているという事例のほうが多い。

テストがあってもコードの複雑さまでは判断できない。

429 :デフォルトの名無しさん:2013/12/31(火) 03:07:34.27
テスト駆動とかフレームワークありきじゃないと無理だわ
全体像を見極めるためにプロトタイプ作るからその時点で挫折する
環境が整った状態が前提になるんじゃないの?

430 :デフォルトの名無しさん:2013/12/31(火) 03:11:34.46
>>427
RDBMS作ってるなら、自動テストやらざるをえないだろうね
RDBMS使う側なら、自動テストが困難だから、予算との戦いになるだろうね

431 :デフォルトの名無しさん:2013/12/31(火) 03:13:50.00
>>430
RDBMSの話じゃないんだけど
SQL発行するコードが合った場合、
いちいちSQLインジェクションが起きるかどうかの
テストコードを書かないといけないのってことなんだけど。

432 :デフォルトの名無しさん:2013/12/31(火) 03:16:32.56
気合でカバー。

433 :デフォルトの名無しさん:2013/12/31(火) 03:18:29.58
プログラミングに禅の心得を融合させればすべて解決する。

434 :デフォルトの名無しさん:2013/12/31(火) 03:20:16.04
大抵の言語のプリペア機能がプレースホルダをサポートするからそれ使うんじゃね
条件式の構造そのものを動的に弄る場合でもなければそれ使うことを仕様として丸投げが普通だと思ってる

435 :デフォルトの名無しさん:2013/12/31(火) 03:21:18.88
>>428
もらったコードがメチャクチャで複雑でも、見た範囲でコードが正しくてコードが動くなら、レビュー側からプログラマにコードを書きなおせとは言えない
とりあえず正しい以上、コードの変更はただ単純にバグを生産するだけだから

仮に書き直せと言う場合も、コーディングの最中に変更前から意味が変更されてないことを「プログラマが」確認する何かが必要
(プログラマにとってはメチャクチャなモノが通常状態で、訂正指示の方がメチャクチャだから)
それは元のコードがパスしたテストコードしかないでしょう

436 :デフォルトの名無しさん:2013/12/31(火) 03:23:33.56
>>434
> 大抵の言語のプリペア機能がプレースホルダをサポートするからそれ使うんじゃね

普通は使うだろうね。
だけど使ってない可能性がある。

普通は使うけど使っていない可能性のために、
テストコードを書くの?って話をしてるんだけど。

コードレビューをすればば明らかにわかることなんだけど、
コードレビューをしないなら、

(普通はプレースホルダ使ってるよな?)
(だからテストコードなくても問題ないよな?)
でも実際は、SQLインジェクションの問題がありました!

ってならない?って話をしているんだよ。

437 :デフォルトの名無しさん:2013/12/31(火) 03:24:41.70
>>435
> とりあえず正しい以上、コードの変更はただ単純にバグを生産するだけだから

なんのためのテストコードだよw

コードをあるべき形にリファクタリングするための
テストコードだろうが。

438 :デフォルトの名無しさん:2013/12/31(火) 03:28:08.64
>>436
ちゃんと使ってるかどうかわからないって状況がちょっとイメージ掴めない
とりあえずチームを信頼できない状況下なら何駆動開発だろうとコードレビューするのが正じゃね?

439 :デフォルトの名無しさん:2013/12/31(火) 03:31:26.18
>>431
例えば、時間が十分にあって、その不都合が起きたら罰金1000万円の場合に、「テストコードを書かないといけないの?」と問われたら、答えは「はい。可能な限りデータを突っ込んで検証するテストを書きましょう」

440 :デフォルトの名無しさん:2013/12/31(火) 03:31:41.78
こういうスレって口だけ番長ばっかだよな

441 :デフォルトの名無しさん:2013/12/31(火) 03:34:27.79
>>437
1. 最終的に正しいコード(バグがないコード)を作成することを目的に

442 :デフォルトの名無しさん:2013/12/31(火) 03:36:11.89
プログラマは底辺
底辺は大きく見られたいという願望がある

443 :デフォルトの名無しさん:2013/12/31(火) 03:38:23.08
底辺連呼する奴も大きく見られたいという願望がある

444 :デフォルトの名無しさん:2013/12/31(火) 03:39:44.71
そもそも十分なテストができないんだから
コードをすっきりさせてバグが発生しづらい状況にするのは当然のこと

テスト済み=問題なしとするような底辺仕事と一緒にすんなよ

445 :デフォルトの名無しさん:2013/12/31(火) 03:40:29.08
>>441
バグがなければ
汚いコードでもいいと言いたいわけ?

汚いコードというのは、
メンテナンス性が悪くて
コードの見通しが悪くて
コピペが多くて
無駄なコードが有るコードのこと。

テストコードがあっても
解決できないもんだよだ。
コードレビューじゃないと解決できない。

446 :デフォルトの名無しさん:2013/12/31(火) 03:41:06.60
>>442
ミスばっかりする底辺でも動くシステムと、天才でしか回せないシステム
どちらが良いでしょうか?

447 :デフォルトの名無しさん:2013/12/31(火) 03:43:00.12
>>427
入力側ではじくのが一般的じゃね
SQLインジェクション対策で、DBに想定しない値が入ってしまったらなんていうテストはしたことないぞ

448 :デフォルトの名無しさん:2013/12/31(火) 03:45:06.20
綺麗なコード=規約通りのコード

ほぼ機械的にはじけるでしょ

449 :デフォルトの名無しさん:2013/12/31(火) 03:45:20.47
天才限定システムのほうが良いですね
馬鹿の入り込む余地が無いので

450 :デフォルトの名無しさん:2013/12/31(火) 03:45:51.76
ミスばっかりする底辺にシステムを触らせるな

451 :デフォルトの名無しさん:2013/12/31(火) 03:47:31.44
>>444
どんな開発手法でいかに綺麗なコードで書いていても、「問題なし」を宣言するのは何かしらのテストが終わったときだと思うが…

452 :デフォルトの名無しさん:2013/12/31(火) 03:48:10.48
どのように優秀なシステムであっても馬鹿が一匹混ざるだけで無効になります
たとえば、安全な日本と言っても基地外が一匹暴れるだけで多くの人が死ぬこともあるわけです
すなわち馬鹿に扱えないのは、一つの美点となるでしょう

453 :デフォルトの名無しさん:2013/12/31(火) 03:50:38.76
馬鹿は極力排除したほうが良いのです
助けになることは万に一つもありません
ここら辺の原理原則がわからないのは社会経験が浅いからでしょうね
早く就職しなさいと言っておきます

454 :デフォルトの名無しさん:2013/12/31(火) 03:51:44.95
要するに「僕ちゃんが悪いんじゃないよ〜」って言いたいのね。
かっこわる

455 :デフォルトの名無しさん:2013/12/31(火) 03:54:00.29
>>446
> ミスばっかりする底辺でも動くシステムと、天才でしか回せないシステム

なんでその二つを比べるの?
都合良すぎるよね。お前。

456 :デフォルトの名無しさん:2013/12/31(火) 03:55:14.23
>>445
テストコードというのは、
メンテナンスのすべての時点における一貫性のレベルを担保して
コードの各粒度を仕様の宣言的表現で見通して
コピペの意味の同一性を適当なレベルで担保して
無駄なコードを削除したときに本当に無駄だったことを適当なレベルで担保するコードのこと

コードレビューをしても
解決できないもんだよだ。
テストコードじゃないと解決できない。

457 :デフォルトの名無しさん:2013/12/31(火) 03:55:20.14
天才だけでやるんだったら当然天才はお前が集めてくるんだよね?

458 :デフォルトの名無しさん:2013/12/31(火) 03:56:39.51
禅の心で挑めば天才は自ずと集まります

459 :デフォルトの名無しさん:2013/12/31(火) 03:59:17.82
確かにコードの質の悪さは
テストコードじゃ解決しない問題だな。

460 :デフォルトの名無しさん:2013/12/31(火) 04:00:44.92
>>454
それが事実
ミスしたバカを見つけて、お前が悪いと言っても解決しない
あなたがいる環境は、そんなバカが集まるべくして集まる環境だから

461 :デフォルトの名無しさん:2013/12/31(火) 04:01:50.20
ひどい場合、テストに通る最低限のコードしか
書いてないってことがありえるからな。
コードレビューしていればわかるが。

462 :デフォルトの名無しさん:2013/12/31(火) 04:02:36.78
>>455
ミスばっかりする底辺でも動くシステムと、半分がバカで半分が天才で回すシステムと、天才でしか回せないシステム
どれが良いでしょうか?

463 :デフォルトの名無しさん:2013/12/31(火) 04:03:13.47
その通り
天才しか扱えないことで、環境が浄化されます
そこには天才しかいられません

464 :デフォルトの名無しさん:2013/12/31(火) 04:03:18.05
無能が他人のせいにするスレ

465 :デフォルトの名無しさん:2013/12/31(火) 04:03:21.98
コードの質の悪さは
バカを排除しなきゃ直らない

466 :デフォルトの名無しさん:2013/12/31(火) 04:03:51.70
真っ先にお前がいなくなるな

467 :デフォルトの名無しさん:2013/12/31(火) 04:04:38.18
そもそもシステムは運用手順書を丸暗記してよく訓練された運用のプロが行うのであって
そこらのわけのわからない派遣プログラマの兄ちゃんにやらせるわけじゃない

468 :デフォルトの名無しさん:2013/12/31(火) 04:05:08.99
>>461
コードレビューの質というか、そもそも「仕事しました」は、客観的にどうやって確認するのでしょうか?

469 :デフォルトの名無しさん:2013/12/31(火) 04:05:27.27
>>462
どれがいいシステムかって?

バグがなくて、
コードがシンプルで
無駄がなくて
見通しがいいコードじゃないの?

470 :デフォルトの名無しさん:2013/12/31(火) 04:06:36.19
バグがなくなるなんて夢物語信じちゃってるの?

471 :デフォルトの名無しさん:2013/12/31(火) 04:07:25.07
バグはなくならないから
コードはメンテナンス性を高くして
シンプルにしましょうね。
どうせあとで修正することになる。

472 :デフォルトの名無しさん:2013/12/31(火) 04:07:58.62
AndroidはLinuxなのでバグが無い。

473 :デフォルトの名無しさん:2013/12/31(火) 04:09:22.92
ミスばっかりする底辺でも、バグがなくて、コードがシンプルで無駄がなくて見通しがいいコードを書けてしまうシステムと
半分がバカで半分が天才が、バグがなくて、コードがシンプルで無駄がなくて見通しがいいコードを書くシステムと、
天才だけが、バグがなくて、コードがシンプルで無駄がなくて見通しがいいコードを書けるシステム

どれが良いでしょうか?

474 :デフォルトの名無しさん:2013/12/31(火) 04:10:38.22
>>461
リテラル返してるバカを見たことあるわw

475 :デフォルトの名無しさん:2013/12/31(火) 04:11:56.64
やっぱ、コーディングとテストは別人がやるべきなんだよ

476 :デフォルトの名無しさん:2013/12/31(火) 04:12:15.56
天才だけが、バグがなくて、コードがシンプルで無駄がなくて見通しが
いいコードを書けるシステムがいいですね
何度も言いますが、馬鹿が一匹混ざるだけで綺麗な世界は瓦解します
馬鹿のやることをチェックするために天才を配置するなら、最初から天才に
やらせればいいのです

477 :デフォルトの名無しさん:2013/12/31(火) 04:15:17.64
馬鹿には無理ということがどれだけ素晴らしいことかわかっていない人がいるようですね
馬鹿には指一本触れさせるべきではないのです

478 :デフォルトの名無しさん:2013/12/31(火) 04:15:37.18
>>475
> やっぱ、コーディングとテストは別人がやるべきなんだよ
それはテスト駆動においてもですか?

479 :デフォルトの名無しさん:2013/12/31(火) 04:15:51.04
>>471
そもそもコードがシンプルならメンテナンス性が高いというのは間違い
理由は、一般に、コードをシンプルにするほど隠れたフローが増大し、演算の例外を出力するドメインが増大するから
後者の典型例が二分探索

直交性が高くメンテナンス性が高いコードはシンプルだが、逆は真ではない

480 :デフォルトの名無しさん:2013/12/31(火) 04:17:07.08
屁理屈ばっかw

481 :デフォルトの名無しさん:2013/12/31(火) 04:18:25.01
テストコードに通っても
コードが正しいとは限らないし、
コードの質が悪いこともある。

結局のところ、コードレビューを行わないと
意味が無い。

482 :デフォルトの名無しさん:2013/12/31(火) 04:19:49.50
JavaやPHPの罪は重いはずです
少なくとも禁固100年は下らないでしょう

483 :デフォルトの名無しさん:2013/12/31(火) 04:20:26.23
>>475
コーディングとテストは別人がやるべきだけど、テストの人に回す前に、コーディングした人が時間が許す限りテストするべき
そして、バグのないコードを書く義務を持つのはコーディングした人であるべき

484 :デフォルトの名無しさん:2013/12/31(火) 04:21:03.68
>>478
>>461みたいな事をされない為にも
プログラマがテスト内容を知るべきじゃない

485 :デフォルトの名無しさん:2013/12/31(火) 04:21:56.52
>>483
テストの人に回す前にコーディングした人がテストをするのはいいとして

テストの人は、どんなテストをするのですか?
テストコードを書くのですか?

486 :デフォルトの名無しさん:2013/12/31(火) 04:22:25.04
コードレビューを行っても
コードが正しいとは限らないし、
コードの質が悪いこともある。

結局のところ、テストコードを通さないと
客観的に示せるモノが何も無い。

487 :デフォルトの名無しさん:2013/12/31(火) 04:22:51.64
勝手にテストまでされちゃ工数の計算が狂うんですけど・・・

488 :デフォルトの名無しさん:2013/12/31(火) 04:23:13.47
なんか仕事したくないだけのやつがいるな

489 :デフォルトの名無しさん:2013/12/31(火) 04:24:40.47
TESTを言葉通りに解釈するのであれば、本人は内容を知るべきでありません
内容を知っていいのはCHECKです

490 :デフォルトの名無しさん:2013/12/31(火) 04:25:01.38
プログラマが十分にテストをした場合
テスターって何か仕事あるの?

そもそもテスト駆動だったら、テストの内容なんて誰がやっても一緒じゃないの?

491 :デフォルトの名無しさん:2013/12/31(火) 04:26:27.06
ブラックボックステストはプログラマーだけじゃ意味ない

492 :デフォルトの名無しさん:2013/12/31(火) 04:26:34.09
>>485
コーダーのテストをテスター1がします
テスター1のテストをテスト2がします
テスト2のテストをコーダーがします

493 :デフォルトの名無しさん:2013/12/31(火) 04:27:18.56
>>485
ブラックボックステスト
コーディングした人が盲点にしてる事項を指摘すること
プログラマのテストの手続きを確認すること

例えば、xUnitのようなテストコードを書いてテストするのは、テスターではなくプログラマの仕事

494 :デフォルトの名無しさん:2013/12/31(火) 04:28:30.53
コーディング前にテストはすでに作成済みなんだろ?
だったらテストなんて誰がやっても同じじゃないのか?

495 :デフォルトの名無しさん:2013/12/31(火) 04:29:07.05
> プログラマがテスト内容を知るべきじゃない
え? テストって仕様だぞ。

仕様を知らないでどうやってコード書くんだ?

496 :デフォルトの名無しさん:2013/12/31(火) 04:30:29.37
俗にいうモンキーテストやなw<テストコードを知らない

497 :デフォルトの名無しさん:2013/12/31(火) 04:30:39.79
イイエ違います
そもそもテストが必要になるのはミスをするからです
ミスを前提に作業するのはプロとしてあるまじき行為
テストに頼るからミスがなくならないのです
テストをしないのが正解です
一球入魂です

498 :デフォルトの名無しさん:2013/12/31(火) 04:31:09.74
>>495
仕様をどのように確認するかは知らなくても書けるだろ

例えばテストが
入力 1, 2 出力 3
だった場合に
return 3なんてコードかかれないようにする為にはテスト内容は非公開にするべき

499 :デフォルトの名無しさん:2013/12/31(火) 04:31:10.21
>>493
テストコードはプログラマが書くか否か

テストコードはコードを書いた人と違う人が書くべき

テスターは何をするの? ブラックボックステストをする

じゃあテストコードは誰が書くの?

コードを書いた人が書く

ようするに?

コードを書いた人と同じ人がテストコードを書く

500 :デフォルトの名無しさん:2013/12/31(火) 04:31:48.73
>>496
プログラマは猿だと書いたはずです

501 :デフォルトの名無しさん:2013/12/31(火) 04:32:13.21
>>490
プログラマは、「プログラマ本人が」「時間の許す限り」十分にテストする
テスターは、プログラマ本人では(ソースを見つづけた先入観や経験や環境やツール的に)できないテストや、プログラマが時間の都合でできないテストをする

502 :デフォルトの名無しさん:2013/12/31(火) 04:34:04.33
というかね、大真面目に書けば社の方針に従えよ。
自分の主義主張で仕事するなよ。
社の方針を変えたいなら社内で議論を尽くせばいい。

503 :デフォルトの名無しさん:2013/12/31(火) 04:35:57.85
こんなとこで議論してるのは、ニート、無職、趣味、派遣。
そういうこと。

504 :デフォルトの名無しさん:2013/12/31(火) 04:37:41.64
>>502
ここって、出社して1時間で他の人が5時までかかる仕事が終了する人たちのスレでしょ?
社の方針がどうであっても、テストくらい書けばいいんじゃね?
バグが少なくなる分には文句言わないだろうし

505 :デフォルトの名無しさん:2013/12/31(火) 04:37:52.60
自分で自分のことを語って
自分で納得していれば良い。

506 :デフォルトの名無しさん:2013/12/31(火) 04:38:20.56
>>501
時間の許す限りってのがうさんくさい
やるならとことんやるべきで、適当なことをするぐらいならはやく次のコードにとりかかって欲しい
ここがうさんくさいから、プログラマ本人ではできないテストってのがさらにうさんくさく見える

>>502
いま社の方針を決めてるからパートナーさんは黙ってて

507 :デフォルトの名無しさん:2013/12/31(火) 04:43:58.51
>>505
俺は趣味でプログラムしてるからいいんだよ。
そもそも自分の職種関連の板なんていかないよ。
覗いたことはあるよ。
でも仕事でやってる人は一人もいない。
どうやったらなれますか?とかそういうスレばかりだよ。
そんなもんだって。
だいたい、自分の仕事を赤の他人に聞いてどうすんの。
自分が尋ねられたら答えるの?
答えられる程度のことなんて、職業でやってる人が尋ねてくるわけないでしょ。
職業でやってれば答えられない部分は分かっているんだし、答えられる部分は
質問などする必要が無い。
そういう仕組み。

508 :デフォルトの名無しさん:2013/12/31(火) 04:44:47.34
>>506
とことんやると、二分探索でも30年かかるけど

509 :デフォルトの名無しさん:2013/12/31(火) 04:52:17.78
>>508
なぜとことん=全探索になるんだよw

510 :デフォルトの名無しさん:2013/12/31(火) 04:53:03.27
>>508
この場合のとことんっていうのはテスターがやるのと同程度の意味

511 :デフォルトの名無しさん:2013/12/31(火) 04:54:30.92
IT系はわりとオープンな議論で業界全体が発展してきたんだから
別に隠さなくていいんだよ

512 :デフォルトの名無しさん:2013/12/31(火) 06:20:20.71
あれ?みんな黙っちゃった?
本当のこと書いちゃダメなルールだった?

513 :デフォルトの名無しさん:2013/12/31(火) 07:12:32.59
趣味に逃げちゃった人ね。新橋のガード下の安酒場で、くだ巻いていれば
いいのに。飲みにいく金もないか?

514 :デフォルトの名無しさん:2013/12/31(火) 07:16:11.62
逃げるも糞も職業プログラマなんていまどき選択するバカ居ないでしょ。
色々やらかして選択肢が減っていって最後に落ちるとこがプログラマ。
本人の意思と無関係にやってるんだと思うよ。

515 :デフォルトの名無しさん:2013/12/31(火) 07:22:36.79
匿名で情報発信するメリットってないし、そういう場所では得るものもないわけでしょ。
職業でやっている以上、何か出すなら何か得ないといけないわけだから
意見を述べるにしてもSNSやブログ、マイクロブログの類になるはずなんだよね。
匿名はあり得ない。
だいたい、このスレや上下のスレ見てごらんよ。
これ、職業でやってる人の書き込み?
ちょっとレベル低すぎない?
明らかに趣味でこれから入門しようって感じの書き込み。
しかもそんなに本気出してない。
ぱらぱらと雑誌めくる感じのレベルだよね。
ほとんどは無職だと思う。

516 :デフォルトの名無しさん:2013/12/31(火) 07:24:00.21
で、井の中の蛙君は、これまでいったいどんな世界を見て、どんな職業に
逃げたのかね? 流行の人売業とかか?

元甲子園球児(でも万年ベンチ組)が、メジャー野球を語っているように
見えて仕方ないよ。

517 :デフォルトの名無しさん:2013/12/31(火) 07:45:49.16
ム板は本質的にアマチュアの板。
派遣はマ板。
職業人なら会社職業学問理系だろ?
でも、特定できるような突っ込んだ話は出来ないんだからほとんど意味はない。
だから二チャンネルでは野球の話とかするわけ。
仕事の話なんかしない。
あたりまえだろ?仕事の相談なら同僚や上司とすればいい。
わざわざ二チャンネルでするわけない。

518 :デフォルトの名無しさん:2013/12/31(火) 07:49:20.93
まあそのクローズドな思考が欧米とのレベルの差なワケだけどね

519 :デフォルトの名無しさん:2013/12/31(火) 07:50:01.71
ピエール、日本語うまくなったな。

520 :デフォルトの名無しさん:2013/12/31(火) 07:50:24.84
つまり、ム板以外でなら
同僚や上司とすべき仕事の相談を
2ちゃんねるでやってるってこと?

521 :デフォルトの名無しさん:2013/12/31(火) 07:54:38.36
いいや?
野球の話とかだろ。

522 :デフォルトの名無しさん:2013/12/31(火) 07:58:02.43
通りで俺以外アマチュアな発言が多いと思った
なんか机上の空論ばかりなんだよ。

テストなんて完璧は無理だし
テスト駆動も同様。
最終的には技術力がものをいう。
何をするには技術がいるからね。

523 :デフォルトの名無しさん:2013/12/31(火) 07:58:42.59
>>522
納得できましたか。

524 :デフォルトの名無しさん:2013/12/31(火) 09:36:35.58
ドカタのレベルが良く分かるスレですね

525 :デフォルトの名無しさん:2013/12/31(火) 09:37:44.15
ドカタ以外にプログラム書ける奴がいないのが日本の問題

526 :デフォルトの名無しさん:2013/12/31(火) 10:26:45.60
水島新司新連載「ドカタアドベンチャー」

527 :デフォルトの名無しさん:2013/12/31(火) 10:47:50.60
人売りや、自称優秀な正社員や公務員という、ドカタという宿主なしに生き
られない寄生虫の数の方が増えてしまったのが今の日本。

能力では敵わないから、ドカタと言って蔑むのが精一杯。所詮寄生虫だから、
工場閉鎖のパナソニックみたいに、宿木がなくなると死ぬしかない。

モノづくり脱却で、金融立国とか言う馬鹿を見かけるが、金融システムは
誰が作るというんだ?

インドやベトナム、中国みたいな新興国だけでなく、アメリカだって、今も
プログラマの希望は多いし、金銭的・社会的な評価も高い。

528 :デフォルトの名無しさん:2013/12/31(火) 11:06:53.68
>>527
>金融システムは誰が作るというんだ?
所詮、生産活動があっての金融、だと思うのだが

529 :デフォルトの名無しさん:2013/12/31(火) 11:08:31.59
金融って生産活動なしにやるものじゃないの?

530 :デフォルトの名無しさん:2013/12/31(火) 11:10:59.56
新興国のモノづくりをドカタ化して上前をはねるのが金融立国だよ

531 :デフォルトの名無しさん:2013/12/31(火) 11:11:43.54
それって、いまやってることじゃないの?

532 :デフォルトの名無しさん:2013/12/31(火) 11:13:32.62
>>522
この世界ほど技術力とかいう漠然としたバズワードなんて存在しないよ

533 :デフォルトの名無しさん:2013/12/31(火) 11:14:40.23
バズワードの前に日本語を学べ

534 :デフォルトの名無しさん:2013/12/31(火) 11:17:17.74
英語か中国語でも覚えた方が楽なのに、なんでプログラム言語なんて覚えたの?
ねぇ、今のどんな気持ち?どんな気持ち?

535 :デフォルトの名無しさん:2013/12/31(火) 11:19:48.04
覚えられる枠が1つしかないというのに重大な選択の誤りだな

536 :デフォルトの名無しさん:2013/12/31(火) 13:56:40.31
テストコードの必要性を理解できないのは
そもそもオブジェクト指向が理解できていないからではないか

手続き思考を引きずったままであることの表れではないか

537 :デフォルトの名無しさん:2013/12/31(火) 14:12:12.10
誰かテストコードが必要じゃないといっていたやつなんかいるか?

テストコードは万能ではない。
テストコードはバグがないことを証明しない
テストに通ってもコードが完成しているとは限らない
テスト駆動はできないか困難な場合がある。

内容としてはこんな所だろ。

538 :デフォルトの名無しさん:2013/12/31(火) 14:43:27.86
テストコードは万能じゃないという当たり前のことを
長々と書き込み続ける馬鹿は居たけど、
テスト駆動が困難な理由を説明できた奴が居ない件

539 :デフォルトの名無しさん:2013/12/31(火) 14:52:16.25
面倒だし時間食う(ドヤ顔)

540 :デフォルトの名無しさん:2013/12/31(火) 15:59:33.37
間違った教育システムのお蔭で、社会人に成ってからも、テスト=得点競争だと勘違いしてるのが多いからな。
肝心のロジックに集中出来るようにする為に、瑣末なミスは自動的に発覚させるのが本来のテスト。

541 :デフォルトの名無しさん:2013/12/31(火) 16:46:27.29
>>538
30 名前:デフォルトの名無しさん[sage] 投稿日:2013/12/23(月) 21:01:15.80
誰もユニットテストがだめとは言ってないんだよ。
テスト"駆動"がだめという話。

テストはアプリを正しく作る上で必須のものではない。
省略しても正しく動くアプリは作れる。

だけどテスト駆動開発だと、テストを最初に書かないといけない。
これが大きなネックになる。

テスト駆動はコードの書き方の一つ
一つの開発の中で、この関数(クラス)はテスト駆動で作ったが
こっちはテストそのものがないみたいに、バランスよく使うもの

542 :デフォルトの名無しさん:2013/12/31(火) 17:23:38.11
全ての関数にテストを書くなんて制約が
テスト駆動にあったっけ?

543 :デフォルトの名無しさん:2014/01/01(水) 06:48:13.03
テストしなければならないということは、バグを埋め込む前提があるから
バグを埋め込んではいけない、子供でも知っている理屈
それがわかっていないからテストが必要になる
本来は必要ない

544 :デフォルトの名無しさん:2014/01/01(水) 07:10:57.61
テストより教育に工数をかけたほうが質はあがる

545 :デフォルトの名無しさん:2014/01/01(水) 09:01:10.83
>>543
こんなところでほざいても何もかわらないわんだけどねw

546 :デフォルトの名無しさん:2014/01/01(水) 09:33:29.96
本来顧客の立場からすれば、テスト駆動開発かどうか、どんなテストを
実施したかどころか、どんな言語で開発したかさえ、最終的に納品した
プログラムが不具合なく動けば問題ないはずなんだけどね。

実際には、まともな仕様もかけない、そもそも開発能力すらもない、
発注元の担当者や、中間会社が、言語やフレームワーク、開発手法
から、箸の上げ下げに至るまで口出しするからグダグダになる。

547 :デフォルトの名無しさん:2014/01/01(水) 09:46:03.62
>>541(=>>30)
なんでテストを最初に書くのが大きなネックになるんだ?
全く理由が書かれていないんだが。

548 :デフォルトの名無しさん:2014/01/01(水) 09:58:14.26
>>546
顧客囲い込みの為にマイナー言語で開発する奴もいるから
ある程度は他社に引き継げる程度にメジャーな言語でやってもらわないと困る

549 :デフォルトの名無しさん:2014/01/01(水) 10:01:48.80
テスト駆動がやりやすくなるような開発環境って整ってるの?

550 :デフォルトの名無しさん:2014/01/01(水) 10:04:58.52
テスト駆動を調べるほど、俺が普段やってる開発スタイルに似ている事に気づいた。
つまり、言語やライブラリに対しての知識がない場合にひとつずつ動作を確認してコードを拡張していく方法だ。
俺だけじゃなくて素人のほとんどは少し書いては実行して動作を確認しているだろう。

おまえら、自分がやってる方法にもっともらしい理由をつけてるだけじゃねーの?

551 :デフォルトの名無しさん:2014/01/01(水) 10:14:26.15
動作の確認を手動でやるのと
コードを書いて自動でやれるようにするのとは
全然違いますから

552 :デフォルトの名無しさん:2014/01/01(水) 10:23:14.05
>>543
この世に、他人に見せたときにバグがなかったアプリケーションが TeX 以外にあったら見てみたい

553 :デフォルトの名無しさん:2014/01/01(水) 10:34:52.96
テストは、コーディングの「すべての段階で」あるレベルのコードの正しさ確認し保つモノである

554 :デフォルトの名無しさん:2014/01/01(水) 10:37:50.00
C#の入門書とテスト駆動開発の本(どちらも洋書)持ってるけど、C#もVisual Studioもバージョンが古いやつでやらないといけないから、英語にエネルギー注いで学習する意欲が湧かない。

本のなかのVisual Studioも手持ちのVSも2010でそこだけ都合が良いのだが。

555 :デフォルトの名無しさん:2014/01/01(水) 10:41:03.12
妄想のなかで架空の人や実在の人と脳内会話するのが好きな寂しがり屋にとっては、テストとコードで対話させるのは楽しいかもしれない。

556 :デフォルトの名無しさん:2014/01/01(水) 10:42:24.81
>>551
テスト駆動の話だよね
リテラルを引数に突っ込んで戻り値をprintfするような事もテストに含まれるぞ
ひょっとしてテストファーストを勘違いしてないか?

557 :デフォルトの名無しさん:2014/01/01(水) 10:42:29.03
バグは寂しがり屋が嫌いだからな…

558 :デフォルトの名無しさん:2014/01/01(水) 10:46:27.63
>>556
それをテストと呼ぶのはドカタ界隈だけ

559 :デフォルトの名無しさん:2014/01/01(水) 10:53:40.78
外延表記か内包表記かの違いでしかない
内包表記にしたって、ランダムにリテラル生成して突っ込んでるだけだし

560 :デフォルトの名無しさん:2014/01/01(水) 12:11:44.77
>>558
それをテストと言わなければなんて呼んでるんだ?

561 :デフォルトの名無しさん:2014/01/01(水) 12:40:23.68
>>560
金をもらうためのレスにマジレスしても意味ないぞw

562 :デフォルトの名無しさん:2014/01/01(水) 12:52:15.24
ドカタチェック

563 :デフォルトの名無しさん:2014/01/01(水) 15:26:08.11
派遣チェック

564 :デフォルトの名無しさん:2014/01/01(水) 15:48:37.05
>>556
printfデバッグ

565 :デフォルトの名無しさん:2014/01/01(水) 16:59:23.83
デバッグは違うんじゃないかと思うが

566 :デフォルトの名無しさん:2014/01/01(水) 17:00:55.01
一文字一文字気持ちを込めて打ち込めばテストなんて必要ありません。
やる気の問題です。

567 :デフォルトの名無しさん:2014/01/01(水) 17:36:09.94
この世でやる気を出すことができるプログラマはクヌース先生だけだったということか…

568 :デフォルトの名無しさん:2014/01/01(水) 17:54:36.56
デバッグにテスト作業が含まれていないとでも?

テストだけやってデバッグ(Bug Fix)しないと、JR北海道の脱線事故みたいに
なる。挙句、テスト結果の記録を捏造して帳尻合わせ&口裏あわせ。

569 :デフォルトの名無しさん:2014/01/01(水) 18:06:55.36
>>568
駆除すべきバグはどうやって見つけるのですか?

570 :デフォルトの名無しさん:2014/01/01(水) 18:14:23.66
レビューで見つけられませんか?
だとするとあなたは能力が低すぎる。

571 :デフォルトの名無しさん:2014/01/01(水) 18:14:29.07
テスト駆動って、ようするにテストを書くのもコード書きの一部になるだけの話で、
本来の意味でのテストとはかけ離れたものになっちゃうんだよな。
そのテストケースに含まれてない部分がバグの発生源になるだけの話。
テストケースを書く労力をコードに向けるのと、結局何も変わらない。

572 :デフォルトの名無しさん:2014/01/01(水) 18:17:25.43
>>570
つまり、納品後にバグが見つからなかったアプリケーションがこの世に存在するということですね
TeX以外に

573 :デフォルトの名無しさん:2014/01/01(水) 18:21:03.26
一球入魂です。

574 :デフォルトの名無しさん:2014/01/01(水) 18:36:31.14
>>569
デバッグはテスト作業を含んでいる。テストなしのデバッグは存在しない。

575 :デフォルトの名無しさん:2014/01/01(水) 18:39:37.61
TeXにバグがないと誰が証明したの? バグではなく不適切なプログラムです
とか、そういう日本人的言い訳か?

576 :デフォルトの名無しさん:2014/01/01(水) 18:39:40.59
テストは甘えだと思います。
間違ってもいいと思っているからテストをするのです。
甘えるのも大概にしたほうが良い。

577 :デフォルトの名無しさん:2014/01/01(水) 18:42:35.47
>>575
作者自身が、「バグが見つかったら賞金を出す」と宣言してる
こんなアプリケーションが他にあるなら挙げてほしい

578 :デフォルトの名無しさん:2014/01/01(水) 18:44:15.28
派遣を全部切ればバグは無くなる。

579 :デフォルトの名無しさん:2014/01/01(水) 18:45:18.40
甘えというか予防線でしょ。まぁ、能力低い開発会社が、バグが出ても、
テストツールでは見つからなかったと言い訳するのに都合がいい。

依頼主はバグのないプログラムを頼んだのであって、テストツールを使って
くれとは頼んでいないだろうけど。

経験上、本気でテストツール使い始めると、テストツールのデバッグに付き
合わされるハメになるのがオチ。

大昔、ソフィアのICEを繋ぐとボードが動かないとかあったのを思い出すわ。

580 :デフォルトの名無しさん:2014/01/01(水) 18:46:15.34
原発ですら爆発したのに…

581 :デフォルトの名無しさん:2014/01/01(水) 18:46:48.84
>>577
どうせ、はした金でしょ。 その手の宣伝行為は暗号化ツールでもやってるよ。

582 :デフォルトの名無しさん:2014/01/01(水) 18:52:21.06
テストとモックだけ書いてコミットしてくる奴なんなん?

583 :デフォルトの名無しさん:2014/01/01(水) 18:53:13.28
金額の問題ではなく、自分の書いたアプリに対してバグがないと断言できるプログラマがいったい何人いるのかという話です

584 :デフォルトの名無しさん:2014/01/01(水) 19:03:04.69
単に注目されたい自意識過剰なヤツってだけでしょ。バグの有無の証明
とは無関係。

585 :デフォルトの名無しさん:2014/01/01(水) 19:07:57.78
>>584
ということは、あなたは「自分のコードの中にバグがあったら給料いりません」と言えるわけか…

586 :デフォルトの名無しさん:2014/01/01(水) 19:11:56.87
日ごろから言ってますが?
あなたは言えないのですか?

587 :デフォルトの名無しさん:2014/01/01(水) 19:16:49.47
禅の心です。

588 :デフォルトの名無しさん:2014/01/01(水) 19:25:30.56
>>586
ニートだからそもそも給料もらってないだろ

589 :デフォルトの名無しさん:2014/01/01(水) 19:30:58.95
テストってマルチスレッドでも機能するのかな?
昔はソース持ってきてビルドする時にテストスクリプトが
走って正規のデータとdiff取るようなのもあったけど
今はマルチスレッドが当たり前だしテストが通っても
OKとは判断できなくなってる気がするんだが
あとコードの網羅度が指数関数的になるGUIプログラムとかは
自動テストは不可能だよね

590 :デフォルトの名無しさん:2014/01/01(水) 19:45:17.06
>>589
Web系だと自動でリンククリックしてくれるテスト用アプリがある

591 :デフォルトの名無しさん:2014/01/01(水) 20:33:41.87
>>576
そうですね。
リリースした以上、バグがあることはありえません。
すべて仕様ですから。

592 :デフォルトの名無しさん:2014/01/01(水) 20:40:44.69
仕様のバグを見つける気がないとか…

593 :18:2014/01/01(水) 20:57:18.78
>>577
バグ見つかってるでしょ。
今のバージョンは 3.1415926 だよ。
http://www.ctan.org/pkg/tex

594 :デフォルトの名無しさん:2014/01/01(水) 20:57:47.71
>>571
コミットする毎にテスターさんがテストしてくれるような
お金がたくさんあるプロジェクトはいいですね。

595 :デフォルトの名無しさん:2014/01/01(水) 21:03:09.86
>>579
テストツール使わないでくれと頼んだ覚えもないんだが。

596 :デフォルトの名無しさん:2014/01/01(水) 21:03:30.38
>>593
クヌース先生が「バグが見つけたら賞金出す」と自信満々でドヤ顔で宣言したのに、それでも見つかったということですよ

597 :デフォルトの名無しさん:2014/01/01(水) 21:07:32.57
>>579
まともなテストツールすら書けないのを棚に上げといて、
テストツール使うのをdisるのはよくないなー

598 :デフォルトの名無しさん:2014/01/01(水) 21:08:29.35
テストファーストってそもそもメッセージの出入り口くらいでしょ
それ以外のことがテストファーストでできないとかほざいても仕方ない
テストツールなんもつかわず学生に5000えんずつ渡してボタン連打
させてるとこより全然幸せな仕事してるよ

599 :18:2014/01/01(水) 21:51:19.59
>>596
いや、そんなことはわかってるんだが...
アンカーつけられたのが気にくわないなら >>572 に変更するよ。

600 :デフォルトの名無しさん:2014/01/01(水) 21:55:50.01
納品後にバグが見つからなかったアプリケーションの例はまだか

601 :18:2014/01/01(水) 22:07:15.57
>>600
俺が納入した保守ソフトは納入後バグ見つからないまま廃棄されたよ。
ほとんど使われなかったけど (w
そう言うソフトは珍しくないだろ。

602 :デフォルトの名無しさん:2014/01/01(水) 22:07:24.39
テストは甘えです。
一文字一文字心を込めて打てばテストなんて必要ありません。

603 :デフォルトの名無しさん:2014/01/01(水) 22:10:51.85
>>601
「使われないモノを開発した」というバグは無視か…

604 :デフォルトの名無しさん:2014/01/01(水) 22:24:40.44
テスト駆動は実用的問題で使える場面が限られてるから
汎用性の高い他の手法に流れるんだろ
やることわかってるならテスト駆動は楽

605 :デフォルトの名無しさん:2014/01/01(水) 22:28:22.99
テスト駆動って小さく作ってテストしてOKだったら大きくしていくって手法だよ
ただ、最初にテストを作ってそれに対していきなり完成した関数やメソッドなりを作ると思ってるなら間違い
テストはどんどん成長していくし、コードも成長していく

606 :デフォルトの名無しさん:2014/01/01(水) 22:28:39.95
手法にこだわるより派遣を全部切るほうがバグなくなる。
派遣は能力が低いというのもあるけど、心構えがまず違う。
派遣切りは大きな成果があるので「派遣切り」という言葉ができるくらい
一般に行われてる。

607 :デフォルトの名無しさん:2014/01/01(水) 22:33:32.77
派遣がいてもOKなシステムと、派遣がいたら回らないシステム
どちらがよいシステムでしょうか

608 :18:2014/01/01(水) 22:34:00.67
>>603
何を言いたいのかさっぱりわからんが、悔しさだけは伝わった (w

609 :デフォルトの名無しさん:2014/01/01(水) 22:35:58.58
>>608
このスレみてると最初に仕様を決めて、それに対応したテストを作ってそれからコーディングって流れになってるだろ?
それはテスト駆動じゃないよ

610 :デフォルトの名無しさん:2014/01/01(水) 22:35:59.40
そもそも必要がない上にミスが多くて使い勝手が悪くて廃棄されたモノをバグがないと表現するスレです

611 :デフォルトの名無しさん:2014/01/01(水) 22:37:08.61
派遣がいたら回らないシステムのほうが良いです。
派遣はバグの元です。
派遣がいないことを保証できる分、派遣がいたら回らないシステムのほうが有利です。

612 :デフォルトの名無しさん:2014/01/01(水) 22:37:46.52
>>607
派遣かどうかでシステムが動いたり動かなかったりするわけないだろ
バカじゃないの

613 :デフォルトの名無しさん:2014/01/01(水) 22:39:30.87
空港のゲートで派遣がチェックできればいいのにな。

614 :デフォルトの名無しさん:2014/01/01(水) 22:39:55.79
バグの元がいてもバグを少なくできるシステムと、バグの元がいたら回らないシステム
どちらがよいシステムでしょうか

615 :デフォルトの名無しさん:2014/01/01(水) 22:40:23.22
>>613
入り口が派遣かどうかでわかれてる所ならあるよ

616 :デフォルトの名無しさん:2014/01/01(水) 22:41:21.79
バグの元がいたら回らないシステムのほうが良いに決まってるだろ。
お前無職だろ。
社会に出れば、その程度の常識すぐ身に付く。

617 :デフォルトの名無しさん:2014/01/01(水) 22:44:39.81
>>616
パワーポイントのプレゼン資料をコンパイルして機械語を出力できると思ってた上司を思い出した

618 :デフォルトの名無しさん:2014/01/01(水) 22:59:39.70
やたら派遣と書いているのは、決裁権のない底辺プロパー社員か何かかね?

勝手に派遣が入ってくるのではなく、派遣会社に依頼して、しかも違法な事前
面接までやって採用決めているんでないの? それとも、派遣に逃げられて
恨み節か?

たとえ決済権がなくても、上司に掛け合ってプロパーだけでプロジェクトを
回せばいいのに。

619 :18:2014/01/01(水) 23:02:44.47
>>609
だからなに?
ますます意味不なんだが。

>>610
単なる煽りだろうけど...
保守って書いてあるでしょ?
装置にトラブルないと使われないのよ。この前のやつも、10年程度の間に使われたの3回だけだし。
しかも、教育受けた保守員が保守マニュアルに従って使うからイレギュラーな事態がほとんど発生しない。
バグはあるとは思うけど、見つからないわな。

620 :デフォルトの名無しさん:2014/01/01(水) 23:33:49.52
>>618
派遣が蔑まれるのは仕方ないんじゃないの?

621 :デフォルトの名無しさん:2014/01/02(木) 00:21:39.20
派遣は二等国民という時代が来るよ

622 :デフォルトの名無しさん:2014/01/02(木) 01:05:07.25
正社員の面接でも、必ず他社の人間が立ち会う
そこで他社の人間が、使うと言えば、採用される

なぜそうするかというと、
雇ったけど、社内でブラブラされると、
月給30万円がただ損になるから

雇ってすぐ、月100万円で他社へ出向させれば、
100-30=70万円の得

企業は簡単にもうけることしか、考えてない
わけのわからない企業に、もうけられるのがイヤなら、
信用できる仲間を集めるか、自分で起業すればよい

623 :デフォルトの名無しさん:2014/01/02(木) 01:23:48.69
プログラマって大変なんだな
日本の法律が適用されない
選挙権や厚生年金、共済ちゃんとあるの?
心配になっちゃうわ

624 :デフォルトの名無しさん:2014/01/02(木) 01:35:10.20
Microsoftの開発はテストと開発は1:1なんだぞ
テストはどう考えたって必要だろうが

625 :デフォルトの名無しさん:2014/01/02(木) 01:36:52.79
>>620
大半は偽装請負だからな。

626 :デフォルトの名無しさん:2014/01/02(木) 01:38:21.21
偽装請負ってよく聞くけどどういうやつ?

627 :デフォルトの名無しさん:2014/01/02(木) 01:42:50.93
>>623
僕の夢は自動コーディング技術を究極までつきつめて、プログラマを労働から解放することです

628 :デフォルトの名無しさん:2014/01/02(木) 01:44:30.18
プログラマは労働から解放してあげるべきだよな
もう十分だ
全ての辛いことから解放してあげるべき

629 :デフォルトの名無しさん:2014/01/02(木) 01:54:23.20
>>623
選挙権はあるよ
社会保険はどうかな
でも君が日本の国籍をもらうより簡単

630 :デフォルトの名無しさん:2014/01/02(木) 02:02:28.14
職業プログラマのみなさんには、今作ってるモノよりももっとバグの少ないモノが次の年に無料でネットでUPされる経験を積み重ねてほしい

631 :デフォルトの名無しさん:2014/01/02(木) 02:07:50.42
>>630
天才

632 :デフォルトの名無しさん:2014/01/02(木) 02:35:04.42
自分のコードのテストは書きたくないが、他人のコードはありとあらゆるテストを書いて徹底的にデバッグするのが趣味です

633 :デフォルトの名無しさん:2014/01/02(木) 05:01:08.04
最初にテストを書くということは、コードを書く前からバグを仕込む気があるということ。
つまり、計画犯罪。
ミスではない。

634 :デフォルトの名無しさん:2014/01/02(木) 05:47:06.74
ソースコードを公開したバグだらけのSoftwareを書いて募金でも募った方が楽しい人生だな

635 :デフォルトの名無しさん:2014/01/02(木) 06:54:31.78
ソフトウェアを書いて幸せになれるわけないだろ

636 :デフォルトの名無しさん:2014/01/02(木) 07:16:38.08
希望という名の大衆向け合法麻薬を作るんだよ
皆、最高にハイになって幸せそうにするぜ

637 :デフォルトの名無しさん:2014/01/02(木) 14:18:12.95
>>629
彼がもし外国人だとして
3年日本に住めば国籍もらえるよ
永住許可でもせいぜい5年

638 :デフォルトの名無しさん:2014/01/02(木) 15:31:26.66
プログラマって犬以下じゃないの?犬ならまだ家族や寝る場所があるのにさ

639 :デフォルトの名無しさん:2014/01/02(木) 15:49:37.27
メリットデメリットがあるのに
品質向上に効果がある=絶対採用する
という一原論でしか考えられない
頭が硬直した人間は手に負えない

640 :デフォルトの名無しさん:2014/01/02(木) 16:38:14.16
ネットカフェ難民ってやつか。
ユニセフがやってきそう。

641 :デフォルトの名無しさん:2014/01/02(木) 16:45:34.32
プログラマは客先の担当にお手と言われたらワンと言ってお手しないといけないんだぞ。
良くやるといつも感心する。

642 :デフォルトの名無しさん:2014/01/02(木) 16:47:06.10
バグによってどんどん立場が悪くなる。
テストなんてやってる場合じゃない。

643 :デフォルトの名無しさん:2014/01/02(木) 17:23:03.91
>>640
グリーンピースやシーシェパードが暴れてくれる方に期待するよ

644 :デフォルトの名無しさん:2014/01/02(木) 20:09:40.14
テスト駆動になにかデメリットあったっけ?

645 :デフォルトの名無しさん:2014/01/02(木) 20:46:28.83
五時で帰れなくなること。

646 :デフォルトの名無しさん:2014/01/02(木) 20:46:33.84
そもそもメリットある? 費用対効果も担保されていないし。
テスト駆動でバグセロとか、ほとんどツール屋のステマでしょ。

647 :デフォルトの名無しさん:2014/01/02(木) 21:56:40.56
>>645
その日の仕事が出社して30分で終わる人はやる価値があるってことか…

648 :デフォルトの名無しさん:2014/01/02(木) 22:05:45.08
>>646
希望的観測としては手戻りが減るんじゃないかと思うんだがどうなんだろうな

649 :デフォルトの名無しさん:2014/01/02(木) 22:09:28.29
>>646
可能な限りバグを少なくするのが目的だから、バグゼロを目指すなら別の開発手法を試した方がいいと思う
念力駆動とか

650 :デフォルトの名無しさん:2014/01/02(木) 22:26:25.62
テストはバグを組み込む前提でやるものだろ?
バグを組み込む気が無ければテストは必要ない。
つまり、テストをしている限りバグは無くならない。
テストは撤廃するべき。

651 :デフォルトの名無しさん:2014/01/02(木) 22:31:54.72
>>650
ぜひテスト不要教でも設立して下さい

652 :デフォルトの名無しさん:2014/01/02(木) 22:34:44.05
>>650
画面を2回以上スクロールする量をコーディングしてバグが一つもなければ拍手
そういう人達が来る板だから、あなたは宗教板へ行った方がいいと思われる

653 :デフォルトの名無しさん:2014/01/02(木) 22:47:27.17
一球入魂です。

654 :デフォルトの名無しさん:2014/01/02(木) 22:55:16.70
遊びの心で給料もらいたいのでテスト駆動開発やります

655 :デフォルトの名無しさん:2014/01/02(木) 23:15:16.98
つまり、ニートですか。

656 :デフォルトの名無しさん:2014/01/02(木) 23:26:43.19
限りなくゼロに近いやる気と責任感でバグの少ないソフトウェアを作ってみんなを失業させたい
そのためにはテスト駆動開発が必要なのです

657 :デフォルトの名無しさん:2014/01/02(木) 23:35:12.71
TDDはニートのおもちゃ。

658 :デフォルトの名無しさん:2014/01/02(木) 23:45:16.09
おもちゃで職業プログラマを駆逐するからこそ楽しい

659 :デフォルトの名無しさん:2014/01/03(金) 00:20:40.98
ソフトウェアのテストは、正しく動くことを確認するために行う場合と、バグを見つけるために行う場合の、2つのアプローチがある。
正しく動くことを確認するアプローチでは、まず、確認すべき正しい『結果』を定める。結果指向のテストである。
これに対して、バグを見つけるためのテストでは、どのようなバグを見つけられるかを、予め定めておくことはできない。
「テスト項目」は、バグを見つけるためのテストに適さない

http://www.aerith.net/design/test_bug-j.html

660 :デフォルトの名無しさん:2014/01/03(金) 00:21:32.73
>>659
ステマ乙。

661 :デフォルトの名無しさん:2014/01/03(金) 01:58:36.03
>>659
実は、どのようなバグを見つけられるかは、ある程度は分かっている
例えば、それをセマンティクスを無視して検出する古典的ツールが lint

現実の開発では、はじめからまったく予想もできなかったバグはごくごく少数
ほとんどのバグは隣で「これ」と言われたら、バグを入れた本人ですら「あっ」と即理解できるバグ

問題は、そのシンプルなミスが広大なコードの中に薄く混入しているという点

662 :デフォルトの名無しさん:2014/01/03(金) 02:06:59.10
だからこそ一球入魂です。

663 :デフォルトの名無しさん:2014/01/03(金) 02:13:42.11
嘘吐いてんじゃねぇぞ。 lintは構文チェックするだけで、論理的な矛盾の
バグの検出なんかできねぇよ。 つぅか、lint程度の構文チェック機能は
最近のコンパイラなら普通に入ってる。

664 :デフォルトの名無しさん:2014/01/03(金) 02:18:37.29
>>661の時代はlintが必須だったんですよ。

665 :デフォルトの名無しさん:2014/01/03(金) 02:47:06.68
>>663
セマンティクスを無視して検出する = 論理を無視して構文だけをチェックする
ですよ

もっと言うと、実際の現場では、普通のコンパイラで -Wall でコンパイルすれば検出できてたバグがほとんど

666 :デフォルトの名無しさん:2014/01/03(金) 02:51:20.82
>>661の時代は大変だったんですよ。

667 :デフォルトの名無しさん:2014/01/03(金) 03:02:20.66
構文チェッカでは、例えば...

int a;
int n;
int table[4]={1,2,3,4};

for(n=0;n<4;n++)
{
  a=table[n];
  ...(略)
}

みたいなコードの「n<4」が「n<=4」となっていてもまず検出できない。
あとテーブルの数を増やすとループ回数と整合とれなくてバグったり。

単純な初期化処理のループなら、毎回すべての値が参照されるけど、例えば
テーブル参照してコマンドライン引数と照合するような処理の場合、仕様上は
未定義の引数を与えてテーブルの最後まで参照しないとバグが見つからない
とかある。 WindowsやLinuxみたいなメモリ保護のあるOS下であっても、要素
数を超える配列をアクセスしてもページ境界を超えなければ保護エラーには
ならない。

本来は「n<(sizeof((table)/sizeof(table[0]))」とか

#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))と定義しておいて
「n<LOOP_COUNT」とか書くべき。 でもテストツールではこういう不適切な
コーディングは検出できない。

668 :デフォルトの名無しさん:2014/01/03(金) 03:04:27.96
気合入れてコーディングしたらバグなんて1/10ぐらいにできる
それは誰でもな

ただ、1日8時間や場合によってはそれ以上の時間を気合が入った状態に保つ事は難しいし
それをしたところでメリットがないのが問題

669 :デフォルトの名無しさん:2014/01/03(金) 03:09:56.30
いいえ、0にできます。
禅の心、そして一球入魂です。

670 :デフォルトの名無しさん:2014/01/03(金) 03:11:09.98
>>667
int a[4],i;
for(i=0; i<=4; i++) { a[i] = ...}

はツールが検出して警告出してくれますよ

671 :デフォルトの名無しさん:2014/01/03(金) 03:14:21.34
気合なんて必要ないよ。

飛べる鳥で、気合入れないと飛べない鳥とかおらへんし、ヤンバルクイナとか
いくら気合入れても飛べへんで〜。

それとも、オッチャン気合入れたてら自分がイチローになれた人生があった
かもしれんと思うてるの? おるよねぇ、そういうオッチャンは安酒場に。

672 :デフォルトの名無しさん:2014/01/03(金) 03:17:24.63
>>667
そのマクロを ( ) で囲んだり関数の引数にしたりしたときに新たにバグが生まれそうな気がしてならない

673 :デフォルトの名無しさん:2014/01/03(金) 03:17:46.64
オッチャンは、禅の心と一球入魂が必要だと思うのです。
気合では1/10だと書かれていました。
禅と入魂なら0にできる。
とってもお得です。

674 :デフォルトの名無しさん:2014/01/03(金) 03:22:02.83
たしかに入魂すればバグはゼロになります
ただ残念なことに、この世には魂が存在しないんですよね…

675 :デフォルトの名無しさん:2014/01/03(金) 03:23:28.32
派遣には無理。

676 :デフォルトの名無しさん:2014/01/03(金) 06:58:30.79
>>667
> int table[4]={1,2,3,4};

バグの匂いがプンプンw

677 :18:2014/01/03(金) 08:53:47.51
char s[4] = "1234"; と勘違いしてね?

678 :デフォルトの名無しさん:2014/01/03(金) 09:05:37.14
C++なんじゃないか?
一球入魂するとC++に見えるけどな。

679 :デフォルトの名無しさん:2014/01/03(金) 09:13:05.65
禅の心で見るとPythonに見える

680 :デフォルトの名無しさん:2014/01/03(金) 09:26:19.61
開発規模やスタイルによって変わると思うけど、俺の場合だと
・最初に実装するときはテストは書かない
・バグが出たら、テストを書いて再現を確認してから直す
くらいが負担も少なくてやりやすい
TDD の最後の D が Development じゃなく Debug の略になってる感じ。

元来が完璧主義者なので、TDD でやるぞ!と意気込むと、バグなんて出すわけのないような簡単なコードまで
きっちりテストを書きたくなってしまって、結果コスト的に見合わないただの自己満足になってしまう。
(プログラマってそういう奴多くない?)
だから、それはやめて、実際にバグを出したところだけテストを書くスタイルに落ち着いた。

681 :デフォルトの名無しさん:2014/01/03(金) 09:31:46.32
ふーん。
ツールは何使ってるの?

682 :デフォルトの名無しさん:2014/01/03(金) 10:09:08.48
>>672
マクロの副作用を防ぐため、#define の定義を()で囲むのは、MISRA-Cの
必須項目だったと思うけど?

683 :デフォルトの名無しさん:2014/01/03(金) 11:14:24.49
簡潔なコードを書くにはいいかもね。テスト書く、それをパスする最小限のコードを書くの繰り返し。

684 :デフォルトの名無しさん:2014/01/03(金) 11:45:11.64
>>673
zen codingってやつかしら?

685 :デフォルトの名無しさん:2014/01/03(金) 11:52:33.83
>>682
そのカッコで囲んだモノをさらにカッコで囲むと新たにバグが生まれることがあるんすよ…

しかもなんだよ、これ↓
#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))

グローバル変数使ってるとか、tableのnullチェックやってないとか、突っ込みどころ満載なんだけど

686 :デフォルトの名無しさん:2014/01/03(金) 12:27:26.63
>>685
式ではない値を含めて#defineを全て括弧で囲っていなくて、演算子の優先順位の
関係でバグが出ることはあるが、宣言に括弧を使ってバグが出るとは初耳だなぁ。

> グローバル変数使ってるとか、tableのnullチェックやってないとか、突っ込みどころ満載なんだけど

グローバル変数? 外部ファイル等から動的に読み込むなら空配列のチェック
も必要だが、プログラム定数配列で空配列かどうかチェックする必要はない。

Cでも別に関数内部でstatic宣言して、その後に関数内部で#defineすれば
いいだけ。 C++のクラスならstaticなメンバ関数やConst型のメンバ変数、
enum値にするとか、いくらでも書き方はある。

そもそも、あくまで例を出しただけだが、馬鹿はあさっての方向にしか突っ
込みできんのだね。

687 :デフォルトの名無しさん:2014/01/03(金) 12:36:12.57
>>686
仮に、プログラム定数配列で空配列かどうかチェックする必要がないほど頑健なら、そもそもそのマクロは必要ない

688 :デフォルトの名無しさん:2014/01/03(金) 12:42:49.33
>>686
カッコの対応をよく見れ↓

#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))

これは、LOOP_COUNT) という狂った使い方をするマクロでしょ?

689 :デフォルトの名無しさん:2014/01/03(金) 12:46:00.97
書き込む前に事前にテストしてれば…

690 :デフォルトの名無しさん:2014/01/03(金) 12:54:42.80
ドヤ顔でレスしてバグ混入させて自称バグゼロの天才さんですらも気づかないんだから、やっぱり自動テストは必要だな

691 :デフォルトの名無しさん:2014/01/03(金) 12:55:12.17
マクロ云々に関してはバグ云々よりも作法だろ。
今の時代に合わなさ過ぎる。

692 :デフォルトの名無しさん:2014/01/03(金) 13:07:46.91
>>691
テンプレートプログラミングといいながら、実際はテキストを置換してバグを混入させるだけの嫌なモノがまた流行ってしまいまして…

693 :デフォルトの名無しさん:2014/01/03(金) 14:09:57.34
>>677
本質が同じということが理解できてないという時点で論外。

694 :デフォルトの名無しさん:2014/01/03(金) 14:17:21.98
>>676
> int table[4]={1,2,3,4};
> バグの匂いがプンプンw

何が変なのかさっぱりわからん。
誰か解説よろ

695 :デフォルトの名無しさん:2014/01/03(金) 14:24:46.23
>>693
えっ?

696 :デフォルトの名無しさん:2014/01/03(金) 14:25:18.90
>>694
・後で要素追加するときに、修正が2箇所にならないように int table[]={1,2,3,4}; とする
・グローバル変数で table という名前はやめれ

697 :デフォルトの名無しさん:2014/01/03(金) 14:35:44.58
>>696

> ・後で要素追加するときに、修正が2箇所にならないように int table[]={1,2,3,4}; とする
非常にくだらない。煽りではなく。

> ・グローバル変数で table という名前はやめれ
>>667を見てどうしてtableがグローバル変数と思えるのか不思議

それにどちらにしてもバグとは言えない。

698 :デフォルトの名無しさん:2014/01/03(金) 14:40:56.37
int table[]={1,2,3,4}; を int table[]={1,2,3,4,5}; に変えてもエラーにならないというだけで、
本当に要素数が5でいいのかは不明。

int table[4]={1,2,3,4}; から int table[5]={1,2,3,4,5}; に変える場合は本当に変える意思が
あると考えられるし、間違って int table[4]={1,2,3,4,5}; としてもエラーになるんだから害なし。

699 :デフォルトの名無しさん:2014/01/03(金) 14:45:13.97
>>697
tableがグローバル変数じゃなくて局所変数だというなら、その局所変数の変数名をマクロに直書きするは「バグだ」と断言していいと思う

700 :デフォルトの名無しさん:2014/01/03(金) 14:45:36.97
なるべく多くの間違いをコンパイルエラーで拾おうという考え方は賛成

701 :デフォルトの名無しさん:2014/01/03(金) 14:50:42.23
>>698
int table[6]={1,2,3,4,5}; とタイプミスしてエラーにならずに table[5] に変な制御コードが入るとか考えないの?

702 :デフォルトの名無しさん:2014/01/03(金) 15:05:25.37
>>701
> int table[6]={1,2,3,4,5}; とタイプミスしてエラーにならずに table[5] に変な制御コードが入る
そりゃ可能性はある。その上でどっちを選ぶ?って話。
俺は int table[5]={1,2,3,4,5}; を選ぶし、バグの匂いとか言うのは違うんじゃね?

703 :デフォルトの名無しさん:2014/01/03(金) 15:09:32.42
>>699
tableがグローバル変数だというなら、for 文がグローバルスコープにあることになる。バグ以前だな。

704 :デフォルトの名無しさん:2014/01/03(金) 15:10:28.57
俺は一球入魂すれば項目が100個になろうが200個になろうが間違わずに入力できるよ。

705 :デフォルトの名無しさん:2014/01/03(金) 15:15:07.55
>>702
5個で要素が順番に並んでるときは int table[5]={1,2,3,4,5}; だとしましょう
10個のときは? 50個のときは? 数値がランダムに並んでるときは?
個数に応じて脳ミソ使ってコーディングスタイルが変わるなら、それはバグの元でしょう

そもそも int table[5]; みたいに宣言時にマジックナンバーを見たらバグだと思うべきではなかろうか

706 :デフォルトの名無しさん:2014/01/03(金) 15:17:12.25
>>703
コンパイルエラーが出てないとすれば、変数宣言の後とfor文の前にmainが省略されてるんだよ

707 :デフォルトの名無しさん:2014/01/03(金) 15:18:13.52
DIのせいだろ
テスト前提でプログラムアーキテクチャまで変更しなきゃならんとなれば
(しかも可読性が下がる方向で)受け容れられん向きも多くなるわな。

708 :デフォルトの名無しさん:2014/01/03(金) 15:30:24.98
>>705
> 10個のときは? 50個のときは?

50個のとき int table[50] = { ・・・
なんて本当に書くのか?個数に応じて方法を変えるのが当たり前だろ?それは「スタイル」の問題じゃないよ。
[ ]の中を空白にするかしないかという論点であって、リテラルを直書きするかどうかは論点外。

709 :デフォルトの名無しさん:2014/01/03(金) 15:32:12.19
わかった、わかった、じゃあ仮にテストが必要だとして、どこから始めればいいんだ?

710 :デフォルトの名無しさん:2014/01/03(金) 15:32:41.26
>>705
>個数に応じて脳ミソ使ってコーディングスタイルが変わるなら

変えろよ。
個数に応じて最適な方法が変わってくるに決まってんだろ。

711 :デフォルトの名無しさん:2014/01/03(金) 15:38:39.74
>>708 >>710
個数に応じて脳ミソ使って方法を変える and しかも修正箇所が複数ある = バグの元

712 :デフォルトの名無しさん:2014/01/03(金) 15:38:47.33
可変で追加があるならvectorにpush_backするとかだよなあ。

713 :デフォルトの名無しさん:2014/01/03(金) 15:41:22.71
>>712
一切変更する予定がなくても 1,3,4,5 と打ち間違えてて、後で気付いて修正することもある

714 :デフォルトの名無しさん:2014/01/03(金) 15:43:17.68
データの集合に固定長配列を使うことはありえない。
何か論理的に決まる組み合わせによって数が不変の場合だけだな。
その時は[ ] の中に数を明記する。マジックナンバーは使わんが。

715 :デフォルトの名無しさん:2014/01/03(金) 15:48:11.06
脳がミソw

716 :デフォルトの名無しさん:2014/01/03(金) 15:52:09.87
エアテストなんてするだけ無駄。
エアギターのほうがまだ意義ある。
お前ら使ってるツールすら言えないじゃん。

717 :デフォルトの名無しさん:2014/01/03(金) 15:57:14.19
int table[] ={ 1,2,3 }; の意味は table.set({1,2,3,}), table.trim
だけど、
int table[3] = {1,2,3} ; の意味はtable.fill, table.set({1,2,3}), で何fillしてるか分からないんだよね
たまに 0 以外を埋めるバカコンパイラもあるし

718 :デフォルトの名無しさん:2014/01/03(金) 15:58:24.55
フフフフフのことか。
むしろ助かりそうなもんだが。

719 :デフォルトの名無しさん:2014/01/03(金) 16:16:30.03
まあ、不定じゃなきゃどっかで引っかかる
そして往々にしてその願いは叶えられないものなのだ
OS変わった時に発覚したりとかな

720 :デフォルトの名無しさん:2014/01/03(金) 16:17:25.50
テストをすればデバッグは必要ない。

フフフフフはバカコンパイラ。

こういう流れなのかな?

721 :デフォルトの名無しさん:2014/01/03(金) 16:25:19.47
テストは、バグをゼロにすることを目標に、限られた時間内で可能な限りバグを減らす努力の一つなのに、バグがゼロになるとか言ってる人はなんなんだ

722 :デフォルトの名無しさん:2014/01/03(金) 16:26:39.44
その認識もいかがなものかと。

723 :デフォルトの名無しさん:2014/01/03(金) 16:30:08.28
その認識は違うだろ。
テストはバグを埋め込むことを目標にしてるからするんだろ。
バグを入れる気が無かったらテストする意味ないだろ。
しかも、お前らがやってるのってエアコーディング、エアテストだろ。
コードも書かずに脳内でコード書いたーテストしたーってだけだろ。
それじゃなきゃ具体的なツール名くらいあるはずだろ。

724 :デフォルトの名無しさん:2014/01/03(金) 16:34:51.61
有効なツールが欲しいよー!
ツール名が知りたいよー!

と素直に書くべき

725 :デフォルトの名無しさん:2014/01/03(金) 16:36:25.48
有名なツールがほしいよー!
ツール名が知りたいよー!

726 :デフォルトの名無しさん:2014/01/03(金) 16:37:32.46
乱数のライブラリがあれば自作すればよいかと

727 :デフォルトの名無しさん:2014/01/03(金) 16:39:26.20
良いの教えてくれなかったらますますアンチテストになるから。

728 :デフォルトの名無しさん:2014/01/03(金) 17:04:10.73
>>723
>テストはバグを埋め込むことを目標にしてるからするんだろ。

私の頭には蛆が湧いてます…のようにしか読めない。

729 :デフォルトの名無しさん:2014/01/03(金) 17:09:32.95
バグが無い。

テスト必要ない。

バグを埋め込む。

テストができる!

730 :デフォルトの名無しさん:2014/01/03(金) 17:12:09.64
>>729
私の頭には蛆が湧いていますなんて自己紹介はもういいからw

731 :デフォルトの名無しさん:2014/01/03(金) 17:15:30.98
仮にバグゼロのプログラマがいても、OSとコンパイラと実機を自作しないかぎり、テストは必要です

732 :デフォルトの名無しさん:2014/01/03(金) 17:16:58.20
ツールが極秘なら、手法名は?
ツールが極秘なのはわかった。
NDAとかCIAとかいろいろあるらしいもんな。
そこは理解してやる。
手法名くらい言っても逮捕されないだろ。

733 :デフォルトの名無しさん:2014/01/03(金) 17:27:35.41
結局、エアテスターしかいないのか?
そもそも、自分で手法を決定し、自分でその手法を運用し、自分でコードを書き、
なんて仕事がそうそうあるわけじゃないし、実は無職とかニートの知ったかとか?

734 :デフォルトの名無しさん:2014/01/03(金) 17:32:49.95
>>732
仮に本当にテストでバグが少なくなるなら、それは金のなる木だから、こんなところで話すわけないでしょ

735 :デフォルトの名無しさん:2014/01/03(金) 17:35:26.76
> 仮に本当にコンパイラで速度が速くなるなら、それは金のなる木だから、こんなところで話すわけないでしょ

いや話すだろ。

736 :デフォルトの名無しさん:2014/01/03(金) 17:35:56.84
>>705
コンパイル通れば全てOKというC言語のルールのみ知ってるという奴は完全スルーでいいと思う。
どうせ運営から金貰ってスレを伸ばそうとしているだけで話の内容なんてどうでもいいんだろうしw

737 :デフォルトの名無しさん:2014/01/03(金) 17:37:51.84
> 仮に本当に言語で生産性が上がるなら、それは金のなる木だから、こんなところで話すわけないでしょ

いや話すだろ。

738 :デフォルトの名無しさん:2014/01/03(金) 17:39:54.73
>>734
真っ当に使えば減るし、使いこなしてる者にとっては、教えたからといって自分の領分を浸蝕はされない。

739 :デフォルトの名無しさん:2014/01/03(金) 17:41:43.38
もしかしてNDAとかFBIとかあんの?

740 :デフォルトの名無しさん:2014/01/03(金) 17:41:45.09
>>735
コンパイルの選択で速度が上がっても、それは金のなる木ではない
ゆえにどんどん話す

741 :デフォルトの名無しさん:2014/01/03(金) 17:43:31.58
>>737
ソフトウェアは無料でコピーできる特殊な製品
ゆえに、生産性が上がる技術があったら、それは金のなる木だから、何があっても隠し通す
しかし、言語のことを全世界に公開するネットで話している
つまり、言語で生産性が上がるというのは嘘

742 :デフォルトの名無しさん:2014/01/03(金) 17:49:21.81
無職だからですか?

743 :デフォルトの名無しさん:2014/01/03(金) 17:53:00.86
そういったところでの生産性の高さで儲かってる会社など

744 :デフォルトの名無しさん:2014/01/03(金) 18:00:22.22
>>705
> 10個のときは? 50個のときは?

世の中、こんなコードはごまんとあるわけだが?

ttp://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-721.26/wtf/MD5.cpp

745 :デフォルトの名無しさん:2014/01/03(金) 18:01:57.24
>>741
思い付きをそれらしく見せたいんなら、もう少し練ろうね。

746 :デフォルトの名無しさん:2014/01/03(金) 18:05:55.60
>>744
配列のサイズに関わらず、きちんと一貫した使い方をしてるのを理解できましたか?

747 :デフォルトの名無しさん:2014/01/03(金) 18:06:45.51
テスト手法は幾つか代表的なものがある
だがその名称を公開すると当社の利益に影響する
守秘義務契約にも違反する
従って公表できない

748 :デフォルトの名無しさん:2014/01/03(金) 18:24:38.31
手法は公表できてもツールは極秘だな
仕様も同時に修正する自作ツールがたくさんあるし

749 :デフォルトの名無しさん:2014/01/03(金) 18:39:35.48
>>747
つまんないから、2点。

750 :デフォルトの名無しさん:2014/01/03(金) 18:41:26.34
>>744
配列を受け取って処理する関数はあるが、配列の宣言と定義がここにはない。
そっちはどうなってるんだ?

751 :デフォルトの名無しさん:2014/01/03(金) 18:57:36.45
JSだから大丈夫じゃないか?

752 :デフォルトの名無しさん:2014/01/03(金) 19:00:05.91
ALMについてはどうですか?

753 :デフォルトの名無しさん:2014/01/03(金) 19:21:04.95
みんなが良いって言ってるからオッチャンもテストを勉強することにしました。

754 :デフォルトの名無しさん:2014/01/04(土) 01:44:04.02
意外とおもしろい議論になったな
配列のサイズを宣言する事がテストの役割を果たしてるんだな

755 :デフォルトの名無しさん:2014/01/04(土) 01:49:23.95
「こまめに保存しましょう」みたいな個人の習慣として取り入れるのか、プロジェクトの一行程として位置付けるのかで評価が異なるな…
テスターとは関係ないプログラマのテストコードを業績評価に入れたら別の悪いことが起きそうな気がする

テストコードは成果物(バグ)がなくて当然のモノだから、昔みたいにコード1行10円とかになりそうな気がする

756 :デフォルトの名無しさん:2014/01/04(土) 01:54:36.81
「こまめに保存しましょう」はツール側の発展(オートセーブ機能)で不要になった
テストもいずれ不要になっていくんじゃないだろうか

757 :デフォルトの名無しさん:2014/01/04(土) 09:18:09.71
どこまで作業してたかわからんオートセーブなぞむしろ邪魔
キーボードショートカットすら使いこなせない雑魚を排除せよ

758 :デフォルトの名無しさん:2014/01/04(土) 09:48:43.40
>>756
ファイルの保存みたいな単純作業とテストを一緒にすんじゃねーよ。

759 :デフォルトの名無しさん:2014/01/04(土) 11:35:41.74
>>754
どういうふうに解釈した?
純粋に質問

760 :デフォルトの名無しさん:2014/01/04(土) 12:18:37.40
流行る=良いもの、という短絡マスゴミ脳のスレ。

761 :デフォルトの名無しさん:2014/01/04(土) 13:30:25.83
>>760
流行る=ツールや事例がたくさんあって選択肢が広がる

良いモノである必要はない

762 :デフォルトの名無しさん:2014/01/04(土) 13:44:15.12
流行りに飛びつくのを浅はかととる奴がいるが、プログラミングについては歓迎すべきこと。
実際に使えるかどうか判断して、使えなかったら捨ててしまえばよいだけ。

763 :デフォルトの名無しさん:2014/01/04(土) 19:32:07.59
流行りに飛びつくのを浅はかととる奴がいるが、○○○については歓迎すべきこと。
実際に使えるかどうか判断して、使えなかったら捨ててしまえばよいだけ。


○○○に "当てはまらないもの をあげよ。
そして理由も述べよ。

例 プログラミング。理由 時間が無駄になるから

764 :デフォルトの名無しさん:2014/01/04(土) 19:38:41.95
例 2ちゃんねる。理由 時間が無駄になるから

765 :デフォルトの名無しさん:2014/01/05(日) 05:50:40.00
ライト兄弟に向かって「飛行機を開発するのなんて時間の無駄だから歩いていけ」って感じだろうか…

766 :デフォルトの名無しさん:2014/01/05(日) 09:48:17.00
たとえ話というのは本質的にすべて恣意的なものだし、過去事例からの類推に過ぎない。

767 :デフォルトの名無しさん:2014/01/05(日) 10:08:49.09
>>758
今でさえ文法エラーはリアルタイムで指摘される
次世代はテストさえ先に書いておけばリアルタイムで単体テストぐらいしてくれるんじゃないだろうか
もしくは、テストすら自動生成される時代が来るのではないか

768 :デフォルトの名無しさん:2014/01/05(日) 10:37:56.54
でも赤い波線はウザいでしゅ

769 :デフォルトの名無しさん:2014/01/05(日) 12:23:39.36
テストが自動生成はありえねーよ
テストの基となる仕様が存在しないわけで。

仕様を数学的に記述した場合はそれを読み込んでテストの自動生成は可能だが、
テストを自分で書く方が仕様を数学的に記述するよりも低コストってのが現在の常識。

770 :デフォルトの名無しさん:2014/01/05(日) 12:36:46.56
>>768
じゃあ黒い破線にすればいいのでは?

771 :デフォルトの名無しさん:2014/01/05(日) 15:17:21.66
>>767
メリットも用途もあんまりないな。
ユニットテスト自動生成はもうあるだろ。

772 :デフォルトの名無しさん:2014/01/09(木) 00:26:25.50
>>763
流行る=世間の大多数が使いたがる。
で、世間の大多数は優秀なのか否かを考えれば、流行るもののレベルが判るだろ。

773 :デフォルトの名無しさん:2014/01/09(木) 01:23:38.10
>>772
みんな嘘だと知ってるのに、納品するときには、書類上はテストをしたことになってる
みんなその矛盾を解決できないかと模索してるんだよ

774 :デフォルトの名無しさん:2014/01/11(土) 00:32:20.20
>>770
そんな設定できたっけ?

775 :デフォルトの名無しさん:2014/01/11(土) 00:33:27.70
>>771
ほんとだ
全分岐テストするぐらいなら自動生成できるんだな
知らなかったよ

776 :デフォルトの名無しさん:2014/01/11(土) 04:26:41.73
いちいち動作の確認するためのコードを作るのが面倒くさい
ではなく、動作をどう確認するかすら分からないのにコードを書き始める連中が大量生産されていくというわけか…

777 :デフォルトの名無しさん:2014/01/11(土) 04:44:39.43
テスト先に作ると、どんな日も帰宅するときには、出社するまでテスト走らせておくのが必ずできるってのがいいわ

778 :デフォルトの名無しさん:2014/01/11(土) 09:41:28.02
それはテストを後で作っても同じだろ

779 :デフォルトの名無しさん:2014/01/11(土) 13:31:43.77
テストコードさえ書いてしまえば
それにマッチする実装作業を別の誰かに任せられる
そういうワークフローとセットじゃないと意味ないんじゃ

ペアプロと相性よさそうだな

780 :デフォルトの名無しさん:2014/01/11(土) 13:45:46.03
テストコードさえ書いてしまえば
完璧なテストがかければな。

1なら2、2なら4を返す関数に、
3を入れたときどうするかなんてわからないんだよ。
想像はできるかもしれないがな。

結局、”仕様"が必要であり、
仕様さえあれば、それにマッチする
実装作業を別の誰かに任せられる

781 :デフォルトの名無しさん:2014/01/11(土) 13:47:46.60
>>779
> ペアプロと相性よさそうだな

ペアプロは担当者わけの仕組みじゃない。
同じコードを見ていなければ意味が無い。

たとえば、一人が書いているテストコードを
もう一人が読んでレビューしなければならない。

782 :デフォルトの名無しさん:2014/01/11(土) 18:56:54.36
仕様が必要なのは当たり前だけどさあ、
完全な仕様を文書化できるなら最初からコードで書けって話であって、
完全に文書化できないからこそ「こういう入力ではこういう出力」
というテストが必要になるんじゃねえのか。

783 :デフォルトの名無しさん:2014/01/11(土) 19:20:26.43
>>778
先にコード書いたら、テストを作るまで帰れないじゃん
作業途中でも帰りたいんだよ

あと、突然にミーティングが入った時に、帰ってくるまでテスト回しておくとかもやりたいし

784 :デフォルトの名無しさん:2014/01/11(土) 19:27:30.32
>>783
> 先にコード書いたら、テストを作るまで帰れないじゃん

帰ればいいんじゃね?


> あと、突然にミーティングが入った時に、帰ってくるまでテスト回しておくとかもやりたいし
テストが中途半端だったらエラーになるし、
コードが出来てなくてもエラーになる。

エラーを何度も出現させてなんの意味があるの?

785 :デフォルトの名無しさん:2014/01/11(土) 19:29:29.77
>>780
仕様は穴があるから、解釈が幾通りもあって多人数でやると失敗しまくる
1なら2、2なら4を返す関数に、 3を入れたときどうするか書いてないのが仕様なんだから

必要なのは、書き上げたコードの何をどう確認するかを、コードを書く前に決めておくこと
頭の中にあってもいいけど、多人数のときには、それがテストコードになる

786 :デフォルトの名無しさん:2014/01/11(土) 19:31:54.22
> 1なら2、2なら4を返す関数に、 3を入れたときどうするか書いてないのが仕様なんだから

違うぞ。仕様は入力と出力を記述するだけなんてことは絶対しない。
仕様には、入力と出力の間にある、処理の内容を書くもの。

787 :デフォルトの名無しさん:2014/01/11(土) 19:34:42.09
>>784
明日の朝と1週間後
エラーの報告を受けるのはいつがいいですか?

788 :デフォルトの名無しさん:2014/01/11(土) 19:37:12.58
>>787
なぜ明日の朝と1週間後?
開発に1週間かかるから?

じゃあさ、毎朝コードがまだできていないことによる
エラー報告を1週間貰って嬉しいという理由を教えてくれ。

789 :デフォルトの名無しさん:2014/01/11(土) 19:37:28.58
>>786
仕様は処理の内容を書くものだから、何を入れれば何が出てくるかは書いてない

790 :デフォルトの名無しさん:2014/01/11(土) 19:38:08.19
そもそもさ、コードが出来た後にテストを書くというだけで
プログラム全体が出来上がってからテストを書くとは
ひとことも言ってないんだがね。

791 :デフォルトの名無しさん:2014/01/11(土) 19:39:09.14
>>789
いやw 処理(=関数)があれば
入力から出力はわかるだろ。

入力と出力がわかっても
関数の内容はわからないけどさ

792 :デフォルトの名無しさん:2014/01/11(土) 19:39:31.81
テストを回しておく の意味がわからなかったりしてw

793 :デフォルトの名無しさん:2014/01/11(土) 19:40:00.47
意味が分かる人が説明するように

794 :デフォルトの名無しさん:2014/01/11(土) 19:47:19.54
>>788
月曜: sin関数を実装する
火曜: cos関数を実装する
水曜: tan関数を実装する
木曜: exp関数を実装する
金曜: テストを書いてテストする
土曜: 前の日までの修正をする

月曜: テストを書く
火曜: sin関数を実装して、寝てる間にsin関数のテストをする
水曜: 前の日までの修正をして、cos関数を実装して、寝てる間にsin関数とcos関数のテストをする
木曜: 前の日までの修正をして、tan関数を実装して、寝てる間にsin関数とcos関数とtan関数のテストをする
金曜: 前の日までの修正をして、exp関数を実装して、寝てる間にsin関数とcos関数とtan関数とexp関数のテストをする
土曜: 前の日までの修正をする

土曜日の朝に残りの作業の見積もりができるのはどちらでしょうか

795 :デフォルトの名無しさん:2014/01/11(土) 19:51:51.68
>>790
コードを書いた後に動作確認をするんだけど、その動作確認用のコードを先に用意するか、後に用意するかの違い

796 :デフォルトの名無しさん:2014/01/11(土) 19:54:14.05
>>791
処理を記述して、入力と出力については典型的なモノしか分からないのが仕様

797 :デフォルトの名無しさん:2014/01/11(土) 19:56:09.45
>>794
ほらな。やっぱりお前が馬鹿だった。>>790で指摘したとおりだな。

月曜: sin関数を実装する。sin関数のテストを書いて、sin関数のテストを実行する。
火曜: 前日までの修正をしてcos関数を実装する。cos関数のテストを書いてsin関数とcos関数のテストを実行する。
水曜: 前日までの修正をしてtan関数を実装する。tan関数のテストを書いてsin関数とcos関数とtan関数のテストを実行する。
木曜: 前日までの修正をしてexp関数を実装する。exp関数のテストを書いてsin関数とcos関数とtan関数とexp関数のテストを実行する。
金曜: 前日までの修正をして終わり
土曜: 休み

798 :デフォルトの名無しさん:2014/01/11(土) 19:57:33.50
>>794はテストを最初に全部まとめてやるか
最後に全部まとめてしかできんのか?w

799 :デフォルトの名無しさん:2014/01/11(土) 20:01:40.71
月曜: テストを書く。テストは失敗する
火曜: sin関数を実装して、sinのテスト結果は次の日の朝までわからない。sin以外のテストは失敗する。
水曜: cos関数を実装して、cosのテスト結果は次の日の朝までわからない。sinとcos以外のテストは失敗する。
木曜: tan関数を実装して、tanのテスト結果は次の日の朝までわからない。sinとcosとtan以外のテストは失敗する
金曜: exp関数を実装して、tanのテスト結果は次の日の朝までわからない。
土曜: tanのテスト結果が終わって、やっとコミットする。エラーが出てる状態でコミットしてはいけないので終末やっとコミットできる。

ひどい開発スタイルだw

もっと小さく開発しろよ。

800 :デフォルトの名無しさん:2014/01/11(土) 20:13:12.40
>>797
そのやり方だと、コードの実装が途中だと、帰って寝てる間にテストできないじゃん

801 :デフォルトの名無しさん:2014/01/11(土) 20:16:12.14
>>800
そんなに時間が掛かるテストを書くな。

テストに一晩かかるようなやり方じゃ、
何度もテストを回せないだろ。

802 :デフォルトの名無しさん:2014/01/11(土) 20:21:31.57
テストに一晩かかるとどうなるか

> 火曜: 前日までの修正をしてcos関数を実装する。

前日までの修正をして・・・そのテストをしないといけない。それが一晩かかる。

803 :デフォルトの名無しさん:2014/01/11(土) 20:21:42.12
>>797-799
テストコードを個々の関数実装よりも後に書いちゃいけない理由は、後にテストを書くと、書いたコードに合わせてテストの方が変更されるから
テストコードとは、書いたコードの動作が正しいことをどのように確認するかの「事前の」同意事項をコード化したもの
だから、本来なら、要求定義の次に用意されてしかるべきもの

804 :デフォルトの名無しさん:2014/01/11(土) 20:23:03.09
> テストコードを個々の関数実装よりも後に書いちゃいけない理由は、後にテストを書くと、書いたコードに合わせてテストの方が変更されるから

なんでだよw

805 :デフォルトの名無しさん:2014/01/11(土) 20:25:01.60
>>801
cos関数なら、本来なら、10^28個の数値できちんと動くことを確認したい
テスト時間はいくらあってもよい

806 :デフォルトの名無しさん:2014/01/11(土) 20:26:06.04
>>800
797さんは、xUnit とか CI とか知らないんぢゃないの?

xUnit は、一度書いてしまえば、IDE( Eclipse / VS / NetBeans) 上で
何度も自動実行できます。最近では、ちょっとコードを書いてはテスト
を実行する開発手法が主流。
そういう流れで、テスト駆動。

CI (継続的インテグ) は、xUnit を全実行して、レポートを作ってくれます。
Jenkins などが有名で、テストの合否の他に、カバレッジや、規約違反、
複雑性の静的評価レポートなども出してくれます。
よくやるのは、15分おきに、git を見に行って、変更があれば pull して全テスト。
深夜に全テスト+静的評価レポート。

807 :デフォルトの名無しさん:2014/01/11(土) 20:31:11.66
>>804
例えば、本来なら、「テストコードの使われ方見るとfloat型だから、float型で実装しよう」 だけど、
実装が先だと、「今日は float型で実装したから、テストコードも float型で書こう」 になる

808 :デフォルトの名無しさん:2014/01/11(土) 20:31:18.39
じゃあ、10^28 = 10000000000000000000000000000
1秒間に10^12個(1兆個)のテストをやって、
115740740740日かけてテストすればいいんじゃね?

809 :デフォルトの名無しさん:2014/01/11(土) 20:33:39.28
>>807
だからなんでだよw
それが間違っているならば
正しく書けばいいだろ。

っていうかテストを最初に書いたつもりでも、実装しなきゃわからんことがあるし、
あとでテストをつけ加えたり、テストを修正したりすることなんてざらにあるんだが。
ましてや、週の最後にならんとわからんようなものを
週の最初に全部完璧にテストをかけるわけがない。
テストが間違っていたとしても、実装の方を直すっていうのか?

実践経験足りないんじゃなねーか?
理屈しかわかってない。

810 :806:2014/01/11(土) 20:48:06.61
>>805
テストは、テスト対象が完全であることを証明できないから無意味
ということを言いたいんだろうけど、そんなの皆分かってますよ。

分かった上で、時間も労力も限られている現実世界でどうするか
っていう話です。

経験的に、同値分割と境界値分析でテストケースをちゃんと作っとけば
単体の不具合も、他のモジュールに起因するリグレッションも検知できる。
仮に漏れたら、テストを追加すればいい。

ちなみに Google の ARM 版 Javascript エンジン (V8) は 境界値分析
がちゃんとできてなくて sin(0), cos(0), tan(0) が変な値になる。

811 :デフォルトの名無しさん:2014/01/11(土) 20:49:26.49
>>809
まず前提として、今から書こうとするコードの動作をどのように確認するかが分からないなら、コーディング作業に入るべきではない
分かってるなら、先に書けばいい

実装した後に、テストを修正したりするのは勝手だけど、それはテスト作成時の仕様の理解不足か思い込みか注意不足か仕様自体の穴の存在を意味する
つまり、実装した後にテストを修正するのが当然と思い込んでいるということは、あなたは、大した熟考をせずに仕事を受注してくる会社にいるということを自覚した方がよい

812 :デフォルトの名無しさん:2014/01/11(土) 20:52:32.81
仕事の手順を変えるだけで、帰宅して寝てる間に自動でテストできるモノが出てくるなら、当然そうすべきでしょう

813 :デフォルトの名無しさん:2014/01/11(土) 20:55:36.60
1000万〜1億円単位の仕事としての話なら、大前提として、どんな開発方法であろうと、嘘をつかないかぎり、何万もの要求について、最終的にはテストを書かされることになる
納品の際にに、きちんとテストをやったという書類を山のように積み上げるから

じゃあ、いつ書くの?  今でしょ

814 :デフォルトの名無しさん:2014/01/11(土) 20:58:44.32
先にテスト仕様書け、馬鹿。

815 :デフォルトの名無しさん:2014/01/11(土) 21:37:28.23
あまってる時間でテストやるんだよ
本格的な運用テストは納品後1ヶ月の瑕疵期間でやる
現場に1人張り付けてもそのほうが効率いいだろ
トラブル対応の経験もできる

816 :デフォルトの名無しさん:2014/01/11(土) 22:16:44.13
コードのテストと運用のテストは違うから一緒にやるなとあれほど…

817 :デフォルトの名無しさん:2014/01/11(土) 22:50:34.14
いやーもう脳が老化してコチコチになってしまったから新しいやり方や考え方にはなじめないんじゃよ

818 :デフォルトの名無しさん:2014/01/11(土) 23:18:47.41
自分の結論に満足したら消えな。

819 :デフォルトの名無しさん:2014/01/11(土) 23:26:49.31
基本設計と詳細設計でわけたりしてないんだから
テストだってわける必要ねーんだよ
どの書類に対するテストか意識せずに
教科書どおりにテストするほうがおかしい

820 :デフォルトの名無しさん:2014/01/11(土) 23:59:55.74
ちょっと訊いてみたいのだけれども、
脳がフレッシュて柔軟な若者からみてSmalltalkのやり方やアラン・ケイの考え方ってどうみえる?
プロダクトはもちろん、それを記述している処理系すらも
常に走らせながら枠組みから変えていける仕組みやスタイルについて。
http://metatoys.org/oxymoron/oxymoron.html

821 :デフォルトの名無しさん:2014/01/12(日) 00:56:00.00
>>819
基本設計と詳細設計でわけたりしてないけど、社内で閉じた納品前の作業と、設計にも関わってこなかった人の目に触れる納品後の作業は意識して分けろよ…

822 :デフォルトの名無しさん:2014/01/12(日) 00:57:51.66
>>820
オープンソースなら使えると思うが、
プログラミング以前に、実務として、どの段階でどうやって契約してお金もらうのか分からない

823 :デフォルトの名無しさん:2014/01/12(日) 01:14:08.85
>>822
なるほど。でもケント・ベックのXPとかはこういう開発スタイルの特性から編み出されたんだよね?
けっきょく失敗したけれど、クライスラーでベックが請け負った仕事もSmalltalkでやっていたわけだし。

824 :デフォルトの名無しさん:2014/01/12(日) 02:53:44.58
そもそもテスト駆動開発が嫌なのか、テストコードを書くことそのものが嫌なのか
分けて考えなきゃダメだろ。テスト駆動開発の是非はともかくてとして、テストコードを
書くことすら嫌な奴は死ねばいいよと思うよ。

825 :デフォルトの名無しさん:2014/01/12(日) 03:46:38.75
現状はエクセルシートに日本語で書かれたテストを手動でテストするだけだ
その習慣をやめてまずはテストコードでテストするようにして
次にテスト駆動にしなければならない
段階すっ飛ばしていきなりテスト駆動にしようとするから
・テストコードなんて書いたことないのに・・・
・しかも、プログラミング前に書くなんて・・・
と障壁が二つになってしまう
もともと、テストコードを書く習慣があれば、すんなりテスト駆動のメリットは理解できるはずだ

826 :デフォルトの名無しさん:2014/01/12(日) 03:54:33.45
というか、コード書いた後にやってるコードの動作確認を、コードを書く前に再利用できる形でファイルに記述するだけなんだけど
テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの?

827 :デフォルトの名無しさん:2014/01/12(日) 04:01:00.98
>>825
そういえば、POI使ってexcelからデータ取り出せるの知ってから仕事が半分になったの思い出したわ

828 :デフォルトの名無しさん:2014/01/12(日) 04:43:44.74
>>825
テストコードでテストする前に
テストコードでテストしやすいコードを書けるように
コード記述力を高めないといけない。
あと各モジュールの独立性が高い設計も。

それれができていないところにテストコードを導入すると悲惨だぞ。
メンテンス不要のテストがたくさん出来きる。
テストコードを書く時間ばかりがかかってしまい、
これが俗にいう、ユニットテスト導入の失敗になる。

829 :デフォルトの名無しさん:2014/01/12(日) 04:46:14.61
>>826
> テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの?
動作確認するぞ。

ただし、単体ではない。
結合された状態でテストをする。

これをそのままテストにしても、
入力と出力の間に数多くの処理が含まれ
複数の入力と複数の出力と複数の副作用
組み合わせ爆発をおこし、再利用可能なコードにならない。

830 :デフォルトの名無しさん:2014/01/12(日) 04:47:20.87
× メンテンス不要のテストがたくさん出来きる。
○ メンテンス不能のテストがたくさん出来きる。

831 :デフォルトの名無しさん:2014/01/12(日) 09:12:51.35
テスト駆動って、ユニットテストは必要っていう前提条件の下
テスト書くのサボらせないために、コード書く前に必ず書かせることを義務づける
っていうことじゃないの?

832 :デフォルトの名無しさん:2014/01/12(日) 09:21:24.44
>>829
そもそもトップダウン構築とボトムアップ構築の意識の齟齬から直すべきだったりして

833 :デフォルトの名無しさん:2014/01/12(日) 10:17:21.44
通らないテストほど要らないものはないので、確実に通るテストを
自分で書く。
その手法を総称して、TDDと言います。
開発時間が短縮される効果があり、コストを低減できます。

834 :デフォルトの名無しさん:2014/01/12(日) 10:22:56.37
テスト駆動開発をうまく説明してるサイトない?

835 :デフォルトの名無しさん:2014/01/12(日) 11:12:22.70
TDDはやってないの?
流行ってるだろ。

836 :デフォルトの名無しさん:2014/01/12(日) 13:48:12.51
流行っちゃダメだ
根付いて静かに広がらないと

837 :デフォルトの名無しさん:2014/01/12(日) 14:32:21.01
>>829
いや、エディタに打ち込んでて、関数のカッコを閉じて、一息つく前に動作確認しないの?

838 :デフォルトの名無しさん:2014/01/12(日) 14:57:14.98
>>837
? するだろ。
結合された状態で。

839 :デフォルトの名無しさん:2014/01/12(日) 15:02:22.99
>>838
いや、結合すらもされてない状態で

例えば、java とか python だと、必要ないのに各ファイルにmainメソッド書いて、そこに関数の典型的な仕様例書いて、mainメソッド呼び出してカッコ閉じたばっかりの関数の動作確認しないの?

840 :デフォルトの名無しさん:2014/01/12(日) 15:14:11.75
>>829
単体テストせずにいきなり結合テストすると、それこそバグの場所特定のときに組み合わせ爆発すると思うのだが…

841 :デフォルトの名無しさん:2014/01/12(日) 15:48:15.82
>>840
今の話をちゃんと書いておくね。
テスト書いたことがない人でもテストをするという話。

そのテストの内容というのは(結合テストではなくて)結合された状態でテストする。

組み合わせ爆発してどっちが大変とかそんなことは今の話はしてなくて
テストを書いたことがない人は、こういうやり方でテストするという話。

>>839
> 例えば、java とか python だと、必要ないのに各ファイルにmainメソッド書いて、そこに関数の典型的な仕様例書いて、mainメソッド呼び出してカッコ閉じたばっかりの関数の動作確認しないの?
だからするって言ってるだろ。それが結合された状態でのテストって話だよ。

842 :デフォルトの名無しさん:2014/01/12(日) 15:53:06.04
>>841
それは結合された状態のテストじゃないでしょ…

843 :デフォルトの名無しさん:2014/01/12(日) 15:55:21.20
>>841
それテストじゃなくて、動作確認じゃね?
結合された状態で、動作確認すると

844 :デフォルトの名無しさん:2014/01/12(日) 15:58:40.24
>>843
例えば、sin(cos(x)) の実装するときに、sin(x) と cos(x) の動作確認はせずに、 sin(cos(x)) の動作確認しかしないってことだよね?

そんなのあるの?

845 :デフォルトの名無しさん:2014/01/12(日) 15:59:53.57
>>842
いや? 結合されたテストだよ。

関数Aを作る、mainを作る。まあ最初の関数Aは単体テストかもしれん。
次に関数Aを利用した関数Bを作る。mainはそのままでテストする
次に関数Bを利用した関数Cを作る。mainはそのままでテストする
以下略

他にも関数Aに処理を追加する。mainはそのままで実行する。
関数Aに追加された処理が正しく動くことを確認。OK
という流れもあるね。

なんか混乱してて話がずれていきそうだから、最初のレス(>>826)を引用すると
> テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの?

テストを書いたことがない人は、自分が書き終わった直後にこうやって動作確認してるんだよ。
(やり方がまずいかどうかは論点ではなく)動作確認自体はこうやってやってるんだよ。という説明を俺はしただけ

846 :デフォルトの名無しさん:2014/01/12(日) 16:07:18.41
もう一つ、最初の>>826にあらためてレスをすると

> というか、コード書いた後にやってるコードの動作確認を、コードを書く前に再利用できる形でファイルに記述するだけなんだけど

>>845みたいなテストをしているわけで、

「コード書いた後にやってるコードの動作確認」= >>845
再利用できる形で記述するだけだと、それは単体テストではなく
結合された状態でのテストコードになるっていうのはわかるよね?

だから、そんな「ファイルに記述するだけ」という単純な話にはならない。

テストコードを書いたことがない人でも、ちゃんと動作確認はしているわけだが、
それを単純に書いただけでは、だめなんだよ。
ちゃんとテストコードを書くのにふさわしいコードの書き方や設計から学ばないと。

ユニットテストっていうのは、既存のやり方にプラスαで追加できるものではありません。
既存のやり方がユニットテストに適していなければ、根本的に変える必要があるもの。
だから導入が大変なんだよ。

847 :デフォルトの名無しさん:2014/01/12(日) 16:08:44.13
>>845
Aを作る → Aだけを確認する
Bを作る → AとBをくっつけた状態で確認する

じゃなくて、普通は

Aを作る → Aだけを確認する
Bを作る → Bだけを確認する → AとBをくっつけた状態で確認する

にする理由は、A〜Bの連結でドメインの不整合が、Bの中だけのバグと同じオーダーで発生するから、バグの場所を特定するために、結局Bだけのテストも書くことになるから

848 :デフォルトの名無しさん:2014/01/12(日) 16:10:18.41
>>847
あぁ、そんなことは知ってる。>>846を読む前にレス書いたんだろうと思うので特にレスはしない。

849 :デフォルトの名無しさん:2014/01/12(日) 16:13:58.77
>>845-846
典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例

システムには相互作用があるから分析不可能な形で積み上げていくなとあれほど…

850 :デフォルトの名無しさん:2014/01/12(日) 16:16:25.10
いやだから、

典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例

を俺はしただけなんだが?


テストコードを付け加えるだけで終わるみたいに考えてるあまちゃんに
大変さを説明しただけ。

851 :デフォルトの名無しさん:2014/01/12(日) 16:16:50.78
テストを書きやすいコードってのはなかなか理解してくれない。
そのためのフレームワークがJavaで流行ったけど(DI。GuiceとかSeasar2とか)、テストのしやすいコードという観点で使用されることがあまりない。

TDDを強制すればちったあ意識してくれるのかな。

852 :850:2014/01/12(日) 16:17:40.09
訂正

いやだから、

典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例

を俺は "説明" しただけなんだが?

853 :デフォルトの名無しさん:2014/01/12(日) 16:19:57.05
>>846
ユーティリティ関数書いたファイルのmainの中に、ユーティリティを利用する側のシステムのコードを記述しちゃダメでしょ

854 :デフォルトの名無しさん:2014/01/12(日) 16:25:29.49
>>850
いや、そもそも、コードの関数のカッコを閉じて一息つく前の動作確認で、結合された状態のテストをする方が稀
余計に作業が多くなってコケることが「普通は」分かってるから

コードを書き終わった後にさっき書いた部分だけのテストコードを書くのは「普通はみんな」やってるんだから、それを最初に書けってだけの話なんだが

855 :デフォルトの名無しさん:2014/01/12(日) 16:25:52.78
>>851
> TDDを強制すればちったあ意識してくれるのかな。

強制するだけじゃだめ。反発する。
そしてうまくいかなければ、それが拒絶になる。

TDDを強制するならば、テストしやすいコードの書き方を知っている人がいて、
そのレビューの元で(既存のコードを直すのではなく)開発しないといけない。

なぜ、「既存のコードを直すのではなく」と書いたのかというと、それは0から
テストコードを書きやすいコードを書くのに比べると「既存のコードを直す」
という大変な手間がTDDをやるために必要なことだと認識されてしまうから。
本来はTDDにしないことで発生していた問題点なのだが、TDDが大変という印象にしかならない。

でも実際はテストコードを導入しましょう!っていう所は
すでにテストコードが導入されていないコードがたくさん存在しており
開発の大部分は新規開発ではなく修正になるわけで、理想的な状態は作れないことになる。

一言で言えば、テストコードを導入するのは、大変ってことだよ。

856 :デフォルトの名無しさん:2014/01/12(日) 16:29:24.11
>>850
普段書いてる程度のテストコードを付け加えるだけで終わらせなければダメ
開発プロセスを提案するときに、普段やってること以外に余計なプロセスを追加するのはダメ
許されるのは順序を変えるとか、意識して保存することくらい

それ以外の作業を追加すると余計に大変になる

857 :デフォルトの名無しさん:2014/01/12(日) 16:34:53.99
>>854
> コードを書き終わった後にさっき書いた部分だけのテストコードを書くのは「普通はみんな」やってるんだから、それを最初に書けってだけの話なんだが

「普通はみんな」っていう言葉は、
「そういうことに俺はしたいんだ」って言ってるようにしか見えないなw

俺がいいたいのはテストはしているが
テストコードが導入されていないところでは
>>845に書いているやり方でテストしているということ。

テストしやすいコードを意識せずに、コードを継ぎ足ししていって出来たコードは悲惨だよ?
テストするのに最初から実行することしか出来ない。

一関数で数千行あって、入力のパラメータは数十個、出力も数十個あるような
コードにテストコードを書くのが、どんなに大変なことかをお前は知らない。

テストコードを導入するというのは、こういう複雑なコードを理解して分解して修正していく作業
そしてそれを書いた人に、なんでこう書いた? こうするべきだ。今までのやり方は間違っている。
ここからどうやって正しい道に直すか。ということを理解させる作業なんだ。

858 :デフォルトの名無しさん:2014/01/12(日) 16:36:19.01
>>855
考え方の順序が逆

テストしにくいコードになる理由は、コードを書く前に、コードが満たすべきテストのインターフェイスがないから
ただそれだけ
だから、テストの技術がないバカプログラマでも、テストを先に書けば、テストしやすいコードしかできない

分散処理やGUIとか、技術的理由で事前にテストコードが書けないときは、別だが

859 :デフォルトの名無しさん:2014/01/12(日) 16:40:53.38
>>857
明示的にテストコードを書く手法が導入されていないところも、場合によっては大学の演習のバカ学生ですら、納期が2週間前のプロジェクトでない限り、

Aを作る → Aを書いた直後にAだけを確認する
Bを作る → Bを書いた直後にBだけを確認する → AとBをくっつけた状態で確認する

が普通ですよ

860 :デフォルトの名無しさん:2014/01/12(日) 16:44:15.74
>>858
> テストの技術がないバカプログラマでも、テストを先に書けば、

それは普通にまともなテストが書けませんでした。で終わり。


テストの技術がないが、既存のプログラムを修正するぐらいの人はたくさんいる。
そういう人が実戦投入されるとどうなるかわかるかな?

そういう人はたいてい既存のプログラムの簡単な修正をやらされることになる。
テストコード導入されていない既存のプログラムの修正からね。

それはゼロからの開発に比べて、テストコードが書きにくい既存のコードを
修正しながら、正しい設計に直すという大変な作業になる。

それをテストの技術がない人、つまり正しい設計も理解してない人がやるのは不可能。

テストコードはまともに書かれることはなく、無駄な作業と認識され
デスマになるだけ。

あんたは理想的な状態で語ってるだけ。人や状態が最善の状況でやるやり方。
それは現実にはありえないので、そのやり方では失敗する。

861 :デフォルトの名無しさん:2014/01/12(日) 16:47:15.09
>>857
仮に、一関数で数千行あって、入力のパラメータは数十個、出力も数十個あるようなコードがあるとしても、関数のカッコ閉じた直後に動作確認するんだから、テストコードが書けないなんてことはあり得ない

逆に、テストコードが書けないなら、その人の環境では動作確認できない機能ってことになるから、コードの複雑さとは関係ない

862 :デフォルトの名無しさん:2014/01/12(日) 16:48:05.53
>>859
> 場合によっては大学の演習のバカ学生ですら、納期が2週間前のプロジェクトでない限り、

語るに落ちたって感じw

大学の演習だから出来るんだよ。

大学の演習っていうのは、問題を適切に解ける時間が十分に与えられている。
0からの開発。問題を適切にとくことが目標であり
(どんな手段を使ってでも)機能を作ることが目標ではない。

そんな理想的な状況なら簡単にできるの当たり前だろ。

ソフトウェアの開発っていうのは、新規開発よりも、既存のシステムの修正や流用が
ほとんどだってわかってる? 書くことよりも読むことのほうが多いんだよ。

863 :デフォルトの名無しさん:2014/01/12(日) 16:50:47.62
>>860
動作確認用のテストがまともに書けないからデスマになって困りますって、それは開発プロセスの話じゃなくて、ただの人事採用の話なんじゃね?

864 :デフォルトの名無しさん:2014/01/12(日) 16:51:22.04
>>861
> テストコードが書けないなんてことはあり得ない

そりゃ書けないことはないだろうねぇ。理論的には。

何がいいたいかわかる?


どうあがいても適切なコードを書く時間が与えられていない状態で
書くにはどうするのかって話。

数千行のコードを読んで正しく理解する時間すら与えられていない。
修正に修正を重ねているから正しい仕様も存在しない。

どうすんだよ?

お前の言うように、テストコードの導入は簡単な作業ではない。

865 :デフォルトの名無しさん:2014/01/12(日) 16:53:37.70
>>862
読む場合も、普通は

Aを読む → Aの動作を理解するためのテストコードを書く → Aを改造する → 改造した直後にAの改造が正しいか動作確認する

だけど

866 :デフォルトの名無しさん:2014/01/12(日) 16:53:41.40
>>863
> ただの人事採用の話なんじゃね?

そうかもね。

んで、どうする?

人事が悪い。優秀な人採用しろ?
なんでうちに優秀な人こない?と叫ぶ?

テストコードを導入するために
高い給料出して人材を揃えるように、上に訴えるかい?

それができるのなら、それが一番だよ。
いますぐやろう!

867 :デフォルトの名無しさん:2014/01/12(日) 16:55:34.78
>>864
どうあがいても適切なコードを書けないと分かってるなら、不良品を世に出さないために職場でウンコをまき散らして、プロジェクトを破壊してください

中国の毒食品じゃないんだからさ

868 :デフォルトの名無しさん:2014/01/12(日) 16:57:46.19
>>865
実際には

Aを読む → (複雑で読み切るだけの十分な時間がない)
Aの動作を理解するためのテストコードを書く → (テストコードを書く十分な時間がない。)
Aを改造する → 改造した直後にAの改造が正しいか動作確認する  → (既存のコードが壊れていないかどうかはわからない)

これがテストコードがない場合の現実だよ。

Aのコードが短かくてAだけの修正で終わる保証なんて無いからね。

だいたいAを修正するときは、Aのインターフェースは変わらなくても
Aの仕様が変わるわけで、それの影響がどれくらい出るかを考えなきゃならん。

869 :デフォルトの名無しさん:2014/01/12(日) 16:59:11.71
>>867
それ絶対に実行不可能な無理な話じゃね?w

870 :デフォルトの名無しさん:2014/01/12(日) 17:00:16.99
>>866
テストコードは「すでに」導入されてる
先に書くか後に書くかの違いだけ
で、先に書けってだけ

テストコードが導入されてないなら、動作確認しないってことだから、問題は「動作確認しないままプログラムを売る方法を知りたい」ということになので、このスレとは関係ない

871 :デフォルトの名無しさん:2014/01/12(日) 17:04:02.18
一行追加しておくか

Aを読む → (複雑で読み切るだけの十分な時間がない)
Aの動作を理解するためのテストコードを書く → (テストコードを書く十分な時間がない。)
(そしてコードが結合しまくりで、分解しなければまともなテストコードが書けない。結合された状態でのテストコードしか書けない)
Aを改造する → 改造した直後にAの改造が正しいか動作確認する  → (既存のコードが壊れていないかどうかはわからない)


>>845で書いたように、Aというコードは、結合しまくりなのに
それにテストコード書いて終わりだと思う?

結合された状態のAのテストコードを書くという話になってるよね。
本来はAを分解して単体に分けてから、それにテストコードを書かないといけないのに、
結合された状態でテストコード書けばいいという話になってるよね。

Aが結合されてないという理想的な状態しか考えてないのかな?それは片手落ち。

872 :デフォルトの名無しさん:2014/01/12(日) 17:05:36.54
>>870
話の発端はこれなんだから、「テストコードは導入されてない状態」がスタート
勝手に話を擦りかるなよ。

826 :デフォルトの名無しさん:2014/01/12(日) 03:54:33.45
というか、コード書いた後にやってるコードの動作確認を、コードを書く前に再利用できる形でファイルに記述するだけなんだけど
テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの?

873 :デフォルトの名無しさん:2014/01/12(日) 17:05:39.49
>>868
逆に聞きたいが、テストなしでそれどうやって実行するの?

既存のプロセスでも論理的に消火不能な仕事がやってきたときには、どの開発手法でも無理ですよ
TDDは可能な限りバグを減らす努力の一つにすぎないんだから

874 :デフォルトの名無しさん:2014/01/12(日) 17:08:14.95
>>873
話をわかってないね。

テストコードが導入されていない所に、
>>826みたいに「テストコードは動作確認をファイルに書くだけ」なんて
現実を知らずに、あまちゃんなことを言ってる人に、
テストコードを導入するのは大変って話をしているだけ。

テストコードがあれば無いよりもいいってのはわかってるよ。
当たり前すぎ。だけどそんな話はしていない。

テストコードの導入が大変って話をしてる。

875 :デフォルトの名無しさん:2014/01/12(日) 17:10:41.48
>>872
前提1: 「普通の」プログラマは、コード書いた後にやってるコードの動作確認をやってる
前提2: 「普通の」プログラマは、それを各モジュールファイルの main メソッドとかに書いてる

提案: それを、コードを書く前に再利用できる形でファイルに記述すれば?

疑問: テスト書いたことない人って、前提1, 前提2の、書き終わった直後の動作確認すらもしてないの?

876 :デフォルトの名無しさん:2014/01/12(日) 17:11:26.45
>>875
普通のプログラマじゃなくて
それは俺がこれが普通と思ってるんだーって
言ってるだけだろw

877 :デフォルトの名無しさん:2014/01/12(日) 17:12:40.92
>>874
テストコードをファイルに書かずにどうやって動作確認するの?
念力?

878 :デフォルトの名無しさん:2014/01/12(日) 17:13:17.45
>>857
答え

前提1: 「普通の」プログラマは、コード書いた後にやってるコードの動作確認をやってる(ただし結合された状態で)
前提2: 「普通の」プログラマは、それを各モジュールファイルの main メソッドとかに書いてる (ただし実行は結合された状態で結果を目視)

提案: それを、コードを書く前に再利用できる形でファイルに記述すれば? (結合された状態でのテストコードにならない)

879 :878:2014/01/12(日) 17:14:27.90
>>857じゃなくて>>875

>>877
テストコードじゃないんだから目視しか無いだろ?
目視じゃ再利用できないから、テストコードってものができたんだし。
なにを当たり前な?

880 :878:2014/01/12(日) 17:18:39.00
テストすべきコードを実行する、mainの話ならそれは使い捨て
とりあえずコードが実行できればいい。
実行した後、結果は目視。
もちろん、各モジュールは結合された状態で動作確認して終わり。

というようなことがやられているのが現実。

言っとくが、俺はこの方法がいいとは一切言っていない。
このやり方をしているというのに、それを単純にコードに置き換えても
使えないテストコードになるって言ってるだけ。

テストコードがないプロジェクトに、テストコードを導入するのはそんなに簡単な話じゃないんだよ?
既存コードの修正や、メンバーの意識を変える必要がある。
テストしにくい設計の既存のコードはそのままで、追加すれば出来るようなもんじゃない。

881 :デフォルトの名無しさん:2014/01/12(日) 17:20:12.28
>>878
「普通」が、

a. 書き終わった直後に今書いたコードだけの動作を確認して、さらに結合した状態の動作も確認するのか、
b. 結合された状態の動作いか確認しないのか

アンケートをとる必要があるようだな…

882 :878:2014/01/12(日) 17:21:01.47
よく見たら>>878も間違ってたな

× 提案: それを、コードを書く前に再利用できる形でファイルに記述すれば? (結合された状態でのテストコードにならない)
○ 提案: それを、コードを書く前に再利用できる形でファイルに記述すれば? (結合された状態でのテストコードにしかならない)

883 :デフォルトの名無しさん:2014/01/12(日) 17:22:28.49
>>881
テストコードを導入していないところの「普通」でお願いねw

テストコードを導入するのが大変って話をしてるんだから。

884 :デフォルトの名無しさん:2014/01/12(日) 17:28:26.41
>>879-880
まず、GUIや分散処理やDBみたいなモノはここでは横に置きましょう

仮に、cos関数の実装の話として、今書いたcos関数の動作を目視で確認する人がいるとしましょう
termに表示された数値と関数表をプリントアウトしたものを照らし合わせて確認する場合、できるのはせいぜい20〜30個ですよ

cos関数を実装してくれと言われた場合、「普通の」プログラマはそれで給料もらえると思います?

885 :デフォルトの名無しさん:2014/01/12(日) 17:45:37.36
時間のないときは、修正するたびに目視確認する方が大変だと思うけど。

886 :デフォルトの名無しさん:2014/01/12(日) 17:52:48.59
>>884
なんでcosみたいな簡単な例を出してるんですか?
関数ライブラリを作って商売をしてるわけじゃあるまいし。

お前が横に置きましょうといった、
GUIを使ったアプリや、ウェブアプリを作るのが普通。
そんな関数作って終わりなんて仕事はない。

たとえば、ボタンを押したら、入力した数個の情報に
10個ぐらいの設定を読み込んでいろんな処理をして
10個ぐらいのデータを作る。

こういったアプリを作るのが普通。
そういう既存の処理に一つ処理を追加する。これが通常の開発。

機能を作るのが仕事として割り当てられる単位で
そんな関数単位で実装してれなんていう仕事はまずない。

887 :デフォルトの名無しさん:2014/01/12(日) 17:54:54.91
>>860
テストの技術がない人 ≠ 正しい設計も理解してない人

888 :デフォルトの名無しさん:2014/01/12(日) 17:57:39.31
>>886
GUIやWEBのテストの話がしたいなら、プロセスとしてのテストではなく、テスト技術そのものが確立してない分野なので、そもそも別のスレに行くべきではなかろうか…

889 :デフォルトの名無しさん:2014/01/12(日) 17:57:48.31
>>887
テストの技術がない人 ≒ 正しい設計も理解してない人


まあ、≒は=ではないから
≠ってのは当てはまるけどねw

890 :デフォルトの名無しさん:2014/01/12(日) 17:58:33.55
>>888
じゃあ言ってやって。

テスト駆動はGUIやWebには使えないって。

891 :デフォルトの名無しさん:2014/01/12(日) 17:58:58.27
現場レベルの努力を超えた問題を抱えてそうな会社があるみたいだな。
努力の方向が間違ってるだよ。
会社ごと滅べばいいんだよ。

農薬入り食品を輸出する他国の工場の話を聞いたらそう思うだろ?
煽りでもなんでもなく、普通の感覚。

892 :デフォルトの名無しさん:2014/01/12(日) 18:00:25.46
>>864とか何だよ?
おまえの会社はすぐ廃業しろ!

893 :デフォルトの名無しさん:2014/01/12(日) 18:01:00.20
>>886
普通は、cos関数よりもさらに単純な関数単位の実装をしろという仕事ばっかりですよ
ただし、その要件が何万もあるわけです

894 :デフォルトの名無しさん:2014/01/12(日) 18:03:58.80
>>890
テスト駆動は、アプリケーションのうち、GUIやWebのリクエストディスパッチの部分には使えない

同時に、どの手法ならバグを減らせるかもよく分かっていない
ゆえに職人が消えたら会社が消滅するような分野

895 :デフォルトの名無しさん:2014/01/12(日) 22:29:02.59
GUIやWebのテストができないって部分がよくわからん
UWSCやSeleniumを使ったらいいんじゃないのか?

896 :デフォルトの名無しさん:2014/01/12(日) 22:34:11.49
そもそもGUIそのものはライブラリに含まれているのでテスト不要だし
TDDでテストする範囲って単体テスト未満だし・・・

897 :デフォルトの名無しさん:2014/01/12(日) 22:43:11.70
>>895
テスト自体はできる
自動でテストができない
自動でテストできても、標準APIについてないような特別なツールを導入するのは避けたい

898 :デフォルトの名無しさん:2014/01/12(日) 23:32:28.17
>>893
> 普通は、cos関数よりもさらに単純な関数単位の実装をしろという仕事ばっかりですよ
ねぇよw

有名な関数以外の、つまりお前が実際に頼まれたその単純な関数の実装の例言ってみ。

899 :デフォルトの名無しさん:2014/01/12(日) 23:32:53.11
>>895
誰もテストできないなんて言ってないと思う
各言語やフレームワークで定番のテスト方法ってあるやろ
でも、Webではまだその辺みんな探り探りだから、導入しづらいっていうことでしょ
去年ですら↓だよ
http://www.atmarkit.co.jp/ait/articles/1305/08/news015.html
>テストツールはいくつかあるが、「どれを選んでも間違いないレベル」であると佐藤氏は話し、会場のコーダーを安心させた。

もともとテストコード書く習慣がなかったところに、一気に選択肢が沸いてきた

900 :デフォルトの名無しさん:2014/01/12(日) 23:35:52.23
重要なのはテストツールじゃなくて考え方だからな。

テストしやすいコードっていうのを理解していれば、
有名どころのツールは何を使ってもいいというのは正しい。

ただ、そのツールを使っても、テストしやすいコードってのを知らなければ
間違った使い方をすることになる。

やろうと思えば出来るんだよね。単体テストを記述するツールで
結合テストを書くことなんて。どんなツールでも間違った使い方はできる。
だから正しいやり方を理解することが必要。

単にテストコードを書けば、必ずしも自体が良くなるってわけじゃない。

901 :デフォルトの名無しさん:2014/01/12(日) 23:40:40.85
何かこんな感じで話がぶれるから、GUIやWebでのテストの話はとりあえず置いとこうって書いてる人がいたんやと思うよ

902 :デフォルトの名無しさん:2014/01/12(日) 23:43:17.53
仕事ではGUIやWebアプリを作っているのに、それを置いといて
普段自分が作らないような物の話をしてもしょうがないだろw

903 :デフォルトの名無しさん:2014/01/12(日) 23:50:47.92
>>898
893じゃないが、
(構造体をつくる関数がすでにあって)
・コンストラクタを作る (8種類のうち4種類)
・空の構造体のデータ領域がヌルで埋まってることをチェックする関数
・すでに作った構造体とメモリがかぶってないか確認する関数
・データのインデックスを、データ領域の配列のインデックスに変換する関数
・構造体の一部を文字列に変換する関数
・文字列の終端がヌルであることを確認する関数
   :
   :

掛け算どころか、引き算もあんまり出てこないよ

904 :デフォルトの名無しさん:2014/01/12(日) 23:53:22.00
>>903
下請け?

普通会社の仕事としては、その関数を使った
アプリ、システムを作るものだが、

お前の会社は、その関数を作って仕事が終わりなんだよね?

へんなのw

905 :デフォルトの名無しさん:2014/01/12(日) 23:55:09.04
>>902
この世に、GUIやWebアプリを作っているときにバグを減らす方法が存在するなら、GUIやWebアプリでTDD使える/使えないを話していいと思うけど

906 :デフォルトの名無しさん:2014/01/12(日) 23:58:39.89
>>902
テストコード書いてる?

907 :デフォルトの名無しさん:2014/01/13(月) 00:00:19.87
>>900
重要なのは、「導入にあたって余計な手順を追加しない」ですよ

今までと異なる正しいテストコードを書けと言うのなら、それは教育プロセスを追加することになるから、それは別で考えるべき
必要に応じて教育プロセスを追加していいという前提なら、それこそ「マイクロソフトで3年研修した後で開発プロセス」でもいいわけだし

目的は、限られた時間でよりバグを少なくすることだから、テストコードを先に書くことで今よりもバグが少なくなるかどうかを考察すべきて、テストの品質は二の次

908 :デフォルトの名無しさん:2014/01/13(月) 00:00:32.78
>>906
GUIやWebアプリではテストコード書けないって話でしょ?

909 :デフォルトの名無しさん:2014/01/13(月) 00:01:10.10
>>904
公官庁のインフラ系はこんなのばっかだよ

910 :デフォルトの名無しさん:2014/01/13(月) 00:02:16.55
>>907
> 重要なのは、「導入にあたって余計な手順を追加しない」ですよ

それは何をするのに重要なこと?

教育プロセス自体、余計な手順なわけだよね?

たとえば、技術力が明らかに低い人。
こういう人に、余計な手順を追加しないで
なのができるというの?

911 :デフォルトの名無しさん:2014/01/13(月) 00:02:24.59
>>908
アプリ―ションの一部(GUI部分やWebアプリのディスパッチ部分など)は自動でテストするコードを書けない

912 :デフォルトの名無しさん:2014/01/13(月) 00:04:23.71
>>909
インフラ系の時点でアプリ開発じゃないじゃんw

インフラ系は、アプリが数十行程度の短いコードで終わり
それを毎回0から開発だから、テストすら要らないようなレベル。

テスト駆動が必要なのはアプリの開発。ファイル数百以上、
コード行数、数万行。そういったアプリの話をしてるの。

913 :デフォルトの名無しさん:2014/01/13(月) 00:05:50.18
>>911
アプリケーションの一部は自動でテストコードを書けないんだよね?

だけど、ファットコントローラみたいにコントローラに
ロジックの大部分が書かれているものはどするんだ?

ロジックの大部分がテストできないって話でいいよね?

914 :デフォルトの名無しさん:2014/01/13(月) 00:06:51.08
>>910
プロジェクトにおいて、プロジェクトメンバー全員で開発プロセスを一貫して利用するにあたった重要なこと

ちなみに、「教育用プロジェクト」でない限り、プロジェクトは教育の場所ではないので、技術力が明らかに低い人は存在しない

915 :デフォルトの名無しさん:2014/01/13(月) 00:08:07.78
>>912
あの…、納品する仕様書だけで98cmありますけど

916 :デフォルトの名無しさん:2014/01/13(月) 00:09:57.77
>>914
> プロジェクトは教育の場所ではないので、技術力が明らかに低い人は存在しない
それはありえない。

たとえば10年選手って言葉が存在するだろう?

それは仕事を10年やってきた(だから力がある)という意味であって、
教育を10年やってきたわけじゃないんだよ。

そして10年選手が力があるという意味になるのは、
10年間で成長しているということなんだよ。

そうすると、教育期間が同じであっても、1年選手と10年選手では
明らかに技術力に差があるわけで、技術力が(高い人に比べて)低い人
っていうのは絶対に存在する。

だいたい、仕事やっていて、成長しないわけがないだろ?

917 :デフォルトの名無しさん:2014/01/13(月) 00:11:02.58
>>913
シナリオを自動でトレースするツールを使わない限り、手で確認するしかないだろうね

918 :デフォルトの名無しさん:2014/01/13(月) 00:12:50.02
>>916
技術力が(高い人に比べて)低い人 っていうのは絶対に存在するが、教育用プロジェクトでない限り、プロジェクトの必要レベルに達していない人は存在しない

919 :デフォルトの名無しさん:2014/01/13(月) 00:15:28.17
>918
> プロジェクトの必要レベルに達していない人は存在しない

じゃあ、話はこういうことだ。

プロジェクトの必要レベルに達するまで
教育は何年必要か?

きれいなコードを書けるようになるまで、
何年もかかるっていうのは知ってるよね?

もし数ヶ月で教育が終わるようであれば、
それはプロジェクトのの技術レベルが全体に低いっていうこと。

920 :デフォルトの名無しさん:2014/01/13(月) 00:15:34.77
>>912
その数十行の変更が何十万人何百万人に影響あるのがインフラ系だろ
テスト必須だった

921 :デフォルトの名無しさん:2014/01/13(月) 00:16:34.36
>>920
利用者の人数は関係ないだろw

922 :デフォルトの名無しさん:2014/01/13(月) 00:19:00.31
SEっていう生物が存在するようなところは
だいたい技術力が低い。
教育機関も極端に少ない(1ヶ月とか)
そういうのは、とりあえず動くコードが書けるだけで
正しい設計までは身についていない。

923 :デフォルトの名無しさん:2014/01/13(月) 00:20:41.43
>>919
その低いプロジェクトの技術レベルで教育ゼロで導入できるバグを減らすための努力が、TDDでしょ

924 :デフォルトの名無しさん:2014/01/13(月) 00:23:17.20
>>921
あるだろ

925 :デフォルトの名無しさん:2014/01/13(月) 00:28:41.61
確実に通るテストは本人にしか書けない。
だから自分で書く。
それがTDD。

もう、通らないテスト、勘違いしてるテストに悩む必要はありません。
自分で書けばいいのです。

これからはTDD。

926 :デフォルトの名無しさん:2014/01/13(月) 00:31:13.23
>>925
逆だよ

確実にテストに通るコードは本人にしか書けない。
だから自分で書く。
それがTDD。

もう、通らないコード、勘違いしてるコードに悩む必要はありません。
自分でテスト書いて、その後にコード書けばいいのです。

これからはTDD。

927 :デフォルトの名無しさん:2014/01/13(月) 00:38:18.11
>>924
ねぇよw
全く同じコード書いていても
その利用者数は全く異なる。

928 :デフォルトの名無しさん:2014/01/13(月) 00:52:58.60
TDDは確実に開発時間を減少させます。

確実に通るテストを書けばよかったのです。
自分で書けばよかったのです。

929 :デフォルトの名無しさん:2014/01/13(月) 01:04:53.95
TDDを使った開発時間 < TDDを使わない開発時間

これは正確には、テスト量が同じ場合。
実際はこうなるから話がややこしい

TDDを使わないが一部のテストを省略した開発時間 < TDDを使った開発時間 < TDDを使わない開発時間

つまり、TDDを使わないがその分テストを省略しているので開発時間は短い。
だけどTDDを使うと開発時間が増えてしまう。

930 :デフォルトの名無しさん:2014/01/13(月) 01:14:06.43
それは違います。
他人が書いたテストはなかなか通りません。
なぜなら、仕様の理解が人によって微妙に違うからです。
自分でテストを書けば違いはありません。
通らなければ通るようにテストを書けばいいのです。
これは便利。
これからはTDD。

931 :デフォルトの名無しさん:2014/01/13(月) 01:21:55.58
初心者がまともなコードを書けるようになるには
いくつの言語を使えるようになって
どれだけの本を読まないといけないかを考えれば、
数ヶ月程度じゃ全然足らないというのは明らか。

932 :デフォルトの名無しさん:2014/01/13(月) 01:24:13.27
俺は最初から書けたけどな。
凡人には難しいんだろな。

933 :デフォルトの名無しさん:2014/01/13(月) 01:35:08.43
「俺は」って言ってるのは参考にならないね。
「他人は」って言えるようなデータじゃないとダメ。

ぐぐると1万時間は勉強しないと使いものにならないと言われてるね
1万時間といったら、1日8時間で計算して1250日。毎日勉強しても3.5年はかかる。
土日祝日を除いたら5年。それが目安

934 :デフォルトの名無しさん:2014/01/13(月) 01:37:51.74
使い物になるっていうのは、まともなコードが書けるようになるって意味。
実際は1年も勉強に割り当てられないので、数ヶ月で実戦投入されちゃう。
そしてそういうレベルのコードが大量に生産される。

935 :デフォルトの名無しさん:2014/01/13(月) 01:42:27.99
>>929
TDDを使った開発時間 = TDDを使わない開発時間



TDDを使ったときのバグの数 < TDDを使わなかったときのバグの数

だよ

936 :デフォルトの名無しさん:2014/01/13(月) 01:44:46.23
> TDDを使った開発時間 = TDDを使わない開発時間
ないないw

コードが違うのだから、絶対に=にはならない。

937 :デフォルトの名無しさん:2014/01/13(月) 01:45:06.68
>>930
勘違いしてると思うけど、普通の開発プロセスでコーディングの後にある「テスト」と、TDDのテストは別だからね
TDDのテストを、そのテストに流用するのはありだと思うが

938 :デフォルトの名無しさん:2014/01/13(月) 01:49:28.02
>>936
テストコードが同じでコードが違う場合は、バグが見付かったか、不必要なコードがあったってことですよね?

939 :デフォルトの名無しさん:2014/01/13(月) 01:50:01.53
俺はATPLなんだけど、総飛行時間が2000時間程度。
プログラマって1万時間も学習してやっと一人前か。
馬鹿ばっかなんだな。

940 :デフォルトの名無しさん:2014/01/13(月) 01:51:37.36
>>931-934
初心者すぎてまともにコードが書けないのは、開発プロセスと関係なく人事の問題だから、別のスレで議論するべきではなかろうか…

941 :デフォルトの名無しさん:2014/01/13(月) 01:52:11.92
たとえば関数AがあってそのテストコードA'があるとする。

テストコード書いても書かなくても関数Aは同じなので、
関数Aのみを書く時間はTDDを使っても使わなくても同じ。

TDDを使った場合は、テストコードの時間が追加される。
TDDを使わない場合は、手動テストの時間が追加される。

TDDで関数Aを書く時間 = 非TDDで関数Aを書く時間

TDD(関数A+テストコードA')< 非TDD(関数A+A'と同等の手動テスト)

一般に言われてるのはこういう理由で、TDDを使ったほうが開発は速いと言われるが、
言うまでもなく明らかなように

非TDD(関数A+手動テスト無し) < TDD(関数A+テストコードA') < 非TDD(関数A+A'と同等の手動テスト)

なのである。

もちろんテストを全くしないわけにはいかないので、少しぐらいするが
その量によってTDDと非TDDでどちらが開発時間が短いかは変わってくるのは当然の話。

942 :デフォルトの名無しさん:2014/01/13(月) 01:53:11.06
>>940
スレタイ通り、「テスト駆動開発が流行らない」原因なんだから
まともなコードが書けない人が多いからってのは、
このスレでいいんだよ。

943 :デフォルトの名無しさん:2014/01/13(月) 01:55:03.42
>>939
総飛行時間だけの話にしたらだめでしょw
勉強時間も含めないと。
ATPLなんかしらないけど、飛行許可を得るまでの時間の話。

944 :デフォルトの名無しさん:2014/01/13(月) 01:55:40.66
>>941
いや、そもそも手動テストってなんなの?

ハードウェアとかGUIや分散処理やWEBのディスパッチの話してるの?

945 :デフォルトの名無しさん:2014/01/13(月) 01:56:35.59
検査が軽視されすぎているのは確かにあるかもしれない。
後から治せるという甘えがあるんだろな。
ミスったら数百人死ぬという緊張感が無いんだと思う。
アップデートとかありえないだろ。

946 :デフォルトの名無しさん:2014/01/13(月) 01:57:41.17
>>942
初心者すぎてまともにコードが書けない=そもそも開発してない だから、流行るとかそういう話ではないのだが

947 :デフォルトの名無しさん:2014/01/13(月) 01:59:47.39
>>945
TDDのテストは検査行程とは違いますよ
TDDのテストは、どちらかというと、プログラマ個人がエディタ保存した直後に行う習慣としてのテストのことですよ

948 :デフォルトの名無しさん:2014/01/13(月) 02:00:52.87
コードを書く前は禁酒、食事、睡眠にも気を使う。
プロとその家族には当たり前だろ。
テストとか甘えたこと言ってたらダメだ。
一発でOKにしろよ。

949 :デフォルトの名無しさん:2014/01/13(月) 02:02:06.04
>>944
テスト関数Aがあったとき、
それを使用する処理Bがあったとする。

int main() {
 いろんな処理
 処理B()
 いろんな処理
}

int B() {
 いろんなコード
 int a = 関数A()
 いろんなコード
 aの処理結果を更に処理した結果をデータベースに保存
}

int A() {
 return 計算結果
}

プログラム実行。
データベース確認。
手動SQLを実行して計算した結果が入っていることを目視で確認
OK

これが手動テストの内容。

950 :949:2014/01/13(月) 02:03:36.13
ちなみに、mainとB()は
A()を作る前から存在している。

だからわざわざA()のために書いたコードではない。
先にmainとBが存在していて、
そこにA()を追加した時の手動テストというのは
こういうものという説明。

951 :デフォルトの名無しさん:2014/01/13(月) 02:04:42.42
>>939
昔受注した飛行のシステム45万件の用件定義
そのうち、13万件は職人以外はデバッグすらできないアセンブラで書かれていました

よく飛行機に乗れますね
私は絶対に乗れません

952 :デフォルトの名無しさん:2014/01/13(月) 02:06:06.52
>>949
分散処理は別だとあれほど…
そもそもツールなしのテスト技術が確立してないんだからさ

953 :949:2014/01/13(月) 02:06:40.19
>>952
え?これのどこが分散処理なの?
ちょっとお前の言う分散処理を説明して見せなさいw

954 :デフォルトの名無しさん:2014/01/13(月) 02:09:15.51
>>953
独立に動いてるDBMSがある点が分散処理

955 :949:2014/01/13(月) 02:09:28.97
手動テストの例を続けるけど、

ウェブプログラミングだとよくF5を押してテストも手動テストになるね。

F5押して、ちゃんと画面に意図したHTMLが表示されてているか?

されていない

最初に戻る

956 :949:2014/01/13(月) 02:10:16.89
>>954
DBMSっていうのは普通独立して動くものだが、
データベースサーバーを使ったものはすべて
分散処理だっていいたいわけだよね?

957 :デフォルトの名無しさん:2014/01/13(月) 02:12:35.03
コンピュータが信頼されていない間は、まったく問題ありません。
FMSは壊れる前提で使われていますし、実際よく故障します。

958 :デフォルトの名無しさん:2014/01/13(月) 02:14:07.29
>>955
実はそういうGUIは、それだけじゃダメなんだ
ブラウザなら、ブラウザのいろんなボタンを押さないと
具体的に言うと、戻るボタンを押して変なページに転送されないことを確認しないと

959 :デフォルトの名無しさん:2014/01/13(月) 02:16:28.76
>>956
DBMSそのものを開発しているのでない限り、DBMSを使ったプログラムはすべて分散処理ですよ

960 :デフォルトの名無しさん:2014/01/13(月) 02:18:09.76
SQLiteがDBMSであるかどうか。

961 :949:2014/01/13(月) 02:20:19.56
>959
DBMSを使ったら全て分散処理(笑)

まあいいけど、この例は別にデータベースサーバーを使わなくて
ファイルを使っても同じなのだけど、
ファイルを使ったら分散処理ではないってことでいいね?

962 :デフォルトの名無しさん:2014/01/13(月) 02:21:22.38
>>960
超簡単に言うと、再代入のタイミングを特定できない変数がシステムの中に一つでも存在するなら、分散処理でいいよ

963 :949:2014/01/13(月) 02:21:41.76
手動テストというものが理解できない人がいるようなので、
手動テストの例

テスト関数Aがあったとき、
それを使用する処理Bがあったとする。

int main() {
 いろんな処理
 処理B()
 いろんな処理
}

int B() {
 いろんなコード
 int a = 関数A()
 いろんなコード
 aの処理結果を更に処理した結果をファイルに保存
}

int A() {
 return 計算結果
}

プログラム実行。
ファイル内容確認。
コマンドラインからファイルを表示して計算した結果が入っていることを目視で確認
OK

これが手動テストの内容。

964 :デフォルトの名無しさん:2014/01/13(月) 02:23:18.78
つまり、キーボード入力があれば分散処理ということですか。

965 :949:2014/01/13(月) 02:24:38.04
再代入? 分散処理と同じで、またオレオレ定義で再代入って用語を使っているように見えるが、
そうか、データベースの書き込みやファイルの書き込みっていうのが
再代入で、それらを使うと分散処理になるのかーw

966 :デフォルトの名無しさん:2014/01/13(月) 02:25:22.60
>>961
ローカルファイルに保存して、そのファイルにアクセスするプロセスがシステム稼働中常に1つ以下なら分散処理じゃない
システム用件としてネットワークファイルシステムが必須としてるなら確実に分散処理

967 :デフォルトの名無しさん:2014/01/13(月) 02:28:36.93
>>965
データベースの書き込みやファイルの書き込みを抽象化して表現するとそれは再代入で、「それらの再代入が行われるタイミングが特定できないなら」分散処理になる

968 :949:2014/01/13(月) 02:28:49.44
面倒くさいから分散処理の一般的な定義書いて、
こいつ放置していい?なんか本当に初心者みたいだからさ。

http://e-words.jp/w/E58886E695A3E587A6E79086.html

> 複数のコンピュータやプロセッサを利用して、分散して計算処理を行うこと。
> 1台のコンピュータに多数のプロセッサを搭載して処理する方法と、
> ネットワークを通じて複数のコンピュータを結びつけて処理する方法の2種類に大別できる。

969 :デフォルトの名無しさん:2014/01/13(月) 02:29:38.86
もっと簡単な話でしょ。

int a = 1; // aは変数。

aという変数に再び代入するタイミングが特定できない、つまりユーザーの入力で
代入が起こる場合は、すべて分散処理。
日本語であればそういう意味。

マウス、キーボードの入力を受け付ければすべて分散処理。
俺はそう読み取った。

970 :デフォルトの名無しさん:2014/01/13(月) 02:30:40.23
>>964
キーボード入力がシステムの一部で、キーボード入力するタイミングが特定できないなら、そのシステムは分散処理ということです

971 :デフォルトの名無しさん:2014/01/13(月) 02:31:20.01
ほとんどのプログラムは、分散処理であり
テスト駆動不可能という話になりました。

972 :デフォルトの名無しさん:2014/01/13(月) 02:32:54.40
平行世界に突入済み。

973 :デフォルトの名無しさん:2014/01/13(月) 02:37:16.10
>>868
「複数のコンピュータやプロセッサやプロセスや人間やその他のシステムを利用して〜 」
で「複数の」を「イベント発生の時系列を相互にコントロールできない」と具体的に定義すれば
なら完璧かな

974 :デフォルトの名無しさん:2014/01/13(月) 02:39:50.27
>>973
完璧かな? いやつまりお前の定義とリンク先の定義は違うってことでしょ?

リンク先の定義のほうが正しいので、
それとお前の言っていることが一致していないのであれば、
お前が間違っているということだよ。

975 :デフォルトの名無しさん:2014/01/13(月) 02:41:06.51
>>971
正確には、
ほとんどのプログラムは分散処理であり、どの開発プロセスであれ、特別なツールなしにバグを減らすテスト手法は確立されていない
ごく一部のプログラムくらいについての、バグを減らすテスト手法を議論しているだけ
です

976 :デフォルトの名無しさん:2014/01/13(月) 02:42:39.96
テスト駆動はなぜ流行らなかったのか?

答え、

ごく一部のプログラムしか通用しないから

>>975によるとという結論です。

977 :デフォルトの名無しさん:2014/01/13(月) 02:42:58.21
TDDはバグを増やすんだけど、そこの認識から間違ってると思うんだよね。

978 :デフォルトの名無しさん:2014/01/13(月) 02:44:30.70
>>974
リンク先の定義が間違っている理由は、処理をシステムとして抽象化してないから

979 :デフォルトの名無しさん:2014/01/13(月) 02:46:01.98
>>978
間違ってるのはお前のほうだよ。自覚しな。

980 :デフォルトの名無しさん:2014/01/13(月) 02:46:54.86
よし!ここで多数決だ。

↓やれ!

981 :デフォルトの名無しさん:2014/01/13(月) 02:46:55.94
>>976
そのTDDが通用しないプログラムでは、そもそも「職人芸」以外に流行ってる開発プロセスはない、と追加しておいて

982 :デフォルトの名無しさん:2014/01/13(月) 02:57:33.59
つまり、コンピュータ処理に限定されていた分散処理を、システムとして抽象化した上でそれを包括する形の新しい定義を発見したということか…

983 :デフォルトの名無しさん:2014/01/13(月) 03:07:23.78
単なる初心者のオレオレ定義さw

984 :デフォルトの名無しさん:2014/01/13(月) 03:14:51.72
お前が初心者ではない証拠を見せろ。

985 :デフォルトの名無しさん:2014/01/13(月) 03:23:56.71
それは意味が無い。俺が初心者だろうがどうかは
相手が初心者であるかどうかと関係ない。

単に一般的な定義とは違う定義をしている奴は
初心者ってだけの話。

986 :デフォルトの名無しさん:2014/01/13(月) 03:42:07.49
>>941
TDDの場合は関数Aに対して複数のテストコードを書くことになるから
テストに要する時間はもっと加算していいのでは?
単体テストに応用できるからそっちの時間削ればプラスマイナスとなって誤差なのかもしれんが

987 :デフォルトの名無しさん:2014/01/13(月) 03:46:51.92
>>971
実際、キーボード入力が絡むとテスト駆動無理じゃね

988 :デフォルトの名無しさん:2014/01/13(月) 03:47:16.86
つまり、お前は初心者だな?

989 :デフォルトの名無しさん:2014/01/13(月) 03:52:46.11
TDDなのにひとつの関数に対してひとつのテストしか書かない前提で話してる奴って何なの?

990 :デフォルトの名無しさん:2014/01/13(月) 03:56:49.40
>>987
> 実際、キーボード入力が絡むとテスト駆動無理じゃね

一連の処理の中にキーボード入力コードが切り離しづらい形で入っているとそうだね。
だからコードの正しい書き方が重要になってくるし、
テストしにくいコードはテストしやすい形に修正する必要が出てくる。
既存のコードに単純にテストコードを追加すればそれでOKとは限らないんだよね。

>>989
誰もそんなこと言ってないと思うが?

991 :デフォルトの名無しさん:2014/01/13(月) 05:44:09.73
言っただろ。

992 :デフォルトの名無しさん:2014/01/13(月) 05:57:50.92
それは誰かアンカー書けばいいだけ。

993 :デフォルトの名無しさん:2014/01/13(月) 06:59:27.57
>>990
キーボード入力が切り離せるなら
GUIも切り離せるから問題ないな

994 :デフォルトの名無しさん:2014/01/13(月) 07:00:23.79
>>992
>>941の式を見る限り1回書ききりだな

995 :デフォルトの名無しさん:2014/01/13(月) 07:22:42.10
>>994
一回なんて書いてないじゃんw

996 :デフォルトの名無しさん:2014/01/13(月) 07:24:21.04
>>993
そのとおりだよ。
だけど、切り離すっていうのは
ソースコードの修正を意味する。

コードの途中にキーボード入力が合ったりしたら
それを取り除くのは大変だからね。

単純にテストコードを追加するだけじゃダメなんだ。
テストコードを導入するには、テストしやすいコードに修正しなければいけない。

997 :デフォルトの名無しさん:2014/01/13(月) 07:37:13.90
そうだ、テストを沢山やる為に
テストの為に機能を追加しよう

998 :デフォルトの名無しさん:2014/01/13(月) 07:38:09.55
いや、機能追加をする前にテストコードが必要。
ただしコードが汚い場合は
テストコードを入れる前にコードの修正が必要。

999 :デフォルトの名無しさん:2014/01/13(月) 07:48:54.17
動いているコードは修正するなっていう格言みたいなのあるじゃん?
あれのせいで日本のコードは品質があがらないんだよ

1000 :デフォルトの名無しさん:2014/01/13(月) 07:54:40.34
>>999
全くだ。

品質をあげることをしない=品質を下げる だからな。

既存のコードの品質をあげないまま、コードを追加するという作業は
品質を下げるということを意味する。

コードを追加したのに品質は変わらないってことは存在しない。
品質は下がるか、(品質を上げる作業をすることで)上げるしかない。
なにもしないでコードを追加したら、当然品質は下がる。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

271 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)