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

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

ソフトウェアのテストについて

1 :仕様書無しさん:2006/04/23(日) 22:01:27
コーディングより時間のかかる単体テスト項目作成・テスト
実行なんて意味なくね?同じ時間かけるなら机上デバッグの
ほうがよくね?

2 :仕様書無しさん:2006/04/23(日) 22:03:11
机上デバッグって何ですか?

3 :仕様書無しさん:2006/04/23(日) 22:06:51
机の上に座ってデッバガでプログラムの動作を追いかけることだ。
椅子が要らない分コスト削減となる。

4 :仕様書無しさん:2006/04/23(日) 22:08:02
 _, ,_
( ゚д゚ ) デッバガ!!

5 :仕様書無しさん:2006/04/23(日) 23:34:26
デパガ

6 :仕様書無しさん:2006/04/23(日) 23:39:39
( *゜ё゜) デパガとペアプロ!

7 :仕様書無しさん:2006/04/23(日) 23:52:26
保守開発とかやってると
コーディングの10倍ぐらいテストに時間使って嫌になるな。


8 :仕様書無しさん:2006/04/24(月) 00:00:08
>>1みたいな考えの偉い人がいた場合の結果は、みずほとか
いろいろいい例があるよ。

9 :仕様書無しさん:2006/04/24(月) 00:03:21
出歯亀ですが何か?

10 :仕様書無しさん:2006/04/24(月) 00:06:07
たとえば単体テスト項目を作成するにあたってコードを参照するならば
それは無意味であろう。テスト項目は当然だが仕様書に基づいて作成し
なければならない。

11 :仕様書無しさん:2006/04/24(月) 00:10:09
>>10

UTはコーディングありきだろ
仕様書に基づくならITの方が自然。

12 :仕様書無しさん:2006/04/24(月) 10:22:44
騎乗位デバッグ

13 :仕様書無しさん:2006/04/24(月) 11:38:09
>11 UTは詳細設計書に基づいて行う。
コーディングに即して行うのは開発テストで、通常は正規のテストとは認めない。

14 :仕様書無しさん:2006/04/24(月) 14:16:02
テスト自動生成ツールがもっと賢ければなぁ('A`)

15 :仕様書無しさん:2006/04/24(月) 19:07:21
安く作れ、早く作れ

テストに工数をかけられない

潜在バグだらけのまま出荷

他社よりも早いリリースでシェア確保

バグが見つかって大騒ぎ

その頃には売上も出て、
ようやくテストに工数をかけられるようになる

16 :仕様書無しさん:2006/04/24(月) 19:49:43
>>15
早く作れ、安く作れ
 ↓
テストができない
 ↓
納入先でテスト
 ↓
すっげぇ嫌な顔で見られる
 ↓
へこむ
 ↓
繰り返す。

17 :仕様書無しさん:2006/04/24(月) 23:03:21
早く安くバグのないものを作れ

という無理難題を普通に言われてしまう業界。

18 :仕様書無しさん:2006/04/24(月) 23:12:22
>>13
この世の中に「正規のテスト」などというものはない。

あるように思えるのは全て幻想。


19 :仕様書無しさん:2006/04/24(月) 23:21:28
VBプログラマ Cプログラマのお仕事
http://www.vb-c.net/

20 :仕様書無しさん:2006/04/24(月) 23:23:03
コード書くよりもテストに時間かけたほうがいい気がするけど。


21 :仕様書無しさん:2006/04/24(月) 23:23:50
究極のテスト仕様書

条件:PG仕様書通りであること。
結果:PG仕様書通りであることを確認しました。

以上

22 :仕様書無しさん:2006/04/24(月) 23:37:24
>>21
今のプロジェクトで使わせてもらうよwwwwww

23 :仕様書無しさん:2006/04/25(火) 00:22:20
>>20
>コード書くよりもテストに時間かけたほうがいい気がするけど。
テストの工数が少なくなるような設計をした方がよいと思う。

24 :仕様書無しさん:2006/04/25(火) 17:36:38
>>23
禿同

だがしかし、
ちゃんと設計する → 仕事が遅いダメな奴
問題を解決しないまま適当に実装する → 仕事が速い優秀な奴
という扱いを受ける。

知識不足、経験不足で恐いもの知らずの新人が重宝されるのは、そういうことなんだよな。

25 :仕様書無しさん:2006/04/25(火) 17:39:09
テストさえしっかりやれば大丈夫といってると、
テストで見つけたバグは直せるけど、
テストで見つけられなかった大量のバグが残る。

そもそも、ハードウェアの製造では、
いいかげんに作って検査で品質を確保するアメリカ式に対して、
しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。

26 :仕様書無しさん:2006/04/25(火) 22:27:48
>>25
>そもそも、ハードウェアの製造では、 
>いいかげんに作って検査で品質を確保するアメリカ式に対して、 
>しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。

だから、ソフトウエアのテストは本物の「テスト」にあらず。
設計の妥当性を検証しているだけ。コーディングは「設計」なの。

本当に「製造」と呼べる作業は、
「コンパイラ」がやってくれている部分だけ。


27 :仕様書無しさん:2006/04/25(火) 22:52:29
>>24
 テストでバグがでない。→テストをさぼってる。
というのがある。



28 :仕様書無しさん:2006/04/25(火) 23:01:43
そういう風潮があるのか
了解営業殿。

29 :仕様書無しさん:2006/04/26(水) 00:08:31
テスト初心者なんですが、本読んで勉強しようと思うのですが、どの本がお勧めですかね?
ちなみに今自分で候補にあげているのが「はじめて学ぶソフトウェアのテスト技法」と「知識ゼロから学ぶ ソフトウェアテスト」です。
予算は3000円前後。お願いしました。


30 :仕様書無しさん:2006/04/26(水) 00:11:33
障害あっても検出できないテスト仕様書って一体......。

31 :仕様書無しさん:2006/04/26(水) 00:15:53
トータルで長い工数、とくに手戻りやリリース後の工数が多い新人に、
トータルでは短い工数で仕事できるベテランが老兵として追いやられるんだよな。

そういうことをしてる限り、ダメだろ。

32 :仕様書無しさん:2006/04/27(木) 12:56:31
姉歯の件でも分かるとおり、普通は安くしろと言うとどこかの手を抜く

33 :仕様書無しさん:2006/05/02(火) 02:12:19
デッバガ

34 :仕様書無しさん:2006/06/18(日) 11:03:11
テスター(バイト)をたくさん雇えば、プログラマはテストしなくていいので最高だよな。

35 :仕様書無しさん:2006/06/18(日) 11:23:14
バイトを雇うのはありだと思うけど、守秘義務のあるビミョーなアプリだった
らその手が使えない。
デバッグ請負会社にまわすのもありだけどコストがベラボーになるし

36 :仕様書無しさん:2006/06/18(日) 11:58:03
正社員プログラマで入社して、テスターとして偽装派遣に出された30歳童貞の僕が来ましたよ。
何か質問ある?

37 :仕様書無しさん:2006/06/18(日) 14:08:45
どうも良くわからない主張が多いような気がする。
テストってどういう目的で、どんな手法でやるのか、>>1はお勉強してから言ってるのかな?。

わたしもこの間研修受けて、「そうはいうけどさー、実際には時間ないし…」とかぶつくさ言いながらも、必要性は理解してきたと思う。


38 :仕様書無しさん:2006/06/18(日) 15:34:24
観測以前にはバグの有無はどちらもありうる状態にあるが、
観測者が観測したことで有無が一方に定まる。

使われないプログラムであるならば観測する意味がない。

39 :仕様書無しさん:2006/06/23(金) 18:00:53
>>36
テスターの仕事ってどう?
俺、テスターとして正社員になれそうなんだ。

イメージとしては、特に難しいこともなく淡々と決められたテストをこなしていく感じ?
PGやSEみたいにデスマで寝てねーよみたいにはならないよね?

40 :仕様書無しさん:2006/06/23(金) 18:15:26
       ,、‐ " ̄:::゙:丶、
    ,r::::l3゙::::::::/ハヽ:ヽ::::、:ヽ
    {::://:::::::// ヽ\ト、:::::::!
    ヾ l:::::::/ 丶   `ヾ ィ、:::|
     |;:r::|  O`  'O ゙ハ| 
      ヽハ :.:.    :.: レ
        ´\ r‐--‐、,ノ   
 r、     r、/ヾ ̄下ヘ
 ヽヾ 三 |:l1、_ヽ/__ .ィヽ
  \>ヽ/ |` }    n_n| |
   ヘ lノ `'ソ     l゚ω゚| |
    /´  /      ̄|. |
    \. ィ   ___ |  |
        | ノ     l |  |

41 :仕様書無しさん:2006/06/23(金) 18:59:25
>>39
デスマなるよ。

コーディング作業が遅れても、期間は変わらないので
当然テストにもしわ寄せがくる。

42 :仕様書無しさん:2006/06/23(金) 19:01:31
いい歳して「職業はテスターです。プログラムは分かりません」
とかいいにくいよね

43 :仕様書無しさん:2006/06/23(金) 19:42:15
>>41
考えてみれば確かに・・・

でも、デバグみたいに「なんかおかしいけどなんでかわからん」状態がないだけマシかなと。
不具合を見つけてPGを苦しませる仕事・・・ドSには合いそうだな。

44 :仕様書無しさん:2006/06/24(土) 01:12:18
指摘すればするだけ、自分の出バグ進行度が進まないだろ

45 :仕様書無しさん:2006/06/24(土) 23:23:49
>>44
やっぱりひとつバグが見つかったら、修正してまた1からテストやりなおし?

46 :仕様書無しさん:2006/06/25(日) 09:21:47
修正が及ぼす範囲内で再テスト。

47 :仕様書無しさん:2006/06/30(金) 23:42:00
で、デグレが見つかると


48 :仕様書無しさん:2006/07/01(土) 18:14:17
昨日面接でテスト工程を行ううえで考えることは何ですか
といわれて。
エビデンスを見やすく作ることです。
と答えた私は落ちかな?
正解の答えは何でしょうか?

49 :仕様書無しさん:2006/07/01(土) 18:20:22
>>48
人員の健康管理

50 :仕様書無しさん:2006/07/01(土) 19:38:25
強い破壊的思想

51 :仕様書無しさん:2006/07/04(火) 23:08:17
「正解の答え」って。

52 :仕様書無しさん:2006/07/05(水) 20:12:20
>>48
エビちゃんがどうしたって

53 :仕様書無しさん:2006/07/05(水) 21:22:29
>>2
ソースコードを印刷してトレースすることだ。



54 :仕様書無しさん:2006/07/06(木) 20:36:10
なんか最近は静的解析ツールを使うことも含まれるらしい
それだけツールを手軽に使えるようになったということか

55 :仕様書無しさん:2006/07/08(土) 18:47:00
静的解析ツールは、どこまで使えるの?

以前に社内の間接部門が、静的解析ツール使いませんかと話を持ち込んで来た時は、
たった数日の仕事でも、百万円寄越せとか言ってきたので、使わずに断ったことがある。
いわく、ツールのライセンス料もさることながら、ツールの出力する結果を読み解く人間が必要だとかで。

ちろっとサンプルコードで試してもらったら、それはもう膨大な両のメッセージをツールが出力して、
「読み解く人間」がこっちに、このコードは何をするものなのか? と大量の質問を浴びせてきてさ、
まるでソースコードを1行ずつ説明させられているような状況で、結局は、人間が判断してるのよ。
だとしたら、数日では済まないし、「読み解く人間」の相手をする人間も長時間、拘束されるわけで。

56 :仕様書無しさん:2006/07/10(月) 01:18:25
ねたなのか?
少なくとも使ったことのある解析ツールは普通に使えたけど...
もちろん「読み解く人間」なんかいらなかったし

57 :仕様書無しさん:2006/07/28(金) 21:37:19
ほしゅ

58 :仕様書無しさん:2006/07/31(月) 21:24:25
テスト技術者資格試験を受ける人ってどのくらいいるんでしょうかね。

59 :仕様書無しさん:2006/08/02(水) 19:00:06
>>58

 相当数。

 このごろテスト技術者も世間的に興味をもたれるようになって
きたんで、時間があれば受けてみた方が良いんじゃない?

 勉強の動機付けにもなるし

60 :仕様書無しさん:2006/08/03(木) 00:12:23
コーディングができることを採用条件にしないで採用しているために、
新入社員は、コーディングができるようになるまで、テスト担当になるのだが、
上がコーディングの機会を与えずに朝から晩までテストさせてるので、
当然の結果、コーディングができるようになるわけもなく、
また、コーディングができるようになると仕事が過酷になる割に給料はまったく上がらないので、
若い人たちは、テストのスペシャリストになろうとする。

もうね、あほかと。

61 :仕様書無しさん:2006/08/03(木) 12:07:24
テストの技術とプログラムの技術は別ものだと思うが、如何か?

62 :仕様書無しさん:2006/08/03(木) 12:20:36
それより、まともなテスト工程が入ってる開発に入った事ないんだけど。
みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの?

おいらのところって、営業ポンチ絵書いて→SEが背景書いて→チームリーダーが
仕様書ポイ書式で書いて→プログラマーがプログラム組んで→プログラマーがプログラムを日本語にして
これを詳細設計書と読んで→プログラマーがテスト仕様書いて→プログラマーテストやって→
プログラマーがテスト報告書を書いて→プログラマーがSEが書いたポンチ絵を一応仕様書ぽく書き直して、

で、納品して。

って感じなんだけど。

63 :仕様書無しさん:2006/08/03(木) 12:36:29
デジタル家電はきちんとしたテストがあるだろ

64 :仕様書無しさん:2006/08/03(木) 17:30:38
>>63
某社のHDD&DVDレコーダーは、いいかげんに作ってテストで見つかったバグだけを修正している
としか思えないくらい、フィールド障害が日常茶飯事ですよ。テスト史上主義の弊害だね。


65 :仕様書無しさん:2006/08/03(木) 21:59:25
>>63
そういう考え方が一番やばいんだよな。

66 :仕様書無しさん:2006/08/03(木) 22:28:51
某ミッションクリティカルなサーバ上で、root権限で動くシェルスクリプトを書きました。
膨大な量の仕様書を書くのに忙しくて、十分にテストができませんでした。
万一鯖を殺してしまったら、マスコミ沙汰になるでしょう。
そろそろ逃げる準備をする必要があります。

67 :仕様書無しさん:2006/08/03(木) 22:56:11
漢にはテスト不十分でもリリースしなければならんときがある。
そんなときは文字化けのように堂々としとけ。

68 :仕様書無しさん:2006/08/03(木) 23:31:06
ソースごとリリースして客に直してもらえば良し

69 :仕様書無しさん:2006/08/04(金) 00:16:11
早く作れ、安く作れ
 ↓
てめぇなにさまだごるぁ
 ↓


70 :仕様書無しさん:2006/08/04(金) 14:42:54
>>66

 修羅場を越えてこそ一丁前になるいい機会。人の尻拭いやプロジェクト全体の
面倒をみることで新しいものが見えることもある。

 ガンガレ

71 :仕様書無しさん:2006/08/04(金) 19:30:28
>>62
開発の規模によるんじゃあるまいか。ある程度以上の規模なら
単体テスト→結合テスト→システムテスト
のような工程を踏むかと思われ。

72 :仕様書無しさん:2006/08/05(土) 13:20:10
>>71
いやいや、その工程が全部プログラマーがやることになってて。。。。。。

73 :仕様書無しさん:2006/08/06(日) 01:38:37
>>62
> それより、まともなテスト工程が入ってる開発に入った事ないんだけど。
> みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの?

メーカー系の仕事だと、QA部門がしっかりして2〜3ヶ月専門部隊で品質管理したりするよ。
あとは大手の仕事とかでも、SEがちゃんとテストしてた。

74 :仕様書無しさん:2006/08/06(日) 14:21:42
某大手に居た頃SEに
「自分で作って自分でテストするならやらなくていい」といわれた。
正論だと思った。

75 :仕様書無しさん:2006/08/06(日) 15:08:12
まともな人もいるんだねぇ〜

76 :仕様書無しさん:2006/08/06(日) 15:41:11
>>74
それはブラックボックステストのことだよな?
単体テストやホワイトボックステストはコーダーが自分でやらないと無駄に工数かかるだけかと。
むしろ単体テストなんてテストファーストで実装すれば良いだけの話しだし。

77 :仕様書無しさん:2006/08/06(日) 16:33:02
人を見て道を説け、ということだな。

74にはそういう判断が下されたとしても、そうじゃないやつは
世の中いるでしょうな。

みんなが自分の作ったところをテストしないとすればどんな
もんができあがるのか興味深い。

78 :仕様書無しさん:2006/08/06(日) 17:52:16
あるプログラムに関して「Aという場合」というのを考慮しないで
コードを書いたとする。
このコードを書いた人がテストを設計すると、当然「Aという場合」を
考慮しない。
したがって「Aという場合」のテストは行われない。
最終的に「Aという場合」には正しく動かない可能性が放置される。

これを防ぐには、テストの設計か、テスト仕様書のレビューを他の
人がする必要がある。

79 :仕様書無しさん:2006/08/06(日) 19:38:27
めんどくせ

80 :仕様書無しさん:2006/08/06(日) 22:27:41
>>78
それはそもそもの機能設計が悪い。
メソッドの機能として「Aという場合」が必要ならそう記さなければ設計ミス。


81 :仕様書無しさん:2006/08/06(日) 23:36:29
俺はテストファーストが大嫌いだ。

試行錯誤的にコードを少しいじってはテストに通し、たまたまテストに通るまで繰り返す輩がいるから。
そんな、まったく穴のないテストを前提とすることは間違いだし、そもそも、生産性が悪すぎる。


82 :仕様書無しさん:2006/08/06(日) 23:51:42
昔話にテストファーストとか言われてもなぁw

83 :仕様書無しさん:2006/08/06(日) 23:53:19
>>80
設計書の段階でわざわざこと細かにあらゆる場合について書かないでしょ。
そんなことしたら設計書が電話帳なみになる。
設計書に書かれていることから実装が決められていくわけで、
その段階で考慮漏れが出る可能性がある。

84 :仕様書無しさん:2006/08/07(月) 06:21:43
>>81
別にそんなに宣言しないでも
おれもいったん実装してから書いてる。一通り実装してこれで詳細
設計に問題なさそうと感じてから書いてる

85 :仕様書無しさん:2006/08/07(月) 11:03:50
俺のソースはコンパイラすら通らないぜ

86 :仕様書無しさん:2006/08/08(火) 00:17:48
コンパイルも静的テストの一種です。

87 :仕様書無しさん:2006/08/08(火) 02:51:32
ワーニング取りしてたらヤバイの見つける時あるよねw

88 :仕様書無しさん:2006/08/08(火) 12:06:37
コンパイラの警告は1つでも出たらダメだろ。

ずらずらと大量に警告が出ていると、
いつの間にか無視できない警告が加わっても、
気がつかないぞ。

89 :仕様書無しさん:2006/08/09(水) 23:30:52
>>88
いまだに動けばいいって奴多いよ・・・
しかも調べる能力も無いから放置だしw

コンパイラの警告は無くてもFindBugで怒られるw

90 :仕様書無しさん:2006/08/12(土) 16:15:43
>>89
怖い所だとエクリプスのコンパイラ設定を全部無視とかやる所あるぞ

91 :仕様書無しさん:2006/08/12(土) 16:27:48
警告抑止のオプションだけはやたら詳しいヤツがいる。
そんなもん調べてる暇があったら他のことしろよ。

92 :仕様書無しさん:2006/08/12(土) 16:35:46
>>89のレスに矛盾を感じる。>>89も調べる能力がありませんって言ってる?

93 :仕様書無しさん:2006/08/12(土) 16:42:01
>>92
うんw無くていいやwww

94 :仕様書無しさん:2006/08/13(日) 09:56:10
ソフトウェア・テストPRESSという雑誌が出ているんだね。Vol1〜Vol3まで出ているようだ。
ソフトウェアテストの専門雑誌が出るなんて、一昔前には考えられなかったな。

95 :仕様書無しさん:2006/08/13(日) 22:19:29
GUI、特に画面表示部分のテストの自動化ってどうやってる?

やっぱ手動&目視しかないのかなぁ o...rz

96 :仕様書無しさん:2006/08/13(日) 22:21:54
写真屋も不良写真の判別は目視だからなぁ

97 :仕様書無しさん:2006/08/13(日) 22:27:45
>>94
開発形態が急激に変わっているからじゃないかな。
本に出してもすぐに内容が開発形態に合わなくなる。
だから雑誌にして定期的にだす需要が出てきた、と。
まあ、実際にはそれほど変わってないけどね、テストなんて

98 :仕様書無しさん:2006/08/13(日) 22:33:42
>>97
大分変わってきてるぞ
ユニットテストでテストツール使うとか10年前は実用的な話じゃなかったし、
ホワイトボックステストを自動化ツールで流すとかもマシンの性能的な問題で不可能だったが最近は出来るようになってるし

99 :仕様書無しさん:2006/08/13(日) 22:55:19
カバレッジテストツールとか昔はあったの?

100 :仕様書無しさん:2006/08/13(日) 22:57:27
>>94
それVol3はテストツールメーカのカタログと化しているんで買う価値ないぞ

101 :仕様書無しさん:2006/08/13(日) 22:58:04
>>100
うはw94じゃないけどさっき買ってきたよ・・・

102 :仕様書無しさん:2006/08/13(日) 22:58:40
sage忘れすまんこ

103 :94:2006/08/14(月) 08:46:13
>>100
そうなんだ、やっぱり売れてないのかな。
てか、俺も既に注文済みだった。w

104 :仕様書無しさん:2006/08/16(水) 04:43:08
「ソフトウェア・テストの技法」の第二版が出てるけど、
もう買った奴いる?
俺は立ち読みでスルーしちゃったけど。
あんまり一版と大差ないように思えたので。

105 :仕様書無しさん:2006/08/21(月) 00:14:34
Abbot使ったひといる?


106 :仕様書無しさん:2006/09/02(土) 00:48:36
どうでした、JSTQB?
俺? 撃沈orz

107 :仕様書無しさん:2006/09/10(日) 23:36:03
正直思ったより難しかったね
思いつきで出版した対策本読んだのがいかんかったか
でも、じじぃの漏れ様でも経験で多分合格だな

108 :仕様書無しさん:2006/09/11(月) 01:07:50
導入立会いにいくとSEが要件定義をはじめている
待機室で新機能が搭載される
コンパイルが通れば稼動中でも本番アップする
現場でエラー発覚→待機室でデバッグを繰り返す
業務終了までに直らない&常駐系&通信系を徹夜で直す


うちの課長が定例会議で開発問題点があればディスカッションするというから
SE(またはその指示)によるテスト工程がない事を問題提起したら
単体テストをしない無責任扱いされたよ。
来月辞めるからいいけどっ

109 :仕様書無しさん:2006/09/11(月) 21:07:05
TEFのMLで釣りを始めた香具師がおるな


110 :仕様書無しさん:2006/09/12(火) 08:12:31
>>104
買ったけど、翻訳の質が酷くないか?

111 :仕様書無しさん:2006/09/18(月) 20:57:35
>>109
消えたな。こことMLが同じだと勘違いしてるふうだったから当然か。

112 :仕様書無しさん:2006/09/27(水) 21:02:20
JSTQBって結局いつ結果がわかるんだろう?
1ヶ月後? 3ヵ月後?

113 :仕様書無しさん:2006/09/29(金) 10:28:18
来週くらいじゃね?!

114 :仕様書無しさん:2006/09/30(土) 19:12:38
合格発表あったぞ
http://www.swtest.jp/certification.html

ちなみに、漏れおじさんだが、(107、113)どうにか合格したぞ
やれやれ;; 正直、簡単じゃなかた


115 :仕様書無しさん:2006/09/30(土) 19:34:00
受験票を職場に置いてきたので、自分の受験番号がわからない。
月曜まで我慢か。

116 :仕様書無しさん:2006/10/01(日) 01:15:37
しっかりせんかい


117 :115:2006/10/02(月) 20:42:27
合格してた

118 :仕様書無しさん:2006/10/02(月) 22:08:16
>>117
おめでとー

119 :仕様書無しさん:2006/10/02(月) 23:03:36
おーめ^でとーさーん

120 :仕様書無しさん:2006/10/03(火) 07:06:45
落ちてる。宮城からの電車代、20Kが無駄にorz

121 :仕様書無しさん:2006/10/04(水) 21:13:51
再チャレンジ!!がんがれっ!!
っていっても受験代、異様に高いよね

122 :120:2006/10/05(木) 21:01:21
更に高い試験も受けたことがあるから諦めているけど、
東京と大阪のみで平日なのは勘弁して欲しいかも。
交通費と有給が必要だから。
プロメトリックとかにしてくれるとうれしい。


123 :仕様書無しさん:2006/10/05(木) 23:40:06
択一式試験なのに、マークーシートではなかったのには正直驚いた

124 :仕様書無しさん:2006/10/08(日) 07:34:36
マークシートで自動処理すれば試験代も少しは安くなりそうだが

125 :仕様書無しさん:2006/10/14(土) 18:46:03
合格証届いた?

126 :仕様書無しさん:2006/10/14(土) 21:49:56
北よ

127 :仕様書無しさん:2006/10/14(土) 22:16:18
なんか封もせずに送られてきたんだが。

128 :仕様書無しさん:2006/10/14(土) 22:37:29
さすがに封はテープで貼ってたな

129 :仕様書無しさん:2006/10/14(土) 23:11:02
テープを剥がしたような跡も無い。忘れたにしてはお粗末だな。
中身って、説明文書、証書、折り曲げ防止用の厚紙の3点?

130 :仕様書無しさん:2006/10/15(日) 00:40:52
イェ〜イ!!

131 :仕様書無しさん:2006/10/15(日) 00:42:16

テストなんて適当

132 :仕様書無しさん:2006/10/26(木) 21:07:12
おれの人生も適当

133 :仕様書無しさん:2006/10/26(木) 21:45:27
俺の人生だけOKがつかない

134 :仕様書無しさん:2006/10/26(木) 21:56:11
俺の人生、テスト漏れが多い

135 :仕様書無しさん:2006/10/26(木) 22:04:23
テストするまでもなくバグだらけです

136 :仕様書無しさん:2006/10/26(木) 22:23:58
オマイラ自虐ネタ大好きだなw

137 :仕様書無しさん:2006/10/26(木) 23:02:49
じゃあデバッグしてくれよ

138 :仕様書無しさん:2006/10/28(土) 10:49:57
作り直したほうが早いんじゃね

139 :仕様書無しさん:2006/10/28(土) 18:44:40
もう運用始めちゃったんだから作り直しは無理っぽい

140 :仕様書無しさん:2006/10/29(日) 19:00:15
俺、どうもマルチスレッドみたい

141 :仕様書無しさん:2006/11/07(火) 22:32:56
多重人格?

142 :仕様書無しさん:2006/11/13(月) 20:04:41
一応保守しとく

143 :仕様書無しさん:2006/11/18(土) 00:28:21
みんな結合テストとかシステムテストってどうやって見積もってるの?
いつも全体の何割とかにしてるからはずしまくる。。。

144 :仕様書無しさん:2006/11/20(月) 22:21:35
そのはずしまくった実績をためておけば
精度は上がってくるだろ???・

145 :仕様書無しさん:2006/11/22(水) 20:46:58
携帯電話開発の結合テストをやってるんですが、
納期に近づくほどテスト工数も項目数も膨れ上がります。
機能や顧客要求がどんどん追加されるからと言われ続けてるんですが、
これってやっぱり基本設計がおかしいのでは?

146 :仕様書無しさん:2006/11/22(水) 21:55:51
>>145
俺も携帯のテストをやっているんだけど携帯電話の業界そのものがおかしいんだよ。
企画の段階で考慮もされていない機能を何も考えずに追加するのが問題。
仕様変更で同じテスト項目を何回もやる場合があるけど
設計や開発が苦労して帳尻を合わせたのがわかって同情することがよくある。

147 :仕様書無しさん:2006/11/22(水) 22:34:16
>>145-146
「携帯 軍曹」 でググレ


148 :仕様書無しさん:2006/11/30(木) 23:02:00
漏れの所はコンパイラの最適化オプション変えただけで、全関数単体テストやり直し
(コンパイラが信用できないということで)なんですが、同じような事をやらされている人いますか?

149 :仕様書無しさん:2006/11/30(木) 23:47:06
>>148
単テやりなおしって言ってもUnit起動するだけだろ?

150 :仕様書無しさん:2006/12/01(金) 06:54:54
コンパイラの最適化オプションではなく、組織の最適化をすべきだったり

151 :仕様書無しさん:2006/12/01(金) 12:25:09
>>148
コンパイラのオプション変えたんなら普通だろ。
逆にテストをやらなくていいって発想の方が漏れにはわからん。
つうかプロジェクト途中でコンパイラのオプションを変える必要が発生したほうを問題視すべきじゃないか?


152 :148:2006/12/01(金) 20:03:43
単体テストと書いてしまいましたが,

関数毎にデバッガのステップ実行で分岐網羅を行い,
デバッガの画面キャプチャを証拠として残す、という事をやってます。
これも普通でしょうか?

153 :仕様書無しさん:2006/12/01(金) 22:53:37
>>152
化石がいっぱいある所ではまだ主流らしいな

154 :仕様書無しさん:2006/12/10(日) 04:36:11
カバレッジ分析ツール使うと楽なんだがなぁ。ないと激しくきつそうだ。
コストが安いならやるべき、と言いたいのだが…

155 :仕様書無しさん:2006/12/26(火) 22:38:51
テストを知れば知るほど、コーダに戻るのが怖くなってくるな〜

156 :仕様書無しさん:2007/01/07(日) 19:27:43
テスト技法やツールを知れば知るほど、今まで経験したプロジェクトは
本当に大丈夫だったのかって思う

157 :仕様書無しさん:2007/01/08(月) 02:57:44
「バッチ系のテスト・運用ツールの簡単な作成技法」を思いついたのですが、
どなたか、開発環境の提供と作業をお手伝いをしてくれる大学の研究室、または、企業はありませんか?
基本的には、環境さえ整えば、色々なOSで実現可能かと思います。
但し、あくまでも、技法ですので実行形式等の提供はありません。

以下の条件で実行可能です。
(1)制御言語が使える(例:sh)
(2)コンパイラー環境(例:COBOL)があり、ソースを自由に作成する事が可能
(3)上記コンパイラーでバッチコンパイル&実行が可能

※私が使い慣れた環境は、
OS=UNIX
制御言語=sh
コンパイラー=COBOL
です。

本当は、論文か何かで広めたら良いのかも知れませんが、色々と制約があり諦めました・・・

158 :仕様書無しさん:2007/01/08(月) 03:00:14
>>157
つ VMWare

159 :仕様書無しさん:2007/01/08(月) 07:43:56
その技法が既知でないか調査はしてるわけだよね、英論文も含めて。
あとは、特許をとれそうであるならば、その希望する扱い次第で大学か企業か個人か絞り込まれてくる。

160 :仕様書無しさん:2007/01/08(月) 21:16:46
>>159
うーん。特許は難しいかもね・・・
考え方だけだし・・・
他人のフンドシをちょっと借りる必要あるし・・・
実行形式の提供ないし・・・

でも、結構便利なので、広められたらいいなと思ってる・・・

161 :仕様書無しさん:2007/01/10(水) 22:51:47
>>160
そんなこと言ったって、
それがどれ程のものなのか、
まるっきり分からない以上、
誰も手を出す訳ないだろ?


162 :仕様書無しさん:2007/01/10(水) 22:54:12
>>160
うん。もういいよ。別スレ立ててやって

163 :仕様書無しさん:2007/01/11(木) 07:16:22
小さな会社だからテストは不要、みたいな考えの管理職が多い気がする


164 :仕様書無しさん:2007/01/15(月) 21:48:55
そろそろ二回目のJSTQBなわけだが

165 :仕様書無しさん:2007/01/17(水) 22:01:51
ttp://seshop.com/detail.asp?pid=7613

166 :仕様書無しさん:2007/01/18(木) 18:56:04
JSTQB 受験している人いるの?

167 :仕様書無しさん:2007/02/11(日) 09:18:57
ノシ

ソフトウェアテストを体系的に学習したいって人に
とっては、有意義だと思う。

ただ、受験料\21,000に見合うかどうかはその人次第。

168 :仕様書無しさん:2007/02/11(日) 09:38:32
報告書に「プログラマの質が悪いために××機能で異常な動作をするケースがあり、要注視」と懸念事項を書いたら
プログラマたちの所属する会社からクレームを受けますた。

169 :仕様書無しさん:2007/02/11(日) 13:22:06
>>168
誤:プログラマの質
正:まともな要求の出来ない>>168

170 :仕様書無しさん:2007/02/11(日) 13:33:57
>>169
>>168の書き込みが癇に触ったのか?

171 :仕様書無しさん:2007/02/11(日) 13:51:51
>>170
ごめん、そんな低レベルな管理方法試した事無いから

172 :仕様書無しさん:2007/02/11(日) 19:46:20
あー鬼太郎になりたい…

173 :仕様書無しさん:2007/02/11(日) 22:56:52
>>168
何をもってプログラマの質が悪いと判断したのかわからんが、
文書で非難する場合、明確な証拠がないと、荒れまっせ。

174 :仕様書無しさん:2007/02/12(月) 09:49:07
バグが出て、ハードコピーを付け、バグの再現手順方法まで細かく書いてるのに、再現しませんとバグジラに回答してくる性格の悪いプログラマ、マジでイラン。
明日彼のクビが切られるからいいけど。。。

175 :仕様書無しさん:2007/02/14(水) 23:56:33
俺の場合自分が作ったソフトで発生したバグはこっそり
修正してバグが無かった事にしてる。

他人が作った部分で発覚したバグは、親の仇の様に捲くし立てる。

ストレス解消ですよ^^;

176 :仕様書無しさん:2007/02/15(木) 00:06:42
哀れなやつ

177 :仕様書無しさん:2007/02/15(木) 00:11:06
なんかひどいスレだな。

178 :仕様書無しさん:2007/02/15(木) 00:24:59
春だからな・・・なんでこんなトコ来るか知らんが

179 :175:2007/02/15(木) 01:56:56
ストレス解消ですよ。
すっきりーしないとね。

もわぁっとしてたらダメでやんす。

180 :仕様書無しさん:2007/02/15(木) 07:05:59
まあ、テスト結果全部嘘なんだけどなw
だってテスト項目作るのからいって半端じゃねぇし。
そもそもテスト項目いくつに付き、いくつバグが必要ってのもわけわからんし。
こういうの大量に作らなきゃいけないってところから作業を定量化するには機械的にバグ数決めたほうが作るの楽なんだよねw

大手の上の人間が何考えてるのか知らないけど、
俺は本音をいうとテスト結果は嘘情報しか挙げたことない。
他の奴のもみんなまじめにやってるのかと思ってチェックしてみたけどみんな嘘ばっかりw

181 :仕様書無しさん:2007/02/15(木) 08:02:07
>>180
まぁお前の人生自体が嘘だらけだからなw

182 :田崎:2007/02/15(木) 21:46:55
私もテスト結果偽装してるよ。

伊達に目立ち情報をバックレタ女じゃないよぉw

183 :仕様書無しさん:2007/03/22(木) 23:36:43
ほしゅ

184 :仕様書無しさん:2007/03/23(金) 00:06:54
保守必要だったか?いらないだろこのスレ

185 :仕様書無しさん:2007/06/03(日) 20:39:55
単調ですか?

186 :仕様書無しさん:2007/06/03(日) 20:56:09
昔のシステムエンジニアです。
銀行、今問題の官公庁、ト○タの経理システム作っていた。

本当か、テスト結果偽装なんて
まったく最近のやつらテストもまともにやらないから
ANNみたいな大規模なミスするんだな

187 :仕様書無しさん:2007/06/03(日) 21:42:39
ANNって何?

188 :仕様書無しさん:2007/06/09(土) 12:16:04
テスト結果を偽装する理由は求められているテスト結果がバカげてるから
真面目にやると不具合でないから、テストちゃんとやってる感のある不具合を捏造する
エラーログ出力時の関数番号が間違ってたとか

189 :仕様書無しさん:2007/06/10(日) 17:59:12
ttp://www.asahi.com/life/update/0610/TKY200706100085.html
年金オンラインシステムが一時ダウン 社保事務所

2007年06月10日13時17分

 社会保険庁が10日に日曜日としては初めて実施した社会保険事務所窓口での年金相談で、
全国309の社会保険事務所のうち、神奈川、兵庫、福岡、沖縄などの130事務所と
東京都の社会保険業務センターで、年金記録確認のオンラインシステム端末が作動しなくなり、
開始時間の午前9時半から11時ごろまで相談に対応できなくなった。

 くわしい原因は調査中だが、初めて日曜日にシステムを立ち上げたことで社会保険業務センター内にある
システムのホストコンピューターの一部に不具合が発生したとみられる。

190 :仕様書無しさん:2007/07/16(月) 17:03:33
一ヶ月レス無しか

191 :仕様書無しさん:2007/07/18(水) 11:31:06
マイクロソフトの製品リリース・システム(CPX) ってなに?


192 :仕様書無しさん:2007/07/20(金) 08:53:26
なにそれ?

193 :仕様書無しさん:2007/08/02(木) 02:52:43
ここも過疎ってるよな・・

【テスター】 携帯電話の評価 【未経験可】
http://science6.2ch.net/test/read.cgi/infosys/1156776566/l50



194 :仕様書無しさん:2007/08/02(木) 03:36:06
大手はQAチーム作って結構失敗してるみたいだなw

195 :仕様書無しさん:2007/09/05(水) 23:20:18
ペアテストで、テスト工数削減&効率アップだぜー

196 :仕様書無しさん:2007/09/06(木) 06:45:16
ノーテストで、テスト工数激減&デスマ率アップだぜー

197 :仕様書無しさん:2007/10/30(火) 07:37:47
デスマだから、ノーテストになるのであって、
ノーテストだからデスマになるんじゃない、
PGは、みんな、まともなテスト期間が欲しいと思ってるのよ。

198 :仕様書無しさん:2007/12/01(土) 23:50:49
あげ

199 :仕様書無しさん:2007/12/02(日) 02:26:02
JUNITとか使うと開発工数2倍に膨らんだりする?
実際のプロジェクトで有効に使ってるやついるの?

200 :仕様書無しさん:2007/12/02(日) 02:45:23
JUnit使わない方が工数かかるだろ。
というか、まだJUnit使ってない所があるのかよ・・・

201 :仕様書無しさん:2007/12/02(日) 10:19:00
JUnitのTestCaseとExcelのテスト仕様書の同期を取るのがめんどいんだけど,
何か良いツール無い?
アノテーションとかにテスト内容記述したりしてさ.
無いなら自分で作れ,とか言わないでね(はぁと

202 :仕様書無しさん:2007/12/02(日) 11:24:20
>>201
TestLinkってのがあるみたいね、使った事無いけど

203 :仕様書無しさん:2007/12/02(日) 16:00:27
スクウェア・エニックスに入社して、ファイナルファンタジーXIのスタッフにしてもらえれば

仕様設計・・・1割
仕様検討・・・0.85割
コーディング・・・8割
テスト・・・0.15割

で仕事できるよ


204 :仕様書無しさん:2007/12/02(日) 16:14:19
テスト関連スレで単体・結合分けないってどんだけだよ

205 :仕様書無しさん:2007/12/02(日) 16:43:08
>203
本当か?、テレビで見たけど
福岡の外注に作らせていたぞ(ドラクエだったかな?)

206 :仕様書無しさん:2007/12/02(日) 17:27:57
>>203
それはテスト部隊が別にいるからでしょ。


207 :仕様書無しさん:2007/12/03(月) 01:56:16
>>206
テスト部隊いないだろ・・・あれ

いたとしたら、時給20円ぐらいの仕事しかしてないぞ

208 :仕様書無しさん:2008/03/05(水) 00:39:05
TestLink使ってる人いる?

209 :仕様書無しさん:2008/03/05(水) 01:38:27
テスターよりも倖田のほうがいい。

210 :仕様書無しさん:2008/03/05(水) 12:51:36
ゲームのテストはテスト仕様書なしのランダム試験しかしないよ

211 :仕様書無しさん:2008/03/15(土) 03:44:26
ぬるぽに数時間食われた
コード書いた奴は表出ろ
そんなので時間潰してる俺もやめちまえ

212 :仕様書無しさん:2008/03/15(土) 23:15:41
>>211
両方自分だったりして

213 :仕様書無しさん:2008/05/04(日) 12:05:38
JUnitで作った単体テストってみんな仕様書に落とし込んだりしてるの?
なんか、無駄すぎる気がしてうちでは落とし込んでないんだけど。

テスターに頼むテストはテストケース作って実施してもらってるけど、
そのテストケースを管理するのがめんどくせぇ。

214 :仕様書無しさん:2008/05/04(日) 13:10:02
>>213
JUnit項目はjavaDoc提出したかな
ケースレビューしてケース出してskeleton+javaDoc書く。
ケース実装者に伝える意味でも使えるし。(実際は自分で書いたから思い出し用になってたな)

>そのテストケースを管理するのがめんどくせぇ。
その「管理」って何指してる?
Version管理なら色々あるし、実projectにコミット権限与えたくなければTest用Project立てればいいし。


なんとなくage

215 :仕様書無しさん:2008/11/11(火) 10:55:46
ぬるほ
ぬるほ

216 :仕様書無しさん:2008/12/02(火) 23:57:34
ぬるほ
ぬるほ

217 :仕様書無しさん:2008/12/03(水) 00:12:22
かっ

218 :仕様書無しさん:2008/12/22(月) 04:01:51
ぬるほ
ぬるほ

219 :仕様書無しさん:2008/12/22(月) 12:57:41
>>218
かっ

220 :nanasi:2009/01/28(水) 01:47:30
ぬるほ
ぬるほ

221 :ひとみ:2009/01/29(木) 20:44:36
遊んでくれる人いますか〜^^ 28才 独身です。                        

222 :仕様書無しさん:2009/01/29(木) 20:50:10
スパムソフトのテスト乙。

223 :仕様書無しさん:2009/06/22(月) 06:18:55
ぬるぽ
ぬるぽ

224 :仕様書無しさん:2009/06/24(水) 22:47:44
このたびシステムテスト工程のお手伝いでプロジェクトにアサインされたんですが、
なんか「タグチメソッドで何でも解決」「直交表は万能」とか、単体/結合テストレベルでは
耳にしたことのない用語が宗教的に蔓延してるんです。
「タグチメソッドは最強」とか「直交表は正義」とか。偉い先生の作った理論というのは
わかったのですが、入門書見ると製造工程の品質管理に関する理論ぽくて、ソフトウェア開発に
向いてないんじゃないかと一人疑問を抱いてます。
なんか機械的に作られた表に従ってテスト項目作ってるけど、傍目にも足りなく見えるし。

 これって本当に大丈夫?


225 :仕様書無しさん:2009/06/24(水) 22:58:22
>タグチメソッド
>直交表
アウトー!!

226 :仕様書無しさん:2009/06/25(木) 00:10:40
>>3
>椅子が要らない分コスト削減となる。

キャノン思い出した。画期的ですね。

227 :仕様書無しさん:2009/06/25(木) 07:28:02
タグチメソッドは知らないけど、直交表は有効だよ。
どこで何を調べて使えないと思ったのかわからないけど、ソフトウェアテストの文脈で
使われる直交表を調べる必要があると思うよ。
簡単に言うと、組み合わせ爆発するようなテストで、効率よく(漏れが全くないという
意味ではない)テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ?

228 :仕様書無しさん:2009/06/25(木) 17:33:15
ためになったねぇ〜

229 :ひとみ:2009/07/05(日) 20:53:53
夫とはレスだし、もっとドキドキする瞬間がほしぃttp://hi-meetinng.com/shokaijo/

230 :仕様書無しさん:2009/08/06(木) 02:07:05
直交表でテストパターンを選ぶと,何がうれしいんだい?
いままでのテスト方法とどんな差があるのか説明してみろ.

231 :仕様書無しさん:2009/08/06(木) 05:00:26
test test

232 :仕様書無しさん:2009/08/06(木) 12:34:04
>>230
簡単に言うと、組み合わせ爆発するようなテストで、効率よく(漏れが全くないという
意味ではない)テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ?

233 :仕様書無しさん:2009/08/08(土) 05:28:45
>232

なんだ。今までのテストとおなじじゃん。

234 :仕様書無しさん:2009/08/09(日) 19:27:56
>232

タグチであたまのいかれたソフトテスト椰子がつくったあほらしー手法。

235 :仕様書無しさん:2009/08/09(日) 22:30:27
>232

直交表で選ばれるテスト条件に都合よくバグがあるというお花畑理論が、あいかわらず痛々しい。

236 :仕様書無しさん:2009/08/09(日) 23:19:07
なにこいつw

いつまで絡む気だよw

237 :仕様書無しさん:2009/08/09(日) 23:40:51
とりあえず、絶対にバグが起こってはいけない組み合わせだけで良くない?

238 :仕様書無しさん:2009/08/09(日) 23:56:32
 俺も詳しいわけではないので、間違いがあったら済まんが、だいたい以下の通りらしい。

・単純に全組み合わせを試した場合、組み合わせ爆発ももちろんのこと、重複するテストがガンガンに行われるため、
 非常に効率が悪い。
・統計学的にみて、複数機能組み合わせによるバグの内、「機能2つの組み合わせ」によるバグは、全体の8割以上である。
・直交表は数学的アプローチにより、「機能2つの組み合わせ」テストを100%満たしつつ、3つ以上の組み合わせテストも
 大半を満たすことが出来、かつ重複を最小限に押さえた組み合わせ表を得ることが出来る。
・ただし、禁則(あり得ない組み合わせ)とかまでを考慮に入れたカバーが出来るわけではない。実際のテスト項目書作成
 に当たってはその辺のノウハウが重要で、それだけで本が2,3冊かけるほど。
 わからんまま流行だからと導入しても痛い目を見るので、素人にはお勧めできない。

 ……と言うことらしい。
#詳しくは詳しい本に当たってくれ。

239 :仕様書無しさん:2009/08/10(月) 11:27:34
>>235
んじゃ、100億通りのマニュアルテストでもやっとけ、猿

240 :仕様書無しさん:2009/08/10(月) 12:39:14
>239
↑馬鹿か!そういう単細胞がタグチの餌食

241 :仕様書無しさん:2009/08/10(月) 14:57:10
永遠に、俺メソッドでガラパゴって下さい

242 :仕様書無しさん:2009/08/10(月) 15:15:17
一生懸命disってる奴の目的が分からん。

243 :仕様書無しさん:2009/08/13(木) 22:49:32
>238
ありがとう。

>242
disってるって、馬鹿にしているという意味か?おかしな言葉やめようよ。240のいうとおり、
数学が苦手でも、ある一定の手順で答えが導けた気がする田口メソッド一派に取り込まれて
気がついたら自分も田口メソッド使いの端くれになって、でも田口メソッドの真髄は理解
できないまま、線点表みたいな直交表を変形させるヒューリスティックをいじくって初学者
を馬鹿にしまくって、田口メソッドで問題が解けませんと言われたら、お前に技術がない
からだとふんぞり返って、人を小ばかにして去っていく連中を非難して排除して何が悪い。


まさに238のいう素人にはお勧めできない、だからタグチストの俺様が解いてしんぜようという
ことが平気で起きる。直交表なんて簡単に作れるのにね。

>239
おまえ、自動テストのこといってる?直交表=自動テストぢゃないぞ。

238のいってる2つの組み合わせで8割うんぬんは、ある文献の一部をつまんだもの。
その先を読んだら、そんなに都合がよければ苦労はないとちゃんと書いてある。



244 :仕様書無しさん:2009/08/13(木) 22:52:13
>>243
disってますねw

245 :仕様書無しさん:2009/08/14(金) 05:28:33
実際のところ、『誰でも理解可能で効率の良い(≠完全網羅)』システムテストの項目作成なんて無いからねえ。
小規模なものならいざしらず、オープン系で複数拠点、多重化でバッチ処理で24h365day〜とかなると泣ける。


246 :仕様書無しさん:2009/08/14(金) 10:35:55
disrespectか
disという語自体は否定の接頭辞で特に意味はないんだが
作者も読者も頭の悪さが滲み出てるな

まあそのうちよろしく頼むわ、先輩

247 :仕様書無しさん:2009/08/14(金) 14:56:32
なんだそのナメた態度は
ぶっ数すぞ


248 :仕様書無しさん:2009/08/14(金) 18:43:32
ぶっすうすぞ?
ぶっかずすぞ?

あたまわるそう

249 :仕様書無しさん:2009/08/15(土) 11:54:57
>>248
マジレスwwww

250 :仕様書無しさん:2009/08/15(土) 13:42:19
>249
ねたにマジレス

251 :仕様書無しさん:2009/08/17(月) 13:01:38
なんか湧いてんな、一般的な知識足りない辺り院生か?

>まあそのうちよろしく頼むわ、先輩
まあそのうち現実思い知るよ

252 :仕様書無しさん:2009/08/17(月) 16:18:17
なんの現実かはあんまり考えたくないな

253 :仕様書無しさん:2009/08/19(水) 08:01:11
何についてもそうだけど、『作りました、お仕舞い』では済まないというのは、知識は兎も角現実として認識するまで結構かかったかな。
卒後しばらくは指示通りやる操り人形だし、上流下流まで目が届くようになってはじめて意識したような。


254 :仕様書無しさん:2009/08/26(水) 07:53:15
学校レベルでできる人ほどテストをおざなりにしがち

255 :仕様書無しさん:2009/08/26(水) 17:37:31
学校レベルでできない人のテストほど信頼できないものはない

256 :仕様書無しさん:2009/08/26(水) 23:02:23
自分のテストほど信頼できないものはない

257 :仕様書無しさん:2009/08/26(水) 23:05:04
といってツールが信頼できるわけでもない

258 :仕様書無しさん:2009/08/29(土) 17:14:16
永遠にTメソッドでガラパゴってHAYST法つくったぉ(w)。直交表も悪くは
ねぇべぇ、でも、タグチが提案した手法のうわっつらをチマチマいじって、
タグチではないような顔で売りまくろうとする魂胆が今一つわからん。
どこをどういじったか、素直に説明すりゃいいじゃん。>何もないってか?

それと、ソフトウェアテストはあくまで後追いのもの、どんなテスト手法も
完全ではない。網羅率の背比べは意味なさげと思うがどんなもんだろなぁ。

259 :aa:2009/10/19(月) 00:46:07
aa

260 :仕様書無しさん:2009/11/22(日) 20:31:17
日本規格協会「標準化と品質管理」誌12月号「読むだけでわかる品質工学」(著者:長谷部光雄)の
中の「直交表によるソフトウェア検査」の提灯持ちは無責任。コーディング経験もろくにないのに。
この日本発ソフトウェアテスト技法は結局タグチメソッド崩れ。どんなに愚劣なものかよくわかった。

261 :仕様書無しさん:2009/11/22(日) 21:47:51
いや、だから君が100万通りのマニュアルテストを誰も止めないって

262 :仕様書無しさん:2009/11/22(日) 22:15:36
〆切内に終わらせる限り、と注釈がつくw

263 :仕様書無しさん:2009/11/22(日) 22:50:43
そもそも、コーディング段階でバグがあるのはソフトウェアの基本機能からはずれてる、と思うが

264 :仕様書無しさん:2009/11/23(月) 04:12:03
そうですか

265 :仕様書無しさん:2009/11/23(月) 11:14:57
掛け合い漫才になったが、>>260 「標準化と品質管理」誌の提灯持ちがひどいから、世間のために補足。

ソフトは本来ねらい通りに動くのが特徴で、これを大きな利点として、まず、十分に活用しない手はない。
最終テストよりも前に、コーディング段階で徹底的な動作確認を1つ1つ積み重ねていくことが重要。

ハードのものづくりは最初からばらつきに悩まされてねらい通りのものが簡単にはできない。タグチも、
統計手法も、基本の目的はハードの仕上がり管理だから、ソフトに持ち込むと見当はずれになりがち。

266 :仕様書無しさん:2009/11/24(火) 07:09:28
具体的に書けよクズ

267 :仕様書無しさん:2009/11/24(火) 22:02:49
>>266 ん?、そうだなぁ・・・

ソフトは仕上がったらそのまま動くよう1行1行を確認しながら作るのが基本。
ハードはばらつきを避けられず仕上がりが成り行きになるから統計手法が必要。

直交表は一般平均と主効果とだけが存在すると仮定して実験数を節約するが、
仮定が成り立つかどうかソフトの場合でもハードの場合でも予知はできない。

268 :仕様書無しさん:2009/11/25(水) 02:04:05
あー、何となくだけどいいたいことわかるわ

269 :仕様書無しさん:2009/11/25(水) 02:16:43
よく分からんのだが、どんな場合にそんな100万通りもの組み合わせテストが必要な状況があるんだろか?
具体的な例が知りたいなぁ


270 :仕様書無しさん:2009/11/25(水) 10:22:16
>>269
例えば、
OS,SPの組み合わせ = 10
ブラウザの種類とそれぞれのバージョン = 15
ユーザ権限 = 2
プリンタの種類 = 15
機能の数 = 20
テストシナリオ = 20
全部の組み合わせは、10×15×2×15×20×20 = 180万

みたいな感じで、ハード・基盤ソフト・機能の組み合わせを網羅させると、簡単に100万超えるよ。

271 :仕様書無しさん:2009/11/25(水) 10:40:16
ソフトによっては、ファイルシステムの種類とか、アロケーションユニットサイズの種類とか、
インストールされているアンチウィルスの種類とか、組み合わせが爆発する因子はそこここにあるでしょ。

272 :仕様書無しさん:2009/11/25(水) 11:41:47
>>270
数はさておいて「全部をこなさなければならない状況」を聞きたいんじゃ無かろうかと。

 コンシューマとは状況が異なるけども、たとえば医療機器、原子力関連と言った、肝心なときに
ハングアップしたらたまらない装置なんかだと、可能な限りのパターンを尽くすとは聞くね。
どんなことやってるのか想像もつかないけど、軍事とか航空宇宙関連もそのはず。

273 :仕様書無しさん:2009/11/25(水) 12:33:26
>>272
どんなに組み合わせが多かろうと、全部やらなきゃならないんだったら、テスト手法はいらないよね。

274 :仕様書無しさん:2009/11/25(水) 16:08:49
>>267
「標準化と品質管理」のどこがどう違ってるのか指摘しないと、さっぱり意味不明なんだが。

275 :仕様書無しさん:2009/11/25(水) 19:47:36
>>274

ハード製品の検査で実験数を直交表で節約する話のついでにソフトの検査でも条件数を節約できると
著者(この場合、長谷部光雄氏)は言ってるが見当はずれだし楽観的過ぎると思う >>260 263 265 267

品質工学系の著者は、長谷部氏とかぎらず、品質工学ありき、タグチありき、で、読者にまかせるという
ことがなく、規格協会なんかの旗印を錦の御旗に、とにかく強引に押し付けてくるのがかなわぬ。

276 :仕様書無しさん:2009/11/25(水) 20:15:15
いやだからお前が100万通りのマニュアルテストをしても、誰も止めないったら

277 :仕様書無しさん:2009/11/25(水) 20:25:12
品質保証って、デバッグじゃないんだけど


278 :仕様書無しさん:2009/11/25(水) 21:30:47
>>276 100万回を直交表で減らすか、ほかの方法で減らすか、いろいろあるはずだから

>>277 長谷部氏はデバッグを言ってるが、デバッグではない品質保証となると、直交表も使えるかも
しれない。でも、直交表だけにしばられ過ぎる必要はないと思う

>>275 もともと「読むだけでわかる品質工学」という連載、素人を唸ならせて信者にしたくて、
粗雑、日本発の管理技術としてhaystなんかを売りまくろうという浅薄な根性と根は同じ

279 :仕様書無しさん:2009/11/26(木) 07:35:59
なんだ私怨か

280 :仕様書無しさん:2009/11/26(木) 22:11:30
>>278 は誰も恨んでないから、私怨はなかろ

281 :仕様書無しさん:2009/11/26(木) 22:55:50
最近xUnitを使い始めたが、テストが大変になった
上手いやり方って、しらないか?
俺は、メソッド毎にテストをしているが、シナリオベースでやった方がいいのか?

メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
教えてくれ

282 :仕様書無しさん:2009/11/26(木) 22:59:09
初期化が大変でも個別にやっといた方が後で楽になるような?

283 :仕様書無しさん:2009/11/27(金) 00:51:55
テストが簡単になるように、メソッドを設計・実装すればいい。
凝集度を上げ、結合度を下げる。

284 :仕様書無しさん:2009/11/27(金) 23:43:35
複数のメソッドを動かしている呼び元みたいな所をテストする
シナリオ(?)の単位が分からないが、そーゆーことかも

まぁそんなテストはもう"単体テスト"じゃないんだが

285 :仕様書無しさん:2009/11/27(金) 23:57:34
シナリオと聞いてピンと来ないような人のレスは希望していません

286 :仕様書無しさん:2009/11/28(土) 02:13:30
工数膨大にしないと金が貰えないからな。
試験を請け負ってる会社はみんなおんなじ。
工数を爆発させて人足をたくさんいれて、その分予算も引っ張る。


287 :281:2009/11/28(土) 05:19:02
>>282
その話は、よく聞くが後からそんなにテストするか?
クラスを継承で拡張していけば、そんなにテストすることもないと思うが

>>283
>テストが簡単になるように、メソッドを設計・実装すればいい。
TDDのやり方だと思うが、その考えは良いのか?
俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが

それに、自分が作っていない標準ライブラリの初期化とかが結構大変

>>286
金額関係なしに、工数を減らしたいんだが

288 :仕様書無しさん:2009/11/28(土) 08:26:52
>>287
>それに、自分が作っていない標準ライブラリの初期化とかが結構大変
ほとんどのOSSはunitのサポートしてないか?
ライブラリ初期化が嫌ならモック作れば?

>金額関係なしに、工数を減らしたいんだが
xUnit導入で品質上げたいんじゃないのか?開発工数を減らしたいのか?
品質あげて工数減らすっていい考えだなw

289 :仕様書無しさん:2009/11/28(土) 08:51:27
>>288
> 品質あげて工数減らすっていい考えだなw

 開発手法にしろテスト手法にしろ、品質の向上と工数の削減が主な目的でしょ。
手戻りの発生を最小限に抑える(リリース後バグ発覚も含め)意味で。

 (開発環境付属の)標準ライブラリの検証ってどの辺までやる?
そこでバグ埋められたら洒落にならんけども、過去何度か実例がある。

290 :281:2009/11/28(土) 11:31:37
>>288
>ライブラリ初期化が嫌ならモック作れば?
その方が工数は増えると思うが、どんなんだ?

>xUnit導入で品質上げたいんじゃないのか?開発工数を減らしたいのか?
xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問?

>品質あげて工数減らすっていい考えだなw
品質を下げて工数を減らしたいとは思わない、品質は同程度以上で工数を減らしたい

>>289
>(開発環境付属の)標準ライブラリの検証ってどの辺までやる?
基本行わない、プロジェクト内で作った標準のライブラリすら行わない
自分担当の部分だけをテストする、もちろん影響があれば、調査するが


俺の既存方法の単体テストは、プログラムをステップ実行で動かして
変数に値が設定されている事や、別メソッドが呼ばれている事を確認しながら
カバレッジ(条件網羅)が100%になるまで行う(もちろん、限界値なども行う)
あと、カバレッジ100%にする為に、、値をデバッグで変更してでも行っている
典型的なホワイトボックステストだが、それに比べて
xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか?

291 :仕様書無しさん:2009/11/29(日) 23:41:52
うぜーよ
聞く耳持たないんだったら、自分のやり方で今後も行け馬鹿

292 :仕様書無しさん:2009/11/30(月) 00:10:58
>>287
そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。

>俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
>あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが

OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。

>>290
> その方が工数は増えると思うが、どんなんだ?
増えない。

> xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
> 勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問?

繰り返し出来ると言うことは、ありがちな「知らない間にデグレードしてた」とか「この修正が
思わぬ所に影響してた」なんてことがなくなるよ。

> xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか?

xUnitはホワイトボックステスト。普通はステップ実行しないよ。

293 :仕様書無しさん:2009/11/30(月) 00:20:52
ブラックボックステストにも使おうと思えば使えるけどな

294 :仕様書無しさん:2009/11/30(月) 00:38:08
OOPから設計から工数のスコープまで色々怪しすぎる
どこか一つ出来るようになってから考えろよ

295 :仕様書無しさん:2009/11/30(月) 00:59:40
俺様の設計は至高の設計、と勘違いしてんだろ

296 :仕様書無しさん:2009/11/30(月) 01:02:09
他人が、自分のコードを変更したり、バグフィックスしたり、十分な時間経過の後に自分がコードを触るときに
実装内容を忘れてるなんてことを考えないのかしら。

297 :仕様書無しさん:2009/11/30(月) 01:21:20
IDEでステップ実行しながら変数の内容を調べるなんて、ド素人もいいとこじゃん。
何で本気で相手してんの、みんな。

298 :仕様書無しさん:2009/11/30(月) 02:10:14
プロジェクトの終盤で仕様変更が入りまくる状況でテストなんて無意味。
家建ててる途中で部屋ふやせって言ってるようなもん。

299 :仕様書無しさん:2009/11/30(月) 02:11:25
そういうときこそ再帰テストの有無が物を言うんじゃ?

300 :orz:2009/11/30(月) 02:14:45
×再帰テスト
○回帰テスト

301 :仕様書無しさん:2009/11/30(月) 03:20:43
実装の継承はSTLでもjavaでも普通に行われてるのに
否定してる奴は原理主義者か何かか?w

工数を滅茶苦茶掛けてテストしてそうなところも
気になるな

時間は関係ないプロジェクトなら別にいいがw

302 :仕様書無しさん:2009/11/30(月) 08:09:57
>>301
煽ってる暇があったら勉強しろよ
滅茶苦茶掛けてテストしてはない、ちゃんと計算+経験の適性工数だ

303 :仕様書無しさん:2009/11/30(月) 10:16:02
>>301
今日本10冊買って帰れアホ

304 :仕様書無しさん:2009/11/30(月) 13:22:53
>>301
なぁ、お前を擁護する人間が出てこないことをどう思う?

305 :仕様書無しさん:2009/11/30(月) 15:32:47
ところで281のところでは、テスト結果の妥当性確認はどのように行うのだろうか。
ステップ実行しながら動作確認をしているところを、別の担当者が見てたりして。

306 :仕様書無しさん:2009/11/30(月) 17:50:04
>>301
デザインパターンを勉強すべし。

307 :仕様書無しさん:2009/11/30(月) 18:57:43
工数を出そうが出すまいが
テスト分の工数は滅茶苦茶掛かるじゃねーかよw
アホかwww

テストまでまとまった工数掛けて
さらにデバッグ工数も普通に取るんだろ?

無能な癖に開き直ってんじゃねーよ

こっちはそんなもん導入しなくても品質くらい保てるんだよ、カス

と言っておくw

308 :仕様書無しさん:2009/11/30(月) 19:32:46
>>307
>>291

309 :仕様書無しさん:2009/11/30(月) 19:47:13
黙れ詐欺師w
って思ってる奴が他にもいるって事や

310 :仕様書無しさん:2009/11/30(月) 20:13:25
テストケースとか考えないで、やってたら、泥沼だろ

311 :仕様書無しさん:2009/11/30(月) 20:41:02
>>310
雑魚プログラマ揃いの場合はそうだなw

312 :仕様書無しさん:2009/11/30(月) 21:08:54
結合度も凝集度も考えずに家系図的な継承しか知らなかった奴がなにをほざいても無駄

313 :仕様書無しさん:2009/11/30(月) 21:12:29
うわ、こいつ自分が雑魚じゃないって思ってるみたいだぞ。

314 :仕様書無しさん:2009/11/30(月) 21:45:53
こういう根拠のない自信を持った馬鹿が、たぶんこいつの会社のトップクラスの技術レベルなんだぜ・・・

315 :仕様書無しさん:2009/11/30(月) 21:51:45
>>307
デバッグ工数って何?

316 :仕様書無しさん:2009/11/30(月) 22:00:48
今日必死こいて単体試験仕様書作ってたんだが、作ってる最中にこんなのいらなくね?って思ってきたんだけど、いらんよなこれ?w
500行ぐらいのソースに3日ぐらいかけて単体試験仕様書作って、よっこらよっこらしてんだけどw
ここは網羅されていない!とか上司に怒鳴られて、作り直しばっかりww

ソースを追いながら試験作れ!って言われて、デバッグしながら単体試験仕様書作ってるもんだから、実際試験したら絶対OKなわけw
デキレースすぎる試験になんの意味あんの?w


317 :仕様書無しさん:2009/11/30(月) 22:09:05
>>316
自分で勉強するつもりがないなら、素直に上司に従っとけアホ

318 :仕様書無しさん:2009/11/30(月) 22:09:48
>>312
形から入っても雑魚は雑魚だからw
ボンクラ揃いで今日もプロジェクト大赤字か?

グダグダくだらない事にばかり拘って
やってるからだ
残念だったなw

319 :仕様書無しさん:2009/11/30(月) 22:11:21
直交表馬鹿がいなくなったと思ったら、また香ばしい奴が登場だな

320 :仕様書無しさん:2009/11/30(月) 22:12:44
>>281=>>316
お前、派遣テスターじゃねーの?

321 :仕様書無しさん:2009/11/30(月) 22:15:15
詐欺師も何かを導入したときの成果を
給料にダイレクトに反映すれば少しはマシになるんだが
会社の金で実験君する気満々だからなw

無駄にプロジェクトを長期化する事しか考えてねぇww

322 :仕様書無しさん:2009/11/30(月) 22:16:06
>>316
ステップ実行しながら変数の内容を確認し、根拠無く「テストOKです」とか言う奴に対するおしおきでしょ。

323 :仕様書無しさん:2009/11/30(月) 22:19:07
学生〜新人1年目(稀に2年目)あたりが考えそうだよね。自分もそうだった。
今年派遣でやって来たドアホは、試験結果報告でっち上げまでしてサボった結果、
かなり愉快なタイミングでバグ発覚→報告書偽造が発覚し、会社ごとプロジェクトからパージされた。

324 :仕様書無しさん:2009/11/30(月) 22:21:27
見て確認してるんだから根拠はあるだろ、アホかw

テストに無駄な工数を掛けないつもりなら
全然アリだよ、穀潰しww

325 :仕様書無しさん:2009/11/30(月) 22:21:45
>>317
さーいえっさー!!
っていっても俺はいつでもYESマンだからwwwいつでも従ってるぜww

>>322
多分お仕置きだなwwwプログラムは完璧だとおもうしww絶対俺おしおきされてるw

326 :仕様書無しさん:2009/11/30(月) 22:25:09
>>281
とりあえず、これ読め。
『レガシーコード改善ガイド』
http://www.amazon.co.jp/dp/4798116831

お前が今量産しているのは、「レガシーコード」だ。

327 :仕様書無しさん:2009/11/30(月) 22:31:15
典型的な馬鹿上司の気分を満足させるための儀式になってるようだなw

予想通りすぎてフイタwww

328 :仕様書無しさん:2009/11/30(月) 22:41:23
>>326
ソースの修正に信じられないほどのスキルがいります
でフイタw

明らかに現場が苦手なタイプだなww

329 :仕様書無しさん:2009/11/30(月) 23:55:09
なんか業種の違う連中が噛み合わない話をしてるな。
テストは勿論大事だしカバレッジをパスしてないソフトが製品と呼べるのかとは思うが、最終的には機能を満足してれば中身はどうでもいいような気もする。

330 :仕様書無しさん:2009/11/30(月) 23:58:02
あっち修正したら、こっちがおかしくなりましたとか、聞いたことあるけど

331 :仕様書無しさん:2009/12/01(火) 00:10:37
ちなみに>>327はプログラミングじゃなくてホームページ作成業務がお似合いだ。
他の仕事は任せられない。
俺が上司なら戯れに首を跳ねるだろう。

332 :仕様書無しさん:2009/12/01(火) 02:37:49
>>331
お前の詐欺業務で全てのプロジェクトが動いている
とでも思ってるのか?w

自分の給料を献上してからテスト工程をぶちこめや、カスw

きっとお前がふんぞり返ってる傍の派遣に
馬鹿にされてるよw

333 :仕様書無しさん:2009/12/01(火) 02:43:27
ちなみにテストケースをプロジェクトにぶちこんで
記録的大赤字な上、プロジェクト大幅遅延
結局途中からテストケースを放り出したプロジェクトを知ってるぞwww

その会社の他のプロジェクトは一つもそんな事は
してないのに壮大な爆死w

かぶれてんじゃねーよとw

まさにこのスレの連中と同じだなww

334 :仕様書無しさん:2009/12/01(火) 03:00:06
低レベルすぎる話だな

335 :仕様書無しさん:2009/12/01(火) 03:15:30
>>334
低レベルすぎな会社でもたぶんお前のとこより
給料良いぞ?w

まあ世の中そんなもんだww

336 :仕様書無しさん:2009/12/01(火) 03:20:03
憶測で貶せるとか凄腕のエスパーだな

337 :仕様書無しさん:2009/12/01(火) 03:41:41
>>336
大企業は資料が揃ってるから大体の基準がわかるじゃん、アホなの?

というか底辺かww

338 :仕様書無しさん:2009/12/01(火) 03:45:15
つーか、記録的な赤字が出せる(笑)って時点で
察しろよ、間抜けな奴だなw

339 :仕様書無しさん:2009/12/01(火) 03:46:15
何言ってんのこのひと。病気?

340 :仕様書無しさん:2009/12/01(火) 03:54:24
>>339
だ・か・ら、テストケースが有効な局面があっても
工数から考えても微妙な話で
かぶれてるような連中がやっても失敗するし
最たる例を知ってる

と書いたわけだが?

そんな頭でプログラムが書けるのか?w

341 :仕様書無しさん:2009/12/01(火) 03:59:22
つーか、工程を組んでテストを書かなくてすむような優秀な人間を集めた方が
余程安上がりだろうに

昔からそうだし、これからもそうだろうw

底辺コーダーを集めて開発とか
乙という他はないなw

342 :仕様書無しさん:2009/12/01(火) 06:41:25
場合分けができないだけか

343 :仕様書無しさん:2009/12/01(火) 07:47:43
>つーか、工程を組んでテストを書かなくてすむような優秀な人間を集めた方が
その発想は無かったな、その趣旨でマネージメント手法の論文書いてみなよ

344 :仕様書無しさん:2009/12/01(火) 11:57:25
>>281のような疑問を持つところを見ると、どう考えてもこいつが底辺コーダーなのだが。

345 :仕様書無しさん:2009/12/01(火) 13:08:06
>>344
別人なわけだがw

346 :仕様書無しさん:2009/12/01(火) 13:31:12
わかんないなりに考えてるじゃないの?

347 :仕様書無しさん:2009/12/01(火) 13:41:39
>>346
>>281じゃないが考えは良くわかるよ

テスト工数が余計に掛かるのは事実だし
機動力が低くなるデメリットもあるしな

マネージメントまで考えた事がないような下っ端だと
想像もしないだろうがかなり重要な話

348 :仕様書無しさん:2009/12/01(火) 13:44:57
一発で完成品作れる魔法使いみたいな奴はそうそういないでしょ

349 :仕様書無しさん:2009/12/01(火) 13:50:20
>>347
はいはい、優秀な人材だけ集めて、テスト工数ゼロでやっててください。

350 :仕様書無しさん:2009/12/01(火) 14:12:57
>>349
はいはい、無駄に開発期間に底辺コーダーレベルの為の
長いテスト工程をぶち込んで
長期化させて会社を大赤字にして潰してってください

351 :仕様書無しさん:2009/12/01(火) 14:19:11
表面的に一発で動いたけど、細かなバグが出たら、長期になったってこともあるし

352 :仕様書無しさん:2009/12/01(火) 14:27:34
多分こいつ、業務アプリプログラマ見習いだな。

353 :仕様書無しさん:2009/12/01(火) 14:31:16
まぁ1〜3,4人くらいの優秀なプログラマが作るプロダクトなら、「テスト工数」みたいなのはいらんかもな。

354 :仕様書無しさん:2009/12/01(火) 16:10:53
 んで、「プログラマの優秀さ」の証明ってどうやるんだ?

355 :仕様書無しさん:2009/12/01(火) 18:01:13
>>354
つーか、優秀というよりもプログラマもベテランになってくると、程度の差はあれど
自分で管理出来るプログラム行数が感覚的に大体わかってくる。

だから、プログラマの人数でテスト工数がいるいらないになるみたいな話ではなくて
その現場のプログラマのプログラム把握行数を越えるか
越えないかなんだよ。


当然、優秀であるほどそのリミットはうなぎ登りなので
OSレベルのソフトでもテストなしで開発出来る
という事になるし
ボンクラ揃いなら全てテストからガッチリ開発する
という事になる

356 :仕様書無しさん:2009/12/01(火) 18:11:29
なるかアホ

357 :仕様書無しさん:2009/12/01(火) 18:52:28
>>356
なるだろ、カス

そしてかぶれた開発をする前から
システムは存在している

358 :仕様書無しさん:2009/12/01(火) 18:52:38
>>355
だから、その「感覚的経験値」を、プロジェクトリーダーとかクライアントとか、
「プログラミングから離れているマネジメントの立場」にどうやって証明するんだと。
お前様の感覚の正しさは、誰がどのように(客観的に理解できる形で)証明するんだね?

359 :仕様書無しさん:2009/12/01(火) 20:41:12
「どうやったら試験に合格できるんですか?」
「簡単だ、全問正解すれば良い」
「では、どうあれば全問正解できるんですか?」
「私が解答すれば全問正解できる」

これと同じだね。

360 :仕様書無しさん:2009/12/01(火) 20:45:19
>357
複雑度とかそういう考慮は一切なしかい、ボケが。

361 :仕様書無しさん:2009/12/01(火) 20:58:07
一発完動教がFPROGで叩かれてたのを思い出す

362 :仕様書無しさん:2009/12/01(火) 21:10:38
現実問題、一発完動を保証できる規模ってどのくらいだろう?
障害が発生したら全損害を引っ被ります、みたいな契約条件だとして。

363 :仕様書無しさん:2009/12/01(火) 21:12:24
テストした方が楽

364 :仕様書無しさん:2009/12/01(火) 21:32:26
>>358
ありのままを話していい相手と
仕事上円滑に進めるために無理やり報告する儀式は
既にあるだろw

それ位うまくやれよw
それこそ派遣ソルジャー部隊じゃあるまいし
アホかとww

365 :仕様書無しさん:2009/12/01(火) 21:35:34
>>360
機械的に何行以上とザックリ割ってない時点で
察しろよ

出来損ないのロボットか己はw

366 :仕様書無しさん:2009/12/01(火) 22:06:11
>>364
楽そうな会社でいいね。
ちょっと会社名教えてもらえる? 絶対その会社に発注しないようにするからw

367 :仕様書無しさん:2009/12/01(火) 23:00:35
500行のコードのテストケース抽出に三日かけてNG出されるなんてあり得ん

368 :仕様書無しさん:2009/12/01(火) 23:11:02
行数行数ってお前等・・・行数で見積りとか工数計算してないだろうな・・・

369 :仕様書無しさん:2009/12/01(火) 23:22:06
コードの行数とかCyclomatic complexityで、テスト工数はある程度見積もれるよね

370 :仕様書無しさん:2009/12/01(火) 23:25:54
職歴だけは無駄に長い、派遣テスターくさいな

371 :仕様書無しさん:2009/12/01(火) 23:29:38
一桁のかけ算を暗算できるからと言って、5桁同士のかけ算は暗算できないがごとし

372 :仕様書無しさん:2009/12/01(火) 23:45:08
>>366
心配しなくても発注する方の会社だから
大丈夫だぞ?w

373 :仕様書無しさん:2009/12/01(火) 23:47:55
つーか、必要必要って騒いでるのって
底辺テスト専門会社の連中なんじゃねーかとオモタww

374 :仕様書無しさん:2009/12/01(火) 23:54:51
なんでこの人こんな所でファビョってんの?

375 :仕様書無しさん:2009/12/01(火) 23:58:35
単純なバグ出してテストすらしてないのかボケと顧客に怒鳴られたんだよ

376 :281:2009/12/02(水) 00:17:52
土日は誰も書き込しなかったのに、凄い事になっているな
>>292
>そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
>「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。
多態性をインタフェース実現とか、機能追加をコンポジションかDecoratorパターンを使うと言う事か?
継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
Bridgeパターンとかは継承の為のパターンだが?

>OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
>依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。
それは分かるが、xUnitの為にTDD(テスト駆動開発入門)を読んだけど
あのクラス・メソッド設計は本当に正しのか分からない

>xUnitはホワイトボックステスト。普通はステップ実行しないよ。
なんと言えば良いのか?、ホワイトボックステストだとも思うが
xUnitのテストは入力値を設定して、実行後の値を確認するだけだから
なにかブラックボックステストに似ていると思ってしまう

俺がよくバグる例として、ある条件がそろった時だけフラグがTrueになるとして
フラグがFalseになるケースをテストをする
入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
想定していない別の条件ではじかれてFalseになっているだけと言う事がある
やはり、俺は単体テストはステップ毎に確認した方が良いと思う
この辺りもxUnitになじめない一因かも

しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか?

377 :仕様書無しさん:2009/12/02(水) 01:01:15
人事に開発は分からないから経験の無い奴がプロジェクトを指揮してカオスになるのは想像できなくもないが
ここでファビョられてもねぇ
マトモな開発やってる奴にはハァ?な訳で
チラシの裏で頼むぜ

378 :仕様書無しさん:2009/12/02(水) 05:24:50
かぶれてるもんだから
地道にやるしかない
の一言が言えない件

379 :仕様書無しさん:2009/12/02(水) 07:50:16
>>376
> 継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
いや、だから駄目とは言ってないよ。
「聞いたことがないなら」「OOの本読んで」だよ。
聞いたことがないんでしょ?だったら、本読もうよ。

> あのクラス・メソッド設計は本当に正しのか分からない
どの設計が駄目なのか言ってくれないとわからない。
入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。

> 入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
> 想定していない別の条件ではじかれてFalseになっているだけと言う事がある
具体的な内容はわからないけど、stubやmockで解決できる話なのかもしれない。

> やはり、俺は単体テストはステップ毎に確認した方が良いと思う
> この辺りもxUnitになじめない一因かも
それ、凝集度が低くて結合度が高く、複雑度が高い関数だからじゃないの?

> しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか?
まず>>326の本読め。

380 :仕様書無しさん:2009/12/02(水) 08:07:51
>>379
>聞いたことがないんでしょ?だったら、本読もうよ。
これだけじゃあれなんで、書名をあげとく。
聞いたことがないんだったらGoFは読んでないよね?まずこれ。
次は『プレリファクタリング』あたりかな。
あと、OOの設計論に言及している最近の本なら、継承のリスクについての議論が載ってる奴が多いと思うよ。

何度も言うけど、xUnitが使いづらいんじゃなくて、現状は単体テストがやりづらく、そのためステップ実行
しないと安心できないんだよね。その理由が、テスト対象メソッドを正しく実行する外部条件をそろえるのが
困難だってのが大きな理由の一つなんでしょ?だから>>326

381 :仕様書無しさん:2009/12/02(水) 08:33:19
ところで、>>355 = >>364 = >>372の会社が多重派遣を行ってる旨暴露してるんだが。

382 :仕様書無しさん:2009/12/02(水) 09:37:36
>>381
そりゃそうさ、多重派遣のレスだもの
355なんて管理・リーダー未経験末端PG以外書けない秀逸さ
そんな物で検収だす発注側もいないし、それで進められると思うPMもPLも居ない

383 :仕様書無しさん:2009/12/02(水) 10:12:55
>>382
単体テストも結合テストも元から工数取ってやってるだろ、アホかw

基本的に
テスト回数を増やさないと完成出来ない≒ボンクラ
なんだよ

気付いたらすぐ給料を返上しとけカス

384 :仕様書無しさん:2009/12/02(水) 13:37:50
だから、お前個人がエンバグやデグレードをしないのはわかったから、
メソッドか工学に結びつけないと>>359と同じなんだよ。

385 :仕様書無しさん:2009/12/02(水) 13:59:01
>>376
どうせリスコフの置換原則も、Open-Closed Principleも知らないんだろうが。
ぐだぐだ言う前に勉強すれ、アホ。

386 :仕様書無しさん:2009/12/02(水) 14:13:03
>>384
だから優秀な人間を集めた方が
いらないコストも掛からなくなるだろ
っつってんだよ、間抜け

そもそもボンクラを集めて大きなものを作ろうって
発想がおかしいと
まず気付け

387 :仕様書無しさん:2009/12/02(水) 14:22:45
MSやGoogleでもテストをしてるわけだが、そこのプログラマもカスってことですね。
さらに優秀なプログラマを集めるには、どうしたら良いのでしょうか。

388 :仕様書無しさん:2009/12/02(水) 14:43:24
>>386
19世紀あたりで思考が停止してるね

389 :仕様書無しさん:2009/12/02(水) 15:42:39
相手にするだけ時間の無駄

390 :仕様書無しさん:2009/12/02(水) 16:25:52
優秀な人間なんてそうそう集まらないのが現実社会、って前提でみんな動いてんだけど?

391 :仕様書無しさん:2009/12/02(水) 16:36:58
>>376
>しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか?

地味なやり方ってどんなやり方?

392 :仕様書無しさん:2009/12/02(水) 18:29:59
>>387
基本的にアプリケーション開発系だけだろ?w
しかも巨大プロジェクトじゃねーかよ、アホかww

お前の個人レベルを上げてから比較しろよ
ボンクラがかぶれてんじゃねーよwww

393 :仕様書無しさん:2009/12/02(水) 18:36:18
>>389
具体的に数字で違いが出せるまで
相手にしなくて結構だが、何か?w

不景気なんで詐欺師お断わりだから
ドバイでも米国でも行って存分に商売すればいいんじゃないかww

394 :仕様書無しさん:2009/12/02(水) 20:38:26
>>379
>入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。
なんだ、「テスト駆動開発入門」も知らないのか、ケントが書いたxUnitのバイブルだぞ、まずお前が本を読めw

>>376
>やっぱり地味にやるしかないのか?
それが一番だw 兎も角>>281がここで参考になる話はないなw

395 :仕様書無しさん:2009/12/02(水) 20:46:16
おい、お前ら
やっとこさ俺様の単体試験仕様書が完成したぞ
最後は自分で何書いてるか分からんかったけどOKもらったから完成したぞ

どや?俺の仕様書でテストしたいか?

396 :仕様書無しさん:2009/12/02(水) 21:27:50
>>394
普通かぶれてる場合でもなければ
下調べしてから開発するだろw

本を読んだと書いてる相手に本を読んでないだろ
とか馬鹿かとw

397 :仕様書無しさん:2009/12/02(水) 21:56:28
>>392
別にお前の仕事が増えるとか、組織的にはどうでもいい話なんだよ。
テストは開発者を楽させる為にある訳じゃないんだ。
解かるかな?

398 :仕様書無しさん:2009/12/02(水) 23:29:49
>>397
ボンクラが多いと組む前から
テストをしなくてはならないですか?w

ボンクラ開発ほど優雅な訳だなww
わかりますwww

399 :仕様書無しさん:2009/12/02(水) 23:44:04
今日の【3010】みたいなスレになってるな。

400 :仕様書無しさん:2009/12/02(水) 23:52:30
よいソフトウェア設計とは、

1. 凝集度が高い(high cohesion)
2. 結合度が低い(low coupling)
3. 重複がない(ZERO duplication)
4. テスト容易性が高い(testability)
5. 可読性が高い(readability)

テストできないソフトウェアは、机上の空論

401 :仕様書無しさん:2009/12/02(水) 23:58:37
テスト出来ないのではなく
テストを前後に挟まないといけなくなるほど
低能なプログラマで仕事してるのか
という話。

それとも天才が束になっても上手くいかない程の
画期的なプロジェクトなのか?w

402 :仕様書無しさん:2009/12/03(木) 00:14:25
逆に
テストを前後に挟めなくなるほど
低能なプロジェクト管理で仕事してるのか
という話。

品質第一。


403 :仕様書無しさん:2009/12/03(木) 00:32:28
>>402
逆にも何も最近になって一部のかぶれてる連中が
始めただけだろw

java厨のアピールあたりから
始まった流れか?w

404 :仕様書無しさん:2009/12/03(木) 01:00:39
1990年代後半からだけどな
まぁ20年前といったら最近だなw

405 :仕様書無しさん:2009/12/03(木) 01:09:19
>>404
小学校からやり直すといいよw

406 :404 Not Found:2009/12/03(木) 01:19:15
...orz

どっちにしろ世界が2012年に終わるからいいよね

407 :仕様書無しさん:2009/12/03(木) 19:12:41
えーっと単に適性が無いという結論でいいのかな?

408 :仕様書無しさん:2009/12/03(木) 21:12:13
いいかげん他所でやってくれよ・・・

409 :仕様書無しさん:2009/12/03(木) 22:46:49
新しいものに飛び付くかぶれた奴が多いという事だな

しっかりテスト駆動とやらも
ちゃんと数字的な根拠もなく
盲目的に導入してるところが多そうだw


ちゃんと利益増えてる?ww

410 :仕様書無しさん:2009/12/03(木) 23:08:56
xUnitが新しいってどんだけタイムスリップしてきてるんだよ

411 :仕様書無しさん:2009/12/03(木) 23:14:35
>>410
1900年代後半だとよw

まだ効果的か確定出来るデータも少ないだろうよ

つまり、今後消えるかもしれないようなレベル

412 :仕様書無しさん:2009/12/03(木) 23:15:41
1990年代後半の間違いorz

413 :仕様書無しさん:2009/12/03(木) 23:32:17
>>409
そもそも君がバグを出さなきゃ誰もテストに関心なんか持たないんだけどねぇ。

414 :仕様書無しさん:2009/12/03(木) 23:36:40
>>413
妄想乙w

415 :仕様書無しさん:2009/12/03(木) 23:40:32
つーか、テスト書いてるうちに
俺は納品終わってるよw

実際そんな感じのプロジェクトがあったが
暇すぎて二度とやりたくないと思ったわww

416 :仕様書無しさん:2009/12/03(木) 23:41:04
ああ、ちなみに俺は仕事でバグを出した事は無い。
何故なら俺の作るバグは全て仕様だからだ。

417 :仕様書無しさん:2009/12/03(木) 23:47:06
>>416
お前自体がバグってる件

418 :仕様書無しさん:2009/12/03(木) 23:49:09
つーか、少々のバグすら出さないとか
詐欺師の典型じゃねーかw

詐欺師のトレンドスレかここはwww

419 :仕様書無しさん:2009/12/03(木) 23:58:11
実際、バグなんて市場に出ないのが普通じゃないか?
出て当たり前ってのはちょっとおかしいだろ
どこのブラック企業だよ

420 :仕様書無しさん:2009/12/04(金) 00:07:48
>>419
テスト工程での話だろw
要はデバッグをした事がないという事

んなアホなっていうww

421 :仕様書無しさん:2009/12/04(金) 00:40:20
馬鹿だな
市場に出さないようにテストをする
ゆえに一般的にはバグが市場に出ることは少ない
逆にテストが甘いと(バグを見逃すと)JRのアレみたいに市場トラブルが起きる
ゆえにテストをしよう!っていう当たり前の話なんだけどね

422 :仕様書無しさん:2009/12/04(金) 00:56:53
>>421
馬鹿はお前だ
テストを前後に挟めばバグが減ると
明確に数字でも出せるのかとw

テストにコストが掛からない人材を手配した方が
よっぽどマシという話

テスト工程を余分にぶち込んで
儲けさせて頂いてんだかしらねーが
時間は無限じゃねーんだぞとww

423 :仕様書無しさん:2009/12/04(金) 00:59:56
あー、勿論トータルの開発期間は同じだからな

テスト工程を余分にぶち込んで期間が足りなくて
デスマとかワロス展開の事も考えて答えてみ?w

424 :仕様書無しさん:2009/12/04(金) 01:13:47
テストで時間かかるってことは無駄に粒度が高すぎるかバグりまくってるってことでしょ
そんなのをテストすっとばして納品するの?
キチガイだな

425 :仕様書無しさん:2009/12/04(金) 01:23:19
>>424
テストで時間が掛からないメンバーでやれと言ってるんだが
アホなの?

お前んとこのボンクラを前提に考えるのはやめろよ
ボケてんのか?

426 :仕様書無しさん:2009/12/04(金) 01:28:59
テストで時間が掛かるメンバーなんて糞はいねーよ
お前んとこはボンクラ未満の無能を飼ってるのか?

427 :仕様書無しさん:2009/12/04(金) 01:32:06
テストチームに預けるにしても、開発チームでざっとテストし終わってから渡すしなあ。
バグだらけのゴミ渡したら締められるぞ。

428 :ググレカス:2009/12/04(金) 01:47:20
こんな数字が ttp://www.infoq.com/jp/news/2009/03/TDD-Improves-Quality
「4製品のリリース前の欠陥密度(コード1000行あたりの欠陥数を測定)は、TDDを使用しないプロジェクトと比較し40%から90%の間で減少した。
チームの管理者は、主観的に見てTDDを使用するチームの初期開発時間に15%から35%の増加が認められると報告したが、チームは、これはメンテナンス・コストの削減により相殺されるとの見解で一致した。」

429 :仕様書無しさん:2009/12/04(金) 01:49:04
>>426
テストで時間が掛からないも何も
わざわざテストを前後で挟まなくても
開発時にバグを潰してるから
残念だったな

つまり、お前らボンクラでいうところの
テスト工数ゼロだ

勿論、後のテストで多少はバグは出るがな
詐欺じゃないんでw

430 :仕様書無しさん:2009/12/04(金) 01:51:14
>>428
15%-30%給料カットなw

431 :仕様書無しさん:2009/12/04(金) 01:55:51
>429
バグもつぶせない無能だと自称なさってますが
それでよろしいのですな?

432 :仕様書無しさん:2009/12/04(金) 01:58:46
>>431
単体テストをスルーするバグは当然あるんだが
詐欺師なのか?

433 :仕様書無しさん:2009/12/04(金) 02:01:02
つまり、単体レベルでは発覚しなくて
結合レベルで発覚するバグ
という事な

434 :仕様書無しさん:2009/12/04(金) 02:07:05
後付け設定乱発だな
話にならね
お前の主張をまとめなおせ

435 :仕様書無しさん:2009/12/04(金) 02:13:54
>>434
はあ?

従来通りのやり方で優秀な人間でやった方が
コストが掛からないっつってるだけだよ、文盲

436 :仕様書無しさん:2009/12/04(金) 02:22:18
はぁ?
従来って何だ?何十年前から来たの?
テストなんてどこでも一般的にやってるだろ
やってねーほうが珍しいだろカス

437 :仕様書無しさん:2009/12/04(金) 07:52:22
やりあってる二人のレベルがジャストレベルすぎて、見分けがつかないほど両方ひどい

438 :仕様書無しさん:2009/12/04(金) 08:01:24
>>436
何10年も前ではないようだが?w

そういう書き込みしか出来なくなったという事は
盲目的にかぶれてるだけな事を内心認めてしまったという事だな

やっぱカスだねww

439 :仕様書無しさん:2009/12/04(金) 08:23:55
何言ってんだお前

440 :仕様書無しさん:2009/12/04(金) 09:04:49
優秀な人間がお前の会社に入るわけ無い

441 :仕様書無しさん:2009/12/04(金) 12:14:52
テストをやることがかぶれる?イミフ

442 :仕様書無しさん:2009/12/04(金) 12:53:02
          ____
       / \  /\ キリッ
.     / (ー)  (ー)\    <「テストをやらない俺カッコイイ」
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー’´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一””””~~``’ー?、   -一”””’ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

443 :仕様書無しさん:2009/12/04(金) 13:36:33
>>439
頭が悪いからだよ
従来方式で山ほどバグを出してただけはあるな

>>440
じゃあ自分とこで育てればいいだろ、カス

15-35%も開発期間が増えるんなら出来るんじゃねーのwww

444 :仕様書無しさん:2009/12/04(金) 16:35:34
できるか馬鹿

445 :仕様書無しさん:2009/12/04(金) 16:56:25
>>443
こいつが一番このスレで頭が悪いのにwww

446 :仕様書無しさん:2009/12/04(金) 17:13:14
ただのレス乞食の無職っぽいな

447 :仕様書無しさん:2009/12/04(金) 18:52:35
>>444
じゃあお前の給料を15-35%カットして
教育が出来る奴を雇えば?

お前くらい馬鹿だと俺でもコンサルが
出来そうな気がするわw

448 :仕様書無しさん:2009/12/04(金) 19:12:02
>>446
馬鹿が必死こいて残業してる間
寝てるようなもんだか、何か?w

どうも優秀すぎるみたいで悪かったな

449 :仕様書無しさん:2009/12/04(金) 20:39:19
何かって言われても、何も。
無能は邪魔だからとっとと(・∀・)カエレ!って話かもしれんしな。

450 :仕様書無しさん:2009/12/04(金) 20:51:48
>>449
無能っぷりが目立つ奴が多いからそれはないなw

つーか、ガンガン突っ込みを入れたり
バグを指摘してやるから感謝しろよ
って感じだしww

451 :仕様書無しさん:2009/12/04(金) 21:05:06
関係ないけど、思い込みって凄いよね。

452 :仕様書無しさん:2009/12/04(金) 22:15:28
思い込みが強いと根拠の確認もなしに
新しいものに手を出しちゃうってのはあるな


まあ自腹でもやるのかと言うと疑問だがw

453 :仕様書無しさん:2009/12/04(金) 23:40:43
まあ、wが荒れるのも分かるけどさー
開発経験の無い素人が適当にトレンドを勉強して適当なテスト計画を立ててデスマったって事だろ
そんなレアケースここの住人が知るわけねーだろが、アホは巣に帰れ
そんな会社で仕事してるお前が無能なんだよ

454 :仕様書無しさん:2009/12/04(金) 23:44:22
まだやってんのか・・・それなりのスレだったのに

455 :仕様書無しさん:2009/12/05(土) 00:38:24
          ____
       / \  /\ キリッ
.     / (ー)  (ー)\    <「テストをやるとデスマるんだよ」
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー’´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一””””~~``’ー?、   -一”””’ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

456 :仕様書無しさん:2009/12/05(土) 01:16:24
>>453
>>452

457 :仕様書無しさん:2009/12/05(土) 01:23:07
つーか、おまえら何年前からテスト方式をチェンジしたか知らねーが
それまで雑魚すぎでテストに苦しんでたのか?w

まあ元々バグりまくりでテストが終わらないような
糞プログラムしか書けなかった
ってんなら効果はあるだろうww

生憎そんな事は一度もなかったので
俺にはボンクラがテスト工数を一手間増やしたとしか思えんな

458 :仕様書無しさん:2009/12/05(土) 01:24:40
いつまでたっても思考停止から抜け出せないキチガイ

459 :仕様書無しさん:2009/12/05(土) 01:45:57
>>457
お前が書くコードにバグがあろうが無かろうが、誰も興味がないってことにいい加減気づけ

460 :仕様書無しさん:2009/12/05(土) 01:50:20
何ヶ月後が、何年後かわからないけど、自分が書いたものを読み返すときがきたら、
きっと死にたくなるに違いない。

461 :仕様書無しさん:2009/12/05(土) 02:01:23
>>459
>>460
つーか
テストが必要か→Yes
テスト工数を増やす必要があるか→No
優秀なプログラマを増やす必要があるか→Yes
なだけの事なんだが
テスト業者でも釣り上げたのかと

462 :仕様書無しさん:2009/12/05(土) 07:23:25
>>461
お前が増やせばいいだけだろ。全く使えない奴だな、片腹痛いわw

463 :仕様書無しさん:2009/12/05(土) 09:36:58
>>461
お前やお前の会社でどのようにやろうが、誰も興味ないったら。

お前が定義するところの無能(バグを作り込む奴)がどうすればいいのかを聞いてるのに、
お前がやめればいいとしか答えてないのに気づけ、馬鹿。

464 :仕様書無しさん:2009/12/05(土) 11:24:48
>>462
じゃあ基本的には俺の意見に異論はないのに
くだらない噛み付き方をしていた馬鹿で
お前に関しては終了という事で

465 :仕様書無しさん:2009/12/05(土) 11:29:06
>>463
どうせ低能無能なプログラマの対処で工数を増やすなら
教育に時間を割けばいいだろ

それも無理なら外部に頼めばいい話だ

466 :仕様書無しさん:2009/12/05(土) 11:55:31
試験が終わったのに、どんどん機能追加って普通?

467 :仕様書無しさん:2009/12/05(土) 12:12:36
>>376
xUnitの最大の利点は、テストをプログラミングにしたこと
これにより、曖昧さを排除できる、結果品質が上がる
でも逆に、正確性が求められるから前準備(コーディング)が大変になる
既存のやりかたでは、人間が行うから曖昧さも柔軟に対応出来た
この辺りが、xUnitテストは大変だと思う原因じゃないの?

>しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか?
確かに、地味にやるしかないけど、プログラミングだから
コーディングテクニックや設計手法が使える
俺の場合は、最初に初期化・入力値設定・出力値確認のクラスを作っている
大変だけど、あとで楽になるよ

468 :仕様書無しさん:2009/12/05(土) 14:21:46
>>465
育つまではコードを書くなってことか。

469 :仕様書無しさん:2009/12/05(土) 14:23:55
>>467
まぁお前は知らないだろうが、xUnitのずっと以前から、コードでテストするのは普通

470 :仕様書無しさん:2009/12/05(土) 15:39:35
>>469
こんなアホがいるから、この板はおもしろいw

471 :仕様書無しさん:2009/12/05(土) 15:43:01
xUnitの話題はム板でやれよ。確かスレがあったからさ。

472 :仕様書無しさん:2009/12/05(土) 19:13:23
単なる事実を言ったら、アホ呼ばわりされたよ

473 :仕様書無しさん:2009/12/05(土) 19:23:59
なに愚痴ってんだ、アホか

474 :仕様書無しさん:2009/12/05(土) 19:27:09
そうだね、こんなところで愚痴っても、アホですねw

475 :仕様書無しさん:2009/12/05(土) 19:31:22
口先だけのレス乞食にムカついたってしかたないさ
ろくに知識がなくて煽るだけだからどこぞのアホコテより話にならない

476 :仕様書無しさん:2009/12/05(土) 19:52:47
>>475
>口先だけのレス乞食にムカついたってしかたないさ
>ろくに知識がなくて煽るだけだからどこぞのアホコテより話にならない
おいおい、それは言いすぎだろう、アホぐらいにしとけよ、アホが泣くぞw

477 :仕様書無しさん:2009/12/05(土) 19:59:45
>>476
お前の事だ

478 :仕様書無しさん:2009/12/05(土) 20:11:25
この一連の書き込みの中に>>467がいるのかなぁ

479 :仕様書無しさん:2009/12/05(土) 20:14:26
>>477
>お前の事だ
何でお前がムキになるんだw わかりやすいな!! >>472=475=478
本当に、アホをからかうのは面白いなw  泣くなってw

480 :仕様書無しさん:2009/12/05(土) 20:16:45
なんだ、>>467=>>479か。
煽りにもマジレスっぽいものにも知性が感じられないなぁ

481 :仕様書無しさん:2009/12/05(土) 20:22:39
メンヘ→メンヘラ→メンヘガ
      ↑今ここ

482 :仕様書無しさん:2009/12/05(土) 20:25:59
>>480
マジかコイツw 俺は別人だぞw
そうだよな、アホ呼ばわりしてる奴は一人だと思いたいよなw がんばれw

483 :仕様書無しさん:2009/12/05(土) 20:27:08
>>467
>この辺りが、xUnitテストは大変だと思う原因じゃないの?

なんだか遠い過去の話に感じるが、xUnitテストが大変だと思う原因は、
>>281自身が書いているとおり、初期化が大変であることでしょ。

で、何度も繰り返して申し訳ないんだが、そんな>>281にぴったりなのが>>326
超絶おすすめ。

484 :仕様書無しさん:2009/12/05(土) 21:09:09
>>482
一人だと思ってる

485 :仕様書無しさん:2009/12/05(土) 21:38:06
xUnit 使ったテストってそんなに難しい話か?
難しいって発想がでてくる時点で無能じゃね?

486 :仕様書無しさん:2009/12/05(土) 22:03:02
xUnitの使用法自体は難しくないが、xUnitを使ったテストを書こうとすると難しい場合もある、
ということも想像できない方が無能

487 :仕様書無しさん:2009/12/05(土) 22:26:14
>>281
xUnitの使用場面は、メソッド単位でも良いし、シナリオベースでも良い。
開発者が行う単体テストにも使えるし、顧客が行う受け入れテストにも使える。

xUnitは単なるテストの実現手段にしか過ぎず、xUnitだからメソッド単位で
テストしなければならないとか、シナリオベースでテストした方が良いなどの
議論は無意味。

さらには、281がテスト対象としているコードが、自分が書いたものなのか他人が
書いたものなのか不明であり、開発プロセスのどの段階にいるかもわからないため、
まさに今どのようなテストを行うべきなのかには答えられない。

今、シナリオベースでのテストではテスト対象の粒度が大きいので、是非メソッド
単位でテストをしたいということであれば、取り得る方法は二つ。
一つは、テスト対象を(mockが使えるように)リファクタリングすること。
もう一つは、>>467の言うように、テスト用の初期化処理をプログラミングしてテストする。

もうすでにテスト工程は終わってしまったのかもしれないが・・・

488 :仕様書無しさん:2009/12/05(土) 22:31:52
何この上から目線

489 :仕様書無しさん:2009/12/05(土) 22:34:25
GUIのテストには使えないと言っても過言ではない

490 :仕様書無しさん:2009/12/05(土) 23:30:37
コードって書いたとおりに動くんだからさ、コードが正しく動くことを確認するテストって意味なくね?

491 :仕様書無しさん:2009/12/05(土) 23:32:48
何が正しいかはわからない

492 :仕様書無しさん:2009/12/06(日) 00:50:06
>>486
それダメなコードだろ
もしくは使い所が全くわかってない

どちらにしろ自ら無能だとアピールして何がしたいんだ?

493 :仕様書無しさん:2009/12/06(日) 01:03:03
お前いい加減にしろよ

494 :仕様書無しさん:2009/12/06(日) 01:16:23
軽やかにスルー

495 :仕様書無しさん:2009/12/06(日) 10:18:56
>>467
>既存のやりかたでは、人間が行うから曖昧さも柔軟に対応出来た

意味がわからん

496 :仕様書無しさん:2009/12/06(日) 13:48:19
不完全なシステムのツケは107億円也。


みずほ証券の株誤発注裁判、東証に107億円の賠償命令、過失は7割
http://itpro.nikkeibp.co.jp/article/NEWS/20091204/341578/

497 :仕様書無しさん:2009/12/06(日) 17:16:44
ソフトは作った側に未来永劫責任があると勘違いしている顧客への良い警鐘

498 :仕様書無しさん:2009/12/06(日) 18:43:50
しかし、400億円損失の時に始めてバグが分かったのかね?
警告表示を普段から無視していた(同じシステムか分からんが)のなら
あまり良いシステムじゃなかったのかな?
SIは、たしかFだよね?、あと、何かでよんだけど、東証のHのシステムも問題があるんだっけ?

499 :仕様書無しさん:2009/12/07(月) 04:14:35
バグじゃなくてオペミス

500 :仕様書無しさん:2009/12/07(月) 20:29:58
仕様もコードにするべきだよね。


501 :仕様書無しさん:2009/12/07(月) 21:43:01
>>499
普通にバグだが、オペミスで何で東証に賠償命令が出るの?
常識で考えればわかるだろう、取消処理をオペレーションでやるか?
証券会社は、取消処理のたびに、東証にオペレーション頼むのか? 君はバカか? それともFか?

http://ja.wikipedia.org/wiki/%E3%82%B8%E3%82%A7%E3%82%A4%E3%82%B3%E3%83%A0%E6%A0%AA%E5%A4%A7%E9%87%8F%E8%AA%A4%E7%99%BA%E6%B3%A8%E4%BA%8B%E4%BB%B6#.E6.9D.B1.E8.A8.BC.E5.81.B4.E3.81.AE.E5.8E.9F.E5.9B.A0


502 :仕様書無しさん:2009/12/07(月) 22:29:34
は?何で富士通だったら東証のバグにしたがらないとか考えるのかわけわからん

503 :仕様書無しさん:2009/12/07(月) 22:44:28
>>501
いやいや、警告云々だからみずほ証券の方でしょ。
だからオペミス。

504 :仕様書無しさん:2009/12/07(月) 23:04:47
瑕疵担保責任の期間もとっくにすぎた、コードごと納品したプロダクトの問い合わせがたまにきて
切れそうになる。
バグだか仕様だかもはやわからんが、仮にバグだとしても無料で俺らを使おうとするんじゃねー。
「テストしましたか?」っていつの話してんだおめー。
受け入れテストして検収して、何年も稼働実績あんだろーが。
寝ぼけてんじゃねーぞ。

505 :仕様書無しさん:2009/12/07(月) 23:09:50
1:オペミスと言うのはやっちゃまずい事である。
2:しかし、人間なんだからミスくらいやらかしちゃう。
3:第一段階の歯止めとして、警告が出るようになっていたが、あまりに毎回警告が出るので無視されてた。
4:「その時」も同じように警告は無視された。
5:第二段階、あるいは第一段階の警告が出ない状態でのオペミス対策として、「キャンセル機能」が提供されていた。
6:当然、ミスに気づいてから速攻キャンセル実施を行った。
---ここまでがみずほの問題。
7:しかし、「取説の説明」「仕様書の記載」「実際の動作」がそれぞれ異なっており、今回の状況でキャンセルが出来なかった。
8:みずほは東証に直電し、「キャンセルできないぞゴルァ!」とねじ込んだ。東証は「んな訳あるかちゃんとやれ」と突っぱねた。
9:東証は、たとえば企業が大事件に巻き込まれた際に情報周知期間を設ける目的で取引を(一部・または全体)中断する
 権限を持っている。みずほはそれも要請したがやっぱり拒絶された。
10:そんなこんなのうちに超お祭り騒ぎ勃発。
11:さすがに慌てた東証は中断権限を用いて処理の中断を行った。

 このうち、東証が賠償責任を負うとされたのは、7番から先の事象についての7割。
妥当なところじゃねえの?

506 :仕様書無しさん:2009/12/08(火) 00:00:57
>>502
>は?何で富士通だったら東証のバグにしたがらないとか考えるのかわけわからん
そうだね、Fにとっては、これくらいのバグは日常茶飯事だから気にしないか
Fには、まともにテストが出来る人間が、いないからな〜

507 :仕様書無しさん:2009/12/08(火) 11:26:03
>>505
違うよ。
東証のソフトにはバグがあって、キャンセルを受け付けられなかったの。

508 :仕様書無しさん:2009/12/08(火) 12:51:39
このスレ的にはみずほ証券の問題を
どうやったら未然に防げたと考える?

やっぱりテストの仕方に問題があったと考える?

509 :仕様書無しさん:2009/12/08(火) 13:35:14
みずほ証券側の問題って何?

510 :仕様書無しさん:2009/12/08(火) 14:06:26
>>509
わかる人間に聞きたいので
無理に答えなくてもいいよ

511 :仕様書無しさん:2009/12/08(火) 14:11:45
まず問題を規定しろよ。
何が問題だと思ってるんだ?
これに答えられないなら、議論する意味ないね。

512 :仕様書無しさん:2009/12/08(火) 14:25:57
最近このスレを荒らしてる奴だから、相手にするだけ無駄

513 :仕様書無しさん:2009/12/08(火) 14:44:26
みずほ証券側は、オペミスを防ぐ設計はどうすればいいかという問題だから、
このスレ的には関係ない。
東証側は、ちゃんとテストしましょうと言うしかない。

514 :仕様書無しさん:2009/12/08(火) 15:27:22
このスレ的にはちゃんとテストしましょうではなく
どんなテストを導入してどんな感じでやりましょう
じゃないのか?

515 :仕様書無しさん:2009/12/08(火) 15:29:28
で、このスレ的なテストはみずほの問題に対して
効果は出るのか?

516 :仕様書無しさん:2009/12/08(火) 17:10:08
ヒューマンエラーだからなあ。
手順書遵守の徹底を教育するくらいしか。
ソフトが配布されてたのかAPIが公開されたのかにもよるけど、
API公開なら重要事項の続行時にパスワード求めるとかかな。

517 :仕様書無しさん:2009/12/08(火) 17:48:26
>>514
どんなテストをどのように実行したのかもわからないのに、
どうやって議論しようと思っているのかわからない。

518 :仕様書無しさん:2009/12/08(火) 18:04:06
>>515
だから、みずほの問題って何だよ?

519 :仕様書無しさん:2009/12/08(火) 18:25:02
>>516
何の話をしているのかさっぱりわからん

520 :仕様書無しさん:2009/12/08(火) 18:34:13
警告が出まくりで無意味になっているのに
テストをちゃんとやるって何のテストの事?

つーか、ヒューマンエラーじゃないエラーって何?

521 :仕様書無しさん:2009/12/08(火) 19:24:43
東証の非はソフトがバグった事でもみずほが誤入力した事でもない。
異常な取引が起きても放置してた事が問題なんだ。

522 :仕様書無しさん:2009/12/08(火) 19:36:09
キャンセルが受け付けられなかったのは非にならないの?

523 :仕様書無しさん:2009/12/08(火) 19:38:07
>>520
お前はしゃべるな

524 :仕様書無しさん:2009/12/08(火) 19:48:35
つーか、プログラムを使ったテストの標準化の必要性を説くために
みずほの例を出したんじゃなかったっけ?w

525 :仕様書無しさん:2009/12/08(火) 19:51:17
>>490が限りなく正解に近かったようだな

526 :仕様書無しさん:2009/12/08(火) 20:12:48
問題は正しいとは何かなのだ。
金融だと市場は常に正しいらしいが。。。


527 :仕様書無しさん:2009/12/08(火) 20:23:14
>>524
何の話をしているのかさっぱりわからない。

528 :仕様書無しさん:2009/12/08(火) 20:27:32
「プログラムを使ったテストの標準化の必要性」の話なんてどこで出たんだ?

529 :仕様書無しさん:2009/12/08(火) 20:32:48
Wikipediaに書かれていることが100%正しいのなら、「東証、ちゃんとテストしろよ」
意外に言うべきことは何もないな。

530 :仕様書無しさん:2009/12/08(火) 22:14:02
>>529
ちゃんとっていうのはこのスレで言うところの
何をするべきなんだ?

まさか散々既出ネタの時間を掛けて丁寧に
なんて話じゃないだろうから
新たにどんな手法を提唱するかwktkが止まらないんだが
果たして具体的な話が出来る人はここにいるかな?

531 :仕様書無しさん:2009/12/08(火) 22:42:25
1:そもそもどういうテストをやっていたのかなんて、中の人しか分からない。
2:しかし、仕様、実装のいずれのミスにしても、検品(≒テスト)が適正に行われていればあらかた防げる。
3:今回の事例も、(報道で確認できる範囲では)テスト漏れがあったと見ることが出来る。
4:ゆえに「ちゃんと」テストするべき、と>>529は述べている。

 具体的どうの以前の話なのよ。一つ一つの状況だけ見れば、さしてレアケースというわけではないのだから。
ついでに言えば丁寧にやることのの何が悪いんだ? 基本中の基本だろ。

532 :仕様書無しさん:2009/12/08(火) 23:29:46
東証がテストするんじゃなく、富士通がテストすべきだろう
イレギュラーなバグならまだしも、こんな、基本操作すらテストをしていない
こんな会社が日本のリーディングカンパニーなんだから凄すぎ

来年1月4日から、東証と富士通は「arrowhead」を稼動させる
300億円のプロジェクトそうだが、なんか大変な事にならないと良いがw

533 :仕様書無しさん:2009/12/09(水) 03:29:34
> 提供されていた「キャンセル」実施を行ったが出来なかった
ってバグ以外の何者でも無いようなキガスw

強いて言えば"テスト"で発見できなかったのは何でだ?
提供する機能が正しく(意図した通りに)動くか/動かないかを確認するのがソフトウェアのテストだろうにw
テストしなかったんだろうか? それともあえて嫌がらせで罠を埋め込んでおいたのか?



534 :仕様書無しさん:2009/12/09(水) 06:56:07
>>530
お前ひとりだけこのスレで浮いてるぞ。

>>532
ド素人かよ。
富士通がテストすべきなのはもちろんだが、東証もテストすべきなんだよ。

535 :仕様書無しさん:2009/12/09(水) 07:03:36
>>533
プログラマの意図なんかどうでもいいんだよ。それは開発者側のテストの話だろ。

536 :仕様書無しさん:2009/12/09(水) 11:17:41
何故バグを検出できなかったのかは、実情を知る以外に議論する方法は無いよ。

537 :仕様書無しさん:2009/12/09(水) 12:06:38
>>534
むしろお前は引っ込んでろ状態なわけだが


>>536
わからないなら引っ込んでる事も出来るわけだが

538 :仕様書無しさん:2009/12/09(水) 12:07:53
ここまで具体的なテスト方法の記述が一切ない件

539 :仕様書無しさん:2009/12/09(水) 13:24:34
>>538
一体何をどう話せと?
話せるなら、お前から何か話せ。

540 :仕様書無しさん:2009/12/09(水) 13:47:11
>>537
>わからないなら引っ込んでる事も出来るわけだが

わからないんじゃない。
議論設定がおかしいだろって言ってるんだが、理解できないか?

541 :仕様書無しさん:2009/12/09(水) 14:10:13
ピントが外れてる奴、プログラマじゃないだろ。

542 :仕様書無しさん:2009/12/09(水) 14:53:51
>>539
>>540
事情がわからないから確かな事が言えない
と思ってるならわざわざ書かなくてもいいと言ってるんだがな

543 :仕様書無しさん:2009/12/09(水) 15:21:29
だから、そう思ってないならお前が何か書け。

544 :仕様書無しさん:2009/12/09(水) 15:36:09
>>530
>>532
>>533
>>537
>>538
>>542
いい加減にしろ

545 :仕様書無しさん:2009/12/09(水) 15:40:42
エビデンス、エビデンスとうるさいから、
.........................................

.......................................

OK(5200)
みたいなのをメールで送ってやった。

546 :仕様書無しさん:2009/12/09(水) 16:59:21
ジェイコム問題よりも、Day2の方に興味がある。
例のセブン銀行にカタカナじゃなくて漢字でメッセージを送った件。

あれってなんだか大成功なプロジェクトということになっているらしく、こんな本まで出る始末。
『システム統合の「正攻法」 世界最大6000人プロジェクト、三菱東京UFJ銀行「Day2」に学ぶ 』
http://www.amazon.co.jp/dp/4822262413/

でもさ、外部システムに送信するメッセージが仕様書で定義されてるのに、それを網羅
してなかったってどんだけザルなんだと思うよ。
何でこれ(テストの質)が問題にならないのか不思議。

それともどっかで問題になってる?

547 :仕様書無しさん:2009/12/09(水) 17:01:53
>>544
意見も人も違うわけだが
テストプログラムでもバグったのかね?

548 :仕様書無しさん:2009/12/09(水) 17:18:39
全員馬鹿ってのが一致してる

549 :仕様書無しさん:2009/12/09(水) 17:31:14
妄想乙

550 :仕様書無しさん:2009/12/09(水) 19:28:20
>>547
どれがまともな意見なんだよ?w

551 :仕様書無しさん:2009/12/09(水) 20:28:07
まともなの定義を明確に出せ

そして、ちゃんとテストするのちゃんともな

適当に引用しといて具体的には何も申し上げられないとかは勘弁だ
頼むでしかしw

552 :仕様書無しさん:2009/12/10(木) 11:40:43
お前がまともだと思う番号を明示すればいいだけの話だろ。
示せないの?

553 :仕様書無しさん:2009/12/10(木) 13:38:09
何度言えばわかるんだろうか。
ちゃんとテストしなかったんだろうから、ちゃんとテストしろとしか言いようが無いではないか。
具体的な話をしろというなら、具体的に何がいけなかったのか書け。

554 :仕様書無しさん:2009/12/10(木) 14:07:14
>>281からこのスレおかしくなったな。
俺は>>281が暴れてるんだと睨んでるが。

555 :仕様書無しさん:2009/12/10(木) 14:36:25
>>554
論理的でない考察だな
そして結果も見事にはずれている

そもそもテスト云々を話す前に脳みそが非論理的になっていて
テストどころではない奴が多すぎるな

なんだよ、ちゃんとテストしろって
ちゃんとで話が済むならプログラマいらねえっつう話

556 :仕様書無しさん:2009/12/10(木) 14:46:41
匿名状態で「何度言えばわかるんだろうか」って言っちゃう馬鹿な人って・・・


557 :仕様書無しさん:2009/12/10(木) 16:09:56
一般的なテストの話と、ジェイコム問題でのテストの話を分けられない馬鹿

558 :仕様書無しさん:2009/12/10(木) 16:14:14
>>555
>なんだよ、ちゃんとテストしろって

だから、何か議論したいんだったら、お前から話を限定していけっつーのがわからんのか。

559 :仕様書無しさん:2009/12/10(木) 20:04:57
みずほの話を持ち出した奴が責任を持って話をまとめるべき
スレに即して具体的かつ明確にな

勿論ちゃんとやるべきとか意味のない書き込みはNG

560 :仕様書無しさん:2009/12/10(木) 21:36:05
前提条件が人により違うから議論にならない。
意見が欲しい人は前提条件を明確にして質問してください。

561 :仕様書無しさん:2009/12/10(木) 23:13:16
>>283
>テストが簡単になるように、メソッドを設計・実装すればいい。
>凝集度を上げ、結合度を下げる。
はい、バカ発見、どうせ本とかの受け売りだろ、バカの一つ覚えw
凝集度を上げ、結合度を下げるとxUnitのテストが簡単になると本に書いてあったか?
凝集度を上げ、結合度を下げたモジュールをxUnitのテストをやったことがないんだろうw


562 :仕様書無しさん:2009/12/11(金) 02:07:27
はぁ?

563 :仕様書無しさん:2009/12/11(金) 02:17:30
>>561
ただの学歴コンプかな?論理的でない奴だな、本に書いてたら鵜呑みにしちゃうのか?なぜかを考えたらわかると思うんだが、なぜかを考えようとしないからいつまでもこんな不毛なやりとりしてるんだろうな。

と、規制解除記念カキコ
韻踏んでるっぽくていい響きだ

564 :仕様書無しさん:2009/12/11(金) 03:40:18
>>562
つまり、凝集度を下げ、結合度を上げましょうってことか。
お前はそうすれば?

565 :仕様書無しさん:2009/12/11(金) 03:41:22
あひゃ、>>561の間違い。

566 :仕様書無しさん:2009/12/11(金) 10:11:50
荒らし耐性無いなー

ほっとけよ

567 :仕様書無しさん:2009/12/11(金) 21:25:43
>>562-566
がんばっているな、バカどもがw
本当に知識も経験もないんだねw もう少し真面目に勉強すればw

凝集度を上げ結合度を下げるとは、モジュールの独立性を高める事だ
理解出来るか?、つまり外部からの干渉され難くなる分かるか?
xUnitテストは別モジュールから検証するテスト方法だとも分かるか?
いくらアホでも、ここまで書けば分かるだろうw

しかし、この時間まで何をやっているんだ、仕事はクビになったのか?
>>562 名前:仕様書無しさん[sage] 投稿日:2009/12/11(金) 02:07:27
>>563 名前:仕様書無しさん[sage] 投稿日:2009/12/11(金) 02:17:30
>>564 名前:仕様書無しさん[sage] 投稿日:2009/12/11(金) 03:40:18
>>565 名前:仕様書無しさん[sage] 投稿日:2009/12/11(金) 03:41:22


568 :仕様書無しさん:2009/12/11(金) 21:27:54
誰もがお前と同じスケジュールで生きてるわけじゃないんだよ?
わかる?

569 :仕様書無しさん:2009/12/11(金) 22:19:55
はてしない馬鹿だな。
ぐぐって嘘でも書かれてるページでも見つけたか?

570 :仕様書無しさん:2009/12/11(金) 22:56:34
>>561
外部機能の複雑さをそのまんま内部実装に持ち込むなって事でしょう。
難しいものを難しいまま実装するのは猿でも出来る。
難しいものを単純なものの組み合わせにして実装するのは難しい。

571 :仕様書無しさん:2009/12/12(土) 00:21:51
言葉遊びみたいな話ではなく別モジュールからテストするための機能を
勘違いしてるのか受け売りしたプログラマがいた
ってだけだな

特定のテスト方法に依存したプログラムを書く方が良いと言っていた事からも
手段と目的を完全に見誤っていたのは明らか

あと難しい処理を簡単な処理の連続にするのが良いわけではないな
無駄にプログラムが冗長になっても仕方ないし
それで制限される環境もまた出てくるだろう

必要な事は難しい処理の呼び出し(でも他でも)のインターフェースを
簡単にする事だ

似て非なる事なんでセンスが出るのはあるが
工数やコストにもろに影響が出るから
重要だったりする

572 :仕様書無しさん:2009/12/12(土) 09:16:03
>>569-571
まだ、分からんバカが多いな、もう少し詳しく書いてやるよ
1.モジュールは、凝集度を上げ結合度を下げると独立性を高める○
2.凝集度を上げ結合度を下げるとテストが容易になる○
3.凝集度を上げ結合度を下げるとxUnitテストが簡単になる×

お前ら、本当にxUnitテストをやったことがあるのか?
メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
テストメソッドを追加したことがないのか? まっ、お前らがちゃんとテストしているとは思えんがw 
とにかく「xUnitテストが簡単になる」事は無い

今度は、お前らに「凝集度を上げ結合度を下げるとxUnitテストが簡単になる」を
詳しく説明してもらおうか

573 :仕様書無しさん:2009/12/12(土) 10:25:54
そうだね、『ぎゃふん』

574 :仕様書無しさん:2009/12/12(土) 11:50:59
たしかに、privateのFieldやMethodで困ることがある
自分は、割り切ってテスト中はpublicにしているけど
みんなどうしているの?

575 :563だけ書き込んだ:2009/12/12(土) 11:52:07
「はい、バカ発見、どうせ本とかの受け売りだろ、バカの一つ覚えw」から「本に書いてあったか?」まで読んで、
学歴コンプの馬鹿が上司に怒られたが、凝集度、結合度、テストファーストの意味がわからず、
拒絶反応起こしてファ病ってんのかとエスパーしてしまった。話通じるみたいなので失礼した。

凝集度•結合度を考えて作られたものの方が、テストの複雑さが減らせるから、結果単体当りの精度はあがるよね?

じゃあ逆に聞くが、nUnitが導入される事になったらテストクラス書くのがめんどくさいからって、独立性の低いクラス書くのかい?それはしないよね?

君の本来の主張は
「めんどくさいからnUnitは使うな」
って事?
それとも
「俺様みたいな天才はテストなんぞいらぬ」
って事?

人間はミスをするって事を常に意識していなければいい仕事はできないんじゃないかなと思うんだけど。

576 :仕様書無しさん:2009/12/12(土) 11:54:19
nUnit使う事によって時間的なコストがかかるなら、あらかじめそれをコストに含めればいいだけの話なのに、なにがそんなに嫌なんだ?めんどくさいだけか?

577 :仕様書無しさん:2009/12/12(土) 12:30:29
>>572
ひとつ聞くが、どのようなテストなら簡単だと言ってる?

578 :仕様書無しさん:2009/12/12(土) 12:52:27
>>572
> メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
> テストメソッドを追加したことがないのか? まっ、お前らがちゃんとテストしているとは思えんがw 

生産的な話をしようぜ。たとえば
class Foo {
public:
 void foo(); // will be modify zot
 void bar() const; // using zot whch was modified by foo()
 void baz() const; // using zot whch was modified by foo()
private:
 int zot;
}
というクラスがあったときに、void foo()のテストがしづらいと言っているのか?
もしこのような例ではないなら、適当な例をコードで書いてくれ。
確かにこのクラスだと、xUnitではテストしづらいな。

579 :仕様書無しさん:2009/12/12(土) 13:00:01
ずっとテストをする=xUnitテストをすると
わざとミスリードしてる奴が多いけど
そういう詭弁を書かないと論が成り立たない時点で
終わってるんだよね

情弱は騙せてもプログラマは無理

580 :578:2009/12/12(土) 13:03:37
ちなみに、>>283を書いたのは俺で、>>283>>281
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
に対するレスであって、それを一般論に敷衍して揚げ足とられてもちと困る。

単独で動かせない、つまり結合度が高く凝集度が低いということだから、
その反対のコードを書けと言っただけの話だ。

結合度が低く凝集度が高ければ、一般にxUnitでもテストし易いと俺は思ってるが、
確かにテストしづらい局面もあることは認めるよ。

俺の場合は、自動テストとテスト容易性を何よりも優先するので、設計を崩す場合もある。
自分で一から書く場合はほとんどやらないが、他人のコードをメンテナンスする場合は、
メンバ変数のgetterを追加したり、privateメソッドををprotectedメソッドにしたり、
テストクラスをfriendクラスにしたりとか。

581 :仕様書無しさん:2009/12/12(土) 13:15:27
ミスリードって誤読じゃないよ

582 :仕様書無しさん:2009/12/12(土) 13:28:21
つーか、昔と同じく普通に網羅テストを実施して足りなければ
アサートでも仕込んどけば済む話なのに、ソースを改変してまでxUnitテストに拘る奴ってアホなの?


当然、網羅テストも別に工数を取ってやるつもりなんだろ?


583 :仕様書無しさん:2009/12/12(土) 13:38:06
その網羅テストは、どうやって実行するんだ?
それと、アサーションはテストの代わりにはならないよ。特にC++では。

584 :578:2009/12/12(土) 13:43:45
>>582
具体的に話そうぜ。
お前の「昔のやり方」がわからないから話が紛糾してるんだよ。

それから、俺はお前にxUnitを使えと説得してるわけじゃないよ。
使いたくなければ使わなければ良いだよ。俺は便利だから使ってるけど。
逆に、何で自分では使わないxUnitにこだわってるのか不思議だ。

アサートでは、たとえば「有効な通貨単位が与えられなかったときに例外をスローする
通貨返還クラス」のテストは出来ないよね。

585 :仕様書無しさん:2009/12/12(土) 13:49:16
網羅テストって何?
C0カバレッジのこと?
C1カバレッジのこと?

586 :仕様書無しさん:2009/12/12(土) 13:54:51
>>584
お前はxUnitテストをする前は
テストをしてなかったのか?w

587 :仕様書無しさん:2009/12/12(土) 13:56:40
>>582
お前やっぱ>>281だろ。
昔のやり方って、ステップ実行のことなんだろ?
んで、画面起動して、マニュアルテストなんだろ?

588 :578:2009/12/12(土) 13:58:58
>>586
だーかーらー、昔のやり方ってのは、世界共通の唯一無二のものじゃないんだから、
昔のやり方でやろうと言われてもわからないんだよ。

ちなみに俺は、自前のテストハーネス&スタブ&シミュレータでやってたよ。

589 :572:2009/12/12(土) 14:07:15
まだ理解出来ない奴がいるな、個別に説明してやるよ
>>575
>>君の本来の主張は
俺の主張は>>561だ、読めば分かるだろう?つまり
>>281に対して>>283の回答が間違っていると言うことだ 281はxUnitの上手いやり方を聞いている
それに対して、283は「凝集度を上げ、結合度を下げる」と書いている、こんなのはxUnitを使ったことが
ある人間なら絶対に書かない、良い悪いは別にして「テストが簡単になる」ことは絶対にない
ただの本の受け売りで「凝集度を上げ、結合度を下げるとテストが容易になる」をバカの一つ覚えで書いている
理解出来たか?

>>576
>nUnit使う事によって時間的なコストがかかるなら、あらかじめそれをコストに含めればいいだけの話なのに、なにがそんなに嫌なんだ?めんどくさいだけか?
だから、「テストが簡単になる」ことは絶対にないと言うことだろう

>>577
>ひとつ聞くが、どのようなテストなら簡単だと言ってる?
逆だ、俺は「テストが簡単になる」とは、一回も言っていない、「テストが簡単になる」と言っている奴に、アホだとは言っているが

>>579,581
>ずっとテストをする=xUnitテストをすると
>わざとミスリードしてる奴が多いけど
>>281>>283を読めばわかるんじゃないか?

>>578,580
>単独で動かせない、つまり結合度が高く凝集度が低いということだから、
>その反対のコードを書けと言っただけの話だ。
本当に、「結合度」と「凝集度」が理解出来ているのか?
「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事
初期化から何もかも、つまり単独で動かし易い事もある
だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして

590 :仕様書無しさん:2009/12/12(土) 14:13:33
だから今までそれぞれがやってた問題が出なかったテストでいいだろ
ってレベルの話なんだがw
例えば関数ごとにinoutで
単体テストしてるんでもいいしな


問題が出まくりのところはxUnitテストを導入しても
どうせバグりまくりだろ?w

591 :仕様書無しさん:2009/12/12(土) 14:19:57
結局、この手の○○を使えば超簡単とか言う
詐欺的手口にすぐに引っ掛かる連中は
元からテストとか考察が必要な作業は出来ないという事だな

592 :仕様書無しさん:2009/12/12(土) 14:36:52
すごい、個別に一つ一つ回答してるが一つもかみ合ってない…

593 :仕様書無しさん:2009/12/12(土) 17:17:47
>>589
どうでもいいけど、昔のやり方とやらを早く書け

594 :仕様書無しさん:2009/12/12(土) 17:22:30
テストうんぬんの前にへぼな設計書が出来てるとか?

595 :仕様書無しさん:2009/12/12(土) 17:33:59
>>593
悪いが頭が悪い奴の道楽に付き合う暇はない

596 :589:2009/12/12(土) 17:38:14
>>593
俺が書いたのは>>572,589
お前勘違いしているぞ、誰と戦っているんだw

597 :578:2009/12/12(土) 17:46:19
>>589
> 本当に、「結合度」と「凝集度」が理解出来ているのか?
> 「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事

いや、全く同じ認識だけど違うように読めた?

> 初期化から何もかも、つまり単独で動かし易い事もある

そういう場合もあるだろうね。
でも>>281
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変
と言ってるよ?

> だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして

見解の相違だね。俺ならこう言うよ。
「凝集度が高ければ、一般にUnitTestは簡単になる」

俺に言わせれば、これを認めない奴はほんとにxUnit使ってるのか?ってことになる。
ちなみに俺は9年くらい使ってるよ。

598 :仕様書無しさん:2009/12/12(土) 18:01:57
つーか、個人的に趣味で使ってる話を
書いてないか?

そんなもんはどうとでも言えるんだがw

599 :589:2009/12/12(土) 18:07:37
>>597
Publicに書いたフィールドを、「結合度を下げる」為にprivateにしました。
はい、どう「xUnitテストが簡単になる」のか説明してくれ

600 :仕様書無しさん:2009/12/12(土) 19:20:14
前提も滅茶苦茶だし論理も滅茶苦茶だし
やりやすいように好きにすればいいじゃん
それで問題ないならそれでいいじゃん
無理に導入されてイラついてるならそこの上司に訴えればいいだけ

××はダメだなんて啓蒙活動になぜ必死になるかわからん
それこそミスリードすればいくらでも騙されてヒートアップするタイプのアホの発想だろ

601 :仕様書無しさん:2009/12/12(土) 19:35:47
安っぽい持論だからとうとう崩壊しちゃったなw

602 :仕様書無しさん:2009/12/12(土) 19:36:14
はぁ?

603 :仕様書無しさん:2009/12/12(土) 21:56:19
どうぞ
http://www.dotup.org/uploda/www.dotup.org446249.jpg

604 :578:2009/12/14(月) 12:51:37
>>599
それは、何と何の結合を、何結合から何結合に下げたのですか?
この辺をを参考にして、明示してください。
(どれもググった上位のページ)
http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html
http://homepage3.nifty.com/koha_hp/KeyWords/KW.Coupling.html
http://members3.jcom.home.ne.jp/daruma_kyo/aboutooa/module_cohesion_coupling.html

605 :仕様書無しさん:2009/12/14(月) 16:06:51
>>598
誰宛のレス?

606 :仕様書無しさん:2009/12/14(月) 16:20:39
アホっぽいのが何人いるのか知らないけど、みんななぜだか文体が同じだよね。

607 :仕様書無しさん:2009/12/14(月) 17:56:56
みずほ証券の株誤発注裁判、東証は控訴せず
ttp://itpro.nikkeibp.co.jp/article/NEWS/20091214/342100/
>重要な論点のほぼすべてにおいて当取引所の主張が認められながらも当取引所に
>賠償責任があるとされたことは残念ではあるが

自分とこのソフトのバグで取り消し処理が受け入れられずに被害が拡大したのに、
なんで残念とかまだ言ってるんだこいつは

608 :仕様書無しさん:2009/12/14(月) 19:30:34
意外だけど、東証に取り消し処理をする義務はないらしいよ

609 :599:2009/12/15(火) 00:53:37
>>604
何故こっちが、回答しないといけないのか理解出来ない、一応回答はするが
内容結合 →(制御結合、スタンプ結合、データ結合)

こっちは答えた、そっちも「xUnitテストが簡単になる」理由を説明してくれ

610 :578:2009/12/15(火) 12:35:23
>>609
何と何の結合を?

611 :578:2009/12/15(火) 13:00:35
やっぱ、答えなくていいや。

public変数をprivateにその他の変更一切なしで変更できるとするなら、
それはクラス内メソッド間で共有するだけの変数だから、その二つの
メソッド間の結合度は変わっていない。

クラス外部から変更/参照するためのpublic変数(class Foo対 class
Barの結合)だとするなら、単純にprivateに持って行くことはできず、
他クラスからアクセスするためのアクセッサを追加する必要がある。
なので、テストメソッドからも容易にアクセスできるはず。

テスト対象クラスとテストクラス間の結合の話なら、>>580で俺のスタンスは
回答済み。

そもそも、>>281で初期化が大変なメソッドのテストをするという話で、
初期化が大変なら初期化しなければいいじゃないということ。
つまり、テスト対象メソッドと、初期化メソッドの結合度を下げましょうねってこと。
どうやればいいかは、>>326読め。

もう君の相手するの飽きたので、何言われても回答しないよ。

612 :仕様書無しさん:2009/12/15(火) 16:51:02
要するにxUnitテスト使いたいから
俺はソースを改変しまくるおw

ってだけの話じゃねーかwww

613 :609:2009/12/15(火) 23:13:32
>>611
「結合度」が理解出来ていないのは分かった

「結合度」は、モジュールの独立性を測る為のもの
外部モジュールから「結合」可能なものの中で一番高いものが、その「結合度」になる
お前の理屈だと、ローカル変数をグローバル変数にしても内部メソッドからしか呼ばなければ「データ結合」だと言う理屈になる
本来「結合度」と言うのは、知らない内に、別モジュールからアクセスされる事を”制限する為の尺度”で、実際の別モジュールとの関係ではない

>クラス外部から変更/参照するためのpublic変数(class Foo対 class
>Barの結合)だとするなら、単純にprivateに持って行くことはできず、
>他クラスからアクセスするためのアクセッサを追加する必要がある。
>なので、テストメソッドからも容易にアクセスできるはず。
だから、”テストメソッドからも容易にアクセスできるはず。”では
ただの現状維持で簡単になってはいない、お前が言ったのは「xUnitテストが簡単になる」だ

>もう君の相手するの飽きたので、何言われても回答しないよ。
分かっている、間違っているから回答出来る訳がない


614 :仕様書無しさん:2009/12/16(水) 03:23:59
勝利宣言で終了ですな。
もうお前来なくていいよ。

615 :仕様書無しさん:2009/12/16(水) 05:37:44
>>608
え、それまじ?
ソースがあったらお願い。
あと、判決文のありか知ってる人がいたら、URLプリーズ。見つからないんだ…

616 :仕様書無しさん:2009/12/16(水) 11:03:32
xUnitは、それなりの設計スキルが無い奴が使うと、工数がかかるばかりで却って害悪。
その意味では、xUnitを使えばUnitTestが楽になるというのは嘘。
xUnitでなくともきちんとUnitTestを行える人間が使って初めてメリットがある。

617 :仕様書無しさん:2009/12/16(水) 14:30:50
つーか、クラス書いてゴニョゴニョやるようなw
プログラム言語用のテスト用ツールなだけなのに
すごい信仰が厚い奴がいるってだけの話

618 :仕様書無しさん:2009/12/16(水) 17:10:31
信仰に厚い奴がいるんじゃなくて、熱心なアンチがいるの間違いでしょ

619 :仕様書無しさん:2009/12/16(水) 17:25:08
>>617
うざいなー
お前は一生アサーションとステップ実行でテストしてろ

620 :仕様書無しさん:2009/12/16(水) 18:30:56
xUnitでメリットを感じてるって言ってるのに、
「いや、お前が感じているメリットはメリットではない」
とか言い出すから荒れるんだよ。

621 :仕様書無しさん:2009/12/16(水) 20:11:00
xUnitテストを使うまで単体テストをしてない連中じゃあ
浮かれるのも仕方ないかもな

622 :仕様書無しさん:2009/12/17(木) 11:36:51
浮かれてるし、信仰が厚いと言うことにしたいのですね

623 :仕様書無しさん:2009/12/17(木) 12:56:24
少なくともツールの受け売りしてる側なのは事実だな

624 :仕様書無しさん:2009/12/17(木) 15:53:45
使ってみてだから、受け売りじゃないだろ、アホ

625 :仕様書無しさん:2009/12/17(木) 16:29:08
もう何が何でもxUnitを使ってる連中を下に見ないと、自己を保てなくなってる段階。

626 :仕様書無しさん:2009/12/17(木) 16:52:47
久しぶりに、よさげな本が発売されてます。

『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド
(IT Architects’Archive ソフトウェア開発の実践)』
2009/11/28発売
http://www.amazon.co.jp/dp/4798119970/

627 :仕様書無しさん:2009/12/17(木) 17:26:16
>>624
伝書鳩だけが受け売りじゃないだろ、アホ

628 :仕様書無しさん:2009/12/17(木) 17:48:26
受け売りじゃないとは例えば言語ツールで言えば
他の言語を使用して同プロジェクトを実行した場合の
長所短所を具体的にかつ数字ベースで示す事

xUnitテストいいよー、簡単になるよー
xUnitテストで上手くいかない奴はソースを改変するか
xUnitを使うための設計をした方がいいよー
では、まさに受け売りをしている事になる

控えめにみても信者だ

629 :仕様書無しさん:2009/12/17(木) 22:51:40
アジる人々のスレ

630 :仕様書無しさん:2009/12/18(金) 10:11:31
>>628
> xUnitテストいいよー、簡単になるよー
こんなこと言ってた奴いたか?

631 :仕様書無しさん:2009/12/18(金) 11:25:56
受け売りの意味がわからない馬鹿

632 :仕様書無しさん:2009/12/18(金) 11:40:41
>>627
意味がわからん

633 :仕様書無しさん:2009/12/18(金) 11:43:54
自分の糞コードのせいでxUnitが上手く使えないってことから始まったのに、
なんで>>628みたいな思い込みするんだろうか。
まぁ、糞コードなんで、xUnitでなくともテストは難しいだろうがw

634 :仕様書無しさん:2009/12/18(金) 16:29:39
>>628
だから、上手く使えない奴が使っても駄目だよ。
上手く使える奴だけがメリットを享受できる。
お前には一生無理だ。

635 :仕様書無しさん:2009/12/18(金) 18:06:04
>>628
こいつリファクタリングしたことなさそうだな

636 :仕様書無しさん:2009/12/19(土) 13:08:27
>>613
どう見ても結合度がわかってないのはお前の方なんだが。

>本来「結合度」と言うのは、知らない内に、別モジュールからアクセスされる事を”制限する為の尺度”で、実際の別モジュ
>ールとの関係ではない

Wikipediaの一行目にもこう書かれている。
>In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.

お前が言いたいのはscopeのことじゃないかとも思えるが、それでも何を言いたいのか良くわからない。

637 :仕様書無しさん:2009/12/19(土) 15:37:28
>>636
英語が理解出来ないのか、それとも日本語が理解出来ないのか?

638 :仕様書無しさん:2009/12/19(土) 22:08:22
物事が理解出来ないじゃないのw

639 :仕様書無しさん:2009/12/21(月) 02:24:00
LoginForm form = new LoginForm();
form.setUserId("user1");
form.setPassword("password1");
form.execute();
String message = form.getMessage();

これアサーションでどうやってテスト書くの?
ちなみに、ログインに成功すると「こんにちは、user1さん」というメッセージが返り、
失敗するとUserInputExceptionがthrowされ、ex.getMesssage()で
「ユーザIDまたはパスワードが違います」が返される。

640 :仕様書無しさん:2009/12/21(月) 14:30:54
つーか、アサーションでテストなんて論外。
駄目なところ:
1. テストに失敗するとそこで止まってしまう
2. 失敗したときの具体的な値がわからない(わかる言語もある?)
3. C++だとデバッグビルドの場合しかアサーションが有効にならない

641 :仕様書無しさん:2009/12/21(月) 15:01:13
オマエラどーでもいいが、知識がない事を
わざわざ晒してどーする?w

642 :仕様書無しさん:2009/12/21(月) 16:50:25
>>641
知識のあるとこ見せてくれよ

643 :仕様書無しさん:2009/12/21(月) 19:44:58
見せたらショックのあまりお前らが自殺するからダメ

644 :仕様書無しさん:2009/12/22(火) 00:25:48
2chだから正直に言うけど、俺もxUnitテスト不要派だなあ。
確かにxUnitテストをするとデグレ発生率が低くなるというメリットはある。
だけどそのために工数(人件費)が2〜4倍になるんじゃコスト対効果が釣り合わないと思う。
ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。

645 :仕様書無しさん:2009/12/22(火) 10:02:38
不要な奴は使わなければいい。
ただそれだけ。

646 :仕様書無しさん:2009/12/22(火) 15:12:18
>>644
こいつリファクタリングしたことなさそうだな

647 :仕様書無しさん:2009/12/22(火) 15:47:54
リファクタリングによるバグはxUnitテストをしても100%防げるわけじゃないんだよ?

648 :仕様書無しさん:2009/12/22(火) 16:57:44
した方がより防げるだろ。

649 :仕様書無しさん:2009/12/22(火) 17:01:29
>>644
> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。

というほどきちんとした設計ができているのに、

> だけどそのために工数(人件費)が2〜4倍になるんじゃコスト対効果が釣り合わないと思う。

というのは、よほどコーディング能力が劣ってるんだろうな。
まぁ、そのレベルならxUnit使っても意味ないね。

650 :仕様書無しさん:2009/12/22(火) 17:43:32
>>644
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。

それは、何か変更したときに、網羅的なテストは必要ないってことかな?
そういうプロジェクトもあるだろうけど、リリース後バグが発見されたらどえらい工数が
かかるプロジェクトもあるんだよ。

651 :仕様書無しさん:2009/12/22(火) 17:48:49
なんつーか、「名も知れないこいつより俺の方がすごい自慢」して、むなしくならんのかね。
たとえここで誰かをやりこめても、それが一体何になるというのだ。

652 :仕様書無しさん:2009/12/22(火) 18:11:19
>>644
> だけどそのために工数(人件費)が2〜4倍になるんじゃコスト対効果が釣り合わないと思う。

例えば、コーディング+単体テストで3ヶ月かかるところが、6ヶ月〜1年かかるってこと?
それはいくらなんでもかかりすぎでは・・・。

> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。

そういう断言しちゃうから叩かれるんだって・・・。

653 :仕様書無しさん:2009/12/23(水) 09:10:48
>>644
その考えは間違っている、たしかに言っている事は分かる
xUnitより通常のデバッガの方が機能も上だし、そちらを使った方が
効率的にテストが出来る、もちろんデグレも
設計(凝集度・;結合度)やアーキテクチャー(分散技術DLL・COMなど)が正しければ
影響範囲が絞らるから、”デグレ確認用のPG”の必要性は低い
しかし、それは優秀な人材がそろっているプロジェクトだけの話だ
いろいろな人間(アホ・バカ・新人)がいるプロジェクトでは
”テスト用のPG”を書かせて、正しく通ることを確認出来るようにして、平均値を上げるしかない
もちろん優秀な人間には苦痛だが、プロジェクト全体で考えれば仕方がない



654 :仕様書無しさん:2009/12/23(水) 11:02:28
>>653
優秀な人間ほどxUnitを使うことは苦痛じゃないんだけど。
ほんとにxUnit使ったことあるのか?

655 :仕様書無しさん:2009/12/23(水) 11:14:32
実装継承して機能を拡張していくポリシーの奴とか、知らない間にデグレしてる危険線がおおありなんだが

656 :仕様書無しさん:2009/12/23(水) 13:31:03
>>650
>それは、何か変更したときに、網羅的なテストは必要ないってことかな?
網羅的なテストをやるかどうかはバグの内容によるでしょう。
大きい修正の場合は、結局他のテストも必要になるし。

>>652
>例えば、コーディング+単体テストで3ヶ月かかるところが、6ヶ月〜1年かかるってこと?
いや、単体テストは除外して
 A.コーディング
 B.コーディング + xUnit用コーディング
の比較で2〜4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位?

>>653
しかしダメなプログラマほどテストコードがザルになる罠…
出来る人間を集めましょう。

>>654
何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。

>>655
そんなバグの出やすいポリシーってどうなの

657 :仕様書無しさん:2009/12/23(水) 17:00:44
いやもう君や君のチームでxUnitが有効じゃないのはわかったから、何も言わなくていいよ。

658 :仕様書無しさん:2009/12/23(水) 17:12:46
>>656
> いや、単体テストは除外して
>  A.コーディング
>  B.コーディング + xUnit用コーディング
> の比較で2〜4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位?

え、3ヶ月でコーディングできるものに対して9ヶ月もテストコード書くの?
おおげさじゃないとしたら、レベルが低すぎる。

> >>654
> 何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。

それ、テストを書き慣れていないということじゃないのなら、設計が悪いか、
テストコードの書き方が悪いか、コーディング能力が低いかのどれかだよ。

659 :仕様書無しさん:2009/12/23(水) 18:54:26
xUnitに嵌れなかった奴は、嵌れた奴がうらやましくてしかたないんだよ。
で、FUD流したり釣り発言したり。ルサンチマン炸裂だな。

660 :仕様書無しさん:2009/12/23(水) 19:06:15
それ、嵌れた奴は嵌れなかった奴を見下したくてしかたがないとも言えるよ。このスレでは。

661 :仕様書無しさん:2009/12/23(水) 20:08:38
マーチン・ファウラーも言ってたけど、デバッグ用のprintfやデバッガ用のコードを書く暇があったら、
テストメソッド書けというくらい、単純な短い軽いメソッドでいいんだよ。
それと、基本I/Fに対してテストするってことね。これがわかってなくて、内部のvectorをpublicにして、
その内容を確認するでかいテストメソッドを書く奴とかがいる。で、hashに変えることになって死ぬと。

662 :仕様書無しさん:2009/12/23(水) 20:17:19
いつまでxUnitの話してんだよ・・・

663 :仕様書無しさん:2009/12/23(水) 20:31:13
スレ住民をテスト中

664 :仕様書無しさん:2009/12/24(木) 22:02:23
しかし、xUnitの話はxUnitのツールの話か
それともTDDみたいな開発手法の話をしているのか?

665 :仕様書無しさん:2010/01/01(金) 00:41:54
>>326読み終わったけど、すげーおもしろかったわ。
マジでおすすめだな。

666 :仕様書無しさん:2010/01/01(金) 01:55:42
>>665
その本は全然駄目
マーチン・ファウラーの 『リファクタリング : プログラミングの体質改善テクニック』の方が100倍為になる
そんな本を薦める人間は、多分本を読まない人間なんだろうな

667 :仕様書無しさん:2010/01/01(金) 13:07:08
>>666
リファクタリングはずっと前にもう読んだ。
>>326の駄目な所ってどこ?

668 :仕様書無しさん:2010/01/01(金) 15:24:45
まぁリファクタリングに関してどれか一冊というならリファクタリング本しか無いんだろうけど、
10年前の本だから古くさいってのも事実。GoFもそうだな。
レガシーコードの方はリファクタリングの本じゃないから、比較はできない。

669 :仕様書無しさん:2010/01/01(金) 23:58:51
>>668
>比較はできない。
本当に両方読んだのか?

670 :仕様書無しさん:2010/01/03(日) 17:56:55
「コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介」
って内容じゃん
リファクタリング"だけ"の本じゃないよ

671 :仕様書無しさん:2010/01/03(日) 17:59:02
むしろ『リファクタリング : プログラミングの体質改善テクニック』の方が
テストを扱っていないので為にはならんのでは?

672 :仕様書無しさん:2010/01/04(月) 00:42:33
>>670
>リファクタリング"だけ"の本じゃないよ
>>671
>テストを扱っていないので為にはならんのでは?
『リファクタリング : プログラミングの体質改善テクニック』がリファクタリングだけの本で
テストを扱っていない

この人たちは、何で読んでもいない本を読んだと言っているのか?

673 :仕様書無しさん:2010/01/04(月) 14:25:37
『リファクタリング』は、既存のコードを改善するのが目的なのに対して、『レガシーコード改善ガイド』は、
既存のコードを改善するのが目的ではない。だから比べられない。
『レガシーコード改善ガイド』は、書名が良くないね。元はWorking Effectively With Legacy Codeなのに。

全然駄目っていう人もいるけど、『レガシーコード改善ガイド』や『Working Effectively With Legacy Code』で
ググれば、世間の評判がわかるし、ここで議論するほどのことでもないよ。

674 :仕様書無しさん:2010/01/04(月) 18:46:25
>>672
ぐだぐだ言わずに、まず駄目なところあげろよ
まぁ読んでないからあげられないんだろうけど

675 :仕様書無しさん:2010/01/04(月) 21:27:09
>>674
文章が駄目だ、原作は良いのかもしれんが
あの日本語訳は駄目だろう、最初から最後まで読んだのなら
普通の人間なら違和感を感じると思うが

676 :仕様書無しさん:2010/01/04(月) 21:49:46
引用して批判しようね

677 :仕様書無しさん:2010/01/04(月) 22:06:22
テクノロジックアートじゃあるまいし。
多少変なとこがあるのかもしれんが、全体を通して駄目ってことはない。
誤訳があるなら指摘しましょう。

678 :仕様書無しさん:2010/01/04(月) 22:12:05
訳が駄目だからリファクタリングの方が良いってのはどういうロジックだ。

679 :仕様書無しさん:2010/01/05(火) 00:06:30
>>673
結局読んでないのか、情けないw

680 :仕様書無しさん:2010/01/05(火) 00:25:36
バカだね、こいつ”レガシーコード改善ガイド”なんてマーチンのパクリじゃんw
本当に教養ないバカは困るわw

でも、なんでそんなにムキになるんだ?326=665がバレるぞw
お前は何がしたいんだw

681 :仕様書無しさん:2010/01/05(火) 06:56:34
このキチガイ、いつまでこのスレに粘着するつもりなんだ

682 :仕様書無しさん:2010/02/10(水) 16:27:36
プログラマーにとってのテストの重要性
http://www.publickey.jp/blog/10/post_92.html

683 :仕様書無しさん:2010/02/10(水) 18:47:44
バグ出しなんか中国人にやらせろ

684 :仕様書無しさん:2010/02/11(木) 01:37:06
仕様わかってなきゃできねーだろ

685 :仕様書無しさん:2010/02/11(木) 01:44:45
コード書いてるやつも仕様なんてわかってねえよ

686 :仕様書無しさん:2010/02/11(木) 01:52:44
テストが仕様書(キリッ
ならコード書く側の人間はかなり楽になるだろうな
とりあえずテスト通るようにすりゃいいんだから

687 :仕様書無しさん:2010/02/11(木) 02:00:52
ユニットテストがあるから安心してリファクタリングできるってのがよく分からんわ
お前が書いたそのテストコードってそんなに信頼できるもんなの?

688 :仕様書無しさん:2010/02/11(木) 04:48:27
>686
テストファーストがそれに近い考えかたぢゃね

>687
とにかく俺様専用テストが通れば問題ないんです(キリッ)

689 :仕様書無しさん:2010/02/11(木) 10:13:06
>>687
テストコードが信用できないとしたら、
じゃあ他に何でテストしたことを客観的に証明するんだ?

690 :仕様書無しさん:2010/02/11(木) 13:36:50
>>687
テストコードもない状態でリファクタリング始めるよりは3万倍くらいマシ
そしてそれだけでテストコードには価値がある

691 :仕様書無しさん:2010/02/11(木) 22:48:24
仕様をコードで書けば(・∀・)。


692 :仕様書無しさん:2010/02/11(木) 22:57:07
xUnit で書いてるようなコードを「テスト」って言うから誤解が生じるんだろ

693 :仕様書無しさん:2010/02/11(木) 23:25:09
誤解してるのはお前の方なんですが

694 :仕様書無しさん:2010/02/12(金) 02:20:18
>>687
確かにその通りだな、もともとリファクタリングが簡単に出来ないソースを書いた奴の
テストなんて絶対信用しないしなw

>>689
>じゃあ他に何でテストしたことを客観的に証明するんだ?
アホか? テストコードが客観的に証明になると思っているのか
証明出来たからには、絶対にそのプログラムではバグが無いんだな

>>690
>テストコードもない状態でリファクタリング始めるよりは3万倍くらいマシ
3万倍の客観的な証拠は? 精神的に良いぐらいの価値しかないぞw

>>692
そうだな、あれはテストじゃなくコーディングの一部だと理解出来てない奴が多いな

>>693
お前、自分の知識の無さが恥ずかしくないかw

695 :仕様書無しさん:2010/02/12(金) 12:08:09
>>694
> >じゃあ他に何でテストしたことを客観的に証明するんだ?
> アホか? テストコードが客観的に証明になると思っているのか
> 証明出来たからには、絶対にそのプログラムではバグが無いんだな

まあ、落ち着けw
コミュニケーションが成り立ってないぞ。

俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。

あと、テストしたという証明は、バグがないという証明のことではないからな。

696 :仕様書無しさん:2010/02/12(金) 14:51:21
>>694
お前はもういいったら。

697 :仕様書無しさん:2010/02/12(金) 14:56:05
xUnitって、Unit Testing Frameworkなんだけど、この'Testing'ってどういう意味?

698 :仕様書無しさん:2010/02/12(金) 15:11:16
プログラムの完全性を証明するようなたぐいの「テスト」の話なんか誰もしてなくて、
リファクタリングを安心して行えるに足る「テスト」の話をしているのに、xUnit大嫌い
馬鹿がまたもや大暴れの予感。

699 :687:2010/02/12(金) 19:20:29
>>689
客観的な証明とかどうでもよくて、
なんで「安心して」リファクタリングできんのかが分からんのだけど

700 :687:2010/02/12(金) 19:33:10
>>698
安心できる方法があるんなら知りたい
テストコードのインスペクションとかやってたりすんの?

701 :仕様書無しさん:2010/02/12(金) 23:36:19
多い日も安心!

702 :仕様書無しさん:2010/02/12(金) 23:46:33
>>700
お前まだ理解してないみたいだなw

リファクタリングって何かわかってるのか?外部から見たプログラムの動きを変えずに、
プログラムの中身を変える(改良する)ことだぞ。

どんなにすばらしいテストを考えたとしてもそれを実施しなければ意味がない。
プログラム修正前、まずテストを実施する。リファクタリングで
プログラムを修正したら、まったく同じテストをしないといけない。

テスト項目が数える程度しかないのなら簡単だろうが、何十、何百もあるような場合、
テストコードを使う以外で、まったく同じテストを漏れなく実行しましたと
どうやって自信を持っていえるんだ?本当にしたとしても時間がかかるだろ。

テストコードがあれば、一瞬で安心することができる。
リファクタリング前にやったテストに、リファクタリングしても合格しましたと。

703 :仕様書無しさん:2010/02/13(土) 00:14:18
インスペクションみたいな高コストなモン、うちじゃ滅多にやらんなぁ。
でもxUnitかどうかによらず、テストの項目、手順と結果のレビューはやるだろ。
近辺だと実装者以外がxUnitやって、2人でターゲットコードのレビューと
テストコードのレビューを同時にやるのとか多い。
もう一人、第三者欲しいけどそんな余裕は無い。

まぁxUnitで安心かどうか分からんけど、コード修正したら
PTからやり直さにゃならんわけで・・・

なんか良い方法ない?
俺は別にxUnit好きじゃないし。
むしろウザいが、まだ他よりマシって感じ。

704 :仕様書無しさん:2010/02/13(土) 01:10:49
>>687
お前には、プログラマとしての決定的な何かが欠けてるので、誰がどんなに説明してもわからんだろう。

705 :694:2010/02/13(土) 04:44:56
>>695
すまん、勘違いした

>俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
>君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。
別にリファクタリングでテストが必須とは限らない、逆になるべくテストしないで済む方法で行う

>>700
安心に行う方法は、リファクタリング支援機能を使うのが一番安全に出来る
今は色々言語用のツールも揃っているし、機能も豊富になってきた
自動でリファクタリングしたものはリファクタリング前の機能と同一だからテスト不要(ツールにバグがある場合知らんが)

>>702
>プログラムを修正したら、まったく同じテストをしないといけない。
お前知識が浅いな、リファクタリング支援ツールも知らないのかw

706 :仕様書無しさん:2010/02/13(土) 10:05:49
君のところのSQA審査は楽そうで良いな。

707 :仕様書無しさん:2010/02/13(土) 10:39:15
>>705
お前、リファクタリングツールでできる範囲の話しかしてないのか?
アルゴリズムの変更などは、リファクタリングツールで自動的に変更なんて
できないんだが。

浅いなぁw

708 :仕様書無しさん:2010/02/13(土) 10:53:16
>>705
きみんちでリファクタリングと呼ばれてるものは世間様と違うようだ
あまり家の外でリファクタリングという言葉を使わないほうがいいぞ

709 :仕様書無しさん:2010/02/13(土) 11:07:20
まぁ落ち着けよ。
きっとそういうツールがあるんだよ。
IF仕様を元にモジュール内を最適化してくれるようなツールが。
俺は知らんけど、多分浅いからだ。

710 :仕様書無しさん:2010/02/13(土) 20:36:55
> どんなにすばらしいテストを考えたとしてもそれを実施しなければ意味がない。

糞のような勘違いテストを何千回実行しても意味なくね?

711 :687:2010/02/13(土) 20:38:47
>>710は俺ね

712 :687:2010/02/13(土) 20:41:10
>>703
なるほどやっぱりレビュー的なものは要るよね

713 :仕様書無しさん:2010/02/13(土) 23:14:27
>>710
勘違いテストをお前はそのままにしておくのか?
遅かれ早かれ直すもんだろ。
直した後は、正しいテストを何千回も実行できるって気づかない?

勘違いテストを直す→バグ発見→修正

コード修正しちゃったよね?

コード修正した状態で、今までやった他のテストが全部ちゃんと動くって
どうやって自信をもって言えるのさ。
少なくとも影響するであろう他のテストを全部やりおえるまで自信は持てないはずだが?

714 :仕様書無しさん:2010/02/13(土) 23:22:28
変更に強いコードの書き方は理解できるのに、
変更に強い開発の仕方は理解できないのか。

715 :687:2010/02/13(土) 23:47:00
>>713
勘違いテストだったってことは突然気づくもんなの?
レビューとかするわけでもなく

716 :仕様書無しさん:2010/02/13(土) 23:49:56
何かかみ合って無いなー
俺の勘違いだったらすまんが、不毛過ぎて見てられん。

687が疑問なのは「どういうプロセスで勘違いに気付くのか」でしょ。
687はxUnitを実施することだけでは、その勘違いを見つけられない、
だから「xUnitをすることでは安心できない」って言ってるんじゃないかね。

対して710が言ってるのはxUnitの「再テストの容易性」についてだと思う。
多分710的には「xUnitをする」ということにテストコードの
検証フェイズが自明に含まれてるんじゃないかな?
(善意に見すぎか?)

それとも、710としてはxUnitのフレームワークでテストすることで
テストの品質そのものが確保出来ると考えてるの?
それならそれで、その説を聞きたいかも知れん。

717 :仕様書無しさん:2010/02/13(土) 23:54:36
ゴフぅっ・・・
長々と書いてたら簡潔に本人に先越される始末・・・orz

718 :687:2010/02/13(土) 23:57:43
>>716
イエスその通り
>>687でそう書いたつもりだったんだけど文章がまずかったのか。すまん

719 :仕様書無しさん:2010/02/14(日) 01:08:04
テストが勘違いだとわかるのは突然でもレビューでもなんでもいいんだよ。
問題は、それでわかった後どうするんだってこと。

テストコードにするだろ。

テストが間違いでしたってわかってテストを修正して、はいおわりじゃ意味がない。
そのあと修正したテストにちゃんと既存のコードが通るかテストしないといけない。

まあ、もともとが間違ったテストで通ったコードだ。当然コードにバグが見つかるわな。
そのあとコードを修正するだろ。ある意味リファクタリングと同じようなことをしているわけだ。

ここでテストコードがなければどうなるか。修正した結果他のバグが発生するかもしれない。
今まで動いていた、できていたはずなのに動かなくなる。これが「安心して修正できない」ってことだよ。

テストは考えただけじゃだめだ。ちゃんとテストにコードが通るか実際に動かしてみないといけない。
それも何度も、コードに修正が入るたびにだ。テストコードでやる以外に他にどんな手段があるよ。

720 :仕様書無しさん:2010/02/14(日) 01:23:41
それから、テストは日本語で紙に書いたって終わりじゃないからな。
テストをレビューという内容が、人間の言葉で書かれた文章が正しいかをチェックする程度じゃ
まだたりない。

その文章どおりちゃんとテストしたかをレビューしないといけない。

つまりだ「テスト項目 このフィールドは入力できる文字が数値三桁である」
こういう内容のテスト仕様書だとか確認表だとかあるだけじゃだめということだ。

なぜなら、テストをサボるかもしれないだろ?
(他にも勘違いで正しく実行してないかもしれない。日本語があいまいかもしれない。)

本当にこのテスト項目を正しく実施したかという証明が必要。
「本当にテストしたのか?」なんていわれたくないだろう。

テストコードってのは、この内容のテストをここに書かれているとおりにテストしました。
「これが私がやったテストです。」という証拠だよ。

やった内容が記録されているから「間違ったテスト」をやってしまったという事実でさえ記録される。
人間の言葉でテスト内容を書き、人間がそれを解釈して動いていたら、テストするたびに人間の不具合が混入する。

721 :仕様書無しさん:2010/02/14(日) 01:25:00
いやいやいや分かった後の話じゃなくってwwww
どうやって分かんのかってことなんだけど

722 :687:2010/02/14(日) 01:44:53
あ、>>721>>687です

723 :694:2010/02/14(日) 02:56:14
>>707
>お前、リファクタリングツールでできる範囲の話しかしてないのか?
まずは、支援機能で出来る事はやるのが鉄則
手動でリファクタリングするのは手動でしか出来ない場合だけ
なんでもかんでもxUnitをすれば良いと考えるのは無知な技術者

>アルゴリズムの変更などは、リファクタリングツールで自動的に変更なんて
>できないんだが。
アルゴリズムの変更は、一般的にレスポンス改善の場合に行う事が多いが
その場合、他メソッドのタイミングバグをxUnitでは検出するのが難しい

また、そのメソッド自身のテストコードも使い物にならないのが普通
本来xUnitのテストは、「「失敗の恐れがのある境界条件を考えて、そこを集中的にテストせよ」だ
アルゴリズム変更で、その境界条件は変ってしまう
お前リファクタリングをとやった事あるのか? その前に本当に理解しているのか? 根本的に間違ってないか?

>>708
>きみんちでリファクタリングと呼ばれてるものは世間様と違うようだ
>あまり家の外でリファクタリングという言葉を使わないほうがいいぞ
心配するな、俺はマーチンが書いた物の受け売りしているだけだ
知識が無い奴には分からんと思うが、まっ、お前は自分だけ正しいと思っていろw

>>709
>IF仕様を元にモジュール内を最適化してくれるようなツールが。
>俺は知らんけど、多分浅いからだ。
707もそうだが、リファクタリングを本当に理解出来ているのか
アルゴリズムの変更や、モジュール内を最適化は”性能改善”だ
xUnitのテストだけで済むと思っているのか?

リファクタリングの主な目的はプログラムの劣化を防ぐ事だと思っているが
お前らは、リファクタリング=性能/機能改善と考えているのか?

724 :仕様書無しさん:2010/02/14(日) 11:01:57
>>723
709だが。
レスの流れ上そう取られても仕方ないかも知れないが、
xUnitすれば十分とは言ってない。
お前の言うリファクタリングはツールだけで
完結するのか?と言っている。
何というツールを使えばコードの劣化が防げるんだ?

個人的にはリファクタリングは再設計だ。
最適化というのは処理を速くする事ではない。
無駄な処理を除いたり、構造を綺麗にしたり、
プログラムを今の目的にマッチさせることだ。
再設計の範囲次第でxUnitのコードがそのまま
使えることもあれば使えないこともある。
が、少なくともテストしなくて良いということはない。

725 :仕様書無しさん:2010/02/14(日) 12:50:23
>>723
> xUnitのテストだけで済むと思っているのか?

お前はどんなものがxUnitではすまないと思っているのだ?

お前が何か答えたとしよう。
じゃあ俺はこう答える。

お前が言ったそのテストをxUnitで実行すればいいだけの話だと。

726 :仕様書無しさん:2010/02/14(日) 13:04:29
xUnitが人間がぽちぽちやって確かめるテストと
まったく同じことをやっているってわかってないのかな?

727 :仕様書無しさん:2010/02/14(日) 15:45:28
>>725のトコだとITやSTもxUnit?
それともリファクタリングにゃそういうテストはいらんのかい?

728 :694:2010/02/15(月) 00:47:46
>>724
俺とはリファクタリング・xUnitの考えが違うみたいだな
俺の考えは

リファクタリング:
長年の改修で、劣化したコードを保守し運用コストを下げる行為
改修との違いは、改修が機能・性能改善、または機能追加・削除する為のものに対して
リファクタリングはリファクタリング前後でも等価であること
また、行う時期についても違い、改修が外部的要因で行うのに対して
リファクタリングは、プログラマの主観で行う
品質についても、リファクタリングは動いている物を修正するのだがら
改修より、厳しい品質が求められる、ユーザーに取って見れば
わざわざ動いている物を、修正してバグが出る何て許されない行為だ


xUnit:
コーディングコストを下げる為に、コーディングにテストを導入したもの
したがって、テストは別に行なう、例えばテストファーストなど
先にテストコードを書いて失敗させる、これはテストが目的じゃなく
コーディングが目的の為、またテストが全ての機能をテストするのに対して
xUnitは失敗の恐れがある所を重点に行い、単純な機能はテストしない

簡単に書くとこんな感じだ

729 :仕様書無しさん:2010/02/15(月) 03:20:49
xUnitはテストツールだろ。
テストファーストを行うときに使うツール。

別にテストファースト専用というわけではなく、
自動テストや回帰テストを行うときにも使える。

人間の言葉で書かれたテスト仕様書をコンピュータで実行できる形にしたもの。
それがテストコードで、xUnitはテストコードを楽に作成するときに使うツールの一つ

730 :仕様書無しさん:2010/02/15(月) 14:09:41
>>728
それ、あくまでも君の考えにすぎないから。
詳しくは、XP本とTDD本読んでね。
具体的に何がどう違うのなんて聞こうと思わないでね。それ甘えだから。

あと、句点打とうね。

731 :仕様書無しさん:2010/02/15(月) 14:44:31
リファクタリングツールが使えない開発環境のことなんか、これっぽっちも頭に浮かばないんだろうか。

732 :仕様書無しさん:2010/02/15(月) 14:51:27
edしかないような環境でプログラミングしなければならない場合も充分に考慮に入れなければなりませんよね!

733 :仕様書無しさん:2010/02/15(月) 15:03:53
紙の上でコーディングしてそれをedを使って延々と打ち込むだけの簡単なお仕事

734 :仕様書無しさん:2010/02/15(月) 15:14:27
UnixでJavaだけどvi

735 :仕様書無しさん:2010/02/15(月) 18:53:00
>具体的に何がどう違うのなんて聞こうと思わないでね。それ甘えだから。
無知な奴の新たなる予防線か
こう書けば突っ込まれて恥をかく必要はなくなるよな
ない知恵絞っていい事思いついたじゃねーか

736 :687:2010/02/15(月) 21:09:15
>>728
> コーディングコストを下げる為に、コーディングにテストを導入したもの

この辺よくわらん。kwsk

737 :687:2010/02/15(月) 21:10:09
×わらん
○わからん

738 :仕様書無しさん:2010/02/15(月) 22:47:41
709だが。

>>728
で、お前のいうリファクタリングはツールで完結するのか?
そのツールの名前は何だ?

739 :694:2010/02/15(月) 22:55:05
>>731-734
別に支援機能が無くても、カタログ通りやれば問題ない

>>736
xUnitは品質の為にやるものでなく、プログラマの生産性を向上するもの
つまり目的が違う、コーディングで時間が掛かるのはある程度
プログラムが正しく動くようにすること、その為にxUnitを使う
その為、上でも書いたが全てのメソッドをテストをするので無く
重要な部分だけをテストする
品質の為に行っているわけではない

>>738
ツールだけで、リファクタリングが完結するとは言っていないし、上でも書いたが
リファクタリングはプログラマーの主観で行うもの、何を持って完結と言っているのか?

740 :仕様書無しさん:2010/02/16(火) 11:14:38
という自説にすぎないってのに、いい加減気づこうね。

741 :仕様書無しさん:2010/02/16(火) 15:35:05
xUnit使うと生産性が落ちるって言う奴がほとんどなのに。

742 :仕様書無しさん:2010/02/16(火) 20:21:22
それはプログラマがテストしてないんだろ。

したとしてもちょっと動かしてみて終わり
あとはテスターにやらせてバグ見つけてもらう。
バグ修正したら、またテスターにやらせる。

たしかに、自分のところだけ見れば、生産性はいいだろうねw


743 :694:2010/02/16(火) 23:36:01
>>740
>という自説にすぎないってのに、いい加減気づこうね。
と自説を言うまえに本を読め

>>741
>xUnit使うと生産性が落ちるって言う奴がほとんどなのに。
だから、生産性を落とすまでxUnitをやる必要は無い
重要だと思う所だけ適用すれば良い

>>742
お前は馬鹿

744 :仕様書無しさん:2010/02/17(水) 00:44:47
xUnit使ってコーディングした後に品質のための単体テストやんのか。
別に悪いとは言わないけど、珍しいプロセスだね。

745 :仕様書無しさん:2010/02/17(水) 00:45:44
コーディングの為の単体テスト(キリッ

746 :仕様書無しさん:2010/02/17(水) 01:29:32
>>743
重要じゃないところはテストしないの?

747 :仕様書無しさん:2010/02/17(水) 07:44:44
自明な部分はテストしない

748 :仕様書無しさん:2010/02/17(水) 08:25:22
>>743
> >>740
> >という自説にすぎないってのに、いい加減気づこうね。
> と自説を言うまえに本を読め

お前の自説を裏付ける書籍があるならあげてみろ。
俺の反証はXP本全般とTDD本だ。

749 :仕様書無しさん:2010/02/17(水) 11:32:16
一人で開発してるんだろうから、自分が必要と思うとこだけテスト書けばいいと結論付けてるんだろう。

750 :仕様書無しさん:2010/02/17(水) 11:34:33
形式的手法が適用できる所以外は全部テスト書く

751 :仕様書無しさん:2010/02/17(水) 12:43:54
なんでそれを除外するのかわからん。

752 :仕様書無しさん:2010/02/17(水) 16:12:30
xUnitというのは、何かのテストをするための手段にすぎないというのがわかってない奴が多いな。
各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。

コーディングの助けになる程度の使い方でも良いし、品質向上のために使っても良い。
どちらも正しい。

753 :仕様書無しさん:2010/02/17(水) 17:47:27
>>694
つまり、コードレビューのかわりに、テストコードを見るひがやすを氏は馬鹿だと。

754 :仕様書無しさん:2010/02/17(水) 19:32:52
>>739=694
品質確保のためのモジュール単体テスト方法で、xUnitより良い方法って何なん?
是非やってみたいので教えてくれん?

それともモジュール単体テストは不要と思ってる人?

755 :仕様書無しさん:2010/02/17(水) 21:12:01
>>744
是非試してくれ、多分試した方が
俺の言いたい事が良く分かると思う

>>746
テストはする、xUnitはしない

>>748
>俺の反証はXP本全般とTDD本だ。
自慢か? だから本を読め、お前の「本を見ている」だけだ
本当に駄目な奴だな、いいかマーチンも
「プログラムの生産性が向上するために行うもの、品質保証部門が満足しても、それは副作用に過ぎない」と言っている

>>749
だから、テストは全てするxUnitは重要な部分を重点的に行う

>>752
>形式的手法が適用できる所以外は全部テスト書く
形式的手法か、テストのスレらしくなってきたなw
つまり、ホーア論理で数学的に証明出来ない部分、例えば例外処理とかをテストするのか?
良い方法だと思う、が! ハードルが高すぎないか? 会社とか集団だと、かなりレベルの高い人材がいないと

>>752
>各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。
その通りだ、だからxUnitは品質の為に使うと言っているが、間違っていると言っている
本来はプログラムの生産性が向上する為のもの、本来の使い方を否定するなと言っている

>>754
地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
単体はこれで充分

756 :694:2010/02/17(水) 21:14:50
名前を直すの忘れた
755=694

757 :687:2010/02/17(水) 22:13:10
>>739
混乱してきた。ユニットテストってのがなんなのか分からなくなってきた

758 :687:2010/02/17(水) 22:21:16
>>752
テストっていうのは品質向上のためにやるもんだって大前提がおかしかったってことか

759 :仕様書無しさん:2010/02/17(水) 22:29:32
品質は上がるよ

結果として

760 :687:2010/02/17(水) 22:55:31
やっぱよく分からんわ・・・
品質のためじゃない xUnit の使い方ってのがピンとこない

761 :仕様書無しさん:2010/02/18(木) 11:07:19
>>755
> その通りだ、だからxUnitは品質の為に使うと言っているが、間違っていると言っている

意味が分かりません。

762 :仕様書無しさん:2010/02/18(木) 11:19:17
Money::add(Money&)とかのコードが自明でテストコードを省略したとすると、第三者はそれが自明かどうか
メソッドのコードを見に行くしかないよね。
んで、テストコードのメソッドの網羅率が60%くらいだったらもううんざりだよね。

763 :仕様書無しさん:2010/02/18(木) 11:59:58
自明な部分でもテストは書く
ただし人間の手で書くのでは無くて自動生成する

764 :754:2010/02/18(木) 19:26:34
>>755
ありがとう。
けどうちの場合、そういう方法と検討した結果xUnitを選択したんで、
あんま参考にならんっぽい。

>>760
そもそもxUnitをテストに使ってないのと違うかな。
ドライバとスタブの作成フレームワークとしてxUnitを使ってるだけ、と。

極端な話、テストケース1件、確認項目0件でも、
ドライバからメソッドを呼べて、それがスタブを使って駆動できればOK、
ちゅーレベル。

765 :仕様書無しさん:2010/02/19(金) 21:51:48
自明な部分はテストしない。
自明じゃない部分はテストする。
そのテストをxUnitを使って行う。

xUnitを使わないところは、そもそもテストをしないところだ。

それで話は終わりだろ?

766 :仕様書無しさん:2010/02/19(金) 21:52:46
>>754
> 品質確保のためのモジュール単体テスト方法で、xUnitより良い方法って何なん?

xUnitより良い方法=テストをしない。


767 :仕様書無しさん:2010/02/19(金) 21:56:15
>>755
> 地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
> 単体はこれで充分

それ、プログラムが修正されるたびに全部ちゃんとやってるか?
それともサボっているか?

どっちか答えよ。

768 :仕様書無しさん:2010/02/19(金) 21:58:49
>>767
リファクタリング支援ツールを使うと
自動的にプログラムは修正されるから
テストが不要になる。

769 :仕様書無しさん:2010/02/19(金) 22:01:29
テストを書く→プログラムを作る。
これをTDDと呼ぶのに対して、

プログラムを作る→ステップ実行でテストする→テストが完了する→リファクタリング支援ツールでプログラムを作る→テストが不要になる。

これを、リファクタリング支援ツール駆動開発と呼ぶ。







770 :仕様書無しさん:2010/02/20(土) 00:41:13
ステップ実行(笑)

771 :仕様書無しさん:2010/02/20(土) 00:51:09
>>768
ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。

772 :仕様書無しさん:2010/02/20(土) 00:57:18
ステップ実行もxUnitも
やっていることは一緒、
ならなぜxUnitが必要なのか?

773 :仕様書無しさん:2010/02/20(土) 00:58:56
xUnitをやれば完璧。
なぜなら自明じゃないところはテストしなくて良いし、
自明じゃないところだけxUnitをすればいいから。

774 :仕様書無しさん:2010/02/20(土) 08:05:51
「なぜなら」の前後が芸術的なまでに関係ねーなw

775 :仕様書無しさん:2010/02/20(土) 12:33:11
>>772
一緒ではない。
xUnitは、
・反復実行可能
・第三者も余分な知識無く実行可能
・第三者がテスト内容を容易に検証できる
というところがステップ実行とは違う。

776 :694:2010/02/20(土) 15:17:58
xUnitを単体テストに使っている奴が多いみたいだが
それで上手く行っているなら、良い事だと思うが3つ教えてくれ

@条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか?
それとも、それ以外か?

Aシステムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
そのテストコード自身の信頼性はどうしてる?
>>771
>ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。
もちろん、こんなアホな考えはしない、xUnit自身の信頼性はあると思っているが
しかしテストコードは、人間がやるコーディングだからミスはあると思うが?

※@で機能でテストコードの場合は、Bは無視してくれ

B単体はホワイトボックステストで行う事が多いと思っている(俺的には単体=ホワイトボックステスト)
xUnit単体では、ホワイトボックステストでの確認が出来ないが、それについて
どのように考えるのか? 割り切っているのか? 

俺的には特別なツールを使わないでテストする場合、ステップ実行しか確認方法は無いと思っている
つまり、単体=ホワイトボックステスト=ステップ実行だから、単体=ステップ実行となる

777 :仕様書無しさん:2010/02/20(土) 16:02:21
>>776
1.両方
機能からテストケース起こして、1回目実行でカバレッジ計測。
その後詳細設計とテストケースの見直し。

2.レビュー
この辺はxUnitでもステップ実行でも変わらんやろ。

3.何が聞きたいのか意味分からん。
網羅性気にしてる時点でホワイトボックスだけど。
ホワイトボックステストが何かを誤解しとるのと違うか?

778 :仕様書無しさん:2010/02/20(土) 17:25:35
xUnitとステップ実行の一番の違いは、xUnitはバッチ等に組み込んで
自動で繰り返し実行できること。

antみたいなビルドツールでまとめてとか、HudsonみたいなCIサーバを使って
ソース管理にコミットされた時に自動で走らすとが出来るのはそれなりの
メリットではある。

そういう自動化を使わない、考慮しない環境ならステップ実行でもそんなに
変わるわけじゃないからね。 繰り返し試験を行わない、それほどバグが出ない
とかほとんど使われない機能とかの場合はxUnitだとコード書く分のコストが
かかるからやらない方がいいこともある。

779 :仕様書無しさん:2010/02/20(土) 22:40:29
>>775
それが成立するには第三者とやらから完全に信用を得ないと駄目だな

780 :仕様書無しさん:2010/02/21(日) 11:36:18
は?

781 :仕様書無しさん:2010/02/21(日) 16:22:30
ステップ実行でテストとは、よっぽど信用ないのね

782 :仕様書無しさん:2010/02/21(日) 20:37:00
>>776
> Aシステムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
> そのテストコード自身の信頼性はどうしてる?

テストコードのレビューは必須。

783 :仕様書無しさん:2010/02/21(日) 20:50:53
テストコードの正当性を第三者のレビューでチェックするというのはちょっと「?」だ。
もし自分が他人のテストコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか?
無理とは言わないが、それは第三者にとって相当な負担になる気がする。

784 :仕様書無しさん:2010/02/21(日) 21:02:42
一人で開発する時はどうするの?て話にもなるな。

785 :仕様書無しさん:2010/02/21(日) 22:01:29
>>783
他人の目が入るってのは結構有用だと思う
ペアプロの目的はそこにあるんじゃないのかな

786 :仕様書無しさん:2010/02/21(日) 22:53:09
それはある。完璧だと思ってても意外と見落としてたりする。

787 :仕様書無しさん:2010/02/22(月) 12:46:52
>>783
コードの正当性を第三者のレビューでチェックするというのはちょっと「?」だ。
もし自分が他人のコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか?
無理とは言わないが、それは第三者にとって相当な負担になる気がする。

って言われたらどうする?

788 :仕様書無しさん:2010/02/22(月) 12:48:48
レビューというものを軽く考えてる気がする
そりゃお遊戯会みたいなのもあるが、たいていは参加者全員がコードの大部分を理解しないとどうにもならんのだぞ
それだけの労力を毎回ゼロから生成するとかありえん

789 :仕様書無しさん:2010/02/22(月) 13:44:37
>>788
何を言いたいのか良くわからん。

790 :仕様書無しさん:2010/02/22(月) 13:49:16
>>783
「気がする」ってことは、実際に他人が書いたテストコードを見たこと無いわけだね。
だから「相当な負担になるかもしれない」なんて思うんだよ。

あるいは、君が書くテストコードがあまりにひどくて、他人もそんなテストコードを書いてると思ってるとか。

791 :仕様書無しさん:2010/02/22(月) 14:01:40
なんかxUnitのテストをオオゲサに考えてる人がいるみたいだけど、基本はこんな感じだよ。

cppunit内の自分自身をテストするコードのひとつ。
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/examples/cppunittest/TestTest.cpp?revision=343&view=markup

これ読むのそんなに負担か?

792 :仕様書無しさん:2010/02/22(月) 15:35:12
>>776
お前はxUnitを使わないんだよな?
俺も聞きたいことがあるんだが。

> @条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか?
> それとも、それ以外か?
条件網羅で、お前はどうやってテストしているんだ?
作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか?
修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか?


> Aシステムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
> そのテストコード自身の信頼性はどうしてる?
xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
そのテスト項目の信頼性はどうしてる? 人間が間違いなくテストを行ったと信じる根拠は何?

793 :仕様書無しさん:2010/02/22(月) 15:41:21
>>791
テストコードのコードが
普通のプログラミングのコードみたいに複雑だと
勘違いしているみたいだね。


テストコードでかかれるコードは、すごく単純。
Aを入れたらBが返る。
Aを入れたらオブジェクトの状態がBになる。
人間の言葉でテスト内容を書くのと大差ないレベルなんだよね。

794 :仕様書無しさん:2010/02/22(月) 16:54:36
xUnit使ってる奴で自明な部分はテストを書かないって奴は、カバレッジツールとか使わないのかな?
カバレッジツール使うと、少なくともメソッド網羅率100%にしないと、どのテストが書かれてないかが
分かりづらいし、そもそも100%になってないと非常に気持ちが悪い。
「自明」って言うくらいなんだから、テストメソッド書くのも一瞬でしょ。

795 :仕様書無しさん:2010/02/22(月) 16:59:23
TDDでやってるから、テストが無いメソッドなど存在しない

796 :仕様書無しさん:2010/02/22(月) 17:05:20
これぐらいテスト無くても良いだろうと思って作っていると、
ある程度大きくなってちゃんと作りたくなってくると、
やっぱりテスト書いとけばよかったってなってくる。

797 :仕様書無しさん:2010/02/22(月) 17:06:14
>>793
どうやって呼べばいいのか困惑するようなコード書く奴がいるのだから(このスレの上の方参照)、
とっても複雑なテストコードになる場合もありうる。

798 :仕様書無しさん:2010/02/22(月) 19:54:13
複雑であるべき理由がないなら教育して書き直させるだけ。
理由があるならレビュアが頑張って理解するしかないだろね。
今んとこ、お目にかかったことないけど。

799 :仕様書無しさん:2010/02/22(月) 21:58:55
>>796
あるある

800 :仕様書無しさん:2010/02/22(月) 22:05:35
>>792
> うごくっぽいと思ったら

そんな適当なテストでいいなら確かに楽だな。

801 :687:2010/02/22(月) 22:23:49
とりあえず xUnit を使おうが使うまいがレビューは必要だってことは分かりました

802 :694:2010/02/22(月) 22:52:13
>>777
>1.両方
それは駄目だろう

>2.レビュー
それだと、単体テスト自体もレビューで良いと言う事にならないか?
なぜ、同じ人間が同じ言語で書いたのに、コードはテストして
テストコードはレビューで良いとなる理屈が分からん?

>ホワイトボックステストが何かを誤解しとるのと違うか?
何かホワイトボックステストを勘違いしている奴が多過ぎる
ホワイトボックステストは、プログラムの内部構造を元にテストするもの
したがって、「シーケンス制御」も確認する
つまり、動作を順序が正しいか、ステップ実行で確かめる、xUnitじゃ確認出来ないぞ

>>792
>条件網羅で、お前はどうやってテストしているんだ?
まず、チェックリストを作る、この時コード1行毎の「シーケンス制御」・「変数値」も明記する、それでステップ実行で確認

>作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか?
なんで、途中でテスト終了と言う話になるんだ、条件網羅が理解出来ているか?

>修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか?
もちろん、単体は追加分だけだ、修正が無いコードは単体では影響がない

>xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
>そのテスト項目の信頼性はどうしてる? 人間が間違いなくテストを行ったと信じる根拠は何?
お前は馬鹿か? 条件網羅だと言っているからカバレッジである程度の信頼性はあるだろう
機能テストを行なうと言っている訳じゃない、条件網羅だから機械的にテストケースは考えられる
本当に何も分かってないだろう

803 :仕様書無しさん:2010/02/23(火) 00:18:00
テストコードはシンプルだからレビューは簡単という意見はおかしくないか?
仕様を把握するだけでも面倒なのにそれを一つずつ照らし合わせていくんだよ?
本当に実務でレビューしたことあるの?

804 :仕様書無しさん:2010/02/23(火) 13:07:01
>>803
>>791のコード見てどう思う?

805 :仕様書無しさん:2010/02/23(火) 13:10:29
>>802
もう相手は馬鹿だ合戦はやめにしない?なんの生産性もないよ?

ところで、xUnitに限らず自動テストがステップ実行に勝る点は、別環境でも時間をかけずにテスト
できるというのもあげられる。
自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
したんだけど、自動テストは大いに役立ったよ。
それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。

806 :仕様書無しさん:2010/02/23(火) 15:16:06
>>803
レビュー実行の容易性について考えると、テストコードがあれば簡単にレビューできるということで、
対象のテストコードやプロダクトの複雑さは言及してなかったつもりだが、言葉が足りなかったかもしれない。
もちろん、そこにテストコードがあるから誰もが内容を容易に理解できるわけではない。

レビュー実行が簡単かどうかの比較対象は、古くからの「入力データと出力データのエビデンスと
テスト内容のチェック」や「ステップ実行によるテスト」など。後者はそもそもレビュー不可能。

807 :仕様書無しさん:2010/02/23(火) 19:00:30
プログラマーの書くテストについては気休め程度に考えるのが良い気がしてきた。
テストコードの信頼性まで厳密にチェックしようとすると会社が回んないと思う。
もちろん品質管理部門でしっかりしたテストを行うことが前提だけどね。

808 :仕様書無しさん:2010/02/23(火) 20:46:42
俺も>>807と同じ意見だ。


809 :仕様書無しさん:2010/02/23(火) 21:56:25
>>806
エビデンスよりテスト項目のレビューが重要

810 :仕様書無しさん:2010/02/23(火) 22:02:15
>>805
実行容易性にメリットがあるのはわかった上で、
実行してる内容の正当性をどうやって確保してんのかなって話じゃん。

811 :仕様書無しさん:2010/02/23(火) 23:42:56
つか、xUnitだけやってテスト終わりましたとか言われて納品されても契約で
そこまでとしてない限りは受け取らないだろ。

812 :694:2010/02/23(火) 23:49:01
>>805
>自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
>したんだけど、自動テストは大いに役立ったよ。
なるほど、64bitはやった事が無いが単体でも違いが出そうな気がする、例えば整数型は
CPUのレジスタに依存する場合が多い、だから2^32か2^64だと動きも違ってくるか?
今まで聞いた中で一番、xUnitの良い使い方だと思う

>それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。
何か俺とは前提が違う気がする、そろそろ話を整理しないか? まずはテストの範囲から

俺が行なっているテストの範囲は
・単体テスト:コードの正しさをテストする、機能が間違っていても構わないコードの正しさのみ求める
・結合テスト:機能の正しさをテストする、機能間の整合性を中心にテストする
・総合テスト:異環境でも正しく動く事をテストする、OS・他アプリ・セキュリティ絡みをテストする

このやり方だから、開発環境が無いPCは総合テストの時に行なう、それとも総合でxUnitを使っているのか?

813 :仕様書無しさん:2010/02/24(水) 11:42:41
>>809
> エビデンスよりテスト項目のレビューが重要
もちろんそれは大事。
だけど、xUnit(というか自動テスト)じゃない場合に、どうやって「テスト実行のレビュー」をするのかということ。
xUnit(というか自動テスト)だったら楽だよねということ。

>>810
> 実行してる内容の正当性をどうやって確保してんのかなって話じゃん。
ん?だから、正当性を知りたければ、テストコードを見れば良いという話。

>>812
実行できるEXEやLMがそこにあるなら動かして、その範囲で正しく動いてるのが確認できるなら実行しない手はないでしょ。
それと、総合テストでもxUnitを使っても何ら問題ないし、受け入れテストで使っても何の問題もないよ。

814 :仕様書無しさん:2010/02/24(水) 11:57:02
「xUnitは品質を担保するものではない」って言ってる人は、多分こんなことを考えてるんだと思う。

TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等)
http://d.hatena.ne.jp/goyoki/20100223/1266939139

厳密に言うと、「TDDでxUnitを使う場合は、そのテストコードは品質を担保するものではない」ってこと。

単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。

815 :仕様書無しさん:2010/02/24(水) 13:37:16
>>807
いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
ざっとレビューすりゃいいじゃん。
ひょっとして>>791が読めないの?
それともこれまで通り、Excelにずらずら書かれた単体テスト仕様書みたいなものを
レビューして、結果にはメクラ判を押すのかな?あるいは「単体はステップ実行で
終わりましたー。」「おつかれさん」レベル?

816 :仕様書無しさん:2010/02/24(水) 16:10:33
TDDについて
http://togetter.com/li/6923

817 :仕様書無しさん:2010/02/24(水) 20:03:29
>>814
一般的な単体テストはまた別にやるってことだな。

818 :仕様書無しさん:2010/02/24(水) 20:06:11
単体テストって言葉が複数の意味で使われてるから訳わかんなくなるんだよ

819 :仕様書無しさん:2010/02/24(水) 20:39:32
単体でテストすれば、一応は単体テストだからな
TDD/BDDなんかで書いたような「コーディング途中で検証に使った」テストも単体テストに入る

820 :仕様書無しさん:2010/02/24(水) 20:57:50
複数の意味にうまいこと別名をつけてください

821 :仕様書無しさん:2010/02/24(水) 22:08:05
一般的な単体テスト→単体テスト
設計目的の単体テスト→設計

822 :仕様書無しさん:2010/02/24(水) 22:58:57
単体テスト→コードテスト
結合テスト→機能テスト

823 :694:2010/02/25(木) 00:13:01
xUnitをテストに使ってる奴で、まともな反論も出来ない奴ばかりだな
もともと、xUnitや単体テストを正しく理解していない

>>813
やっぱり、コイツ駄目だな

>>814
>単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。
既存のテスト方法並に、品質が担保出来るか?

>>815
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが?
逆に複雑だとテストコードもテストするのか?

824 :仕様書無しさん:2010/02/25(木) 01:22:33
>>815
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
ざっとレビューって具体的にはどうするの?
それでテストコードの信頼性を厳密にチェックできるの?

825 :仕様書無しさん:2010/02/25(木) 11:43:30
深夜のテストTL
http://togetter.com/li/5878

TDDはテスト手法か否か
http://togetter.com/li/6759

826 :仕様書無しさん:2010/02/25(木) 11:45:58
>>824
> ざっとレビューって具体的にはどうするの?
ちょっと意味がわからないです。
「コードレビューって具体的にはどうするの?」と聞かれても、「えっと、コードを見ます」
以外に答えようがないというか。

> それでテストコードの信頼性を厳密にチェックできるの?
そこに書かれている範囲で、確かに動作するということは確認できます。
それが「既存のテスト方法」(ってステップ実行のこと?)との違いです。

827 :仕様書無しさん:2010/02/25(木) 12:08:52
>>823
>それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが?

一般に、テスト対象のコードより、テストコードの方が簡潔で分り易いです。
(ド下手なテストコードということも考えられますが、それは例外として。)

例えば>>791で主にテストされているTestPathクラスのソースは
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/src/cppunit/TestPath.cpp?revision=441&view=markup
なんですが、このコードから帰納的にテストコードで記述されている仕様を得るのは
時間がかかると思いませんか?

828 :仕様書無しさん:2010/02/25(木) 13:43:27
「既存のテスト方法並に、品質が担保出来る」根拠がわからない。
というか、既存のテスト方法ってなんだ?

829 :仕様書無しさん:2010/02/25(木) 13:45:09
なんだか良くわからない文章だったので訂正。
>「既存のテスト方法並に、品質が担保出来る」根拠がわからない。

既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。

830 :仕様書無しさん:2010/02/25(木) 16:27:22
>>816,825
読みごたえあるね。このスレの糞な奴らとは大違いw

831 :仕様書無しさん:2010/02/25(木) 17:58:28
xUnitの問題点を挙げているが、それ以上に問題点が多いのが、
手動によるステップ実行。そういう結論だよ。


人間は間違いを犯す。
手動だと時間がかかる。特に再テストする場合。

手動でテストするためにチェックリストを作ったとして、そのチェックリスト内容を本当に実行したという担保が無い。
リストだけ立派で、それ本当にテストしたんですか?ということがおきる。
ステップ実行テストを後からレビューすることができない。録画すればできるか?w やってないだろうけど。

つまりは、チェックリストのレビューと、チェック作業のレビューが必要になる。
本質的には同じことをしているのに、無駄に重複してしまう。

ある関数を修正したら、その関数を使用している関数(こっちは修正なし)もすべてテストしなければいけないというのがわかっていない。
手動でこれを実際にやったら大変だからテストをサボる。

xUnitのテストコードが簡単だということが理解できていない。複雑なテストコードもある?
あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になるってことが理解できていない。

832 :仕様書無しさん:2010/02/25(木) 18:16:25
TDDはテストではないということだが、xUnitに関連しての興味深い記事。

- テスト駆動開発(TDD)の事例 - IBMとMS 計4プロジェクトを紹介した論文 -
http://blogs.itmedia.co.jp/morisaki/2010/02/tdd-ebd9.html

Microsoftは、Visual Studioの一部の開発で、TDDを使うチームと使わないチームで
メトリクスを取ったそうな。(詳しくは、リンク先の論文参照)
で、そのメトリクスは以下の通り。

ソースコードサイズ(KLOC) 155.2
テストコードサイズ(KLOC) 60.3
TDDを採用していない類似プロジェクトでの欠陥密度を1としたときの欠陥密度 0.09
TDD採用により増加したコード実装時間(管理者の見積りによる) 25〜20%

833 :仕様書無しさん:2010/02/25(木) 18:28:52
>>831
> あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になる
世界を構築するような複雑な前処理が必要でも、ステップ実行だと、目的の行にブレークポイントを
おけば良いので、関係ないんです。
逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。

834 :仕様書無しさん:2010/02/25(木) 19:35:10
ステップ実行テストとかしているやつは、
ショッピングカートに商品を入れて、
住所氏名など入力して、購入完了!
あっ、在庫減らす処理忘れていた。

ってとき、また在庫戻して、購入履歴消して
データベースの状態を同じに戻して、
また最初っからショッピングカートに商品入れて
・・・ってところからはじめるの?(笑)

そういう一連の動きのテストやらないの?
もしかして、言われた関数だけ作るアルバイトかな?

835 :仕様書無しさん:2010/02/25(木) 20:05:06
同じようなことをいつまでグダグダ言ってんだよ。
xUnit派の俺様でも、さすがにあきれるよ。

836 :仕様書無しさん:2010/02/25(木) 21:19:18
>>832
底辺PGだらけのカス企業でもメトリクス取ってみてほしいわ

837 :仕様書無しさん:2010/02/25(木) 21:42:45
>>802

>>1.両方
>それは駄目だろう

なんで?

>>2.レビュー
>それだと、単体テスト自体もレビューで良いと言う事にならないか?

極端に言えばその通り。
ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
おらんので、テストせざるを得んだけ。

>何かホワイトボックステストを勘違い云々

ホワイトボックスとは何かはさておき、言いたいことは分かった。
ような気がする。

シーケンスって処理フローのことよな?
簡単に言うと、関数の外部に関係するフローはITで見る。
内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。

838 :仕様書無しさん:2010/02/25(木) 22:23:57
.NET でカバレッジ計測するいいツールない?

839 :仕様書無しさん:2010/02/25(木) 23:20:23
>>826
断っとくと824と694は別人ね。
826は実装者の書いたテストとは別に品質管理部門のテストがあるという前提?
ない場合はその方法ではまずいと思うよ。

840 :仕様書無しさん:2010/02/26(金) 00:09:08
どのみちITとSTはやるでしょ。
で、品管に回すのってSTまで終わってからじゃないの?

まぁITもxUnit的な方法かも知れないけども。

841 :仕様書無しさん:2010/02/26(金) 01:15:25
>>834
>そういう一連の動きのテストやらないの?
>もしかして、言われた関数だけ作るアルバイトかな?

それを単体テストと位置づけてるか、位置づけていないかの違い。
xUnitでも上記の条件のような試験はできるけど、そういうテストコード書くくらい
なら、もう少し実装に近い機能単位でテストコードを書くようにして、複雑な条件が
必要なテストは結合とかのもう少し後工程のテストでやるって考えかな。

842 :仕様書無しさん:2010/02/26(金) 06:25:07
>>839
> 826は実装者の書いたテストとは別に品質管理部門のテストがあるという前提?

いえ、そのような前提はありません。
品質管理部門があろうがなかろうが、後続のテストプロセスがどのようなものだろうと、
目の前のテストコードを読む方法はかわりません。
(review methodが変わらないということではなく、code reading methodが変わらない
ということ)
その意味で>>824
>ざっとレビューって具体的にはどうするの?
は、意味がわからないのです。
ひょっとして>>824は、code reading methodではなくてreview methodの話だったんでしょうか。

さらに言えば、誰かがレビューしようとしまいと、現実に存在するテストコードは
そこに書かれている範囲でテスト対象コードの動作を保証しています。
そこに書かれているテストコードが信頼できるものかどうかを知りたいなら、
内容を読めばわかります。このことのどこに疑問が沸くのかわからないのです。

843 :仕様書無しさん:2010/02/26(金) 12:07:26
>>842
例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ?
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの?
ハードコーディングしない場合でもリソース番号1番のところを2番と勘違いしてる場合とかね。

844 :仕様書無しさん:2010/02/26(金) 12:49:33
>>843
>でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの?
いまいち質問の意図がわからないのですが・・・。

要求仕様との適合性をレビューで確認できるかということでしたら、
その仕様を知っており、なおかつ仕様との適合性をチェックしようと
いう意志を持ってレビューすれば確認できるとしか言えません。

845 :仕様書無しさん:2010/02/26(金) 12:59:22
なんだか話が良くわからなくなっていますが、TDD/BDD/単体テスト目的の
何でも良いですが、そこにxUnitで書かれたテストコードがあるなら、>>775
言えるという、ただそれだけのことです。

846 :仕様書無しさん:2010/02/26(金) 13:11:32
>>844
「えっと、コードを見ます」と言うからコードしか見ないんだと思ってたよ。

>その仕様を知っており、なおかつ仕様との適合性をチェックしようと
>いう意志を持ってレビューすれば確認できるとしか言えません。
そこをきっちりやるなら問題ないと思う。
ただUTレビュー段階でそこまでやるのは大変だと思うけど。

847 :仕様書無しさん:2010/02/26(金) 13:50:35
話がかみあったのかどうか自信がありませんが、良しとしましょう。

「自然言語で書かれたテストケースの(テスト仕様書)の品質を確認するために
レビューしましょう」と言うと、おそらく誰からも異論も疑問も出ないと思うんですが、
「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
反発や疑問が出るのが不思議です。

848 :仕様書無しさん:2010/02/26(金) 18:54:08
そんな話なの?

わざわざ「レビューする」に「ざっと」とか付けてたから
「おおまかにコードをナナメ読みして問題がなさそうならOK」
と読んだよ。(俺は、だが)

テストコードの検証ってそんなんでいいの?って話じゃないの?

849 :仕様書無しさん:2010/02/26(金) 21:49:03
>>847
テストコードのレビューがすごく大変って言っている奴がいるから、
別に大変じゃない。レビューといえないぐらいのレベルで終わるって反論されてるだけだろ。
話を摩り替えるなよ。

それで、xUnitのテストコードのレビューに対抗して、
じゃあ手動テストのレビューはどうすんの?って問いの答えはどうなったんだ?

850 :仕様書無しさん:2010/02/26(金) 21:53:29
>>843
> 例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ?
> でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの?

じゃあその話を手動テストに置き換えてみましょうか?

例えばファイルに"apple"と出力するメソッドの手動コードは"apple"の文字列を確認するでしょ?
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの?

手動テストにすることで何か解決しましたか?

間違ったテストをしてしまいましたね。
でも手動だから間違ったテストをしたという記録が残りませんね。
どんなテストをしたかの記録が無いまま、テストはOKとして扱われるわけです。

851 :仕様書無しさん:2010/02/26(金) 23:04:49
>>850
意図的に議論をややこしくしてるだろ?

852 :仕様書無しさん:2010/02/26(金) 23:08:29
その話が終わってるのが理解できてないだけじゃない?

853 :仕様書無しさん:2010/02/27(土) 02:04:11
>>847
>「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
>反発や疑問が出るのが不思議です。
「品質管理部門が使うテストコードを厳密にレビューしましょう」なら反発されないと思うよ。
「TDDで実装者が書くテストコードを厳密にレビューしましょう」だと反発されるだろうね。
あと843と694は別人なのであしからず。

854 :仕様書無しさん:2010/02/27(土) 02:29:52
>>829
>既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。
条件網羅が確認出来る
>>831
論理がアホだな
>>832
だから、TDDはテストか開発か? と言う事だ
それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
http://www.aerith.net/design/risk_analysis-j.html#american_japanese
>>833
>逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。
難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない
>>834
取り合えず勉強しろよ、アホが
>>837
>なんで?
なぜテストが単体・結合・総合と別れてテストするのか考えろ
>ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
複雑かどうかの基準は、人間の主観にすぎない
>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。
"カバレッジ以上には検証は必要ない"もお前の主観でしかない
テストとは、客観的でなくてわならない
>>845
>何でも良いですが、そこにxUnitで書かれたテストコードがあるなら、>>775
>言えるという、ただそれだけのことです。
xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ



855 :仕様書無しさん:2010/02/27(土) 07:11:55
> xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ

一度しか行わないテストはまず無いから。

プログラムは作っていくと必ず変更がある。
直接は変更されなくても、そこで使用している関数が
変更される場合がある。

バグはどこにあるかわからない。バグを修正する行為も
プログラムの修正と同じ。

こうなった場合、同じテストを再度テストする必要がある。
それをしなかったら、手抜きという。大幅な時間短縮が可能

なぜ、時間短縮したら良いのか? 残業代が減るだけではないのか。
という疑問がわくのなら話にならないなw


856 :仕様書無しさん:2010/02/27(土) 07:16:03
>>854
> 難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない

なぜ内部変数を確認しないといけないのか。


「シーケンス制御」はなんかお前間違った用語の使いかたしてないか?
普通はハードウェアの制御のことを言うんだぞ。

857 :694:2010/02/27(土) 13:28:23
最初に、名前を直し忘れてア854=694だから

>>855
>プログラムは作っていくと必ず変更がある。
コーディング中と言う事か?

>直接は変更されなくても、そこで使用している関数が
>変更される場合がある。
具体的に単体(コード)テストで、修正個所以外でどのような影響が出る?
何べんも書くが単体(コード)テストでだぞ

>>856
>「シーケンス制御」はなんかお前間違った用語の使いかたしてないか?
「シーケンスの制御」で良いか? シーケンス図とか知ってるか?

>なぜ内部変数を確認しないといけないのか。
処理後の結果だけ確認して正しければ、 バグじゃないが
想定していた値と違う値、それはコーディングミスになるが、バグじゃないから良しとするのか?


もう一度聞くが、単体で反復実行が可能だと何が良いのか詳しく説明してくれ

あと、例えばあるメソッドの機能が「日本の国コードを取得する」ものだったとする
内部では、RDBから日本の国コードを問い合わせ、その値(49)を戻り値に設定する仕様だ
この場合、xUnitではそのメソッドを実行し、その戻り値が49か確かめるシンプルなテストコードになる

その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードのバグだ、こんな場合をどう考える? xUnitは仕様をしらないと正しいか判断出来ないが?
シンプルだからソースレビューで大丈夫だと言っている奴はどう考える?


858 :仕様書無しさん:2010/02/27(土) 13:35:18
>>854
> 複雑かどうかの基準は、人間の主観にすぎない
そうでもない。こことか参照。
http://ja.wikipedia.org/wiki/%E5%BE%AA%E7%92%B0%E7%9A%84%E8%A4%87%E9%9B%91%E5%BA%A6

> テストとは、客観的でなくてわならない
「ステップ実行しました」ということは、客観的には検証できない。

> xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
自分がコードを変更したときに便利なのは言わずもがなだが、以下のような時にも便利。

・使用している同じプロジェクト内の第三者のコードが変更されたとき、自分が書いたコードが
 今まで通り動くかどうか確認する
・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
 自分が書いた(以下略)
・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき

859 :仕様書無しさん:2010/02/27(土) 13:39:33
>>857
> 「シーケンスの制御」で良いか? シーケンス図とか知ってるか?
シーケンス図的な意味のシーケンスの確認であれば、xUnitでもテストできる。

> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードが正しかったことの証明になる。

> それはテストコードのバグだ、こんな場合をどう考える? xUnitは仕様をしらないと正しいか判断出来ないが?
ステップ実行の時は149になるのを確認するのと同様、テストコードを149に変えるだけだが。

860 :仕様書無しさん:2010/02/27(土) 13:44:03
>>853
> 「TDDで実装者が書くテストコードを厳密にレビューしましょう」だと反発されるだろうね。
TDDで実装者が書くテストコードは誰もレビューしなくて良い。
時間の無駄。

861 :仕様書無しさん:2010/02/27(土) 13:51:14
>>857
> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
> それはテストコードのバグだ、こんな場合をどう考える? xUnitは仕様をしらないと正しいか判断出来ないが?
よく考えたら、そのようなテストコードは単体テストレベルでは書かないということに気づいた。
xUnitでは、自分の力の及ばない値とのアサーションは基本的に行わない。
この場合のメソッドは、「データベースから値を取得してそれをそのまま返す」というメソッドの
はずだから、テストコードも当然それを確認するコードになる。
そして、その取得元のデータは、テストコードのあずかり知らない所で設定されてはならない。
つまり、テストコードで値を設定すべき。

862 :仕様書無しさん:2010/02/27(土) 13:53:38
わかるだろうが、>>858-861はずっと俺ということでよろしく。

863 :仕様書無しさん:2010/02/27(土) 15:18:59
そもそも単体テストだと、fakeクラスやmockオブジェクトを使って、データベースとは
接続しない派も多いんじゃなかろうか。Slow Testsになるし。
ちなみに俺はDBアクセスするテストとそうじゃないテストを別のLMに分けてる。

864 :仕様書無しさん:2010/02/27(土) 15:25:19
>>857
> 具体的に単体(コード)テストで、修正個所以外でどのような影響が出る?
> 何べんも書くが単体(コード)テストでだぞ
class Foo {
public:
void foo(void);
void bar(void);
void baz(void) const;
...etc
}
で、foo,barがbazを使っているときに、bazを変更したらどのようなときでもfooとbarは正しく動くと言えるか?
さらには、bazがconstではない場合、foo,bar以外のFoo内のすべてのメソッドに影響を及ぼすが、それでも
他のメソッドはすべて正しく動くと言えるか?

865 :仕様書無しさん:2010/02/27(土) 15:54:40
xUnitに限らず、ツールとかを使うものってのは完全なものではなく、今までの
作業の肩代わりを若干してくれて、手間が多少減らせるってものだよな。

銀の弾丸は無いといいますが、これだけやってれば問題ない完璧な解決策
なんてものは無いから、使えそうなものを上手に利用して、それで

866 :仕様書無しさん:2010/02/27(土) 16:22:31
>>694
xUnitのことならなんでもわかってるような口調で持論を展開してきたけど、
全然わかってなかったことが暴露されちゃったね

867 :仕様書無しさん:2010/02/27(土) 17:40:40
ステップ実行派は、レガシーコード改善ガイドを読んで、将来お前の書いたコードをメンテナンスする奴が、どんな
悲惨な目にあうのか気づいてくれ。

868 :仕様書無しさん:2010/02/27(土) 18:17:43
>>854
> それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
マイヤーズ本と、基礎から学ぶソフトウェアテスト、体系的ソフトウェアテスト、
Effective Software Testing、Automated Software Testingあたりを読んでから
寝言はほざけ

869 :仕様書無しさん:2010/02/27(土) 18:50:14
Boris Beizerの方がいいと思うよ。
「ソフトウェアテスト技法」と「実践的プログラムテスト入門」。

870 :仕様書無しさん:2010/02/27(土) 22:20:04
>>694って>>281じゃないの?
文章の感じが似てるし、句点打たないし、なによりステップ実行派ってのが共通してる。
まぁ>>281はxUnitのことはTDD本でしか勉強してないとのことだが。
あと、>>694はC++が読めるのかどうかはっきりしてくれ。

871 :仕様書無しさん:2010/02/27(土) 22:23:38
C++とテストってなんか関係あんの?

872 :仕様書無しさん:2010/02/27(土) 22:37:46
>>791紹介したの俺だし、>>864も俺だから、話が通じてる(通じる)のかどうかはっきりしてくれ的な意味で。

873 :仕様書無しさん:2010/02/27(土) 22:56:11
なんか似たようなこと前にあったなーとこのスレ読み返したら、ほぼ同じコードを>>578で書いてた。
578の時も>>572がコードに全く言及しなくてイライラしたんだよね。

874 :694:2010/02/28(日) 05:32:37
>>861
>つまり、テストコードで値を設定すべき。
>>863
>そもそも単体テストだと、fakeクラスやmockオブジェクトを使って、データベースとは
>接続しない派も多いんじゃなかろうか。Slow Testsになるし。
つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが...

それじゃ設定を変える、49をコンストで定義していたとする
日本の国コードを印刷用形式で取得するメソッドが有ったする
内部で日本の国コード取得メソッドを呼び出し、49を取得し3桁右寄せで”△49”と編集して戻り値に設定する
これのテストコードは? また49が149に変更された時のテストコードは?

xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
不正になる場合なんて、よくあると思うが...

>>864
>で、foo,barがbazを使っているときに、bazを変更したらどのようなときでもfooとbarは正しく動くと言えるか?
具体的に書いてくれ、単体レベルで修正した以外のメソッドで、どんなバグが出る?
>さらには、bazがconstではない場合、foo,bar以外のFoo内のすべてのメソッドに影響を及ぼすが、それでも
>他のメソッドはすべて正しく動くと言えるか?
フィールドの値が変ったからと言って、それが単体レベルで、どんなバグになるのか?

>>867-868
アホ、自分が見て書籍を出して知識をひけらかすな
具体的な自分の意見を書け


875 :694:2010/02/28(日) 07:23:34
>>858
>そうでもない。こことか参照。
>http://ja.wikipedia.org/wiki/%E5%BE%AA%E7%92%B0%E7%9A%84%E8%A4%87%E9%9B%91%E5%BA%A6
なるほど、そんな基準もあるのか、しかし、テストするしないの基準をどこに決めるのは主観だと思うが?

>・使用している同じプロジェクト内の第三者のコードが変更されたとき、自分が書いたコードが
> 今まで通り動くかどうか確認する
修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている

>・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
> 自分が書いた(以下略)
>・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
それは、メリットがあると思う、32bitOSから64bitOSへの変更もそうだし、使用言語のVerUpもそうだと思う
が、そんな事は頻繁に無いし、xUnitで大丈夫でも最終確認は総合テスト実施で行なう
それを考えた場合、xUnitを単体テストに使用するコストに見合うのか?

876 :仕様書無しさん:2010/02/28(日) 09:09:13
>>874
> 内部で日本の国コード取得メソッドを呼び出し、49を取得し3桁右寄せで”△49”と編集して戻り値に設定する
> これのテストコードは? 
assert(日本の国コードを取得() == ”△49”)

> また49が149に変更された時のテストコードは?
assert(日本の国コードを取得() == ”149”)

こういう意味か? 人間の言葉でテスト仕様を書くと、あいまいでわからん。
テストコードで話してくれw
assert(国コードを取得(日本) == ”△49”)
こっちの可能性もあるな。


> xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
> 不正になる場合なんて、よくあると思うが...

xUnitわかってないじゃんw

最初にテストコードを修正するんだよ。
そのあとテストを失敗させてから
プログラムを修正する

877 :861:2010/02/28(日) 12:09:42
>>874
> つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そんなこと言ってない。

> そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが...
後付けで品質保証目的の網羅的な単体テストレベルのテストスィートを書いても
全然問題ない。俺は先にテストするが。

> それじゃ設定を変える、49をコンストで定義していたとする
> 日本の国コードを印刷用形式で取得するメソッドが有ったする
> 内部で日本の国コード取得メソッドを呼び出し、49を取得し3桁右寄せで”△49”と編集して戻り値に設定する
> これのテストコードは? 

void CoutryCodeTest::test_GetPrintableJapaneseCountryCode
{
CoutryCode c;
setCountryCode("日本", "49");
CPPUNIT_ASSERT_EQUAL("△49", c.GetPrintableCountryCode("日本");

this->setCountryCode("some country", "123");
CPPUNIT_ASSERT_EQUAL("123", c.GetPrintableCountryCode("some country");

CPPUNIT_ASSERT_EQUAL("△△△", c.GetPrintableCountryCode("not exist country");
}
(三つのテストメソッドに分ける派もいる)

あと、必要に応じて、次の場合のテストもする。
this->setCountryCode("some country", "");
this->setCountryCode("some country", "1234");

>また49が149に変更された時のテストコードは?
追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。

878 :861:2010/02/28(日) 12:27:02
>>875
> なるほど、そんな基準もあるのか、しかし、テストするしないの基準をどこに決めるのは主観だと思うが?
え?条件網羅でテストするってのは、C1カバレッジかC2カバレッジ100%を目指すってことでしょ?
循環的複雑度はまさにその客観的な指標となる値だろ。

> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
正直、お前とそれ話し合うの気が進まない。
影響が無いと思うならそれでいいじゃん、って気持ち。(投げやり)

> >・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
> > 自分が書いた(以下略)
> >・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
> それは、メリットがあると思う、32bitOSから64bitOSへの変更もそうだし、使用言語のVerUpもそうだと思う
> が、そんな事は頻繁に無いし、xUnitで大丈夫でも最終確認は総合テスト実施で行なう
> それを考えた場合、xUnitを単体テストに使用するコストに見合うのか?
人・プロダクト・環境・組織それぞれで違うので一概には言えない。
ただ一つ言えることは、10秒で終わる1万個のテストケースは、なにをするにも10秒で終わると言うことだ。

879 :仕様書無しさん:2010/02/28(日) 12:54:56
自動化されたテストはバックグラウンドでやらせればいいから
作業時間は実質0という考え方もあるな。

880 :仕様書無しさん:2010/02/28(日) 14:51:33
>>876
>assert(日本の国コードを取得() == ”△49”)
>> また49が149に変更された時のテストコードは?
>assert(日本の国コードを取得() == ”149”)
変更・バグの無いメソッドも、テストコードのみ修正すると言う事だな
つまり、テストコードのバグだな

>>877
>>また49が149に変更された時のテストコードは?
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か? 出力値・桁数=3桁のチェックのみと言う事か?
それだと、出力値が”49△”でも正常だと判定するのか?

>>878
>> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
>正直、お前とそれ話し合うの気が進まない。
>影響が無いと思うならそれでいいじゃん、って気持ち。(投げやり)
一人逃げたな

もう一度話を整理する、xUnitを単体テストで使うメリットは”反復実行可能”と言う事だが
疑問点
 1.修正メソッドはもちろん単体テストをするが、それ以外のメソッドは単体テストが本当に必要か?
 2.その場合、修正メソッド以外のメソッドが、単体テストレベルでバグになるケースは?
 3.修正メソッド以外のメソッドでxUnitを実行した場合、メソッドは正常でもテストケースがバグるケースは無いのか?
 4.3が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える?


881 :仕様書無しさん:2010/02/28(日) 14:56:00
>>880
> ・バグの無いメソッドも、テストコードのみ修正すると言う事だな
> つまり、テストコードのバグだな

テストが失敗するのはバグとは言わんよ。
それを、わかってないだろ?

テストコードを修正するのは、仕様が変わったとき。
仕様が変わったのだから、テストも変わるのは当たり前。

お前が言ってるのは仕様が変わった=バグだなっていっているのと同じこと。
少しは考える頭を持てよ。

882 :仕様書無しさん:2010/02/28(日) 15:04:02
>  1.修正メソッドはもちろん単体テストをするが、それ以外のメソッドは単体テストが本当に必要か?
必要じゃない場合もあるが、必要な場合もある。
修正メソッドを使用しているメソッドはテストをしないといけない。
そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。



883 :仕様書無しさん:2010/02/28(日) 15:09:19
>  2.その場合、修正メソッド以外のメソッドが、単体テストレベルでバグになるケースは?

他のメソッドが修正メソッドを呼ばれている場合はすでに書いた。

それ以外の場合でもバグになるケースもある。

クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。

「修正メソッド」のコードが修正され、status=2の状態が追加される。
「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。

884 :仕様書無しさん:2010/02/28(日) 15:13:28
>  3.修正メソッド以外のメソッドでxUnitを実行した場合、メソッドは正常でもテストケースがバグるケースは無いのか?

それは、正しくテストを行っていない状態 という。

>  4.3が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える?

テストはちゃんとしないといけない。
テストをサボりたいならテストケース消せば?w


885 :仕様書無しさん:2010/02/28(日) 15:31:39
>>880とかそれ絡み
主張する人らの間で何を単体とするかが違って無いか?
特に864と880。

具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。

ちょっと例を挙げると、以下辺りの認識の違い。
・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか

886 :仕様書無しさん:2010/02/28(日) 16:18:57
>>881
アホだなw。

887 :仕様書無しさん:2010/02/28(日) 19:51:36
>>881
お前はず〜っと馬鹿だな、ちゃんと読め

>テストコードを修正するのは、仕様が変わったとき。
>仕様が変わったのだから、テストも変わるのは当たり前。
修正していないメソッドの話で、自動的に反復テストが可能だと言う
xUnitの利点として...もぅい実行


888 :仕様書無しさん:2010/02/28(日) 20:14:54
>>885
俺もそう思う
話し合ってる論点が違うから全く噛み合ってないw
そもそもプログラムの作り方そのものが違ってないか?
ちなみに俺の感覚は>>861に近い

889 :861:2010/02/28(日) 20:26:35
>>887は俺が書いている途中、間違って書きこんだが、まっ、>>881には充分だなw

>>882
>修正メソッドを使用しているメソッドはテストをしないといけない。
>そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。
単体で必要か? 

>>883
>クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
>「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。
>「修正メソッド」のコードが修正され、status=2の状態が追加される。
>「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。
修正漏れか、その場合でも、そのメソッドに単体が必要か? 
status=0とstatus=1は正しく動いているし、status=2の処理が、そのメソッドで必要かは
結合テスト(機能の確認)じゃないと判断出来ないだろう

>>884
>それは、正しくテストを行っていない状態 という。
???

>テストはちゃんとしないといけない。
>テストをサボりたいならテストケース消せば?w
意味の無い事をやるよりは、結合テスト以降を重点的にやれと言うことだ

>>885
>具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。
俺の単体は、コードテストと上でも書いている、xUnitもメソッド単位で書くだろう

>・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
>・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか
意味がわからん、メソッドを実行して、戻り値・フィールドを確認するだけだろう?
俺はステップ実行で、内部変数も確認するが

890 :仕様書無しさん:2010/02/28(日) 22:23:07
長々書いてたら長すぎと怒られてもた。

>>854
>なぜテストが単体・結合・総合と別れてテストするのか考えろ
結合するとあるパスを通すテストが困難になる場合があるから。
問題があった時テスト対象が小さい方がと原因の解析が簡単だから。
結合する範囲が大きくなるほどスケジュール調整が大変になるから。

で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ?

>複雑かどうかの基準は、人間の主観にすぎない
テストコードだからコードが簡単でレビューで大丈夫なんじゃなくて、
レビューで十分なようにテストコードを簡単にするんよ。
うちでは幾つかルールを決めてる。
具体的な話は長かったので割愛。

>>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。 検証しないと書いたけど、よく考えたらしとることに気付いた。
後出しですまんけど、xUnitのアサートでの確認項目じゃないんで頭から漏れてた。

静的解析ツールと動的解析ツールを併用しとるわ。
たまたま動くケースは、コードレビューとあわせてほぼ潰せる。
細かい話は長かったので割愛。

で、xUnitでは内部で閉じたフローは検証しない。(出来なくて良い)
テストケースが十分かどうかの指標の1つにカバレッジを利用する。

>"カバレッジ以上には検証は必要ない"もお前の主観でしかない
>テストとは、客観的でなくてわならない
これで良しとしてる判断基準は、過去のバグについての
原因と実装への手戻り件数の分析結果から。
テストミスも含めて過去に発見されたバグの原因を
フォロー出来るように、テスト方法を改善していってる。

891 :仕様書無しさん:2010/03/01(月) 00:29:56
おい
>>889は861であってんのか?
694じゃないのか?
誰が何言ってんだ?
話の流れが889で俺の理解を超えた。
誰か解説頼む。

892 :861:2010/03/01(月) 10:26:34
俺が本当の861。

>>880
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か? 出力値・桁数=3桁のチェックのみと言う事か?
"149"は"123"と同値クラスだからテストの追加はしない。
また、値のチェックもやってるだろ。
>CPPUNIT_ASSERT_EQUAL("123", c.GetPrintableCountryCode("some country");

>それだと、出力値が”49△”でも正常だと判定するのか?
意味がわからない。ちゃんとテストしてるだろ。
>CPPUNIT_ASSERT_EQUAL("△49", c.GetPrintableCountryCode("日本");

ところで、C++のコードが読めるのかどうかはっきりしてくれ。
あと、お前のデグレードの定義とリグレッションテストの定義と意義も知りたいところだ。

893 :861:2010/03/01(月) 10:31:07
>>889
> 俺の単体は、コードテストと上でも書いている、xUnitもメソッド単位で書くだろう
コードテストって何?
ステップ実行じゃなかったっけ?

894 :861:2010/03/01(月) 10:34:27
さて、>>694がなかなか使用言語をあかさないので書かなかったが、Visual StudioのC++の場合、
ステップ実行できるのはDebugモードだけだという致命的な問題がある。
俺は、単体レベルはReleaseモードの出力を使うべき派。

895 :仕様書無しさん:2010/03/01(月) 11:24:47
>>889
> status=0とstatus=1は正しく動いているし、status=2の処理が、そのメソッドで必要かは
> 結合テスト(機能の確認)じゃないと判断出来ないだろう

どうして結合テストでないと判断できないのか理解不能。
そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
status = 2の時に各メソッドの振る舞いが変わるかどうかは、status = 2となる修正を行う時に
わかるはずだ。

それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
status = 2で他のメソッドを呼べば簡単に落ちる。

896 :仕様書無しさん:2010/03/01(月) 15:27:02
>>880
> そのコストはどう考える?

まだ
テストコードの修正&実行のコスト>>>>>>ステップ実行のコスト
だと思い込んでるようだな。
テストコードの修正&実行=ステップ実行のコスト
となるケースはおろか、
テストコードの修正&実行<<<<<ステップ実行のコスト
になる場合だってあるってのが、これまでのテストコード例でわかんないの?

897 :仕様書無しさん:2010/03/03(水) 07:49:28
昨日、Rubyのリファクタリング本を買ってきたら、1章で死ぬほどテストしろって書いてるんだけど、
本家リファクタリング本ではテストしろって書いてないの?

898 :仕様書無しさん:2010/03/03(水) 16:34:11
>>894
Releaseでも普通にステップ実行できるよ。
落ちたときは、ステップ実行で確認してる。

899 :694:2010/03/03(水) 23:16:39
>>889
間違えた861→694
>>890
>結合するとあるパスを通すテストが困難になる場合があるから。
違う、それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする

>で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ?
コーディングのミスと機能の間違いは別の観点、テストも別

>レビューで十分なようにテストコードを簡単にするんよ。
何時でも簡単に出来るのか? オブジェクトの作成・入力データの設定は
大変じゃないのか? 特にオブジェクト作成は、正しいオブジェクト指向設計だと
複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが

>これで良しとしてる判断基準は、過去のバグについての
>原因と実装への手戻り件数の分析結果から。
統計からの基準と言う事か? 数学を知っていれば分かると思うが
統計は、個々のシステムには通用しない、統計じゃなく経験則だと言うなら、それは主観だ



900 :694:2010/03/03(水) 23:18:03
>>892-894 
お前とは話が噛み合わん、ちゃんと読め

>>895
>どうして結合テストでないと判断できないのか理解不能。
上でも書いたが、それぞれのテストは観点が違う、単体ではコードが正しいかの観点だ

>そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
上からの流れを読め、プログラムを修正した時の話だ、元を誰が作ったのか限定していない
それに、修正漏れをしている以上、修正した本人は影響を認識していないと言う事だろう
お前も話が噛み合わない

>それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
>status = 2で他のメソッドを呼べば簡単に落ちる。
意味が分からん、なんで”statusが0か1しか取らないという前提”で配列を使うんだ? 整数型でいいだろう
”要素数2個の固定長配列”には何が設定されるんだ? 本当に、お前も話が噛み合わない

>>896 
アホ

>>897 
本家は10ページぐらい(全体で400ページぐらい)

901 :仕様書無しさん:2010/03/04(木) 01:41:16
>>899
>それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする
それこそ違う。
単体テストは単体の仕様に基づいて行われるから単体テストなんだ。

>コーディングのミスと機能の間違いは別の観点、テストも別
何言ってんのかよく分からんが、うちのxUnitの目的としては、基本的には
関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
と思って貰って良いよ。

>オブジェクト云々
C言語ですけど何か?

>統計からの基準と言う事か?
プロセス改善のための定量的なメトリクスってそういうモンよ。
逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの?
または、テスト方法が改善されたと判断するのよ?

>経験則だと言うなら、それは主観だ
そういう面もあるけど、過去事例と言って貰いたい。

今回はこういう問題が出ました。(検出出来なかったバグがあった)
原因はこれです。(例えば解析ツールの機能不足、など)
ですので今後はこのようにします。
(例えばその種のバグが検出可能な新規ツールの導入、など)

そういう改善。
例でいうと、次から同種のバグが単体テストで
発見出来るようになってれば、改善されたとみなす。
バグがなければ評価保留。再発したら効果無し。

902 :仕様書無しさん:2010/03/04(木) 10:42:19
なんか必死な奴がいるなぁw

903 :861:2010/03/04(木) 11:13:34
>>900
> >>892-894 
> お前とは話が噛み合わん、ちゃんと読め

いやいや、俺が書いた内容をちゃんと読んでないのはお前の方だよ。
お前は、「仕様変更の対応で、データベースの設定内容を変更したとき」の話をしていて、
それに対して俺はテストコードの変更の必要もないし、テスト実行の必要も無いと言ってるんだよ。

つまり、お前の「データベースの値を変えたらテストに失敗したのでテストコードのバグ」
というのはいいがかりに過ぎないということだ。

もちろん、テストコードにバグがある可能性はあるが、心配ならテストコード読めって話だ。

> >それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
> >status = 2で他のメソッドを呼べば簡単に落ちる。
> 意味が分からん、なんで”statusが0か1しか取らないという前提”で配列を使うんだ? 整数型でいいだろう
> ”要素数2個の固定長配列”には何が設定されるんだ? 本当に、お前も話が噛み合わない

>>895じゃないがコメント。
もともとは、お前が「修正対象以外に影響を及ぼすことなんて無い(のでテストしない)」という
ことから話が始まっている。
例えばそのstatusがON/OFFを表すものだとして、ONのときとOFFのときに何かの値を保存する
必要があったら、somedata[2]とすることだってあるだろ。で、somedata[status] = hoge;で
statusが2を取り得ることになると落ちるってことだ。

これ、システムテストまでテストしないの?

904 :861:2010/03/04(木) 11:19:53
>>899
> >レビューで十分なようにテストコードを簡単にするんよ。
> 何時でも簡単に出来るのか? オブジェクトの作成・入力データの設定は
> 大変じゃないのか? 特にオブジェクト作成は、正しいオブジェクト指向設計だと
> 複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが

やっぱお前>>281じゃないの?ちゃんと答えてくれよ。
リファクタリング、リファクタリングって言ってるけど、本当に日常的にリファクタリング
してるのか疑うよ。
テストし辛いのは、元コードが駄目コードだから。それと、お前がxUnitを使い慣れて
なくて、fakeもmockも知らないから。

(そして>>281からの議論へとループ)

905 :仕様書無しさん:2010/03/04(木) 11:54:30
>>900
> >>896 
> アホ
反論できないんだw
コーディング時間中のステップ実行をやってる時間を厳密に計測したら、
50%くらいいってるんじゃないの?w

906 :仕様書無しさん:2010/03/04(木) 15:17:02
>>861は言ってることはまともなんだが、昼間書き込んでるのが・・・

907 :仕様書無しさん:2010/03/04(木) 15:29:50
>>900
>本家は10ページぐらい(全体で400ページぐらい)

それほど強調されてないから、リファクタリングにはテストは不要と判断したの?

908 :仕様書無しさん:2010/03/04(木) 15:35:47
>>906
お前マ板初めてか力抜いてどっか行けよ

>>907
本家 Refactoring: Ruby Edition は肥溜めのよーな本だともっぱらの評判
ttp://www.amazon.com/dp/0321603508/

909 :仕様書無しさん:2010/03/04(木) 17:41:00
>>908
別にRuby版リファクタリング本の出来なんてどうでもよくて、
>>694がテスト無しにリファクタリングをしているという由来を
知りたいだけ。

910 :仕様書無しさん:2010/03/05(金) 05:18:23
>>900
お前以外のこのスレの住人ほとんどと話がかみ合わないようだが、それはお前以外の
このスレの住人が全員アホなのか、お前がアホなのか、どっちだろうねw

911 :仕様書無しさん:2010/03/05(金) 07:14:17
>>910
俺以外全員アホなのは間違いない

912 :仕様書無しさん:2010/03/05(金) 15:31:56
>>908
うわ、コードは読み飛ばしてたからバグがあるのかどうか気づかなかったよ。
ちなみに、日本語訳はいまのとこまとも。

リファクタリングカタログの所拾い読みしてるけど、一つのリファクタリングを
三つくらいのステップに分けて実行するとき、一つ一つのステップでしつこいほど
テストやれって書いてる。本当に本家リファクタリングはテストやれって書いてないの?

913 :仕様書無しさん:2010/03/05(金) 15:51:42
「のか?」でこのスレを検索して、ヒットしたレスのほとんどが多分>>694

914 :仕様書無しさん:2010/03/05(金) 16:12:04
ニカ?で検索して、ヒットしたものが・・・

915 :仕様書無しさん:2010/03/06(土) 00:41:35
一人が一年かけて作った、とある計測器制御&測定値分析のアプリを引き継いで
機能拡張をまかされた。
今時VB6ってのもアレなんだが、我慢してソースざっとみたら、ボタンとかのイベント
ハンドラに処理をガンガン書いてて、おまけにGPIBコマンドが直接いたるところに
ばらまかれてた。
作った奴はもうすぐやめるんだけど、とっつかまえてどうやってテストしたのかって
聞いたら、現地に行って計測器借りてデバッグしてたらしい。
つか、あんたほとんど社内にいたじゃん・・・

916 :仕様書無しさん:2010/03/06(土) 00:48:43
測定器相手だから、測定レンジ切り替えたときとかに測定値がふらつくから
微妙にSleepしないといけないし、余分なSleep入れると測定時間が何時間にも
なるってのはわかる。それは実機が無いとわからないだろう。
でも、GPIBボードがないと起動すら出来ないってひどいよ・・・

917 :仕様書無しさん:2010/03/06(土) 00:48:53
よくある話

918 :649:2010/03/06(土) 13:51:28
>>901
>単体テストは単体の仕様に基づいて行われるから単体テストなんだ。
単体の仕様? それが単体の観点じゃないのか?

>関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
>と思って貰って良いよ。
仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ

例えば郵便番号判定の関数があったとする、数値はOKで数値以外でもXXX-XXXXみたいなハイフンはOK
それ以外はNGの関数を作ったとする

1:戻り値=True
2:if (入力値 <> 数値) then
3: 戻り値=ハイフン判定関数(入力値)

と関数が有ったとする、これに”△1234567”と入力値を設定した場合
処理が1→2→3と処理され戻り値にTrueが設定されたとする
しかし、PGの考えでは処理が1→2で終了してTrueが設定されることを想定していた
つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなw

>逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの?
その考えが間違っている、テストに良いも悪いもない、色々な観点のテストを行なう
それに品質管理を考えるなら、それは設計やコーディングから始まっている

919 :694:2010/03/06(土) 14:09:48
>>903
>いやいや、俺が書いた内容をちゃんと読んでないのはお前の方だよ。
>お前は、「仕様変更の対応で、データベースの設定内容を変更したとき」の話をしていて、
>それに対して俺はテストコードの変更の必要もないし、テスト実行の必要も無いと言ってるんだよ。
アホちゃんと読め
>>874
>それじゃ設定を変える、49をコンストで定義していたとする

>例えばそのstatusがON/OFFを表すものだとして、ONのときとOFFのときに何かの値を保存する
>必要があったら、somedata[2]とすることだってあるだろ。で、somedata[status] = hoge;で
>statusが2を取り得ることになると落ちるってことだ。
>これ、システムテストまでテストしないの?
それ関数がstatus=2の時に呼ばれるのか? 呼ばれない場合はバグじゃない 呼ぶ呼ばないは仕様だ
単体と結合を一緒にするな
あと、俺は単体にxUnitを使わないが、xUnitを使って自動化していても
その関数のテストコードではバグは発見出来ないだろう、修正していない関数をいままでのテストコードを流しても正常のままだと思うが
結局結合以降のテストで発覚する


920 :694:2010/03/06(土) 14:19:14
>>907-909
お前達、アホか?
リファクタリングの話なんてして無いぞ、今の話は改修の話だ
リファクタリングが理解出来てないだろうw 

>>910-911
意見が違うだけで、まともな奴もいる
でも、お前達はアホw

921 :861:2010/03/06(土) 15:13:37
>>919
>それじゃ設定を変える、49をコンストで定義していたとする

テストを実行するとテストは失敗するけど、それは別にテストのバグじゃないよ。
逆にテストが正しいことを証明している。

> それ関数がstatus=2の時に呼ばれるのか? 呼ばれない場合はバグじゃない 呼ぶ呼ばないは仕様だ
> 単体と結合を一緒にするな

実際に呼ばれるかどうかは関係ないし、これは単体レベルの話だ。
インスタンスメソッドに取ってはフィールドは外部入力と同じなので、それが取り得る範囲すべてで
正しく動作しなければならない。
・Foo::statusはFoo::foo()でしか設定しなくて、仕様変更でstatus=2になる場合が増えた
・一方Foo::bar()はstatus=2の時に呼ばれると落ちる
・Fooのクライアントコードを全部調べたが、status=2でFoo::bar()を呼んでいるコードは今のところ無い

これ、いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちたら、それはクライアント
コードのバグ?
そうじゃないよね。Fooのバグ。つまりFooの単体レベルの話。

922 :861:2010/03/06(土) 15:21:30
>>918
「トリムするのを忘れた」というのが、どのレイヤーの話なのかいまいちわからないが、
言わんとしてることはわかった。

その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。

>>920
>リファクタリングの話なんてして無いぞ、今の話は改修の話だ
なんだか話が良くわからないけど、そもそも>>687
>ユニットテストがあるから安心してリファクタリングできるってのがよく分からんわ
>お前が書いたそのテストコードってそんなに信頼できるもんなの?
に同意した>>694が、このスレだかこの話題だかの君の初登場じゃないの?
で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの?
何のためにxUnitの話をしてたのかわからん。

923 :896:2010/03/07(日) 06:19:05
>.>918
その関数を実際に実装したとして、入力候補には次のような物が考えられるんだけど、
ステップ実行だとどれくらいかかる?
テストコードだと、まあ言語にもよるけど、5分くらいあれば書いて実行できるぞ。

正常ケース
"1234567", "123-4567", "△1234567", "1234567△", "△123-4567", "123-4567△",
"△1234567△", "△123-4567△"

異常ケース
"", "123456", "△123456", "123-456", "123△456", "123-△456",
"123,456", "123.456", "123456A", "123-456A"

こんなのいちいちステップ実行するの超めんどいだろ。
ちなみに俺ならregexp使うから、そんなメソッド書かないし、上のようなテストもしないがなw

924 :896:2010/03/07(日) 06:21:33
あー、あと、
"12-34567", "1234-567", "-1234567"
もあるな。
ほら、テストケースを思いついた場合、テストコードがあれば1分で上の3つを追加して実行できちゃうぞw

925 :896:2010/03/07(日) 06:23:46
あー、まだあった(俺しつこいw

"12345678", "123-45678",
"123--456"

926 :896:2010/03/07(日) 06:26:30
んでさ、こんなテストやりましたってExcelかなんかに書くとするわな。
それ何分かかる?
テストコードがあれば、こんなのやりましたってコードみせればいいじゃん。

927 :896:2010/03/07(日) 06:31:44
お前さー、xUnit使って無いのにどうしてxUnit使うときの工数がわかるわけ?
神様?w

928 :仕様書無しさん:2010/03/07(日) 07:36:04
"1234567"
"123-4567"
"123−4567"
というのもあるな。

929 :仕様書無しさん:2010/03/07(日) 07:40:07
まぁコード書いた本人がホワイトボックス視点で単体テストをするわけだから
もう少しケースは絞り込めるかもしれないが、それでもマニュアルテストは
めんどくさすぎる。

930 :仕様書無しさん:2010/03/07(日) 08:41:57
Java JUnit で private メソッドをテストする
http://www.horse-water.mydns.jp/tips/tips_P00015.html

931 :694:2010/03/07(日) 13:46:49
>>919
>テストを実行するとテストは失敗するけど、それは別にテストのバグじゃないよ。
>逆にテストが正しいことを証明している。
メソッドはバグが無いのに、テストコードがバグだと判定している状態で、何で”テストが正しいことを証明している”だ?

>これ、いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちたら、それはクライアント
>コードのバグ?
>そうじゃないよね。Fooのバグ。つまりFooの単体レベルの話。
"いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちた"だから、それが仕様だろう
仕様が変ったから呼ばれし、呼ぶ方も改修が入るから、修正漏れでバグは結合テストで検出する
もとろん、その前に検出出来ても問題ないが、本来は設計段階か結合以降で検出

>>922
>その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。
俺はxUnitを信用してない訳じゃない、単体テストをxUnitで行なう事に問題があると言っている

>で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの?
>何のためにxUnitの話をしてたのかわからん。
いまの流れは>>776からだ、お前もリファクタリングと改修の区別がつかんのか? >>728を読め
いまの例題は、修正前後が機能的に等価じゃないだろう

>>923-927
アホ、お前だけレベルが違いすぎる、俺に絡むな
>神様?w
俺が神じゃなく、お前のレベルが低いだけだ

932 :861:2010/03/07(日) 14:53:45
>>931
> メソッドはバグが無いのに、テストコードがバグだと判定している状態で、何で”テストが正しいことを証明している”だ?

constで49を指定する場合、仕様変更で49を149に変えるのなら、コードとテストコードの*両方*を変更する
必要がある。
俺が言ってるのは、constを149に変えてそのままテストが失敗したら、それは「仕様変更以前は正しく日本の
国コードのチェックをしていた」ことの証明になるということ。

> 仕様が変ったから呼ばれし、呼ぶ方も改修が入るから、修正漏れでバグは結合テストで検出する

そういうことを言ってるんじゃない。
今誰かが呼んでいて落ちるのからバグで、今は誰も呼んでないからバグではないと判定するのは誤りだと
いっている。

今は呼ばれていないが将来誰かが呼んで落ちるのかにかかわりなく、Fooクラスは自分の取り得る状態で
自分の公開メソッドが正しく動くのはFooクラス自身の責務であって、それをテストするのは単体テストレベル
だということ。

今回の仕様変更からちょっと離れて考えて欲しい。
二つの公開メソッドA、BがあるクラスFooで連続して同じメソッドを呼ばない呼び出しパターンは、
「A」「B」「AB」「BA」の4つある。
これらのどのパターンでも正しく動作するのはFooの責任でしょ?Fooが保証しなくて誰が保証するの?

そこにBを変更すべき仕様変更が発生した。
Bの変更後、やはり「A」「B」「AB」「BA」のどれもが正しく動くのはFoo自身の責任。

933 :861:2010/03/07(日) 15:08:57
C++の話なので理解できるかどうかわからないが(いい加減C++が読めるかどうか教えてくれ)、
最近ム板でこんなことがあった。

初心者らしきプログラマが先輩に「お前の作ったライブラリ使うと落ちる」と文句を言われたという
レスをした。その原因は、ポインタをメンバーに持っているクラスのインスタンスのコピーを作り、
その一方をdeleteしたら、もう一方のポインタがダングリングポインタになってしまった。

その初心者らしきプログラマ曰く「それは使い方が悪い」と主張。
だが普通のC++プログラマなら、コピー禁止にしておくか、deep copyすべきだと答えるはず。

このケースで悪いのは、使った方?使われたクラスを書いた方?

934 :694:2010/03/07(日) 16:07:19
>>931
>constで49を指定する場合、仕様変更で49を149に変えるのなら、コードとテストコードの*両方*を変更する
>必要がある。
だから、変更して無いメソッドの話だろう、変更したメソッドのテストコードを修正するのは当たり前だし
影響があるメソッドのテストコードを修正出来るのなら、修正漏れは起きないだろう

>俺が言ってるのは、constを149に変えてそのままテストが失敗したら、それは「仕様変更以前は正しく日本の
>国コードのチェックをしていた」ことの証明になるということ。
それを証明して何になるんだ? 修正前のメソッドは動いているのは当たり前だろう

>そういうことを言ってるんじゃない。
>今誰かが呼んでいて落ちるのからバグで、今は誰も呼んでないからバグではないと判定するのは誤りだと
>いっている。
>今は呼ばれていないが将来誰かが呼んで落ちるのかにかかわりなく、Fooクラスは自分の取り得る状態で
>自分の公開メソッドが正しく動くのはFooクラス自身の責務であって、それをテストするのは単体テストレベル
>だということ。
まず一点目、例え今回のクラスが共通クラスで、どのプロジェクトから使われるのかも解らなかったとする
その場合でも、バグはバグになった時点からバグだ、0と1で使われている限りバグじゃない

二点目、”Fooクラス自身の責務”この考えは一つの考えにしかすぎない、使う方でそのオブジェクトを使う条件に
合わせると言う考えもある、つまりこのメソッドは0と1以外の時は使わない、もちろん0と1の時は
仕様を満たす事を保証する、システム工学では後者の方が主流だ、どんな値でも対応するのでなく
決められた前提条件の時のみ、機能を保証する(契約プログラム)


935 :694:2010/03/07(日) 16:09:56
>>931
>今回の仕様変更からちょっと離れて考えて欲しい。
>二つの公開メソッドA、BがあるクラスFooで連続して同じメソッドを呼ばない呼び出しパターンは、
>「A」「B」「AB」「BA」の4つある。
>これらのどのパターンでも正しく動作するのはFooの責任でしょ?Fooが保証しなくて誰が保証するの?
>そこにBを変更すべき仕様変更が発生した。
>Bの変更後、やはり「A」「B」「AB」「BA」のどれもが正しく動くのはFoo自身の責任。
だから、単体じゃないと言っているだけで、その保証は結合テストで行なえばいいだろう
メソッドの組み合わせのテストは結合以降だと思っている

>>933
>C++の話なので理解できるかどうかわからないが(いい加減C++が読めるかどうか教えてくれ)、
C++は、ほぼやってない(必要に迫られて何回か修正した事はあるが)

>このケースで悪いのは、使った方?使われたクラスを書いた方?
上でも書いたが、俺が書いているのは単体レベルだと言う事、また、そのメソッドが仕様を満たしていないならバグだ
このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思うが、statusはの場合は明らかに仕様だ
仕様の場合は、0と1以外はエラーで構わない、使う方が悪いと俺は思う、それが契約プログラムの考えだ
C++は契約プログラムをサポートしていないが、UMLでOCLを書けば実装出来ると思う、その方が品質は上がる

936 :694:2010/03/07(日) 16:19:18
修正 
 「契約プログラム」⇒「契約プログラミング」

http://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

937 :仕様書無しさん:2010/03/07(日) 16:51:48
>>918
>単体の仕様? それが単体の観点じゃないのか?
そっちがどういう意味で「観点」って言ってんのか分からん。
プログラムが概ね組み上がってから単体テストを始めるの?
うちとしては、プログラムに対する観点とかどうでも良くて、
結合に入る前に単体実装フェイズのアウトプットを検証してるだけ。

>仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ
わりとどうでもいい。

>例えば〜〜
単体仕様の捉え方が違いすぎて何が言いたいかよく分からん。
うちとしては下のような単体仕様。
「入力値が数値である場合、Trueを返す。
入力値が数値でない場合、入力値を引数にハイフン判定関数を呼び出し、
その戻り値を返す。」
例の場合の問題は、ハイフン判定関数が呼び出されたかどうかの
結果確認で発見される。

ハイフン判定関数が実はベタ書きだとして、
そこで違うパスを通ってTrueを返したとして、
カバレッジの正当性チェックレビューとテスト項目結果から見た
詳細設計(単体仕様)レビューをすり抜けたとして、
それで後々どういう問題が起こるのよ?

>色々な観点のテストを行なう
それらの観点で単体検証は必要十分である、という判断は何が基準?
ある観点ついて正しく検証出来ている、とう判断は何が基準?

なんか「客観的に、客観的に」言うてる割には、
言ってることが全部主観的に見えて、すごく説得力に乏しい。

938 :861:2010/03/08(月) 12:52:07
>>934
>仕様の場合は、0と1以外はエラーで構わない、使う方が悪いと俺は思う
お前がそう思うことは理解した。もうお互いこの件については、話し合う価値ないよな。

>どんな値でも対応するのでなく
>決められた前提条件の時のみ、機能を保証する
どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
いつ誰が動作保証すべきかって話なんだが。

>このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思う
つまり、このケースでも単体テストで保証すべき問題ではないということだな。
根本的に話が合わないということを思い知らされた。

呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。

939 :861:2010/03/08(月) 12:54:53
契約プログラミングについて。
俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。

940 :仕様書無しさん:2010/03/08(月) 16:27:26
>>931
> アホ、お前だけレベルが違いすぎる、俺に絡むな
> >神様?w
> 俺が神じゃなく、お前のレベルが低いだけだ

最近書き込んでる奴でレベルが違いすぎるのはお前だアホ。

・都合の悪いことには一切答えない
・曖昧な例を曖昧な日本語で説明し、それを根拠として論を展開
・それらしきテクニカルタームを出すが、具体的な記述は一切無し
・技術的背景を明確にしない

スキルがあるというなら、これJavaでもいいから書いてみろよ。

> 1:戻り値=True
> 2:if (入力値 <> 数値) then
> 3: 戻り値=ハイフン判定関数(入力値)

当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
書けたら少しは認めてやる。

逃げるなよw

941 :仕様書無しさん:2010/03/08(月) 16:32:48
694の主張内容は、物事が良くわかってない管理者が、「xUnitでテストした?信用できん。
全てステップ実行でC2カバレッジやれ」と言ってるのとなんら変わりないんだよね。

このスレの住人をひれ伏させるような論理展開やコードの一つも示してみろ。

あー、どのパターンのどのクラスがテストやりづらいのかを理由とともに書くってのもいいぞ。
GoFのクラス名でいいから書いてみそw

942 :仕様書無しさん:2010/03/08(月) 16:34:22
あー、status=2の件で、契約プログラミングを実コードで示すってのでもいいぞ。

943 :仕様書無しさん:2010/03/08(月) 21:06:01
>>694の主張をまとめるとこうだ。
自らの変更によって、あるメソッドを変更したとき、そのクラス内の他のメソッドが
動かなくなったとしても、それは単体テストではテストしなくて良い。

なぜなら、自分では動かなくなるような呼び方はしないからだ。

動かなくなるような呼び方をするようなクライアントコードがあったとしたら、
それは結合テストで検出されるべきだ。

第三者が検証できなくとも、単体テストではステップ実行以外にテストする方法は無い。

他者の単体テスト実行品質の客観的評価は出来ない。なぜならステップ実行するからだ。

どんなに工数が掛かろうと、ステップ実行でしか単体テストはできない。他の方法では
コードが正しく実装されているかどうかを検出できないからだ。

こんなところか。むちゃくちゃだな。

944 :仕様書無しさん:2010/03/08(月) 21:24:20
これも追加してくれ。

一度ステップ実行で単体テストがOKになったメソッドは、単体テスト期間中に繰り返しテストする必要はない。
いつの間にか壊れてたとしても俺の知ったこっちゃないし、結合テストで検出されるだろう。
繰り返しテストできるxUnitとかいうものがあるそうだが、繰り返しテストする意味がわからない。

945 :仕様書無しさん:2010/03/08(月) 21:29:48
それからこんなことも主張してるな。

xUnitでテストを書いて、それで安心してリファクタリングする奴は馬鹿。
俺のコードは複雑で簡単に初期化なんてできないんだから、xUnitで簡単にテストできるはずがない。
俺は統合環境のリファクタリング支援機能でしかリファクタリングしなから、テストなんて不要。
なにせその機能は100%安全だからな。

946 :694:2010/03/08(月) 22:47:53
>>938
>どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
>いつ誰が動作保証すべきかって話なんだが。
だから、”取り得る状態が増えた”かどうかは仕様だと言っている

>呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
>阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。
落ちるとは限定していなが 上ではエラーと書いた、基本、正しい動作を保証しないと言う事だ、それが契約プログラミングだと思う
まっ、それはどっちでもいいが、考え方の違いしか言いようがないな

>俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。
statusは、publicじゃない、と言っても俺の場合は多分privateじゃなくprotectedにすると思うが(これは俺の趣味だ)
しかし、俺の例題が悪いとは思うが、setter・getterは使わないのか? そこでのチェックとかは?
また、継承も使わないのか? 俺の場合、多分status=0or1は既存メソッド
status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
正しく動いている物に、出来るだけ手をいれないようにしている

>>940-945
低いな、レベル


947 :861:2010/03/09(火) 16:46:27
>>946
> だから、”取り得る状態が増えた”かどうかは仕様だと言っている

俺がこの件の最初の発言者じゃないんだが、なんか話がずれてきてる(のか、最初からずれてたか)。
そもそもは、コードを変更したときに変更箇所以外のテストは必要なのかという話だったはず。

多分俺も含めて、Foo::bar()を変更したときにFoo::foo()に影響を及ぼす可能性があるならテストする
というスタンスだろうが、その変更が仕様変更によるものかどうかなんて関係ないんだよ。
インクリメンタルにコーディングしてるから。

この話の結論はこうじゃないの?
俺:Foo内に変更があった場合は、Foo全体の動作保証は単体テストでやるべき。
お前:Foo内に変更があって、仮に動作しない場合があったとしても、単体テストではテストしない。
シンプルに言えば、こういうことだよな?

> しかし、俺の例題が悪いとは思う
え?何の話?>>883が出した例じゃないの?
クラスの状態を表す変数なんだから、外部には出さないよ。

948 :861:2010/03/09(火) 17:04:39
>>940
> 当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
> 書けたら少しは認めてやる。

これは俺も見たい。
xUnitでは検出できないケースがあるんなら、ちゃちゃっとコードで書いてみせてよ。

949 :861:2010/03/09(火) 17:07:23
読み返せって>俺
>>947
> 多分俺も含めて、

> 多分俺も含めてxUnitで繰り返しテストをする派は、

950 :仕様書無しさん:2010/03/09(火) 17:18:23
「単体テスト」の定義って難しいな

951 :861:2010/03/09(火) 17:30:26
>>946
> setter・getterは使わないのか? そこでのチェックとかは?

前述したとおり、公開しない性質のメンバ/プロパティだということが前提。

> また、継承も使わないのか? 俺の場合、多分status=0or1は既存メソッド
> status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
> 正しく動いている物に、出来るだけ手をいれないようにしている

ケースバイケースだとしか言えないが、status=0, 1, 2の処理それぞれが処理内容的に
同じレベルの処理だろうから継承はしない。(でなければ同じstatusで状態を表現しないだろうから)

あえて言うなら、status=2の処理をべた書き(クラス内にコードを追加)するか、
StateパターンかStrategyパターンで、status=0, 1, 2を全部外に出すか、そんな感じだと思う。

このスレはテストスレだから、設計の話はこの辺で。
テスタビリティを高める設計の話なら大歓迎。

952 :仕様書無しさん:2010/03/10(水) 01:42:33
>>946
逃げたか。恥ずかしくないんかなこいつ。

>status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
そんな糞コード書くからテストやりづらくなる一方なんだよw

>正しく動いている物に、出来るだけ手をいれないようにしている
そしてつぎはぎだらけの糞の山ができあがるんだよw

953 :仕様書無しさん:2010/03/10(水) 11:33:43
ぬるほ
ぬるほ

954 :仕様書無しさん:2010/03/10(水) 14:16:58
>>946
> 正しく動いている物に、出来るだけ手をいれないようにしている

自動テストで得られる程度の安心感もないから、手を入れるのを躊躇するんじゃないの?
つか、テストも無しでどんどんリファクタリングしてますってのが信じられないんだけど。
その安心感はどこから来てるんだろう?

955 :仕様書無しさん:2010/03/10(水) 16:27:52
多分>>694は、基本、ツールを使ったコードの移動系のリファクタリングしかしないんでしょ。

とすると、デザインパターンを導入するようなリファクタリングはコードの構造を変えるものなので
到底受け入れられないということになる。

だから、継承で差分プログラミングするんでしょ。

956 :仕様書無しさん:2010/03/11(木) 14:33:57
すげー伸びてるな。

まさか、
>>857
> 具体的に単体(コード)テストで、修正個所以外でどのような影響が出る?
のオチが、

コードの修正で他に影響が出る場合もあるが、それは単体テストでは
テストしないので、「単体テストの範囲では修正箇所以外には影響は出ない」。
影響が出ないのだから、繰り返しテストする必要はない

ということだったなんて想像出来なかった。

957 :仕様書無しさん:2010/03/11(木) 15:22:53
しつこいぞ

958 :仕様書無しさん:2010/03/12(金) 12:53:54
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト
http://d.hatena.ne.jp/hyoshiok/20100312#p1

959 :仕様書無しさん:2010/03/12(金) 13:06:28
テスト駆動開発の効果はどのくらいある?
http://www.publickey.jp/blog/10/post_99.html

960 :694:2010/03/13(土) 01:27:47
>>947
>俺がこの件の最初の発言者じゃないんだが、なんか話がずれてきてる(のか、最初からずれてたか)。
>そもそもは、コードを変更したときに変更箇所以外のテストは必要なのかという話だったはず。
必要ないとは言ってない、なぜ必要かの理由を聞いている

>この話の結論はこうじゃないの?
>俺:Foo内に変更があった場合は、Foo全体の動作保証は単体テストでやるべき。
>お前:Foo内に変更があって、仮に動作しない場合があったとしても、単体テストではテストしない。
>シンプルに言えば、こういうことだよな?
簡単に言えばそうだ

>>948
>> 当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
>> 書けたら少しは認めてやる。
>これは俺も見たい。
>xUnitでは検出できないケースがあるんなら、ちゃちゃっとコードで書いてみせてよ。
戻り値 = False
if (入力値 = "1234567" ) or (入力値 = "123-4567" ) or (入力値 = "△1234567" ) or (入力値 = "1234567△" ) or
(入力値 = "△123-4567") or (入力値 = "123-4567△") or (入力値 = "△1234567△") or (入力値 = "△123-4567△") then
戻り値 = True

961 :694:2010/03/13(土) 01:29:36
>>952-956
相変わらず、アホだな


しかし、xUnitを単体に使うと言う奴は、どんな書籍を読んでいるんだ?
マーチンやケントは、そんな事をは書いていないが

あと、お前ら本当にxUnitの使い方が分かっているのか?
修正個所と関係ないメソッドをxUnitでテストしてどうする?
SetUp・TearDownが何故あるのか、理解出来るか?
テストコードは他のテストコードに影響しないように作るもんだ理解出来るか?
ケントも
「テストの結合は、コードが正しくても、1つのテストの失敗が次の10個の
 テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
と言っている、俺が出した例題もこれだ、分かる奴がいるかと思ったが
話さえ通じん、本当にxUnitをやっているのか?


962 :仕様書無しさん:2010/03/13(土) 03:33:57
>>960
アホか。
>1:戻り値=True
>2:if (入力値 <> 数値) then
>3: 戻り値=ハイフン判定関数(入力値)
のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。

>修正個所と関係ないメソッドをxUnitでテストしてどうする?
リグレッション。

>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか?
いきなり何を言い出すんだ?

>「テストの結合は、コードが正しくても、1つのテストの失敗が次の10個の
> テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
>と言っている、
テストの結合って何?

>俺が出した例題もこれだ、
どれ?

>分かる奴がいるかと思ったが
>話さえ通じん、本当にxUnitをやっているのか?

話が通じないのは、お前がxUnitについて何もわかってないから。

963 :仕様書無しさん:2010/03/13(土) 12:00:33
>>694

>>937はスルーか?

964 :仕様書無しさん:2010/03/13(土) 12:26:48
xUnit は caller での assertion なので white box testing には使えない。
こんなの考えるまでもないと思うが。

まぁ、俺なんか最右翼だから、
white box testing が必要だと感じるほど複雑な method は分割せよ
って言っちゃうけどな。

> SetUp・TearDownが何故あるのか、理解出来るか?
> テストコードは他のテストコードに影響しないように作るもんだ理解出来るか?

理解は出来るが現実は厳しい。
これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。


965 :仕様書無しさん:2010/03/13(土) 13:30:52
>>964
お前もxUnitがわかってねーわ

966 :仕様書無しさん:2010/03/13(土) 13:38:26
ホワイトボックステストもわかってねーわ。
適当な日本語ページが見つからなかったので、Wikipedia。
http://en.wikipedia.org/wiki/White_box_testing

967 :仕様書無しさん:2010/03/13(土) 13:57:59
>>921

>・Foo::statusはFoo::foo()でしか設定しなくて、仕様変更でstatus=2になる場合が増えた
>・一方Foo::bar()はstatus=2の時に呼ばれると落ちる

Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
それは Foo::bar() も「修正メソッド」だということでは。

968 :仕様書無しさん:2010/03/13(土) 14:10:59
test case 内で function ではなく process を call すれば CT の自動化に応用できるし、
callee に trace 吐かせて、それを expected な内容と比較すれば white box testing にも使えるだろう。

そんなのは各自で工夫すればいいんじゃないかな。xUnit とは無関係な話だが。

969 :仕様書無しさん:2010/03/13(土) 18:16:31
ルー大柴は芸能界にお帰りください。

970 :仕様書無しさん:2010/03/13(土) 19:27:51
>>964
> まぁ、俺なんか最右翼だから、
> white box testing が必要だと感じるほど複雑な method は分割せよ
> って言っちゃうけどな。

なんだろう。何かの自慢なのかな。
それ、リファクタリングって言うんですよ。

> > SetUp・TearDownが何故あるのか、理解出来るか?
> > テストコードは他のテストコードに影響しないように作るもんだ理解出来るか?
>
> 理解は出来るが現実は厳しい。
> これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。

xUnit使ってる人はなら、大体理解も実践もしてると思うけど。
あと、TDDじゃなくてもxUnit使いますから。

971 :仕様書無しさん:2010/03/13(土) 19:30:28
>>967
> Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら

問題ならって、問題以外の何者でもないですねぇ。

> それは Foo::bar() も「修正メソッド」だということでは。

あたりまえじゃないですか。

972 :仕様書無しさん:2010/03/13(土) 20:04:37
>>776
xUnit を UT に使う現場の場合、そもそも white box testing を行っていないのではないか。少なくとも俺はそうだ。
正確に言えば、必要に応じて C2 が 100% になる「だろう」test case を用意はするが、その実行を trace することはしない。
実際に検証するのは、あくまでも coverage と output だけだ。

その意味で
> 割り切っているのか?

yes.
割り切って良しとする根拠は
white box testing が必要だと感じるほど複雑な method は分割せよ

ということになる。

973 :仕様書無しさん:2010/03/13(土) 20:33:32
>>972
何言ってるのか理解できん。

ホワイトボックスしない、処理のパスはトレースしない。
にもかかわらずカバレッジは検証するという。

トレースしないのにカバレッジが出るのか、そもそもトレースとは何か、
カバレッジについてどんな検証するのか、辺りを教えてくれんか?

974 :仕様書無しさん:2010/03/13(土) 20:38:19
>>972
お前の言うホワイトボックステストというのは、どうやって実行するものなんだ?

975 :仕様書無しさん:2010/03/13(土) 20:40:55
>>951
なぜ Foo::status の accessibility が論点になるのだろうと疑問に思って考えたのだが、
こういう言い方をすれば議論が進むだろうか。

Foo::status が private ならば
「Foo::status = 2 の状態で Foo::bar() を呼び出した場合には云々」という仕様にはならない。
必ず「これこれの条件で Foo::foo() を実行した状態で Foo::bar() を呼び出した場合には云々」という仕様になる。

したがって Foo::bar() の test case には「これこれの条件で Foo::foo() を実行」する code が含まれるはずで、
Foo::foo() の仕様変更が Foo::bar() の挙動に影響を与えるのであれば、それは Foo::bar() の test で検出される。


976 :仕様書無しさん:2010/03/13(土) 20:46:31
テスト以前に書き方を一からやり直したら

977 :仕様書無しさん:2010/03/13(土) 20:48:01
それから、>>694は早いとこxUnitでは検出できないバグを含む>>918の実コードを示してくれ。
xUnitでは検出できないケースがあるのだからステップ実行しなければならないということなんだろ?

まあ俺的にはなんでxUnitを毛嫌いするのかわからんが、xUnitでテストコード書いて
最初の一回はステップ実行で確認して、あとは自動テストじゃいけないんだろうか。
SCMが甘くてデグレしたなんてアホなことやらかすのを除いても、デグレはまあありうる
ことだし、コストをかけずに繰り返しテストできる意味がわからないというのが
意味がわからない。

978 :694:2010/03/13(土) 22:18:54
>>962
>> 1:戻り値=True
>> 2:if (入力値 <> 数値) then
>> 3: 戻り値=ハイフン判定関数(入力値)
> のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。
まったく、上でも書いただろう理解出来ないのか?

>>918
>つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
>PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
>あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなw
つまり、PGの書きたかったコードは、これだ
1:戻り値=True
2:if (TRIM(入力値) <> 数値) then
3: 戻り値=ハイフン判定関数(入力値)
本来PGは2:で終了し、戻り値=Trueとする所を、ハイフン判定関数に助けられて
バグになっていない状態の事を言っている

>>修正個所と関係ないメソッドをxUnitでテストしてどうする?
>リグレッション。
もう一度書く、リグレッションを”xUnitでテストしてどうする?”

>>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか?
>いきなり何を言い出すんだ?
本当にxUnitを理解してないな

>テストの結合って何?
明日本屋に行け


979 :694:2010/03/13(土) 22:20:27
>>964
>white box testing が必要だと感じるほど複雑な method は分割せよ
>って言っちゃうけどな。
いいな、簡単なプログラムしか作った事が無い人間は

>これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。
一般的には、TDDをやるとOODが崩れると言われているが
まっ、崩れたから悪いとも一概には言えないが

>>965
>お前もxUnitがわかってねーわ
お前より>>965の方がましだと思うが

>>966
>ホワイトボックステストもわかってねーわ。
>適当な日本語ページが見つからなかったので、Wikipedia。
ホワイトボックステストぐらいで、何で英語のページなんだ?
自分の言葉で説明出来んのか?

>>967
>Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
>それは Foo::bar() も「修正メソッド」だということでは。
多分xUnitで、その修正漏れを見つけ出せると言う主張だと思うが
それでも間違っているが

>>977
>まあ俺的にはなんでxUnitを毛嫌いするのかわからんが、xUnitでテストコード書いて
俺はxUnitが好きだ、正しく使っているからな


しかし誰でもいいから、いいかげん、単体でxUnitの使い方が書いてある書籍を教えて欲しいが
お前らケントの”独立したテスト”が理解出来ているのか?

980 :仕様書無しさん:2010/03/13(土) 22:42:46
>>979
やっぱり>>937はスルーか。
結局大した根拠もなく他人のやり方を否定したかっただけなんだな。

君の言葉は全部薄っぺらい。

981 :仕様書無しさん:2010/03/13(土) 23:46:58
>>979

> いいな、簡単なプログラムしか作った事が無い人間は

そうだな。同意する。
俺は十人並みの平凡な programmer なので簡単な仕事しか経験してしない。
医療機器の制御も飛行機を飛ばすこともない。俺の話はその範囲にしか適用できないものと考えてもらってよい。
そもそも大規模で複雑な仕事への適用は TDD ひいては agile の課題なのではないかとも思う。

俺が扱うような簡単な仕事なら

> 2:if (TRIM(入力値) <> 数値) then

この condition clause を別の method に切り出して、その method を test する。


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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)