ソフトウェアのテストについて
1 ：仕様書無しさん：
コーディングより時間のかかる単体テスト項目作成・テスト
実行なんて意味なくね？同じ時間かけるなら机上デバッグの
ほうがよくね？
実行なんて意味なくね？同じ時間かけるなら机上デバッグの
ほうがよくね？
|
|
|
2 ：仕様書無しさん：2006/04/23(日) 22:03:11
机上デバッグって何ですか？
机の上に座ってデッバガでプログラムの動作を追いかけることだ。
椅子が要らない分コスト削減となる。
椅子が要らない分コスト削減となる。
_, ,_
( ﾟдﾟ ) デッバガ!!
( ﾟдﾟ ) デッバガ!!
5 ：仕様書無しさん：2006/04/23(日) 23:34:26
デパガ
6 ：仕様書無しさん：2006/04/23(日) 23:39:39
( *゜ё゜) デパガとペアプロ！
7 ：仕様書無しさん：2006/04/23(日) 23:52:26
保守開発とかやってると
コーディングの１０倍ぐらいテストに時間使って嫌になるな。
コーディングの１０倍ぐらいテストに時間使って嫌になるな。
8 ：仕様書無しさん：2006/04/24(月) 00:00:08
>>1みたいな考えの偉い人がいた場合の結果は、みずほとか
いろいろいい例があるよ。
いろいろいい例があるよ。
出歯亀ですが何か？
たとえば単体テスト項目を作成するにあたってコードを参照するならば
それは無意味であろう。テスト項目は当然だが仕様書に基づいて作成し
なければならない。
それは無意味であろう。テスト項目は当然だが仕様書に基づいて作成し
なければならない。
11 ：仕様書無しさん：2006/04/24(月) 00:10:09
12 ：仕様書無しさん：2006/04/24(月) 10:22:44
騎乗位デバッグ
13 ：仕様書無しさん：2006/04/24(月) 11:38:09
>11 UTは詳細設計書に基づいて行う。
コーディングに即して行うのは開発テストで、通常は正規のテストとは認めない。
コーディングに即して行うのは開発テストで、通常は正規のテストとは認めない。
テスト自動生成ツールがもっと賢ければなぁ('A`)
安く作れ、早く作れ
↓
テストに工数をかけられない
↓
潜在バグだらけのまま出荷
↓
他社よりも早いリリースでシェア確保
↓
バグが見つかって大騒ぎ
↓
その頃には売上も出て、
ようやくテストに工数をかけられるようになる
↓
テストに工数をかけられない
↓
潜在バグだらけのまま出荷
↓
他社よりも早いリリースでシェア確保
↓
バグが見つかって大騒ぎ
↓
その頃には売上も出て、
ようやくテストに工数をかけられるようになる
17 ：仕様書無しさん：2006/04/24(月) 23:03:21
早く安くバグのないものを作れ
という無理難題を普通に言われてしまう業界。
という無理難題を普通に言われてしまう業界。
19 ：仕様書無しさん：2006/04/24(月) 23:21:28
ＶＢプログラマ Ｃプログラマのお仕事
http://www.vb-c.net/
http://www.vb-c.net/
コード書くよりもテストに時間かけたほうがいい気がするけど。
21 ：仕様書無しさん：2006/04/24(月) 23:23:50
究極のテスト仕様書
条件：PG仕様書通りであること。
結果：PG仕様書通りであることを確認しました。
以上
条件：PG仕様書通りであること。
結果：PG仕様書通りであることを確認しました。
以上
22 ：仕様書無しさん：2006/04/24(月) 23:37:24
>>21
今のプロジェクトで使わせてもらうよｗｗｗｗｗｗ
今のプロジェクトで使わせてもらうよｗｗｗｗｗｗ
23 ：仕様書無しさん：2006/04/25(火) 00:22:20
>>23
禿同
だがしかし、
ちゃんと設計する → 仕事が遅いダメな奴
問題を解決しないまま適当に実装する → 仕事が速い優秀な奴
という扱いを受ける。
知識不足、経験不足で恐いもの知らずの新人が重宝されるのは、そういうことなんだよな。
禿同
だがしかし、
ちゃんと設計する → 仕事が遅いダメな奴
問題を解決しないまま適当に実装する → 仕事が速い優秀な奴
という扱いを受ける。
知識不足、経験不足で恐いもの知らずの新人が重宝されるのは、そういうことなんだよな。
テストさえしっかりやれば大丈夫といってると、
テストで見つけたバグは直せるけど、
テストで見つけられなかった大量のバグが残る。
そもそも、ハードウェアの製造では、
いいかげんに作って検査で品質を確保するアメリカ式に対して、
しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。
テストで見つけたバグは直せるけど、
テストで見つけられなかった大量のバグが残る。
そもそも、ハードウェアの製造では、
いいかげんに作って検査で品質を確保するアメリカ式に対して、
しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。
>>25
>そもそも、ハードウェアの製造では、
>いいかげんに作って検査で品質を確保するアメリカ式に対して、
>しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。
だから、ソフトウエアのテストは本物の「テスト」にあらず。
設計の妥当性を検証しているだけ。コーディングは「設計」なの。
本当に「製造」と呼べる作業は、
「コンパイラ」がやってくれている部分だけ。
>そもそも、ハードウェアの製造では、
>いいかげんに作って検査で品質を確保するアメリカ式に対して、
>しっかり作って品質を確保する日本式が勝利したのに、ソフトウェアでは逆だよね。
だから、ソフトウエアのテストは本物の「テスト」にあらず。
設計の妥当性を検証しているだけ。コーディングは「設計」なの。
本当に「製造」と呼べる作業は、
「コンパイラ」がやってくれている部分だけ。
27 ：仕様書無しさん：2006/04/25(火) 22:52:29
28 ：仕様書無しさん：2006/04/25(火) 23:01:43
そういう風潮があるのか
了解営業殿。
了解営業殿。
テスト初心者なんですが、本読んで勉強しようと思うのですが、どの本がお勧めですかね？
ちなみに今自分で候補にあげているのが「はじめて学ぶソフトウェアのテスト技法」と「知識ゼロから学ぶ ソフトウェアテスト」です。
予算は３０００円前後。お願いしました。
ちなみに今自分で候補にあげているのが「はじめて学ぶソフトウェアのテスト技法」と「知識ゼロから学ぶ ソフトウェアテスト」です。
予算は３０００円前後。お願いしました。
30 ：仕様書無しさん：2006/04/26(水) 00:11:33
障害あっても検出できないテスト仕様書って一体．．．．．．。
トータルで長い工数、とくに手戻りやリリース後の工数が多い新人に、
トータルでは短い工数で仕事できるベテランが老兵として追いやられるんだよな。
そういうことをしてる限り、ダメだろ。
トータルでは短い工数で仕事できるベテランが老兵として追いやられるんだよな。
そういうことをしてる限り、ダメだろ。
32 ：仕様書無しさん：2006/04/27(木) 12:56:31
姉歯の件でも分かるとおり、普通は安くしろと言うとどこかの手を抜く
デッバガ
34 ：仕様書無しさん：2006/06/18(日) 11:03:11
テスター（バイト）をたくさん雇えば、プログラマはテストしなくていいので最高だよな。
バイトを雇うのはありだと思うけど、守秘義務のあるﾋﾞﾐｮｰなアプリだった
らその手が使えない。
デバッグ請負会社にまわすのもありだけどコストがベラボーになるし
らその手が使えない。
デバッグ請負会社にまわすのもありだけどコストがベラボーになるし
正社員プログラマで入社して、テスターとして偽装派遣に出された３０歳童貞の僕が来ましたよ。
何か質問ある？
何か質問ある？
37 ：仕様書無しさん：2006/06/18(日) 14:08:45
どうも良くわからない主張が多いような気がする。
テストってどういう目的で、どんな手法でやるのか、>>1はお勉強してから言ってるのかな？。
わたしもこの間研修受けて、「そうはいうけどさー、実際には時間ないし…」とかぶつくさ言いながらも、必要性は理解してきたと思う。
テストってどういう目的で、どんな手法でやるのか、>>1はお勉強してから言ってるのかな？。
わたしもこの間研修受けて、「そうはいうけどさー、実際には時間ないし…」とかぶつくさ言いながらも、必要性は理解してきたと思う。
観測以前にはバグの有無はどちらもありうる状態にあるが、
観測者が観測したことで有無が一方に定まる。
使われないプログラムであるならば観測する意味がない。
観測者が観測したことで有無が一方に定まる。
使われないプログラムであるならば観測する意味がない。
39 ：仕様書無しさん：2006/06/23(金) 18:00:53
>>36
テスターの仕事ってどう？
俺、テスターとして正社員になれそうなんだ。
イメージとしては、特に難しいこともなく淡々と決められたテストをこなしていく感じ？
PGやSEみたいにデスマで寝てねーよみたいにはならないよね？
テスターの仕事ってどう？
俺、テスターとして正社員になれそうなんだ。
イメージとしては、特に難しいこともなく淡々と決められたテストをこなしていく感じ？
PGやSEみたいにデスマで寝てねーよみたいにはならないよね？
,､‐ "￣:::ﾞ:丶､
,r::::l3ﾞ::::::::/ﾊヽ:ヽ::::､:ヽ
{::://:::::::// ヽ＼ﾄ､:::::::!
ヾ l:::::::/ 丶 ｀ヾ ｨ､:::|
|;:r::| Ｏ` 'Ｏ ﾞﾊ|
ヽﾊ :.:. :.: ﾚ
´＼ r‐--‐､,ノ
r､ r､／ヾ￣下ヘ
ヽヾ 三 |:l1､＿ヽ/__ .ィヽ
＼>ヽ/ |｀ ｝ n_n| |
ﾍ lノ `'ｿ lﾟωﾟ| |
/´ / ￣|. |
＼. ｨ ＿＿＿ | |
| ﾉ l | |
,r::::l3ﾞ::::::::/ﾊヽ:ヽ::::､:ヽ
{::://:::::::// ヽ＼ﾄ､:::::::!
ヾ l:::::::/ 丶 ｀ヾ ｨ､:::|
|;:r::| Ｏ` 'Ｏ ﾞﾊ|
ヽﾊ :.:. :.: ﾚ
´＼ r‐--‐､,ノ
r､ r､／ヾ￣下ヘ
ヽヾ 三 |:l1､＿ヽ/__ .ィヽ
＼>ヽ/ |｀ ｝ n_n| |
ﾍ lノ `'ｿ lﾟωﾟ| |
/´ / ￣|. |
＼. ｨ ＿＿＿ | |
| ﾉ l | |
いい歳して「職業はテスターです。プログラムは分かりません」
とかいいにくいよね
とかいいにくいよね
指摘すればするだけ、自分の出バグ進行度が進まないだろ
45 ：仕様書無しさん：2006/06/24(土) 23:23:49
>>44
やっぱりひとつバグが見つかったら、修正してまた１からテストやりなおし？
やっぱりひとつバグが見つかったら、修正してまた１からテストやりなおし？
修正が及ぼす範囲内で再テスト。
で、デグレが見つかると
48 ：仕様書無しさん：2006/07/01(土) 18:14:17
昨日面接でテスト工程を行ううえで考えることは何ですか
といわれて。
エビデンスを見やすく作ることです。
と答えた私は落ちかな？
正解の答えは何でしょうか？
といわれて。
エビデンスを見やすく作ることです。
と答えた私は落ちかな？
正解の答えは何でしょうか？
>>48
人員の健康管理
人員の健康管理
強い破壊的思想
「正解の答え」って。
52 ：仕様書無しさん：2006/07/05(水) 20:12:20
>>48
エビちゃんがどうしたって
エビちゃんがどうしたって
なんか最近は静的解析ツールを使うことも含まれるらしい
それだけツールを手軽に使えるようになったということか
それだけツールを手軽に使えるようになったということか
静的解析ツールは、どこまで使えるの?
以前に社内の間接部門が、静的解析ツール使いませんかと話を持ち込んで来た時は、
たった数日の仕事でも、百万円寄越せとか言ってきたので、使わずに断ったことがある。
いわく、ツールのライセンス料もさることながら、ツールの出力する結果を読み解く人間が必要だとかで。
ちろっとサンプルコードで試してもらったら、それはもう膨大な両のメッセージをツールが出力して、
「読み解く人間」がこっちに、このコードは何をするものなのか? と大量の質問を浴びせてきてさ、
まるでソースコードを1行ずつ説明させられているような状況で、結局は、人間が判断してるのよ。
だとしたら、数日では済まないし、「読み解く人間」の相手をする人間も長時間、拘束されるわけで。
以前に社内の間接部門が、静的解析ツール使いませんかと話を持ち込んで来た時は、
たった数日の仕事でも、百万円寄越せとか言ってきたので、使わずに断ったことがある。
いわく、ツールのライセンス料もさることながら、ツールの出力する結果を読み解く人間が必要だとかで。
ちろっとサンプルコードで試してもらったら、それはもう膨大な両のメッセージをツールが出力して、
「読み解く人間」がこっちに、このコードは何をするものなのか? と大量の質問を浴びせてきてさ、
まるでソースコードを1行ずつ説明させられているような状況で、結局は、人間が判断してるのよ。
だとしたら、数日では済まないし、「読み解く人間」の相手をする人間も長時間、拘束されるわけで。
ねたなのか？
少なくとも使ったことのある解析ツールは普通に使えたけど...
もちろん「読み解く人間」なんかいらなかったし
少なくとも使ったことのある解析ツールは普通に使えたけど...
もちろん「読み解く人間」なんかいらなかったし
ほしゅ
テスト技術者資格試験を受ける人ってどのくらいいるんでしょうかね。
59 ：仕様書無しさん：2006/08/02(水) 19:00:06
コーディングができることを採用条件にしないで採用しているために、
新入社員は、コーディングができるようになるまで、テスト担当になるのだが、
上がコーディングの機会を与えずに朝から晩までテストさせてるので、
当然の結果、コーディングができるようになるわけもなく、
また、コーディングができるようになると仕事が過酷になる割に給料はまったく上がらないので、
若い人たちは、テストのスペシャリストになろうとする。
もうね、あほかと。
新入社員は、コーディングができるようになるまで、テスト担当になるのだが、
上がコーディングの機会を与えずに朝から晩までテストさせてるので、
当然の結果、コーディングができるようになるわけもなく、
また、コーディングができるようになると仕事が過酷になる割に給料はまったく上がらないので、
若い人たちは、テストのスペシャリストになろうとする。
もうね、あほかと。
61 ：仕様書無しさん：2006/08/03(木) 12:07:24
テストの技術とプログラムの技術は別ものだと思うが、如何か？
それより、まともなテスト工程が入ってる開発に入った事ないんだけど。
みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの？
おいらのところって、営業ポンチ絵書いて→SEが背景書いて→チームリーダーが
仕様書ポイ書式で書いて→プログラマーがプログラム組んで→プログラマーがプログラムを日本語にして
これを詳細設計書と読んで→プログラマーがテスト仕様書いて→プログラマーテストやって→
プログラマーがテスト報告書を書いて→プログラマーがSEが書いたポンチ絵を一応仕様書ぽく書き直して、
で、納品して。
って感じなんだけど。
みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの？
おいらのところって、営業ポンチ絵書いて→SEが背景書いて→チームリーダーが
仕様書ポイ書式で書いて→プログラマーがプログラム組んで→プログラマーがプログラムを日本語にして
これを詳細設計書と読んで→プログラマーがテスト仕様書いて→プログラマーテストやって→
プログラマーがテスト報告書を書いて→プログラマーがSEが書いたポンチ絵を一応仕様書ぽく書き直して、
で、納品して。
って感じなんだけど。
デジタル家電はきちんとしたテストがあるだろ
65 ：仕様書無しさん：2006/08/03(木) 21:59:25
>>63
そういう考え方が一番やばいんだよな。
そういう考え方が一番やばいんだよな。
某ミッションクリティカルなサーバ上で、root権限で動くシェルスクリプトを書きました。
膨大な量の仕様書を書くのに忙しくて、十分にテストができませんでした。
万一鯖を殺してしまったら、マスコミ沙汰になるでしょう。
そろそろ逃げる準備をする必要があります。
膨大な量の仕様書を書くのに忙しくて、十分にテストができませんでした。
万一鯖を殺してしまったら、マスコミ沙汰になるでしょう。
そろそろ逃げる準備をする必要があります。
漢にはテスト不十分でもリリースしなければならんときがある。
そんなときは文字化けのように堂々としとけ。
そんなときは文字化けのように堂々としとけ。
68 ：仕様書無しさん：2006/08/03(木) 23:31:06
ソースごとリリースして客に直してもらえば良し
早く作れ、安く作れ
↓
てめぇなにさまだごるぁ
↓
完
↓
てめぇなにさまだごるぁ
↓
完
70 ：仕様書無しさん：2006/08/04(金) 14:42:54
>>71
いやいや、その工程が全部プログラマーがやることになってて。。。。。。
いやいや、その工程が全部プログラマーがやることになってて。。。。。。
>>62
> それより、まともなテスト工程が入ってる開発に入った事ないんだけど。
> みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの？
メーカー系の仕事だと、QA部門がしっかりして２～３ヶ月専門部隊で品質管理したりするよ。
あとは大手の仕事とかでも、SEがちゃんとテストしてた。
> それより、まともなテスト工程が入ってる開発に入った事ないんだけど。
> みんながカッコ良く言ってるテスト工程って、金融の世界なら有るの？
メーカー系の仕事だと、QA部門がしっかりして２～３ヶ月専門部隊で品質管理したりするよ。
あとは大手の仕事とかでも、SEがちゃんとテストしてた。
74 ：仕様書無しさん：2006/08/06(日) 14:21:42
某大手に居た頃SEに
「自分で作って自分でテストするならやらなくていい」といわれた。
正論だと思った。
「自分で作って自分でテストするならやらなくていい」といわれた。
正論だと思った。
75 ：仕様書無しさん：2006/08/06(日) 15:08:12
まともな人もいるんだねぇ～
>>74
それはﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄのことだよな？
単体ﾃｽﾄやﾎﾜｲﾄﾎﾞｯｸｽﾃｽﾄはｺｰﾀﾞｰが自分でやらないと無駄に工数かかるだけかと。
むしろ単体ﾃｽﾄなんてﾃｽﾄﾌｧｰｽﾄで実装すれば良いだけの話しだし。
それはﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄのことだよな？
単体ﾃｽﾄやﾎﾜｲﾄﾎﾞｯｸｽﾃｽﾄはｺｰﾀﾞｰが自分でやらないと無駄に工数かかるだけかと。
むしろ単体ﾃｽﾄなんてﾃｽﾄﾌｧｰｽﾄで実装すれば良いだけの話しだし。
77 ：仕様書無しさん：2006/08/06(日) 16:33:02
人を見て道を説け、ということだな。
74にはそういう判断が下されたとしても、そうじゃないやつは
世の中いるでしょうな。
みんなが自分の作ったところをテストしないとすればどんな
もんができあがるのか興味深い。
74にはそういう判断が下されたとしても、そうじゃないやつは
世の中いるでしょうな。
みんなが自分の作ったところをテストしないとすればどんな
もんができあがるのか興味深い。
78 ：仕様書無しさん：2006/08/06(日) 17:52:16
あるプログラムに関して「Aという場合」というのを考慮しないで
コードを書いたとする。
このコードを書いた人がテストを設計すると、当然「Aという場合」を
考慮しない。
したがって「Aという場合」のテストは行われない。
最終的に「Aという場合」には正しく動かない可能性が放置される。
これを防ぐには、テストの設計か、テスト仕様書のレビューを他の
人がする必要がある。
コードを書いたとする。
このコードを書いた人がテストを設計すると、当然「Aという場合」を
考慮しない。
したがって「Aという場合」のテストは行われない。
最終的に「Aという場合」には正しく動かない可能性が放置される。
これを防ぐには、テストの設計か、テスト仕様書のレビューを他の
人がする必要がある。
79 ：仕様書無しさん：2006/08/06(日) 19:38:27
めんどくせ
80 ：仕様書無しさん：2006/08/06(日) 22:27:41
俺はテストファーストが大嫌いだ。
試行錯誤的にコードを少しいじってはテストに通し、たまたまテストに通るまで繰り返す輩がいるから。
そんな、まったく穴のないテストを前提とすることは間違いだし、そもそも、生産性が悪すぎる。
試行錯誤的にコードを少しいじってはテストに通し、たまたまテストに通るまで繰り返す輩がいるから。
そんな、まったく穴のないテストを前提とすることは間違いだし、そもそも、生産性が悪すぎる。
82 ：仕様書無しさん：2006/08/06(日) 23:51:42
昔話にテストファーストとか言われてもなぁｗ
>>80
設計書の段階でわざわざこと細かにあらゆる場合について書かないでしょ。
そんなことしたら設計書が電話帳なみになる。
設計書に書かれていることから実装が決められていくわけで、
その段階で考慮漏れが出る可能性がある。
設計書の段階でわざわざこと細かにあらゆる場合について書かないでしょ。
そんなことしたら設計書が電話帳なみになる。
設計書に書かれていることから実装が決められていくわけで、
その段階で考慮漏れが出る可能性がある。
俺のソースはコンパイラすら通らないぜ
コンパイルも静的テストの一種です。
ワーニング取りしてたらヤバイの見つける時あるよねｗ
コンパイラの警告は1つでも出たらダメだろ。
ずらずらと大量に警告が出ていると、
いつの間にか無視できない警告が加わっても、
気がつかないぞ。
ずらずらと大量に警告が出ていると、
いつの間にか無視できない警告が加わっても、
気がつかないぞ。
89 ：仕様書無しさん：2006/08/09(水) 23:30:52
90 ：仕様書無しさん：2006/08/12(土) 16:15:43
>>89
怖い所だとエクリプスのコンパイラ設定を全部無視とかやる所あるぞ
怖い所だとエクリプスのコンパイラ設定を全部無視とかやる所あるぞ
91 ：仕様書無しさん：2006/08/12(土) 16:27:48
警告抑止のオプションだけはやたら詳しいヤツがいる。
そんなもん調べてる暇があったら他のことしろよ。
そんなもん調べてる暇があったら他のことしろよ。
92 ：仕様書無しさん：2006/08/12(土) 16:35:46
93 ：仕様書無しさん：2006/08/12(土) 16:42:01
>>92
うんｗ無くていいやｗｗｗ
うんｗ無くていいやｗｗｗ
ソフトウェア・テストＰＲＥＳＳという雑誌が出ているんだね。Vol1～Vol3まで出ているようだ。
ソフトウェアテストの専門雑誌が出るなんて、一昔前には考えられなかったな。
ソフトウェアテストの専門雑誌が出るなんて、一昔前には考えられなかったな。
95 ：仕様書無しさん：2006/08/13(日) 22:19:29
GUI、特に画面表示部分のテストの自動化ってどうやってる？
やっぱ手動&目視しかないのかなぁ o...rz
やっぱ手動&目視しかないのかなぁ o...rz
96 ：仕様書無しさん：2006/08/13(日) 22:21:54
写真屋も不良写真の判別は目視だからなぁ
97 ：仕様書無しさん：2006/08/13(日) 22:27:45
>>94
開発形態が急激に変わっているからじゃないかな。
本に出してもすぐに内容が開発形態に合わなくなる。
だから雑誌にして定期的にだす需要が出てきた、と。
まあ、実際にはそれほど変わってないけどね、テストなんて
開発形態が急激に変わっているからじゃないかな。
本に出してもすぐに内容が開発形態に合わなくなる。
だから雑誌にして定期的にだす需要が出てきた、と。
まあ、実際にはそれほど変わってないけどね、テストなんて
>>97
大分変わってきてるぞ
ユニットテストでテストツール使うとか10年前は実用的な話じゃなかったし、
ホワイトボックステストを自動化ツールで流すとかもマシンの性能的な問題で不可能だったが最近は出来るようになってるし
大分変わってきてるぞ
ユニットテストでテストツール使うとか10年前は実用的な話じゃなかったし、
ホワイトボックステストを自動化ツールで流すとかもマシンの性能的な問題で不可能だったが最近は出来るようになってるし
99 ：仕様書無しさん：2006/08/13(日) 22:55:19
カバレッジテストツールとか昔はあったの？
>>94
それVol3はテストツールメーカのカタログと化しているんで買う価値ないぞ
それVol3はテストツールメーカのカタログと化しているんで買う価値ないぞ
101 ：仕様書無しさん：2006/08/13(日) 22:58:04
>>100
うはｗ94じゃないけどさっき買ってきたよ・・・
うはｗ94じゃないけどさっき買ってきたよ・・・
sage忘れすまんこ
「ソフトウェア・テストの技法」の第二版が出てるけど、
もう買った奴いる？
俺は立ち読みでスルーしちゃったけど。
あんまり一版と大差ないように思えたので。
もう買った奴いる？
俺は立ち読みでスルーしちゃったけど。
あんまり一版と大差ないように思えたので。
105 ：仕様書無しさん：2006/08/21(月) 00:14:34
Abbot使ったひといる？
どうでした、ＪＳＴＱＢ？
俺？ 撃沈orz
俺？ 撃沈orz
107 ：仕様書無しさん：2006/09/10(日) 23:36:03
正直思ったより難しかったね
思いつきで出版した対策本読んだのがいかんかったか
でも、じじぃの漏れ様でも経験で多分合格だな
思いつきで出版した対策本読んだのがいかんかったか
でも、じじぃの漏れ様でも経験で多分合格だな
108 ：仕様書無しさん：2006/09/11(月) 01:07:50
導入立会いにいくとＳＥが要件定義をはじめている
待機室で新機能が搭載される
コンパイルが通れば稼動中でも本番アップする
現場でエラー発覚→待機室でデバッグを繰り返す
業務終了までに直らない＆常駐系＆通信系を徹夜で直す
うちの課長が定例会議で開発問題点があればディスカッションするというから
ＳＥ（またはその指示）によるテスト工程がない事を問題提起したら
単体テストをしない無責任扱いされたよ。
来月辞めるからいいけどっ
待機室で新機能が搭載される
コンパイルが通れば稼動中でも本番アップする
現場でエラー発覚→待機室でデバッグを繰り返す
業務終了までに直らない＆常駐系＆通信系を徹夜で直す
うちの課長が定例会議で開発問題点があればディスカッションするというから
ＳＥ（またはその指示）によるテスト工程がない事を問題提起したら
単体テストをしない無責任扱いされたよ。
来月辞めるからいいけどっ
TEFのMLで釣りを始めた香具師がおるな
110 ：仕様書無しさん：2006/09/12(火) 08:12:31
>>104
買ったけど、翻訳の質が酷くないか？
買ったけど、翻訳の質が酷くないか？
>>109
消えたな。こことMLが同じだと勘違いしてるふうだったから当然か。
消えたな。こことMLが同じだと勘違いしてるふうだったから当然か。
ＪＳＴＱＢって結局いつ結果がわかるんだろう？
１ヶ月後？ ３ヵ月後？
１ヶ月後？ ３ヵ月後？
113 ：仕様書無しさん：2006/09/29(金) 10:28:18
来週くらいじゃね？！
114 ：仕様書無しさん：2006/09/30(土) 19:12:38
受験票を職場に置いてきたので、自分の受験番号がわからない。
月曜まで我慢か。
月曜まで我慢か。
116 ：仕様書無しさん：2006/10/01(日) 01:15:37
しっかりせんかい
合格してた
>>117
おめでとー
おめでとー
119 ：仕様書無しさん：2006/10/02(月) 23:03:36
おーめ＾でとーさーん
落ちてる。宮城からの電車代、20Kが無駄にorz
121 ：仕様書無しさん：2006/10/04(水) 21:13:51
再チャレンジ！！がんがれっ！！
っていっても受験代、異様に高いよね
っていっても受験代、異様に高いよね
更に高い試験も受けたことがあるから諦めているけど、
東京と大阪のみで平日なのは勘弁して欲しいかも。
交通費と有給が必要だから。
プロメトリックとかにしてくれるとうれしい。
東京と大阪のみで平日なのは勘弁して欲しいかも。
交通費と有給が必要だから。
プロメトリックとかにしてくれるとうれしい。
123 ：仕様書無しさん：2006/10/05(木) 23:40:06
択一式試験なのに、マークーシートではなかったのには正直驚いた
マークシートで自動処理すれば試験代も少しは安くなりそうだが
合格証届いた？
126 ：仕様書無しさん：2006/10/14(土) 21:49:56
北よ
なんか封もせずに送られてきたんだが。
128 ：仕様書無しさん：2006/10/14(土) 22:37:29
さすがに封はテープで貼ってたな
テープを剥がしたような跡も無い。忘れたにしてはお粗末だな。
中身って、説明文書、証書、折り曲げ防止用の厚紙の３点？
中身って、説明文書、証書、折り曲げ防止用の厚紙の３点？
130 ：仕様書無しさん：2006/10/15(日) 00:40:52
イェ～イ！！
131 ：仕様書無しさん：2006/10/15(日) 00:42:16
テストなんて適当
おれの人生も適当
俺の人生だけOKがつかない
俺の人生、テスト漏れが多い
テストするまでもなくバグだらけです
ｵﾏｲﾗ自虐ネタ大好きだなｗ
じゃあデバッグしてくれよ
作り直したほうが早いんじゃね
もう運用始めちゃったんだから作り直しは無理っぽい
俺、どうもマルチスレッドみたい
多重人格？
一応保守しとく
143 ：仕様書無しさん：2006/11/18(土) 00:28:21
みんな結合テストとかシステムテストってどうやって見積もってるの？
いつも全体の何割とかにしてるからはずしまくる。。。
いつも全体の何割とかにしてるからはずしまくる。。。
そのはずしまくった実績をためておけば
精度は上がってくるだろ？？？・
精度は上がってくるだろ？？？・
携帯電話開発の結合テストをやってるんですが、
納期に近づくほどテスト工数も項目数も膨れ上がります。
機能や顧客要求がどんどん追加されるからと言われ続けてるんですが、
これってやっぱり基本設計がおかしいのでは？
納期に近づくほどテスト工数も項目数も膨れ上がります。
機能や顧客要求がどんどん追加されるからと言われ続けてるんですが、
これってやっぱり基本設計がおかしいのでは？
>>145
俺も携帯のテストをやっているんだけど携帯電話の業界そのものがおかしいんだよ。
企画の段階で考慮もされていない機能を何も考えずに追加するのが問題。
仕様変更で同じテスト項目を何回もやる場合があるけど
設計や開発が苦労して帳尻を合わせたのがわかって同情することがよくある。
俺も携帯のテストをやっているんだけど携帯電話の業界そのものがおかしいんだよ。
企画の段階で考慮もされていない機能を何も考えずに追加するのが問題。
仕様変更で同じテスト項目を何回もやる場合があるけど
設計や開発が苦労して帳尻を合わせたのがわかって同情することがよくある。
漏れの所はコンパイラの最適化オプション変えただけで、全関数単体テストやり直し
(コンパイラが信用できないということで)なんですが、同じような事をやらされている人いますか?
(コンパイラが信用できないということで)なんですが、同じような事をやらされている人いますか?
>>148
単テやりなおしって言ってもUnit起動するだけだろ？
単テやりなおしって言ってもUnit起動するだけだろ？
コンパイラの最適化オプションではなく、組織の最適化をすべきだったり
>>148
コンパイラのオプション変えたんなら普通だろ。
逆にテストをやらなくていいって発想の方が漏れにはわからん。
つうかプロジェクト途中でコンパイラのオプションを変える必要が発生したほうを問題視すべきじゃないか？
コンパイラのオプション変えたんなら普通だろ。
逆にテストをやらなくていいって発想の方が漏れにはわからん。
つうかプロジェクト途中でコンパイラのオプションを変える必要が発生したほうを問題視すべきじゃないか？
単体テストと書いてしまいましたが,
関数毎にデバッガのステップ実行で分岐網羅を行い,
デバッガの画面キャプチャを証拠として残す、という事をやってます。
これも普通でしょうか?
関数毎にデバッガのステップ実行で分岐網羅を行い,
デバッガの画面キャプチャを証拠として残す、という事をやってます。
これも普通でしょうか?
>>152
化石がいっぱいある所ではまだ主流らしいな
化石がいっぱいある所ではまだ主流らしいな
カバレッジ分析ツール使うと楽なんだがなぁ。ないと激しくきつそうだ。
コストが安いならやるべき、と言いたいのだが…
コストが安いならやるべき、と言いたいのだが…
テストを知れば知るほど、コーダに戻るのが怖くなってくるな～
テスト技法やツールを知れば知るほど、今まで経験したプロジェクトは
本当に大丈夫だったのかって思う
本当に大丈夫だったのかって思う
「バッチ系のテスト・運用ツールの簡単な作成技法」を思いついたのですが、
どなたか、開発環境の提供と作業をお手伝いをしてくれる大学の研究室、または、企業はありませんか？
基本的には、環境さえ整えば、色々なＯＳで実現可能かと思います。
但し、あくまでも、技法ですので実行形式等の提供はありません。
以下の条件で実行可能です。
（１）制御言語が使える（例：sh）
（２）コンパイラー環境（例：COBOL）があり、ソースを自由に作成する事が可能
（３）上記コンパイラーでバッチコンパイル＆実行が可能
※私が使い慣れた環境は、
OS=UNIX
制御言語=sh
コンパイラー=COBOL
です。
本当は、論文か何かで広めたら良いのかも知れませんが、色々と制約があり諦めました・・・
どなたか、開発環境の提供と作業をお手伝いをしてくれる大学の研究室、または、企業はありませんか？
基本的には、環境さえ整えば、色々なＯＳで実現可能かと思います。
但し、あくまでも、技法ですので実行形式等の提供はありません。
以下の条件で実行可能です。
（１）制御言語が使える（例：sh）
（２）コンパイラー環境（例：COBOL）があり、ソースを自由に作成する事が可能
（３）上記コンパイラーでバッチコンパイル＆実行が可能
※私が使い慣れた環境は、
OS=UNIX
制御言語=sh
コンパイラー=COBOL
です。
本当は、論文か何かで広めたら良いのかも知れませんが、色々と制約があり諦めました・・・
>>157
つ VMWare
つ VMWare
その技法が既知でないか調査はしてるわけだよね、英論文も含めて。
あとは、特許をとれそうであるならば、その希望する扱い次第で大学か企業か個人か絞り込まれてくる。
あとは、特許をとれそうであるならば、その希望する扱い次第で大学か企業か個人か絞り込まれてくる。
>>159
うーん。特許は難しいかもね・・・
考え方だけだし・・・
他人のフンドシをちょっと借りる必要あるし・・・
実行形式の提供ないし・・・
でも、結構便利なので、広められたらいいなと思ってる・・・
うーん。特許は難しいかもね・・・
考え方だけだし・・・
他人のフンドシをちょっと借りる必要あるし・・・
実行形式の提供ないし・・・
でも、結構便利なので、広められたらいいなと思ってる・・・
>>160
うん。もういいよ。別スレ立ててやって
うん。もういいよ。別スレ立ててやって
小さな会社だからテストは不要、みたいな考えの管理職が多い気がする
そろそろ二回目のＪＳＴＱＢなわけだが
ＪＳＴＱＢ 受験している人いるの？
167 ：仕様書無しさん：2007/02/11(日) 09:18:57
ノシ
ソフトウェアテストを体系的に学習したいって人に
とっては、有意義だと思う。
ただ、受験料\21,000に見合うかどうかはその人次第。
ソフトウェアテストを体系的に学習したいって人に
とっては、有意義だと思う。
ただ、受験料\21,000に見合うかどうかはその人次第。
報告書に「プログラマの質が悪いために××機能で異常な動作をするケースがあり、要注視」と懸念事項を書いたら
プログラマたちの所属する会社からクレームを受けますた。
プログラマたちの所属する会社からクレームを受けますた。
>>170
ごめん、そんな低レベルな管理方法試した事無いから
ごめん、そんな低レベルな管理方法試した事無いから
あー鬼太郎になりたい…
バグが出て、ハードコピーを付け、バグの再現手順方法まで細かく書いてるのに、再現しませんとバグジラに回答してくる性格の悪いプログラマ、マジでイラン。
明日彼のクビが切られるからいいけど。。。
明日彼のクビが切られるからいいけど。。。
175 ：仕様書無しさん：2007/02/14(水) 23:56:33
俺の場合自分が作ったソフトで発生したバグはこっそり
修正してバグが無かった事にしてる。
他人が作った部分で発覚したバグは、親の仇の様に捲くし立てる。
ストレス解消ですよ＾＾；
修正してバグが無かった事にしてる。
他人が作った部分で発覚したバグは、親の仇の様に捲くし立てる。
ストレス解消ですよ＾＾；
176 ：仕様書無しさん：2007/02/15(木) 00:06:42
哀れなやつ
なんかひどいスレだな。
春だからな・・・なんでこんなトコ来るか知らんが
179 ：175：2007/02/15(木) 01:56:56
ストレス解消ですよ。
すっきりーしないとね。
もわぁっとしてたらダメでやんす。
すっきりーしないとね。
もわぁっとしてたらダメでやんす。
180 ：仕様書無しさん：2007/02/15(木) 07:05:59
まあ、テスト結果全部嘘なんだけどなｗ
だってテスト項目作るのからいって半端じゃねぇし。
そもそもテスト項目いくつに付き、いくつバグが必要ってのもわけわからんし。
こういうの大量に作らなきゃいけないってところから作業を定量化するには機械的にバグ数決めたほうが作るの楽なんだよねｗ
大手の上の人間が何考えてるのか知らないけど、
俺は本音をいうとテスト結果は嘘情報しか挙げたことない。
他の奴のもみんなまじめにやってるのかと思ってチェックしてみたけどみんな嘘ばっかりｗ
だってテスト項目作るのからいって半端じゃねぇし。
そもそもテスト項目いくつに付き、いくつバグが必要ってのもわけわからんし。
こういうの大量に作らなきゃいけないってところから作業を定量化するには機械的にバグ数決めたほうが作るの楽なんだよねｗ
大手の上の人間が何考えてるのか知らないけど、
俺は本音をいうとテスト結果は嘘情報しか挙げたことない。
他の奴のもみんなまじめにやってるのかと思ってチェックしてみたけどみんな嘘ばっかりｗ
>>180
まぁお前の人生自体が嘘だらけだからなw
まぁお前の人生自体が嘘だらけだからなw
182 ：田崎：2007/02/15(木) 21:46:55
私もテスト結果偽装してるよ。
伊達に目立ち情報をバックレタ女じゃないよぉｗ
伊達に目立ち情報をバックレタ女じゃないよぉｗ
183 ：仕様書無しさん：2007/03/22(木) 23:36:43
ほしゅ
保守必要だったか？いらないだろこのスレ
185 ：仕様書無しさん：2007/06/03(日) 20:39:55
単調ですか？
186 ：仕様書無しさん：2007/06/03(日) 20:56:09
昔のシステムエンジニアです。
銀行、今問題の官公庁、ト○タの経理システム作っていた。
本当か、テスト結果偽装なんて
まったく最近のやつらテストもまともにやらないから
ANNみたいな大規模なミスするんだな
銀行、今問題の官公庁、ト○タの経理システム作っていた。
本当か、テスト結果偽装なんて
まったく最近のやつらテストもまともにやらないから
ANNみたいな大規模なミスするんだな
ANNって何？
テスト結果を偽装する理由は求められているテスト結果がバカげてるから
真面目にやると不具合でないから、テストちゃんとやってる感のある不具合を捏造する
エラーログ出力時の関数番号が間違ってたとか
真面目にやると不具合でないから、テストちゃんとやってる感のある不具合を捏造する
エラーログ出力時の関数番号が間違ってたとか
ttp://www.asahi.com/life/update/0610/TKY200706100085.html
年金オンラインシステムが一時ダウン 社保事務所
2007年06月10日13時17分
社会保険庁が１０日に日曜日としては初めて実施した社会保険事務所窓口での年金相談で、
全国３０９の社会保険事務所のうち、神奈川、兵庫、福岡、沖縄などの１３０事務所と
東京都の社会保険業務センターで、年金記録確認のオンラインシステム端末が作動しなくなり、
開始時間の午前９時半から１１時ごろまで相談に対応できなくなった。
くわしい原因は調査中だが、初めて日曜日にシステムを立ち上げたことで社会保険業務センター内にある
システムのホストコンピューターの一部に不具合が発生したとみられる。
年金オンラインシステムが一時ダウン 社保事務所
2007年06月10日13時17分
社会保険庁が１０日に日曜日としては初めて実施した社会保険事務所窓口での年金相談で、
全国３０９の社会保険事務所のうち、神奈川、兵庫、福岡、沖縄などの１３０事務所と
東京都の社会保険業務センターで、年金記録確認のオンラインシステム端末が作動しなくなり、
開始時間の午前９時半から１１時ごろまで相談に対応できなくなった。
くわしい原因は調査中だが、初めて日曜日にシステムを立ち上げたことで社会保険業務センター内にある
システムのホストコンピューターの一部に不具合が発生したとみられる。
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
大手はQAチーム作って結構失敗してるみたいだなｗ
ペアテストで、テスト工数削減＆効率アップだぜー
ノーテストで、テスト工数激減＆デスマ率アップだぜー
デスマだから、ノーテストになるのであって、
ノーテストだからデスマになるんじゃない、
PGは、みんな、まともなテスト期間が欲しいと思ってるのよ。
ノーテストだからデスマになるんじゃない、
PGは、みんな、まともなテスト期間が欲しいと思ってるのよ。
198 ：仕様書無しさん：2007/12/01(土) 23:50:49
あげ
JUNITとか使うと開発工数2倍に膨らんだりする?
実際のプロジェクトで有効に使ってるやついるの?
実際のプロジェクトで有効に使ってるやついるの?
JUnit使わない方が工数かかるだろ。
というか、まだJUnit使ってない所があるのかよ・・・
というか、まだJUnit使ってない所があるのかよ・・・
JUnitのTestCaseとExcelのテスト仕様書の同期を取るのがめんどいんだけど，
何か良いツール無い？
アノテーションとかにテスト内容記述したりしてさ．
無いなら自分で作れ，とか言わないでね(はぁと
何か良いツール無い？
アノテーションとかにテスト内容記述したりしてさ．
無いなら自分で作れ，とか言わないでね(はぁと
>>201
TestLinkってのがあるみたいね、使った事無いけど
TestLinkってのがあるみたいね、使った事無いけど
203 ：仕様書無しさん：2007/12/02(日) 16:00:27
スクウェア･エニックスに入社して、ファイナルファンタジーXIのスタッフにしてもらえれば
仕様設計・・・1割
仕様検討・・・0.85割
コーディング・・・8割
テスト・・・0.15割
で仕事できるよ
仕様設計・・・1割
仕様検討・・・0.85割
コーディング・・・8割
テスト・・・0.15割
で仕事できるよ
テスト関連スレで単体・結合分けないってどんだけだよ
>203
本当か？、テレビで見たけど
福岡の外注に作らせていたぞ（ドラクエだったかな？）
本当か？、テレビで見たけど
福岡の外注に作らせていたぞ（ドラクエだったかな？）
206 ：仕様書無しさん：2007/12/02(日) 17:27:57
207 ：仕様書無しさん：2007/12/03(月) 01:56:16
208 ：仕様書無しさん：2008/03/05(水) 00:39:05
TestLink使ってる人いる？
209 ：仕様書無しさん：2008/03/05(水) 01:38:27
テスターよりも倖田のほうがいい。
210 ：仕様書無しさん：2008/03/05(水) 12:51:36
ゲームのテストはテスト仕様書なしのランダム試験しかしないよ
ぬるぽに数時間食われた
コード書いた奴は表出ろ
そんなので時間潰してる俺もやめちまえ
コード書いた奴は表出ろ
そんなので時間潰してる俺もやめちまえ
>>211
両方自分だったりして
両方自分だったりして
JUnitで作った単体テストってみんな仕様書に落とし込んだりしてるの？
なんか、無駄すぎる気がしてうちでは落とし込んでないんだけど。
テスターに頼むテストはテストケース作って実施してもらってるけど、
そのテストケースを管理するのがめんどくせぇ。
なんか、無駄すぎる気がしてうちでは落とし込んでないんだけど。
テスターに頼むテストはテストケース作って実施してもらってるけど、
そのテストケースを管理するのがめんどくせぇ。
214 ：仕様書無しさん：2008/05/04(日) 13:10:02
>>213
JUnit項目はjavaDoc提出したかな
ケースレビューしてケース出してskeleton+javaDoc書く。
ケース実装者に伝える意味でも使えるし。（実際は自分で書いたから思い出し用になってたな）
>そのテストケースを管理するのがめんどくせぇ。
その「管理」って何指してる？
Version管理なら色々あるし、実projectにコミット権限与えたくなければTest用Project立てればいいし。
なんとなくage
JUnit項目はjavaDoc提出したかな
ケースレビューしてケース出してskeleton+javaDoc書く。
ケース実装者に伝える意味でも使えるし。（実際は自分で書いたから思い出し用になってたな）
>そのテストケースを管理するのがめんどくせぇ。
その「管理」って何指してる？
Version管理なら色々あるし、実projectにコミット権限与えたくなければTest用Project立てればいいし。
なんとなくage
ぬるほ
ぬるほ
ぬるほ
ぬるほ
ぬるほ
ぬるほ
かっ
ぬるほ
ぬるほ
ぬるほ
219 ：仕様書無しさん：2008/12/22(月) 12:57:41
>>218
かっ
かっ
ぬるほ
ぬるほ
ぬるほ
遊んでくれる人いますか～＾＾ 28才 独身です。
スパムソフトのテスト乙。
ぬるぽ
ぬるぽ
ぬるぽ
224 ：仕様書無しさん：2009/06/24(水) 22:47:44
このたびシステムテスト工程のお手伝いでプロジェクトにアサインされたんですが、
なんか「タグチメソッドで何でも解決」「直交表は万能」とか、単体/結合テストレベルでは
耳にしたことのない用語が宗教的に蔓延してるんです。
「タグチメソッドは最強」とか「直交表は正義」とか。偉い先生の作った理論というのは
わかったのですが、入門書見ると製造工程の品質管理に関する理論ぽくて、ソフトウェア開発に
向いてないんじゃないかと一人疑問を抱いてます。
なんか機械的に作られた表に従ってテスト項目作ってるけど、傍目にも足りなく見えるし。
これって本当に大丈夫？
なんか「タグチメソッドで何でも解決」「直交表は万能」とか、単体/結合テストレベルでは
耳にしたことのない用語が宗教的に蔓延してるんです。
「タグチメソッドは最強」とか「直交表は正義」とか。偉い先生の作った理論というのは
わかったのですが、入門書見ると製造工程の品質管理に関する理論ぽくて、ソフトウェア開発に
向いてないんじゃないかと一人疑問を抱いてます。
なんか機械的に作られた表に従ってテスト項目作ってるけど、傍目にも足りなく見えるし。
これって本当に大丈夫？
>タグチメソッド
>直交表
アウトー！！
>直交表
アウトー！！
タグチメソッドは知らないけど、直交表は有効だよ。
どこで何を調べて使えないと思ったのかわからないけど、ソフトウェアテストの文脈で
使われる直交表を調べる必要があると思うよ。
簡単に言うと、組み合わせ爆発するようなテストで、効率よく（漏れが全くないという
意味ではない）テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ？
どこで何を調べて使えないと思ったのかわからないけど、ソフトウェアテストの文脈で
使われる直交表を調べる必要があると思うよ。
簡単に言うと、組み合わせ爆発するようなテストで、効率よく（漏れが全くないという
意味ではない）テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ？
ためになったねぇ～
夫とはレスだし、もっとドキドキする瞬間がほしぃttp://hi-meetinng.com/shokaijo/
直交表でテストパターンを選ぶと，何がうれしいんだい？
いままでのテスト方法とどんな差があるのか説明してみろ．
いままでのテスト方法とどんな差があるのか説明してみろ．
231 ：仕様書無しさん：2009/08/06(木) 05:00:26
test test
>>230
簡単に言うと、組み合わせ爆発するようなテストで、効率よく（漏れが全くないという
意味ではない）テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ？
簡単に言うと、組み合わせ爆発するようなテストで、効率よく（漏れが全くないという
意味ではない）テストをするための組み合わせを導き出すもの。
何十億通りものテストはしたくないしできないでしょ？
>232
なんだ。今までのテストとおなじじゃん。
なんだ。今までのテストとおなじじゃん。
>232
タグチであたまのいかれたソフトテスト椰子がつくったあほらしー手法。
タグチであたまのいかれたソフトテスト椰子がつくったあほらしー手法。
235 ：仕様書無しさん：2009/08/09(日) 22:30:27
>232
直交表で選ばれるテスト条件に都合よくバグがあるというお花畑理論が、あいかわらず痛々しい。
直交表で選ばれるテスト条件に都合よくバグがあるというお花畑理論が、あいかわらず痛々しい。
236 ：仕様書無しさん：2009/08/09(日) 23:19:07
なにこいつｗ
いつまで絡む気だよｗ
いつまで絡む気だよｗ
とりあえず、絶対にバグが起こってはいけない組み合わせだけで良くない？
俺も詳しいわけではないので、間違いがあったら済まんが、だいたい以下の通りらしい。
・単純に全組み合わせを試した場合、組み合わせ爆発ももちろんのこと、重複するテストがガンガンに行われるため、
非常に効率が悪い。
・統計学的にみて、複数機能組み合わせによるバグの内、「機能２つの組み合わせ」によるバグは、全体の８割以上である。
・直交表は数学的アプローチにより、「機能２つの組み合わせ」テストを100％満たしつつ、３つ以上の組み合わせテストも
大半を満たすことが出来、かつ重複を最小限に押さえた組み合わせ表を得ることが出来る。
・ただし、禁則(あり得ない組み合わせ)とかまでを考慮に入れたカバーが出来るわけではない。実際のテスト項目書作成
に当たってはその辺のノウハウが重要で、それだけで本が２，３冊かけるほど。
わからんまま流行だからと導入しても痛い目を見るので、素人にはお勧めできない。
……と言うことらしい。
＃詳しくは詳しい本に当たってくれ。
・単純に全組み合わせを試した場合、組み合わせ爆発ももちろんのこと、重複するテストがガンガンに行われるため、
非常に効率が悪い。
・統計学的にみて、複数機能組み合わせによるバグの内、「機能２つの組み合わせ」によるバグは、全体の８割以上である。
・直交表は数学的アプローチにより、「機能２つの組み合わせ」テストを100％満たしつつ、３つ以上の組み合わせテストも
大半を満たすことが出来、かつ重複を最小限に押さえた組み合わせ表を得ることが出来る。
・ただし、禁則(あり得ない組み合わせ)とかまでを考慮に入れたカバーが出来るわけではない。実際のテスト項目書作成
に当たってはその辺のノウハウが重要で、それだけで本が２，３冊かけるほど。
わからんまま流行だからと導入しても痛い目を見るので、素人にはお勧めできない。
……と言うことらしい。
＃詳しくは詳しい本に当たってくれ。
>>235
んじゃ、100億通りのマニュアルテストでもやっとけ、猿
んじゃ、100億通りのマニュアルテストでもやっとけ、猿
>239
↑馬鹿か！そういう単細胞がタグチの餌食
↑馬鹿か！そういう単細胞がタグチの餌食
永遠に、俺メソッドでガラパゴって下さい
一生懸命disってる奴の目的が分からん。
243 ：仕様書無しさん：2009/08/13(木) 22:49:32
>238
ありがとう。
>242
disってるって、馬鹿にしているという意味か？おかしな言葉やめようよ。240のいうとおり、
数学が苦手でも、ある一定の手順で答えが導けた気がする田口メソッド一派に取り込まれて
気がついたら自分も田口メソッド使いの端くれになって、でも田口メソッドの真髄は理解
できないまま、線点表みたいな直交表を変形させるヒューリスティックをいじくって初学者
を馬鹿にしまくって、田口メソッドで問題が解けませんと言われたら、お前に技術がない
からだとふんぞり返って、人を小ばかにして去っていく連中を非難して排除して何が悪い。
まさに238のいう素人にはお勧めできない、だからタグチストの俺様が解いてしんぜようという
ことが平気で起きる。直交表なんて簡単に作れるのにね。
>239
おまえ、自動テストのこといってる？直交表=自動テストぢゃないぞ。
238のいってる２つの組み合わせで８割うんぬんは、ある文献の一部をつまんだもの。
その先を読んだら、そんなに都合がよければ苦労はないとちゃんと書いてある。
ありがとう。
>242
disってるって、馬鹿にしているという意味か？おかしな言葉やめようよ。240のいうとおり、
数学が苦手でも、ある一定の手順で答えが導けた気がする田口メソッド一派に取り込まれて
気がついたら自分も田口メソッド使いの端くれになって、でも田口メソッドの真髄は理解
できないまま、線点表みたいな直交表を変形させるヒューリスティックをいじくって初学者
を馬鹿にしまくって、田口メソッドで問題が解けませんと言われたら、お前に技術がない
からだとふんぞり返って、人を小ばかにして去っていく連中を非難して排除して何が悪い。
まさに238のいう素人にはお勧めできない、だからタグチストの俺様が解いてしんぜようという
ことが平気で起きる。直交表なんて簡単に作れるのにね。
>239
おまえ、自動テストのこといってる？直交表=自動テストぢゃないぞ。
238のいってる２つの組み合わせで８割うんぬんは、ある文献の一部をつまんだもの。
その先を読んだら、そんなに都合がよければ苦労はないとちゃんと書いてある。
>>243
disってますねｗ
disってますねｗ
245 ：仕様書無しさん：2009/08/14(金) 05:28:33
実際のところ、『誰でも理解可能で効率の良い(≠完全網羅)』システムテストの項目作成なんて無いからねえ。
小規模なものならいざしらず、オープン系で複数拠点、多重化でバッチ処理で24h365day～とかなると泣ける。
小規模なものならいざしらず、オープン系で複数拠点、多重化でバッチ処理で24h365day～とかなると泣ける。
disrespectか
disという語自体は否定の接頭辞で特に意味はないんだが
作者も読者も頭の悪さが滲み出てるな
まあそのうちよろしく頼むわ、先輩
disという語自体は否定の接頭辞で特に意味はないんだが
作者も読者も頭の悪さが滲み出てるな
まあそのうちよろしく頼むわ、先輩
なんだそのナメた態度は
ぶっ数すぞ
ぶっ数すぞ
ぶっすうすぞ？
ぶっかずすぞ？
あたまわるそう
ぶっかずすぞ？
あたまわるそう
>>248
マジレスｗｗｗｗ
マジレスｗｗｗｗ
>249
ねたにマジレス
ねたにマジレス
なんか湧いてんな、一般的な知識足りない辺り院生か？
>まあそのうちよろしく頼むわ、先輩
まあそのうち現実思い知るよ
>まあそのうちよろしく頼むわ、先輩
まあそのうち現実思い知るよ
なんの現実かはあんまり考えたくないな
253 ：仕様書無しさん：2009/08/19(水) 08:01:11
何についてもそうだけど、『作りました、お仕舞い』では済まないというのは、知識は兎も角現実として認識するまで結構かかったかな。
卒後しばらくは指示通りやる操り人形だし、上流下流まで目が届くようになってはじめて意識したような。
卒後しばらくは指示通りやる操り人形だし、上流下流まで目が届くようになってはじめて意識したような。
254 ：仕様書無しさん：2009/08/26(水) 07:53:15
学校レベルでできる人ほどテストをおざなりにしがち
学校レベルでできない人のテストほど信頼できないものはない
自分のテストほど信頼できないものはない
といってツールが信頼できるわけでもない
永遠にTメソッドでガラパゴってHAYST法つくったぉ（w）。直交表も悪くは
ねぇべぇ、でも、タグチが提案した手法のうわっつらをチマチマいじって、
タグチではないような顔で売りまくろうとする魂胆が今一つわからん。
どこをどういじったか、素直に説明すりゃいいじゃん。＞何もないってか？
それと、ソフトウェアテストはあくまで後追いのもの、どんなテスト手法も
完全ではない。網羅率の背比べは意味なさげと思うがどんなもんだろなぁ。
ねぇべぇ、でも、タグチが提案した手法のうわっつらをチマチマいじって、
タグチではないような顔で売りまくろうとする魂胆が今一つわからん。
どこをどういじったか、素直に説明すりゃいいじゃん。＞何もないってか？
それと、ソフトウェアテストはあくまで後追いのもの、どんなテスト手法も
完全ではない。網羅率の背比べは意味なさげと思うがどんなもんだろなぁ。
aa
日本規格協会「標準化と品質管理」誌１２月号「読むだけでわかる品質工学」（著者：長谷部光雄）の
中の「直交表によるソフトウェア検査」の提灯持ちは無責任。コーディング経験もろくにないのに。
この日本発ソフトウェアテスト技法は結局タグチメソッド崩れ。どんなに愚劣なものかよくわかった。
中の「直交表によるソフトウェア検査」の提灯持ちは無責任。コーディング経験もろくにないのに。
この日本発ソフトウェアテスト技法は結局タグチメソッド崩れ。どんなに愚劣なものかよくわかった。
いや、だから君が100万通りのマニュアルテストを誰も止めないって
〆切内に終わらせる限り、と注釈がつくｗ
そもそも、コーディング段階でバグがあるのはソフトウェアの基本機能からはずれてる、と思うが
そうですか
掛け合い漫才になったが、>>260 「標準化と品質管理」誌の提灯持ちがひどいから、世間のために補足。
ソフトは本来ねらい通りに動くのが特徴で、これを大きな利点として、まず、十分に活用しない手はない。
最終テストよりも前に、コーディング段階で徹底的な動作確認を１つ１つ積み重ねていくことが重要。
ハードのものづくりは最初からばらつきに悩まされてねらい通りのものが簡単にはできない。タグチも、
統計手法も、基本の目的はハードの仕上がり管理だから、ソフトに持ち込むと見当はずれになりがち。
ソフトは本来ねらい通りに動くのが特徴で、これを大きな利点として、まず、十分に活用しない手はない。
最終テストよりも前に、コーディング段階で徹底的な動作確認を１つ１つ積み重ねていくことが重要。
ハードのものづくりは最初からばらつきに悩まされてねらい通りのものが簡単にはできない。タグチも、
統計手法も、基本の目的はハードの仕上がり管理だから、ソフトに持ち込むと見当はずれになりがち。
具体的に書けよクズ
>>266 ん？、そうだなぁ・・・
ソフトは仕上がったらそのまま動くよう１行１行を確認しながら作るのが基本。
ハードはばらつきを避けられず仕上がりが成り行きになるから統計手法が必要。
直交表は一般平均と主効果とだけが存在すると仮定して実験数を節約するが、
仮定が成り立つかどうかソフトの場合でもハードの場合でも予知はできない。
ソフトは仕上がったらそのまま動くよう１行１行を確認しながら作るのが基本。
ハードはばらつきを避けられず仕上がりが成り行きになるから統計手法が必要。
直交表は一般平均と主効果とだけが存在すると仮定して実験数を節約するが、
仮定が成り立つかどうかソフトの場合でもハードの場合でも予知はできない。
あー、何となくだけどいいたいことわかるわ
よく分からんのだが、どんな場合にそんな100万通りもの組み合わせテストが必要な状況があるんだろか？
具体的な例が知りたいなぁ
具体的な例が知りたいなぁ
>>269
例えば、
OS,SPの組み合わせ = 10
ブラウザの種類とそれぞれのバージョン = 15
ユーザ権限 = 2
プリンタの種類 = 15
機能の数 = 20
テストシナリオ = 20
全部の組み合わせは、10×15×2×15×20×20 = 180万
みたいな感じで、ハード・基盤ソフト・機能の組み合わせを網羅させると、簡単に100万超えるよ。
例えば、
OS,SPの組み合わせ = 10
ブラウザの種類とそれぞれのバージョン = 15
ユーザ権限 = 2
プリンタの種類 = 15
機能の数 = 20
テストシナリオ = 20
全部の組み合わせは、10×15×2×15×20×20 = 180万
みたいな感じで、ハード・基盤ソフト・機能の組み合わせを網羅させると、簡単に100万超えるよ。
ソフトによっては、ファイルシステムの種類とか、アロケーションユニットサイズの種類とか、
インストールされているアンチウィルスの種類とか、組み合わせが爆発する因子はそこここにあるでしょ。
インストールされているアンチウィルスの種類とか、組み合わせが爆発する因子はそこここにあるでしょ。
>>270
数はさておいて「全部をこなさなければならない状況」を聞きたいんじゃ無かろうかと。
コンシューマとは状況が異なるけども、たとえば医療機器、原子力関連と言った、肝心なときに
ハングアップしたらたまらない装置なんかだと、可能な限りのパターンを尽くすとは聞くね。
どんなことやってるのか想像もつかないけど、軍事とか航空宇宙関連もそのはず。
数はさておいて「全部をこなさなければならない状況」を聞きたいんじゃ無かろうかと。
コンシューマとは状況が異なるけども、たとえば医療機器、原子力関連と言った、肝心なときに
ハングアップしたらたまらない装置なんかだと、可能な限りのパターンを尽くすとは聞くね。
どんなことやってるのか想像もつかないけど、軍事とか航空宇宙関連もそのはず。
>>272
どんなに組み合わせが多かろうと、全部やらなきゃならないんだったら、テスト手法はいらないよね。
どんなに組み合わせが多かろうと、全部やらなきゃならないんだったら、テスト手法はいらないよね。
>>267
「標準化と品質管理」のどこがどう違ってるのか指摘しないと、さっぱり意味不明なんだが。
「標準化と品質管理」のどこがどう違ってるのか指摘しないと、さっぱり意味不明なんだが。
>>274
ハード製品の検査で実験数を直交表で節約する話のついでにソフトの検査でも条件数を節約できると
著者（この場合、長谷部光雄氏）は言ってるが見当はずれだし楽観的過ぎると思う >>260 263 265 267
品質工学系の著者は、長谷部氏とかぎらず、品質工学ありき、タグチありき、で、読者にまかせるという
ことがなく、規格協会なんかの旗印を錦の御旗に、とにかく強引に押し付けてくるのがかなわぬ。
ハード製品の検査で実験数を直交表で節約する話のついでにソフトの検査でも条件数を節約できると
著者（この場合、長谷部光雄氏）は言ってるが見当はずれだし楽観的過ぎると思う >>260 263 265 267
品質工学系の著者は、長谷部氏とかぎらず、品質工学ありき、タグチありき、で、読者にまかせるという
ことがなく、規格協会なんかの旗印を錦の御旗に、とにかく強引に押し付けてくるのがかなわぬ。
いやだからお前が100万通りのマニュアルテストをしても、誰も止めないったら
品質保証って、デバッグじゃないんだけど
>>276 100万回を直交表で減らすか、ほかの方法で減らすか、いろいろあるはずだから
>>277 長谷部氏はデバッグを言ってるが、デバッグではない品質保証となると、直交表も使えるかも
しれない。でも、直交表だけにしばられ過ぎる必要はないと思う
>>275 もともと「読むだけでわかる品質工学」という連載、素人を唸ならせて信者にしたくて、
粗雑、日本発の管理技術としてhaystなんかを売りまくろうという浅薄な根性と根は同じ
>>277 長谷部氏はデバッグを言ってるが、デバッグではない品質保証となると、直交表も使えるかも
しれない。でも、直交表だけにしばられ過ぎる必要はないと思う
>>275 もともと「読むだけでわかる品質工学」という連載、素人を唸ならせて信者にしたくて、
粗雑、日本発の管理技術としてhaystなんかを売りまくろうという浅薄な根性と根は同じ
なんだ私怨か
>>278 は誰も恨んでないから、私怨はなかろ
最近xUnitを使い始めたが、テストが大変になった
上手いやり方って、しらないか？
俺は、メソッド毎にテストをしているが、シナリオベースでやった方がいいのか？
メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
教えてくれ
上手いやり方って、しらないか？
俺は、メソッド毎にテストをしているが、シナリオベースでやった方がいいのか？
メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
教えてくれ
初期化が大変でも個別にやっといた方が後で楽になるような？
テストが簡単になるように、メソッドを設計・実装すればいい。
凝集度を上げ、結合度を下げる。
凝集度を上げ、結合度を下げる。
複数のメソッドを動かしている呼び元みたいな所をテストする
シナリオ(?)の単位が分からないが、そーゆーことかも
まぁそんなテストはもう"単体テスト"じゃないんだが
シナリオ(?)の単位が分からないが、そーゆーことかも
まぁそんなテストはもう"単体テスト"じゃないんだが
シナリオと聞いてピンと来ないような人のレスは希望していません
工数膨大にしないと金が貰えないからな。
試験を請け負ってる会社はみんなおんなじ。
工数を爆発させて人足をたくさんいれて、その分予算も引っ張る。
試験を請け負ってる会社はみんなおんなじ。
工数を爆発させて人足をたくさんいれて、その分予算も引っ張る。
>>282
その話は、よく聞くが後からそんなにテストするか？
クラスを継承で拡張していけば、そんなにテストすることもないと思うが
>>283
>テストが簡単になるように、メソッドを設計・実装すればいい。
TDDのやり方だと思うが、その考えは良いのか？
俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが
それに、自分が作っていない標準ライブラリの初期化とかが結構大変
>>286
金額関係なしに、工数を減らしたいんだが
その話は、よく聞くが後からそんなにテストするか？
クラスを継承で拡張していけば、そんなにテストすることもないと思うが
>>283
>テストが簡単になるように、メソッドを設計・実装すればいい。
TDDのやり方だと思うが、その考えは良いのか？
俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが
それに、自分が作っていない標準ライブラリの初期化とかが結構大変
>>286
金額関係なしに、工数を減らしたいんだが
>>287
>それに、自分が作っていない標準ライブラリの初期化とかが結構大変
ほとんどのOSSはunitのサポートしてないか？
ライブラリ初期化が嫌ならモック作れば？
>金額関係なしに、工数を減らしたいんだが
xUnit導入で品質上げたいんじゃないのか？開発工数を減らしたいのか？
品質あげて工数減らすっていい考えだなｗ
>それに、自分が作っていない標準ライブラリの初期化とかが結構大変
ほとんどのOSSはunitのサポートしてないか？
ライブラリ初期化が嫌ならモック作れば？
>金額関係なしに、工数を減らしたいんだが
xUnit導入で品質上げたいんじゃないのか？開発工数を減らしたいのか？
品質あげて工数減らすっていい考えだなｗ
>>288
> 品質あげて工数減らすっていい考えだなｗ
開発手法にしろテスト手法にしろ、品質の向上と工数の削減が主な目的でしょ。
手戻りの発生を最小限に抑える(リリース後バグ発覚も含め)意味で。
(開発環境付属の)標準ライブラリの検証ってどの辺までやる？
そこでバグ埋められたら洒落にならんけども、過去何度か実例がある。
> 品質あげて工数減らすっていい考えだなｗ
開発手法にしろテスト手法にしろ、品質の向上と工数の削減が主な目的でしょ。
手戻りの発生を最小限に抑える(リリース後バグ発覚も含め)意味で。
(開発環境付属の)標準ライブラリの検証ってどの辺までやる？
そこでバグ埋められたら洒落にならんけども、過去何度か実例がある。
>>288
>ライブラリ初期化が嫌ならモック作れば？
その方が工数は増えると思うが、どんなんだ？
>xUnit導入で品質上げたいんじゃないのか？開発工数を減らしたいのか？
xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問？
>品質あげて工数減らすっていい考えだなｗ
品質を下げて工数を減らしたいとは思わない、品質は同程度以上で工数を減らしたい
>>289
>(開発環境付属の)標準ライブラリの検証ってどの辺までやる？
基本行わない、プロジェクト内で作った標準のライブラリすら行わない
自分担当の部分だけをテストする、もちろん影響があれば、調査するが
俺の既存方法の単体テストは、プログラムをステップ実行で動かして
変数に値が設定されている事や、別メソッドが呼ばれている事を確認しながら
カバレッジ（条件網羅）が１００％になるまで行う（もちろん、限界値なども行う）
あと、カバレッジ１００％にする為に、、値をデバッグで変更してでも行っている
典型的なホワイトボックステストだが、それに比べて
xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか？
>ライブラリ初期化が嫌ならモック作れば？
その方が工数は増えると思うが、どんなんだ？
>xUnit導入で品質上げたいんじゃないのか？開発工数を減らしたいのか？
xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問？
>品質あげて工数減らすっていい考えだなｗ
品質を下げて工数を減らしたいとは思わない、品質は同程度以上で工数を減らしたい
>>289
>(開発環境付属の)標準ライブラリの検証ってどの辺までやる？
基本行わない、プロジェクト内で作った標準のライブラリすら行わない
自分担当の部分だけをテストする、もちろん影響があれば、調査するが
俺の既存方法の単体テストは、プログラムをステップ実行で動かして
変数に値が設定されている事や、別メソッドが呼ばれている事を確認しながら
カバレッジ（条件網羅）が１００％になるまで行う（もちろん、限界値なども行う）
あと、カバレッジ１００％にする為に、、値をデバッグで変更してでも行っている
典型的なホワイトボックステストだが、それに比べて
xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか？
うぜーよ
聞く耳持たないんだったら、自分のやり方で今後も行け馬鹿
聞く耳持たないんだったら、自分のやり方で今後も行け馬鹿
292 ：仕様書無しさん：2009/11/30(月) 00:10:58
>>287
そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。
>俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
>あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが
OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。
>>290
> その方が工数は増えると思うが、どんなんだ？
増えない。
> xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
> 勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問？
繰り返し出来ると言うことは、ありがちな「知らない間にデグレードしてた」とか「この修正が
思わぬ所に影響してた」なんてことがなくなるよ。
> xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか？
xUnitはホワイトボックステスト。普通はステップ実行しないよ。
そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。
>俺的には、テストの為にクラス・メソッドの設計を変えるのは間違っていると思う
>あくまでも、オブジェクト指向のクラス設計に基づいて行うべきだと思うが
OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。
>>290
> その方が工数は増えると思うが、どんなんだ？
増えない。
> xUnit導入で品質が上がるとは思っていない、品質はテストケースしだいだから、既存の方法と同じだと思っている
> 勿論繰り返しテストが、簡単に出来るから多少は品質も上がるのかも知れないが疑問？
繰り返し出来ると言うことは、ありがちな「知らない間にデグレードしてた」とか「この修正が
思わぬ所に影響してた」なんてことがなくなるよ。
> xUnitはブラックボックステストに近い感じがするが、xUnitもステップ実行で確認するものなのか？
xUnitはホワイトボックステスト。普通はステップ実行しないよ。
ブラックボックステストにも使おうと思えば使えるけどな
OOPから設計から工数のスコープまで色々怪しすぎる
どこか一つ出来るようになってから考えろよ
どこか一つ出来るようになってから考えろよ
俺様の設計は至高の設計、と勘違いしてんだろ
他人が、自分のコードを変更したり、バグフィックスしたり、十分な時間経過の後に自分がコードを触るときに
実装内容を忘れてるなんてことを考えないのかしら。
実装内容を忘れてるなんてことを考えないのかしら。
IDEでステップ実行しながら変数の内容を調べるなんて、ド素人もいいとこじゃん。
何で本気で相手してんの、みんな。
何で本気で相手してんの、みんな。
298 ：仕様書無しさん：2009/11/30(月) 02:10:14
プロジェクトの終盤で仕様変更が入りまくる状況でテストなんて無意味。
家建ててる途中で部屋ふやせって言ってるようなもん。
家建ててる途中で部屋ふやせって言ってるようなもん。
そういうときこそ再帰テストの有無が物を言うんじゃ？
×再帰テスト
○回帰テスト
○回帰テスト
実装の継承はSTLでもjavaでも普通に行われてるのに
否定してる奴は原理主義者か何かか？w
工数を滅茶苦茶掛けてテストしてそうなところも
気になるな
時間は関係ないプロジェクトなら別にいいがw
否定してる奴は原理主義者か何かか？w
工数を滅茶苦茶掛けてテストしてそうなところも
気になるな
時間は関係ないプロジェクトなら別にいいがw
>>301
今日本10冊買って帰れアホ
今日本10冊買って帰れアホ
>>301
なぁ、お前を擁護する人間が出てこないことをどう思う？
なぁ、お前を擁護する人間が出てこないことをどう思う？
ところで281のところでは、テスト結果の妥当性確認はどのように行うのだろうか。
ステップ実行しながら動作確認をしているところを、別の担当者が見てたりして。
ステップ実行しながら動作確認をしているところを、別の担当者が見てたりして。
>>301
デザインパターンを勉強すべし。
デザインパターンを勉強すべし。
307 ：仕様書無しさん：2009/11/30(月) 18:57:43
工数を出そうが出すまいが
テスト分の工数は滅茶苦茶掛かるじゃねーかよw
アホかwww
テストまでまとまった工数掛けて
さらにデバッグ工数も普通に取るんだろ？
無能な癖に開き直ってんじゃねーよ
こっちはそんなもん導入しなくても品質くらい保てるんだよ、カス
と言っておくw
テスト分の工数は滅茶苦茶掛かるじゃねーかよw
アホかwww
テストまでまとまった工数掛けて
さらにデバッグ工数も普通に取るんだろ？
無能な癖に開き直ってんじゃねーよ
こっちはそんなもん導入しなくても品質くらい保てるんだよ、カス
と言っておくw
黙れ詐欺師w
って思ってる奴が他にもいるって事や
って思ってる奴が他にもいるって事や
テストケースとか考えないで、やってたら、泥沼だろ
>>310
雑魚プログラマ揃いの場合はそうだなw
雑魚プログラマ揃いの場合はそうだなw
結合度も凝集度も考えずに家系図的な継承しか知らなかった奴がなにをほざいても無駄
うわ、こいつ自分が雑魚じゃないって思ってるみたいだぞ。
こういう根拠のない自信を持った馬鹿が、たぶんこいつの会社のトップクラスの技術レベルなんだぜ・・・
>>307
デバッグ工数って何？
デバッグ工数って何？
今日必死こいて単体試験仕様書作ってたんだが、作ってる最中にこんなのいらなくね？って思ってきたんだけど、いらんよなこれ？ｗ
５００行ぐらいのソースに３日ぐらいかけて単体試験仕様書作って、よっこらよっこらしてんだけどｗ
ここは網羅されていない！とか上司に怒鳴られて、作り直しばっかりｗｗ
ソースを追いながら試験作れ！って言われて、デバッグしながら単体試験仕様書作ってるもんだから、実際試験したら絶対ＯＫなわけｗ
デキレースすぎる試験になんの意味あんの？ｗ
５００行ぐらいのソースに３日ぐらいかけて単体試験仕様書作って、よっこらよっこらしてんだけどｗ
ここは網羅されていない！とか上司に怒鳴られて、作り直しばっかりｗｗ
ソースを追いながら試験作れ！って言われて、デバッグしながら単体試験仕様書作ってるもんだから、実際試験したら絶対ＯＫなわけｗ
デキレースすぎる試験になんの意味あんの？ｗ
>>316
自分で勉強するつもりがないなら、素直に上司に従っとけアホ
自分で勉強するつもりがないなら、素直に上司に従っとけアホ
直交表馬鹿がいなくなったと思ったら、また香ばしい奴が登場だな
321 ：仕様書無しさん：2009/11/30(月) 22:15:15
詐欺師も何かを導入したときの成果を
給料にダイレクトに反映すれば少しはマシになるんだが
会社の金で実験君する気満々だからなw
無駄にプロジェクトを長期化する事しか考えてねぇww
給料にダイレクトに反映すれば少しはマシになるんだが
会社の金で実験君する気満々だからなw
無駄にプロジェクトを長期化する事しか考えてねぇww
>>316
ステップ実行しながら変数の内容を確認し、根拠無く「テストOKです」とか言う奴に対するおしおきでしょ。
ステップ実行しながら変数の内容を確認し、根拠無く「テストOKです」とか言う奴に対するおしおきでしょ。
学生～新人１年目(稀に２年目)あたりが考えそうだよね。自分もそうだった。
今年派遣でやって来たドアホは、試験結果報告でっち上げまでしてサボった結果、
かなり愉快なタイミングでバグ発覚→報告書偽造が発覚し、会社ごとプロジェクトからパージされた。
今年派遣でやって来たドアホは、試験結果報告でっち上げまでしてサボった結果、
かなり愉快なタイミングでバグ発覚→報告書偽造が発覚し、会社ごとプロジェクトからパージされた。
見て確認してるんだから根拠はあるだろ、アホかw
テストに無駄な工数を掛けないつもりなら
全然アリだよ、穀潰しww
テストに無駄な工数を掛けないつもりなら
全然アリだよ、穀潰しww
典型的な馬鹿上司の気分を満足させるための儀式になってるようだなw
予想通りすぎてフイタwww
予想通りすぎてフイタwww
329 ：仕様書無しさん：2009/11/30(月) 23:55:09
なんか業種の違う連中が噛み合わない話をしてるな。
テストは勿論大事だしカバレッジをパスしてないソフトが製品と呼べるのかとは思うが、最終的には機能を満足してれば中身はどうでもいいような気もする。
テストは勿論大事だしカバレッジをパスしてないソフトが製品と呼べるのかとは思うが、最終的には機能を満足してれば中身はどうでもいいような気もする。
あっち修正したら、こっちがおかしくなりましたとか、聞いたことあるけど
331 ：仕様書無しさん：2009/12/01(火) 00:10:37
333 ：仕様書無しさん：2009/12/01(火) 02:43:27
ちなみにテストケースをプロジェクトにぶちこんで
記録的大赤字な上、プロジェクト大幅遅延
結局途中からテストケースを放り出したプロジェクトを知ってるぞwww
その会社の他のプロジェクトは一つもそんな事は
してないのに壮大な爆死w
かぶれてんじゃねーよとw
まさにこのスレの連中と同じだなww
記録的大赤字な上、プロジェクト大幅遅延
結局途中からテストケースを放り出したプロジェクトを知ってるぞwww
その会社の他のプロジェクトは一つもそんな事は
してないのに壮大な爆死w
かぶれてんじゃねーよとw
まさにこのスレの連中と同じだなww
低レベルすぎる話だな
憶測で貶せるとか凄腕のエスパーだな
つーか、記録的な赤字が出せる（笑）って時点で
察しろよ、間抜けな奴だなw
察しろよ、間抜けな奴だなw
何言ってんのこのひと。病気？
>>339
だ・か・ら、テストケースが有効な局面があっても
工数から考えても微妙な話で
かぶれてるような連中がやっても失敗するし
最たる例を知ってる
と書いたわけだが？
そんな頭でプログラムが書けるのか？w
だ・か・ら、テストケースが有効な局面があっても
工数から考えても微妙な話で
かぶれてるような連中がやっても失敗するし
最たる例を知ってる
と書いたわけだが？
そんな頭でプログラムが書けるのか？w
つーか、工程を組んでテストを書かなくてすむような優秀な人間を集めた方が
余程安上がりだろうに
昔からそうだし、これからもそうだろうw
底辺コーダーを集めて開発とか
乙という他はないなw
余程安上がりだろうに
昔からそうだし、これからもそうだろうw
底辺コーダーを集めて開発とか
乙という他はないなw
場合分けができないだけか
>つーか、工程を組んでテストを書かなくてすむような優秀な人間を集めた方が
その発想は無かったな、その趣旨でマネージメント手法の論文書いてみなよ
その発想は無かったな、その趣旨でマネージメント手法の論文書いてみなよ
>>281のような疑問を持つところを見ると、どう考えてもこいつが底辺コーダーなのだが。
>>344
別人なわけだがw
別人なわけだがw
わかんないなりに考えてるじゃないの？
>>346
>>281じゃないが考えは良くわかるよ
テスト工数が余計に掛かるのは事実だし
機動力が低くなるデメリットもあるしな
マネージメントまで考えた事がないような下っ端だと
想像もしないだろうがかなり重要な話
>>281じゃないが考えは良くわかるよ
テスト工数が余計に掛かるのは事実だし
機動力が低くなるデメリットもあるしな
マネージメントまで考えた事がないような下っ端だと
想像もしないだろうがかなり重要な話
一発で完成品作れる魔法使いみたいな奴はそうそういないでしょ
>>347
はいはい、優秀な人材だけ集めて、テスト工数ゼロでやっててください。
はいはい、優秀な人材だけ集めて、テスト工数ゼロでやっててください。
表面的に一発で動いたけど、細かなバグが出たら、長期になったってこともあるし
多分こいつ、業務アプリプログラマ見習いだな。
まぁ1～3,4人くらいの優秀なプログラマが作るプロダクトなら、「テスト工数」みたいなのはいらんかもな。
んで、「プログラマの優秀さ」の証明ってどうやるんだ？
>>354
つーか、優秀というよりもプログラマもベテランになってくると、程度の差はあれど
自分で管理出来るプログラム行数が感覚的に大体わかってくる。
だから、プログラマの人数でテスト工数がいるいらないになるみたいな話ではなくて
その現場のプログラマのプログラム把握行数を越えるか
越えないかなんだよ。
当然、優秀であるほどそのリミットはうなぎ登りなので
OSレベルのソフトでもテストなしで開発出来る
という事になるし
ボンクラ揃いなら全てテストからガッチリ開発する
という事になる
つーか、優秀というよりもプログラマもベテランになってくると、程度の差はあれど
自分で管理出来るプログラム行数が感覚的に大体わかってくる。
だから、プログラマの人数でテスト工数がいるいらないになるみたいな話ではなくて
その現場のプログラマのプログラム把握行数を越えるか
越えないかなんだよ。
当然、優秀であるほどそのリミットはうなぎ登りなので
OSレベルのソフトでもテストなしで開発出来る
という事になるし
ボンクラ揃いなら全てテストからガッチリ開発する
という事になる
なるかアホ
>>355
だから、その「感覚的経験値」を、プロジェクトリーダーとかクライアントとか、
「プログラミングから離れているマネジメントの立場」にどうやって証明するんだと。
お前様の感覚の正しさは、誰がどのように（客観的に理解できる形で）証明するんだね？
だから、その「感覚的経験値」を、プロジェクトリーダーとかクライアントとか、
「プログラミングから離れているマネジメントの立場」にどうやって証明するんだと。
お前様の感覚の正しさは、誰がどのように（客観的に理解できる形で）証明するんだね？
「どうやったら試験に合格できるんですか？」
「簡単だ、全問正解すれば良い」
「では、どうあれば全問正解できるんですか？」
「私が解答すれば全問正解できる」
これと同じだね。
「簡単だ、全問正解すれば良い」
「では、どうあれば全問正解できるんですか？」
「私が解答すれば全問正解できる」
これと同じだね。
>357
複雑度とかそういう考慮は一切なしかい、ボケが。
複雑度とかそういう考慮は一切なしかい、ボケが。
一発完動教がFPROGで叩かれてたのを思い出す
現実問題、一発完動を保証できる規模ってどのくらいだろう？
障害が発生したら全損害を引っ被ります、みたいな契約条件だとして。
障害が発生したら全損害を引っ被ります、みたいな契約条件だとして。
テストした方が楽
500行のコードのテストケース抽出に三日かけてNG出されるなんてあり得ん
行数行数ってお前等・・・行数で見積りとか工数計算してないだろうな・・・
コードの行数とかCyclomatic complexityで、テスト工数はある程度見積もれるよね
職歴だけは無駄に長い、派遣テスターくさいな
一桁のかけ算を暗算できるからと言って、5桁同士のかけ算は暗算できないがごとし
つーか、必要必要って騒いでるのって
底辺テスト専門会社の連中なんじゃねーかとオモタww
底辺テスト専門会社の連中なんじゃねーかとオモタww
なんでこの人こんな所でファビョってんの？
単純なバグ出してテストすらしてないのかボケと顧客に怒鳴られたんだよ
土日は誰も書き込しなかったのに、凄い事になっているな
>>292
>そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
>「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。
多態性をインタフェース実現とか、機能追加をコンポジションかDecoratorパターンを使うと言う事か？
継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
Bridgeパターンとかは継承の為のパターンだが？
>OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
>依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。
それは分かるが、xUnitの為にTDD(テスト駆動開発入門)を読んだけど
あのクラス・メソッド設計は本当に正しのか分からない
>xUnitはホワイトボックステスト。普通はステップ実行しないよ。
なんと言えば良いのか？、ホワイトボックステストだとも思うが
xUnitのテストは入力値を設定して、実行後の値を確認するだけだから
なにかブラックボックステストに似ていると思ってしまう
俺がよくバグる例として、ある条件がそろった時だけフラグがTrueになるとして
フラグがFalseになるケースをテストをする
入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
想定していない別の条件ではじかれてFalseになっているだけと言う事がある
やはり、俺は単体テストはステップ毎に確認した方が良いと思う
この辺りもxUnitになじめない一因かも
しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
>>292
>そもそも、クラスを継承で拡張していくという考え方が間違ってるかもしれない。
>「実装の継承はするな」というのを聞いたこと無いなら、最近のOOの本とか読んで。
多態性をインタフェース実現とか、機能追加をコンポジションかDecoratorパターンを使うと言う事か？
継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
Bridgeパターンとかは継承の為のパターンだが？
>OOの理念に従って、なおかつテストが簡単になるように設計・実装すればいいじゃない。
>依存を減らし、抽象化を高め、なおかつテスタビリティに気を遣った設計をするんだ。
それは分かるが、xUnitの為にTDD(テスト駆動開発入門)を読んだけど
あのクラス・メソッド設計は本当に正しのか分からない
>xUnitはホワイトボックステスト。普通はステップ実行しないよ。
なんと言えば良いのか？、ホワイトボックステストだとも思うが
xUnitのテストは入力値を設定して、実行後の値を確認するだけだから
なにかブラックボックステストに似ていると思ってしまう
俺がよくバグる例として、ある条件がそろった時だけフラグがTrueになるとして
フラグがFalseになるケースをテストをする
入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
想定していない別の条件ではじかれてFalseになっているだけと言う事がある
やはり、俺は単体テストはステップ毎に確認した方が良いと思う
この辺りもxUnitになじめない一因かも
しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
377 ：仕様書無しさん：2009/12/02(水) 01:01:15
人事に開発は分からないから経験の無い奴がプロジェクトを指揮してカオスになるのは想像できなくもないが
ここでファビョられてもねぇ
マトモな開発やってる奴にはハァ？な訳で
チラシの裏で頼むぜ
ここでファビョられてもねぇ
マトモな開発やってる奴にはハァ？な訳で
チラシの裏で頼むぜ
かぶれてるもんだから
地道にやるしかない
の一言が言えない件
地道にやるしかない
の一言が言えない件
>>376
> 継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
いや、だから駄目とは言ってないよ。
「聞いたことがないなら」「OOの本読んで」だよ。
聞いたことがないんでしょ？だったら、本読もうよ。
> あのクラス・メソッド設計は本当に正しのか分からない
どの設計が駄目なのか言ってくれないとわからない。
入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。
> 入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
> 想定していない別の条件ではじかれてFalseになっているだけと言う事がある
具体的な内容はわからないけど、stubやmockで解決できる話なのかもしれない。
> やはり、俺は単体テストはステップ毎に確認した方が良いと思う
> この辺りもxUnitになじめない一因かも
それ、凝集度が低くて結合度が高く、複雑度が高い関数だからじゃないの？
> しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
まず>>326の本読め。
> 継承以外にもやり方があるのは理解しているが、しかし、継承が駄目だとは聞いた事はないし
いや、だから駄目とは言ってないよ。
「聞いたことがないなら」「OOの本読んで」だよ。
聞いたことがないんでしょ？だったら、本読もうよ。
> あのクラス・メソッド設計は本当に正しのか分からない
どの設計が駄目なのか言ってくれないとわからない。
入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。
> 入力値を設定し動かしてフラグがFalseになっているが、実際にステップ実行すると
> 想定していない別の条件ではじかれてFalseになっているだけと言う事がある
具体的な内容はわからないけど、stubやmockで解決できる話なのかもしれない。
> やはり、俺は単体テストはステップ毎に確認した方が良いと思う
> この辺りもxUnitになじめない一因かも
それ、凝集度が低くて結合度が高く、複雑度が高い関数だからじゃないの？
> しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
まず>>326の本読め。
>>379
>聞いたことがないんでしょ？だったら、本読もうよ。
これだけじゃあれなんで、書名をあげとく。
聞いたことがないんだったらGoFは読んでないよね？まずこれ。
次は『プレリファクタリング』あたりかな。
あと、OOの設計論に言及している最近の本なら、継承のリスクについての議論が載ってる奴が多いと思うよ。
何度も言うけど、xUnitが使いづらいんじゃなくて、現状は単体テストがやりづらく、そのためステップ実行
しないと安心できないんだよね。その理由が、テスト対象メソッドを正しく実行する外部条件をそろえるのが
困難だってのが大きな理由の一つなんでしょ？だから>>326。
>聞いたことがないんでしょ？だったら、本読もうよ。
これだけじゃあれなんで、書名をあげとく。
聞いたことがないんだったらGoFは読んでないよね？まずこれ。
次は『プレリファクタリング』あたりかな。
あと、OOの設計論に言及している最近の本なら、継承のリスクについての議論が載ってる奴が多いと思うよ。
何度も言うけど、xUnitが使いづらいんじゃなくて、現状は単体テストがやりづらく、そのためステップ実行
しないと安心できないんだよね。その理由が、テスト対象メソッドを正しく実行する外部条件をそろえるのが
困難だってのが大きな理由の一つなんでしょ？だから>>326。
だから、お前個人がエンバグやデグレードをしないのはわかったから、
メソッドか工学に結びつけないと>>359と同じなんだよ。
メソッドか工学に結びつけないと>>359と同じなんだよ。
MSやGoogleでもテストをしてるわけだが、そこのプログラマもカスってことですね。
さらに優秀なプログラマを集めるには、どうしたら良いのでしょうか。
さらに優秀なプログラマを集めるには、どうしたら良いのでしょうか。
>>386
19世紀あたりで思考が停止してるね
19世紀あたりで思考が停止してるね
相手にするだけ時間の無駄
優秀な人間なんてそうそう集まらないのが現実社会、って前提でみんな動いてんだけど？
>>379
>入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。
なんだ、「テスト駆動開発入門」も知らないのか、ケントが書いたxUnitのバイブルだぞ、まずお前が本を読めｗ
>>376
>やっぱり地味にやるしかないのか？
それが一番だｗ 兎も角>>281がここで参考になる話はないなｗ
>入門書レベルの本なら、テスタビリティのために○○を犠牲にしましょう、みたいな例は無いと思うんだけど。
なんだ、「テスト駆動開発入門」も知らないのか、ケントが書いたxUnitのバイブルだぞ、まずお前が本を読めｗ
>>376
>やっぱり地味にやるしかないのか？
それが一番だｗ 兎も角>>281がここで参考になる話はないなｗ
おい、お前ら
やっとこさ俺様の単体試験仕様書が完成したぞ
最後は自分で何書いてるか分からんかったけどＯＫもらったから完成したぞ
どや？俺の仕様書でテストしたいか？
やっとこさ俺様の単体試験仕様書が完成したぞ
最後は自分で何書いてるか分からんかったけどＯＫもらったから完成したぞ
どや？俺の仕様書でテストしたいか？
397 ：仕様書無しさん：2009/12/02(水) 21:56:28
今日の【3010】みたいなスレになってるな。
よいソフトウェア設計とは、
1. 凝集度が高い(high cohesion)
2. 結合度が低い(low coupling)
3. 重複がない(ZERO duplication)
4. テスト容易性が高い(testability)
5. 可読性が高い(readability)
テストできないソフトウェアは、机上の空論
1. 凝集度が高い(high cohesion)
2. 結合度が低い(low coupling)
3. 重複がない(ZERO duplication)
4. テスト容易性が高い(testability)
5. 可読性が高い(readability)
テストできないソフトウェアは、机上の空論
テスト出来ないのではなく
テストを前後に挟まないといけなくなるほど
低能なプログラマで仕事してるのか
という話。
それとも天才が束になっても上手くいかない程の
画期的なプロジェクトなのか？w
テストを前後に挟まないといけなくなるほど
低能なプログラマで仕事してるのか
という話。
それとも天才が束になっても上手くいかない程の
画期的なプロジェクトなのか？w
逆に
テストを前後に挟めなくなるほど
低能なプロジェクト管理で仕事してるのか
という話。
品質第一。
テストを前後に挟めなくなるほど
低能なプロジェクト管理で仕事してるのか
という話。
品質第一。
1990年代後半からだけどな
まぁ20年前といったら最近だなw
まぁ20年前といったら最近だなw
>>404
小学校からやり直すといいよw
小学校からやり直すといいよw
406 ：404 Not Found：2009/12/03(木) 01:19:15
...orz
どっちにしろ世界が2012年に終わるからいいよね
どっちにしろ世界が2012年に終わるからいいよね
えーっと単に適性が無いという結論でいいのかな？
いいかげん他所でやってくれよ・・・
新しいものに飛び付くかぶれた奴が多いという事だな
しっかりテスト駆動とやらも
ちゃんと数字的な根拠もなく
盲目的に導入してるところが多そうだw
ちゃんと利益増えてる？ww
しっかりテスト駆動とやらも
ちゃんと数字的な根拠もなく
盲目的に導入してるところが多そうだw
ちゃんと利益増えてる？ww
ｘUnitが新しいってどんだけタイムスリップしてきてるんだよ
1990年代後半の間違いorz
413 ：仕様書無しさん：2009/12/03(木) 23:32:17
>>409
そもそも君がバグを出さなきゃ誰もテストに関心なんか持たないんだけどねぇ。
そもそも君がバグを出さなきゃ誰もテストに関心なんか持たないんだけどねぇ。
>>413
妄想乙w
妄想乙w
つーか、テスト書いてるうちに
俺は納品終わってるよw
実際そんな感じのプロジェクトがあったが
暇すぎて二度とやりたくないと思ったわww
俺は納品終わってるよw
実際そんな感じのプロジェクトがあったが
暇すぎて二度とやりたくないと思ったわww
416 ：仕様書無しさん：2009/12/03(木) 23:41:04
ああ、ちなみに俺は仕事でバグを出した事は無い。
何故なら俺の作るバグは全て仕様だからだ。
何故なら俺の作るバグは全て仕様だからだ。
>>416
お前自体がバグってる件
お前自体がバグってる件
つーか、少々のバグすら出さないとか
詐欺師の典型じゃねーかw
詐欺師のトレンドスレかここはwww
詐欺師の典型じゃねーかw
詐欺師のトレンドスレかここはwww
419 ：仕様書無しさん：2009/12/03(木) 23:58:11
実際、バグなんて市場に出ないのが普通じゃないか？
出て当たり前ってのはちょっとおかしいだろ
どこのブラック企業だよ
出て当たり前ってのはちょっとおかしいだろ
どこのブラック企業だよ
馬鹿だな
市場に出さないようにテストをする
ゆえに一般的にはバグが市場に出ることは少ない
逆にテストが甘いと（バグを見逃すと）JRのアレみたいに市場トラブルが起きる
ゆえにテストをしよう！っていう当たり前の話なんだけどね
市場に出さないようにテストをする
ゆえに一般的にはバグが市場に出ることは少ない
逆にテストが甘いと（バグを見逃すと）JRのアレみたいに市場トラブルが起きる
ゆえにテストをしよう！っていう当たり前の話なんだけどね
>>421
馬鹿はお前だ
テストを前後に挟めばバグが減ると
明確に数字でも出せるのかとw
テストにコストが掛からない人材を手配した方が
よっぽどマシという話
テスト工程を余分にぶち込んで
儲けさせて頂いてんだかしらねーが
時間は無限じゃねーんだぞとww
馬鹿はお前だ
テストを前後に挟めばバグが減ると
明確に数字でも出せるのかとw
テストにコストが掛からない人材を手配した方が
よっぽどマシという話
テスト工程を余分にぶち込んで
儲けさせて頂いてんだかしらねーが
時間は無限じゃねーんだぞとww
あー、勿論トータルの開発期間は同じだからな
テスト工程を余分にぶち込んで期間が足りなくて
デスマとかワロス展開の事も考えて答えてみ？w
テスト工程を余分にぶち込んで期間が足りなくて
デスマとかワロス展開の事も考えて答えてみ？w
テストで時間かかるってことは無駄に粒度が高すぎるかバグりまくってるってことでしょ
そんなのをテストすっとばして納品するの？
キチガイだな
そんなのをテストすっとばして納品するの？
キチガイだな
テストで時間が掛かるメンバーなんて糞はいねーよ
お前んとこはボンクラ未満の無能を飼ってるのか？
お前んとこはボンクラ未満の無能を飼ってるのか？
テストチームに預けるにしても、開発チームでざっとテストし終わってから渡すしなあ。
バグだらけのゴミ渡したら締められるぞ。
バグだらけのゴミ渡したら締められるぞ。
こんな数字が ttp://www.infoq.com/jp/news/2009/03/TDD-Improves-Quality
「4製品のリリース前の欠陥密度（コード1000行あたりの欠陥数を測定）は、TDDを使用しないプロジェクトと比較し40%から90%の間で減少した。
チームの管理者は、主観的に見てTDDを使用するチームの初期開発時間に15%から35%の増加が認められると報告したが、チームは、これはメンテナンス・コストの削減により相殺されるとの見解で一致した。」
「4製品のリリース前の欠陥密度（コード1000行あたりの欠陥数を測定）は、TDDを使用しないプロジェクトと比較し40%から90%の間で減少した。
チームの管理者は、主観的に見てTDDを使用するチームの初期開発時間に15%から35%の増加が認められると報告したが、チームは、これはメンテナンス・コストの削減により相殺されるとの見解で一致した。」
>>426
テストで時間が掛からないも何も
わざわざテストを前後で挟まなくても
開発時にバグを潰してるから
残念だったな
つまり、お前らボンクラでいうところの
テスト工数ゼロだ
勿論、後のテストで多少はバグは出るがな
詐欺じゃないんでw
テストで時間が掛からないも何も
わざわざテストを前後で挟まなくても
開発時にバグを潰してるから
残念だったな
つまり、お前らボンクラでいうところの
テスト工数ゼロだ
勿論、後のテストで多少はバグは出るがな
詐欺じゃないんでw
>>428
15%-30%給料カットなw
15%-30%給料カットなw
>429
バグもつぶせない無能だと自称なさってますが
それでよろしいのですな？
バグもつぶせない無能だと自称なさってますが
それでよろしいのですな？
つまり、単体レベルでは発覚しなくて
結合レベルで発覚するバグ
という事な
結合レベルで発覚するバグ
という事な
後付け設定乱発だな
話にならね
お前の主張をまとめなおせ
話にならね
お前の主張をまとめなおせ
はぁ？
従来って何だ？何十年前から来たの？
テストなんてどこでも一般的にやってるだろ
やってねーほうが珍しいだろカス
従来って何だ？何十年前から来たの？
テストなんてどこでも一般的にやってるだろ
やってねーほうが珍しいだろカス
やりあってる二人のレベルがジャストレベルすぎて、見分けがつかないほど両方ひどい
何言ってんだお前
優秀な人間がお前の会社に入るわけ無い
テストをやることがかぶれる？イミフ
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ ＜「テストをやらない俺カッコイイ」
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー’´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一””””~~｀`’ー?､ -一”””’ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ ＜「テストをやらない俺カッコイイ」
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー’´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一””””~~｀`’ー?､ -一”””’ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
できるか馬鹿
>>443
こいつが一番このスレで頭が悪いのにwww
こいつが一番このスレで頭が悪いのにwww
ただのレス乞食の無職っぽいな
何かって言われても、何も。
無能は邪魔だからとっとと(･∀･)ｶｴﾚ!って話かもしれんしな。
無能は邪魔だからとっとと(･∀･)ｶｴﾚ!って話かもしれんしな。
関係ないけど、思い込みって凄いよね。
思い込みが強いと根拠の確認もなしに
新しいものに手を出しちゃうってのはあるな
まあ自腹でもやるのかと言うと疑問だがw
新しいものに手を出しちゃうってのはあるな
まあ自腹でもやるのかと言うと疑問だがw
453 ：仕様書無しさん：2009/12/04(金) 23:40:43
まあ、wが荒れるのも分かるけどさー
開発経験の無い素人が適当にトレンドを勉強して適当なテスト計画を立ててデスマったって事だろ
そんなレアケースここの住人が知るわけねーだろが、アホは巣に帰れ
そんな会社で仕事してるお前が無能なんだよ
開発経験の無い素人が適当にトレンドを勉強して適当なテスト計画を立ててデスマったって事だろ
そんなレアケースここの住人が知るわけねーだろが、アホは巣に帰れ
そんな会社で仕事してるお前が無能なんだよ
454 ：仕様書無しさん：2009/12/04(金) 23:44:22
まだやってんのか・・・それなりのスレだったのに
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ ＜「テストをやるとデスマるんだよ」
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー’´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一””””~~｀`’ー?､ -一”””’ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ ＜「テストをやるとデスマるんだよ」
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー’´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一””””~~｀`’ー?､ -一”””’ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
つーか、おまえら何年前からテスト方式をチェンジしたか知らねーが
それまで雑魚すぎでテストに苦しんでたのか？w
まあ元々バグりまくりでテストが終わらないような
糞プログラムしか書けなかった
ってんなら効果はあるだろうww
生憎そんな事は一度もなかったので
俺にはボンクラがテスト工数を一手間増やしたとしか思えんな
それまで雑魚すぎでテストに苦しんでたのか？w
まあ元々バグりまくりでテストが終わらないような
糞プログラムしか書けなかった
ってんなら効果はあるだろうww
生憎そんな事は一度もなかったので
俺にはボンクラがテスト工数を一手間増やしたとしか思えんな
いつまでたっても思考停止から抜け出せないキチガイ
>>457
お前が書くコードにバグがあろうが無かろうが、誰も興味がないってことにいい加減気づけ
お前が書くコードにバグがあろうが無かろうが、誰も興味がないってことにいい加減気づけ
何ヶ月後が、何年後かわからないけど、自分が書いたものを読み返すときがきたら、
きっと死にたくなるに違いない。
きっと死にたくなるに違いない。
462 ：仕様書無しさん：2009/12/05(土) 07:23:25
>>461
お前が増やせばいいだけだろ。全く使えない奴だな、片腹痛いわw
お前が増やせばいいだけだろ。全く使えない奴だな、片腹痛いわw
>>461
お前やお前の会社でどのようにやろうが、誰も興味ないったら。
お前が定義するところの無能（バグを作り込む奴）がどうすればいいのかを聞いてるのに、
お前がやめればいいとしか答えてないのに気づけ、馬鹿。
お前やお前の会社でどのようにやろうが、誰も興味ないったら。
お前が定義するところの無能（バグを作り込む奴）がどうすればいいのかを聞いてるのに、
お前がやめればいいとしか答えてないのに気づけ、馬鹿。
試験が終わったのに、どんどん機能追加って普通？
>>376
xUnitの最大の利点は、テストをプログラミングにしたこと
これにより、曖昧さを排除できる、結果品質が上がる
でも逆に、正確性が求められるから前準備（コーディング）が大変になる
既存のやりかたでは、人間が行うから曖昧さも柔軟に対応出来た
この辺りが、xUnitテストは大変だと思う原因じゃないの？
>しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
確かに、地味にやるしかないけど、プログラミングだから
コーディングテクニックや設計手法が使える
俺の場合は、最初に初期化・入力値設定・出力値確認のクラスを作っている
大変だけど、あとで楽になるよ
xUnitの最大の利点は、テストをプログラミングにしたこと
これにより、曖昧さを排除できる、結果品質が上がる
でも逆に、正確性が求められるから前準備（コーディング）が大変になる
既存のやりかたでは、人間が行うから曖昧さも柔軟に対応出来た
この辺りが、xUnitテストは大変だと思う原因じゃないの？
>しかし、誰が上手いxUnitの使い方を教えてほしい、それとも、やっぱり地味にやるしかないのか？
確かに、地味にやるしかないけど、プログラミングだから
コーディングテクニックや設計手法が使える
俺の場合は、最初に初期化・入力値設定・出力値確認のクラスを作っている
大変だけど、あとで楽になるよ
>>465
育つまではコードを書くなってことか。
育つまではコードを書くなってことか。
>>467
まぁお前は知らないだろうが、xUnitのずっと以前から、コードでテストするのは普通
まぁお前は知らないだろうが、xUnitのずっと以前から、コードでテストするのは普通
>>469
こんなアホがいるから、この板はおもしろいｗ
こんなアホがいるから、この板はおもしろいｗ
xUnitの話題はム板でやれよ。確かスレがあったからさ。
単なる事実を言ったら、アホ呼ばわりされたよ
なに愚痴ってんだ、アホか
そうだね、こんなところで愚痴っても、アホですねｗ
口先だけのレス乞食にムカついたってしかたないさ
ろくに知識がなくて煽るだけだからどこぞのアホコテより話にならない
ろくに知識がなくて煽るだけだからどこぞのアホコテより話にならない
>>476
お前の事だ
お前の事だ
この一連の書き込みの中に>>467がいるのかなぁ
メンヘ→メンヘラ→メンヘガ
↑今ここ
↑今ここ
>>467
>この辺りが、xUnitテストは大変だと思う原因じゃないの？
なんだか遠い過去の話に感じるが、xUnitテストが大変だと思う原因は、
>>281自身が書いているとおり、初期化が大変であることでしょ。
で、何度も繰り返して申し訳ないんだが、そんな>>281にぴったりなのが>>326。
超絶おすすめ。
>この辺りが、xUnitテストは大変だと思う原因じゃないの？
なんだか遠い過去の話に感じるが、xUnitテストが大変だと思う原因は、
>>281自身が書いているとおり、初期化が大変であることでしょ。
で、何度も繰り返して申し訳ないんだが、そんな>>281にぴったりなのが>>326。
超絶おすすめ。
>>482
一人だと思ってる
一人だと思ってる
xUnit 使ったテストってそんなに難しい話か？
難しいって発想がでてくる時点で無能じゃね？
難しいって発想がでてくる時点で無能じゃね？
xUnitの使用法自体は難しくないが、xUnitを使ったテストを書こうとすると難しい場合もある、
ということも想像できない方が無能
ということも想像できない方が無能
>>281
xUnitの使用場面は、メソッド単位でも良いし、シナリオベースでも良い。
開発者が行う単体テストにも使えるし、顧客が行う受け入れテストにも使える。
xUnitは単なるテストの実現手段にしか過ぎず、xUnitだからメソッド単位で
テストしなければならないとか、シナリオベースでテストした方が良いなどの
議論は無意味。
さらには、281がテスト対象としているコードが、自分が書いたものなのか他人が
書いたものなのか不明であり、開発プロセスのどの段階にいるかもわからないため、
まさに今どのようなテストを行うべきなのかには答えられない。
今、シナリオベースでのテストではテスト対象の粒度が大きいので、是非メソッド
単位でテストをしたいということであれば、取り得る方法は二つ。
一つは、テスト対象を（mockが使えるように）リファクタリングすること。
もう一つは、>>467の言うように、テスト用の初期化処理をプログラミングしてテストする。
もうすでにテスト工程は終わってしまったのかもしれないが・・・
xUnitの使用場面は、メソッド単位でも良いし、シナリオベースでも良い。
開発者が行う単体テストにも使えるし、顧客が行う受け入れテストにも使える。
xUnitは単なるテストの実現手段にしか過ぎず、xUnitだからメソッド単位で
テストしなければならないとか、シナリオベースでテストした方が良いなどの
議論は無意味。
さらには、281がテスト対象としているコードが、自分が書いたものなのか他人が
書いたものなのか不明であり、開発プロセスのどの段階にいるかもわからないため、
まさに今どのようなテストを行うべきなのかには答えられない。
今、シナリオベースでのテストではテスト対象の粒度が大きいので、是非メソッド
単位でテストをしたいということであれば、取り得る方法は二つ。
一つは、テスト対象を（mockが使えるように）リファクタリングすること。
もう一つは、>>467の言うように、テスト用の初期化処理をプログラミングしてテストする。
もうすでにテスト工程は終わってしまったのかもしれないが・・・
何この上から目線
GUIのテストには使えないと言っても過言ではない
コードって書いたとおりに動くんだからさ、コードが正しく動くことを確認するテストって意味なくね？
何が正しいかはわからない
お前いい加減にしろよ
軽やかにスルー
不完全なシステムのツケは107億円也。
みずほ証券の株誤発注裁判、東証に107億円の賠償命令、過失は7割
http://itpro.nikkeibp.co.jp/article/NEWS/20091204/341578/
みずほ証券の株誤発注裁判、東証に107億円の賠償命令、過失は7割
http://itpro.nikkeibp.co.jp/article/NEWS/20091204/341578/
ソフトは作った側に未来永劫責任があると勘違いしている顧客への良い警鐘
しかし、４００億円損失の時に始めてバグが分かったのかね？
警告表示を普段から無視していた（同じシステムか分からんが）のなら
あまり良いシステムじゃなかったのかな？
SIは、たしかFだよね？、あと、何かでよんだけど、東証のHのシステムも問題があるんだっけ？
警告表示を普段から無視していた（同じシステムか分からんが）のなら
あまり良いシステムじゃなかったのかな？
SIは、たしかFだよね？、あと、何かでよんだけど、東証のHのシステムも問題があるんだっけ？
バグじゃなくてオペミス
仕様もコードにするべきだよね。
>>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
普通にバグだが、オペミスで何で東証に賠償命令が出るの？
常識で考えればわかるだろう、取消処理をオペレーションでやるか？
証券会社は、取消処理のたびに、東証にオペレーション頼むのか？ 君はバカか？ それとも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
>は？何で富士通だったら東証のバグにしたがらないとか考えるのかわけわからん
そうだね、Fにとっては、これくらいのバグは日常茶飯事だから気にしないか
Fには、まともにテストが出来る人間が、いないからな～
>は？何で富士通だったら東証のバグにしたがらないとか考えるのかわけわからん
そうだね、Fにとっては、これくらいのバグは日常茶飯事だから気にしないか
Fには、まともにテストが出来る人間が、いないからな～
508 ：仕様書無しさん：2009/12/08(火) 12:51:39
このスレ的にはみずほ証券の問題を
どうやったら未然に防げたと考える？
やっぱりテストの仕方に問題があったと考える？
どうやったら未然に防げたと考える？
やっぱりテストの仕方に問題があったと考える？
みずほ証券側の問題って何？
まず問題を規定しろよ。
何が問題だと思ってるんだ？
これに答えられないなら、議論する意味ないね。
何が問題だと思ってるんだ？
これに答えられないなら、議論する意味ないね。
最近このスレを荒らしてる奴だから、相手にするだけ無駄
みずほ証券側は、オペミスを防ぐ設計はどうすればいいかという問題だから、
このスレ的には関係ない。
東証側は、ちゃんとテストしましょうと言うしかない。
このスレ的には関係ない。
東証側は、ちゃんとテストしましょうと言うしかない。
このスレ的にはちゃんとテストしましょうではなく
どんなテストを導入してどんな感じでやりましょう
じゃないのか？
どんなテストを導入してどんな感じでやりましょう
じゃないのか？
で、このスレ的なテストはみずほの問題に対して
効果は出るのか？
効果は出るのか？
ヒューマンエラーだからなあ。
手順書遵守の徹底を教育するくらいしか。
ソフトが配布されてたのかAPIが公開されたのかにもよるけど、
API公開なら重要事項の続行時にパスワード求めるとかかな。
手順書遵守の徹底を教育するくらいしか。
ソフトが配布されてたのかAPIが公開されたのかにもよるけど、
API公開なら重要事項の続行時にパスワード求めるとかかな。
>>515
だから、みずほの問題って何だよ？
だから、みずほの問題って何だよ？
>>516
何の話をしているのかさっぱりわからん
何の話をしているのかさっぱりわからん
警告が出まくりで無意味になっているのに
テストをちゃんとやるって何のテストの事？
つーか、ヒューマンエラーじゃないエラーって何？
テストをちゃんとやるって何のテストの事？
つーか、ヒューマンエラーじゃないエラーって何？
521 ：仕様書無しさん：2009/12/08(火) 19:24:43
東証の非はソフトがバグった事でもみずほが誤入力した事でもない。
異常な取引が起きても放置してた事が問題なんだ。
異常な取引が起きても放置してた事が問題なんだ。
キャンセルが受け付けられなかったのは非にならないの？
>>520
お前はしゃべるな
お前はしゃべるな
つーか、プログラムを使ったテストの標準化の必要性を説くために
みずほの例を出したんじゃなかったっけ？w
みずほの例を出したんじゃなかったっけ？w
>>490が限りなく正解に近かったようだな
問題は正しいとは何かなのだ。
金融だと市場は常に正しいらしいが。。。
金融だと市場は常に正しいらしいが。。。
>>524
何の話をしているのかさっぱりわからない。
何の話をしているのかさっぱりわからない。
「プログラムを使ったテストの標準化の必要性」の話なんてどこで出たんだ？
Wikipediaに書かれていることが100%正しいのなら、「東証、ちゃんとテストしろよ」
意外に言うべきことは何もないな。
意外に言うべきことは何もないな。
>>529
ちゃんとっていうのはこのスレで言うところの
何をするべきなんだ？
まさか散々既出ネタの時間を掛けて丁寧に
なんて話じゃないだろうから
新たにどんな手法を提唱するかwktkが止まらないんだが
果たして具体的な話が出来る人はここにいるかな？
ちゃんとっていうのはこのスレで言うところの
何をするべきなんだ？
まさか散々既出ネタの時間を掛けて丁寧に
なんて話じゃないだろうから
新たにどんな手法を提唱するかwktkが止まらないんだが
果たして具体的な話が出来る人はここにいるかな？
１：そもそもどういうテストをやっていたのかなんて、中の人しか分からない。
２：しかし、仕様、実装のいずれのミスにしても、検品(≒テスト)が適正に行われていればあらかた防げる。
３：今回の事例も、(報道で確認できる範囲では)テスト漏れがあったと見ることが出来る。
４：ゆえに「ちゃんと」テストするべき、と>>529は述べている。
具体的どうの以前の話なのよ。一つ一つの状況だけ見れば、さしてレアケースというわけではないのだから。
ついでに言えば丁寧にやることのの何が悪いんだ？ 基本中の基本だろ。
２：しかし、仕様、実装のいずれのミスにしても、検品(≒テスト)が適正に行われていればあらかた防げる。
３：今回の事例も、(報道で確認できる範囲では)テスト漏れがあったと見ることが出来る。
４：ゆえに「ちゃんと」テストするべき、と>>529は述べている。
具体的どうの以前の話なのよ。一つ一つの状況だけ見れば、さしてレアケースというわけではないのだから。
ついでに言えば丁寧にやることのの何が悪いんだ？ 基本中の基本だろ。
東証がテストするんじゃなく、富士通がテストすべきだろう
イレギュラーなバグならまだしも、こんな、基本操作すらテストをしていない
こんな会社が日本のリーディングカンパニーなんだから凄すぎ
来年1月4日から、東証と富士通は「arrowhead」を稼動させる
300億円のプロジェクトそうだが、なんか大変な事にならないと良いがｗ
イレギュラーなバグならまだしも、こんな、基本操作すらテストをしていない
こんな会社が日本のリーディングカンパニーなんだから凄すぎ
来年1月4日から、東証と富士通は「arrowhead」を稼動させる
300億円のプロジェクトそうだが、なんか大変な事にならないと良いがｗ
> 提供されていた「キャンセル」実施を行ったが出来なかった
ってバグ以外の何者でも無いようなキガスw
強いて言えば"テスト"で発見できなかったのは何でだ？
提供する機能が正しく(意図した通りに)動くか/動かないかを確認するのがソフトウェアのテストだろうにw
テストしなかったんだろうか？ それともあえて嫌がらせで罠を埋め込んでおいたのか?
ってバグ以外の何者でも無いようなキガスw
強いて言えば"テスト"で発見できなかったのは何でだ？
提供する機能が正しく(意図した通りに)動くか/動かないかを確認するのがソフトウェアのテストだろうにw
テストしなかったんだろうか？ それともあえて嫌がらせで罠を埋め込んでおいたのか?
>>533
プログラマの意図なんかどうでもいいんだよ。それは開発者側のテストの話だろ。
プログラマの意図なんかどうでもいいんだよ。それは開発者側のテストの話だろ。
何故バグを検出できなかったのかは、実情を知る以外に議論する方法は無いよ。
ここまで具体的なテスト方法の記述が一切ない件
ピントが外れてる奴、プログラマじゃないだろ。
だから、そう思ってないならお前が何か書け。
エビデンス、エビデンスとうるさいから、
.........................................
略
.......................................
OK(5200)
みたいなのをメールで送ってやった。
.........................................
略
.......................................
OK(5200)
みたいなのをメールで送ってやった。
ジェイコム問題よりも、Day2の方に興味がある。
例のセブン銀行にカタカナじゃなくて漢字でメッセージを送った件。
あれってなんだか大成功なプロジェクトということになっているらしく、こんな本まで出る始末。
『システム統合の「正攻法」 世界最大6000人プロジェクト、三菱東京UFJ銀行「Day2」に学ぶ 』
http://www.amazon.co.jp/dp/4822262413/
でもさ、外部システムに送信するメッセージが仕様書で定義されてるのに、それを網羅
してなかったってどんだけザルなんだと思うよ。
何でこれ（テストの質）が問題にならないのか不思議。
それともどっかで問題になってる？
例のセブン銀行にカタカナじゃなくて漢字でメッセージを送った件。
あれってなんだか大成功なプロジェクトということになっているらしく、こんな本まで出る始末。
『システム統合の「正攻法」 世界最大6000人プロジェクト、三菱東京UFJ銀行「Day2」に学ぶ 』
http://www.amazon.co.jp/dp/4822262413/
でもさ、外部システムに送信するメッセージが仕様書で定義されてるのに、それを網羅
してなかったってどんだけザルなんだと思うよ。
何でこれ（テストの質）が問題にならないのか不思議。
それともどっかで問題になってる？
全員馬鹿ってのが一致してる
妄想乙
>>547
どれがまともな意見なんだよ？ｗ
どれがまともな意見なんだよ？ｗ
まともなの定義を明確に出せ
そして、ちゃんとテストするのちゃんともな
適当に引用しといて具体的には何も申し上げられないとかは勘弁だ
頼むでしかしw
そして、ちゃんとテストするのちゃんともな
適当に引用しといて具体的には何も申し上げられないとかは勘弁だ
頼むでしかしw
お前がまともだと思う番号を明示すればいいだけの話だろ。
示せないの？
示せないの？
何度言えばわかるんだろうか。
ちゃんとテストしなかったんだろうから、ちゃんとテストしろとしか言いようが無いではないか。
具体的な話をしろというなら、具体的に何がいけなかったのか書け。
ちゃんとテストしなかったんだろうから、ちゃんとテストしろとしか言いようが無いではないか。
具体的な話をしろというなら、具体的に何がいけなかったのか書け。
>>554
論理的でない考察だな
そして結果も見事にはずれている
そもそもテスト云々を話す前に脳みそが非論理的になっていて
テストどころではない奴が多すぎるな
なんだよ、ちゃんとテストしろって
ちゃんとで話が済むならプログラマいらねえっつう話
論理的でない考察だな
そして結果も見事にはずれている
そもそもテスト云々を話す前に脳みそが非論理的になっていて
テストどころではない奴が多すぎるな
なんだよ、ちゃんとテストしろって
ちゃんとで話が済むならプログラマいらねえっつう話
匿名状態で「何度言えばわかるんだろうか」って言っちゃう馬鹿な人って・・・
一般的なテストの話と、ジェイコム問題でのテストの話を分けられない馬鹿
みずほの話を持ち出した奴が責任を持って話をまとめるべき
スレに即して具体的かつ明確にな
勿論ちゃんとやるべきとか意味のない書き込みはNG
スレに即して具体的かつ明確にな
勿論ちゃんとやるべきとか意味のない書き込みはNG
前提条件が人により違うから議論にならない。
意見が欲しい人は前提条件を明確にして質問してください。
意見が欲しい人は前提条件を明確にして質問してください。
>>283
>テストが簡単になるように、メソッドを設計・実装すればいい。
>凝集度を上げ、結合度を下げる。
はい、バカ発見、どうせ本とかの受け売りだろ、バカの一つ覚えｗ
凝集度を上げ、結合度を下げるとxUnitのテストが簡単になると本に書いてあったか？
凝集度を上げ、結合度を下げたモジュールをｘUnitのテストをやったことがないんだろうｗ
>テストが簡単になるように、メソッドを設計・実装すればいい。
>凝集度を上げ、結合度を下げる。
はい、バカ発見、どうせ本とかの受け売りだろ、バカの一つ覚えｗ
凝集度を上げ、結合度を下げるとxUnitのテストが簡単になると本に書いてあったか？
凝集度を上げ、結合度を下げたモジュールをｘUnitのテストをやったことがないんだろうｗ
はぁ？
>>561
ただの学歴コンプかな？論理的でない奴だな、本に書いてたら鵜呑みにしちゃうのか？なぜかを考えたらわかると思うんだが、なぜかを考えようとしないからいつまでもこんな不毛なやりとりしてるんだろうな。
と、規制解除記念カキコ
韻踏んでるっぽくていい響きだ
ただの学歴コンプかな？論理的でない奴だな、本に書いてたら鵜呑みにしちゃうのか？なぜかを考えたらわかると思うんだが、なぜかを考えようとしないからいつまでもこんな不毛なやりとりしてるんだろうな。
と、規制解除記念カキコ
韻踏んでるっぽくていい響きだ
あひゃ、>>561の間違い。
荒らし耐性無いなー
ほっとけよ
ほっとけよ
>>562-566
がんばっているな、バカどもがｗ
本当に知識も経験もないんだねｗ もう少し真面目に勉強すればｗ
凝集度を上げ結合度を下げるとは、モジュールの独立性を高める事だ
理解出来るか？、つまり外部からの干渉され難くなる分かるか？
xUnitテストは別モジュールから検証するテスト方法だとも分かるか？
いくらアホでも、ここまで書けば分かるだろうｗ
しかし、この時間まで何をやっているんだ、仕事はクビになったのか？
>>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
がんばっているな、バカどもがｗ
本当に知識も経験もないんだねｗ もう少し真面目に勉強すればｗ
凝集度を上げ結合度を下げるとは、モジュールの独立性を高める事だ
理解出来るか？、つまり外部からの干渉され難くなる分かるか？
xUnitテストは別モジュールから検証するテスト方法だとも分かるか？
いくらアホでも、ここまで書けば分かるだろうｗ
しかし、この時間まで何をやっているんだ、仕事はクビになったのか？
>>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
誰もがお前と同じスケジュールで生きてるわけじゃないんだよ？
わかる？
わかる？
はてしない馬鹿だな。
ぐぐって嘘でも書かれてるページでも見つけたか？
ぐぐって嘘でも書かれてるページでも見つけたか？
言葉遊びみたいな話ではなく別モジュールからテストするための機能を
勘違いしてるのか受け売りしたプログラマがいた
ってだけだな
特定のテスト方法に依存したプログラムを書く方が良いと言っていた事からも
手段と目的を完全に見誤っていたのは明らか
あと難しい処理を簡単な処理の連続にするのが良いわけではないな
無駄にプログラムが冗長になっても仕方ないし
それで制限される環境もまた出てくるだろう
必要な事は難しい処理の呼び出し（でも他でも）のインターフェースを
簡単にする事だ
似て非なる事なんでセンスが出るのはあるが
工数やコストにもろに影響が出るから
重要だったりする
勘違いしてるのか受け売りしたプログラマがいた
ってだけだな
特定のテスト方法に依存したプログラムを書く方が良いと言っていた事からも
手段と目的を完全に見誤っていたのは明らか
あと難しい処理を簡単な処理の連続にするのが良いわけではないな
無駄にプログラムが冗長になっても仕方ないし
それで制限される環境もまた出てくるだろう
必要な事は難しい処理の呼び出し（でも他でも）のインターフェースを
簡単にする事だ
似て非なる事なんでセンスが出るのはあるが
工数やコストにもろに影響が出るから
重要だったりする
>>569-571
まだ、分からんバカが多いな、もう少し詳しく書いてやるよ
１．モジュールは、凝集度を上げ結合度を下げると独立性を高める○
２．凝集度を上げ結合度を下げるとテストが容易になる○
３．凝集度を上げ結合度を下げるとxUnitテストが簡単になる×
お前ら、本当にxUnitテストをやったことがあるのか？
メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
テストメソッドを追加したことがないのか？ まっ、お前らがちゃんとテストしているとは思えんがｗ
とにかく「xUnitテストが簡単になる」事は無い
今度は、お前らに「凝集度を上げ結合度を下げるとxUnitテストが簡単になる」を
詳しく説明してもらおうか
まだ、分からんバカが多いな、もう少し詳しく書いてやるよ
１．モジュールは、凝集度を上げ結合度を下げると独立性を高める○
２．凝集度を上げ結合度を下げるとテストが容易になる○
３．凝集度を上げ結合度を下げるとxUnitテストが簡単になる×
お前ら、本当にxUnitテストをやったことがあるのか？
メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
テストメソッドを追加したことがないのか？ まっ、お前らがちゃんとテストしているとは思えんがｗ
とにかく「xUnitテストが簡単になる」事は無い
今度は、お前らに「凝集度を上げ結合度を下げるとxUnitテストが簡単になる」を
詳しく説明してもらおうか
そうだね、『ぎゃふん』
たしかに、privateのFieldやMethodで困ることがある
自分は、割り切ってテスト中はpublicにしているけど
みんなどうしているの？
自分は、割り切ってテスト中はpublicにしているけど
みんなどうしているの？
575 ：563だけ書き込んだ：2009/12/12(土) 11:52:07
「はい、バカ発見、どうせ本とかの受け売りだろ、バカの一つ覚えｗ」から「本に書いてあったか？」まで読んで、
学歴コンプの馬鹿が上司に怒られたが、凝集度、結合度、テストファーストの意味がわからず、
拒絶反応起こしてファ病ってんのかとエスパーしてしまった。話通じるみたいなので失礼した。
凝集度•結合度を考えて作られたものの方が、テストの複雑さが減らせるから、結果単体当りの精度はあがるよね？
じゃあ逆に聞くが、nUnitが導入される事になったらテストクラス書くのがめんどくさいからって、独立性の低いクラス書くのかい？それはしないよね？
君の本来の主張は
「めんどくさいからnUnitは使うな」
って事？
それとも
「俺様みたいな天才はテストなんぞいらぬ」
って事？
人間はミスをするって事を常に意識していなければいい仕事はできないんじゃないかなと思うんだけど。
学歴コンプの馬鹿が上司に怒られたが、凝集度、結合度、テストファーストの意味がわからず、
拒絶反応起こしてファ病ってんのかとエスパーしてしまった。話通じるみたいなので失礼した。
凝集度•結合度を考えて作られたものの方が、テストの複雑さが減らせるから、結果単体当りの精度はあがるよね？
じゃあ逆に聞くが、nUnitが導入される事になったらテストクラス書くのがめんどくさいからって、独立性の低いクラス書くのかい？それはしないよね？
君の本来の主張は
「めんどくさいからnUnitは使うな」
って事？
それとも
「俺様みたいな天才はテストなんぞいらぬ」
って事？
人間はミスをするって事を常に意識していなければいい仕事はできないんじゃないかなと思うんだけど。
nUnit使う事によって時間的なコストがかかるなら、あらかじめそれをコストに含めればいいだけの話なのに、なにがそんなに嫌なんだ？めんどくさいだけか？
>>572
ひとつ聞くが、どのようなテストなら簡単だと言ってる？
ひとつ聞くが、どのようなテストなら簡単だと言ってる？
>>572
> メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
> テストメソッドを追加したことがないのか？ まっ、お前らがちゃんとテストしているとは思えんがｗ
生産的な話をしようぜ。たとえば
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ではテストしづらいな。
> メソッドやフィールドを一時的にpublicに変更したり・フィールドを確認する
> テストメソッドを追加したことがないのか？ まっ、お前らがちゃんとテストしているとは思えんがｗ
生産的な話をしようぜ。たとえば
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ではテストしづらいな。
ずっとテストをする＝xUnitテストをすると
わざとミスリードしてる奴が多いけど
そういう詭弁を書かないと論が成り立たない時点で
終わってるんだよね
情弱は騙せてもプログラマは無理
わざとミスリードしてる奴が多いけど
そういう詭弁を書かないと論が成り立たない時点で
終わってるんだよね
情弱は騙せてもプログラマは無理
ちなみに、>>283を書いたのは俺で、>>283は>>281の
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
に対するレスであって、それを一般論に敷衍して揚げ足とられてもちと困る。
単独で動かせない、つまり結合度が高く凝集度が低いということだから、
その反対のコードを書けと言っただけの話だ。
結合度が低く凝集度が高ければ、一般にxUnitでもテストし易いと俺は思ってるが、
確かにテストしづらい局面もあることは認めるよ。
俺の場合は、自動テストとテスト容易性を何よりも優先するので、設計を崩す場合もある。
自分で一から書く場合はほとんどやらないが、他人のコードをメンテナンスする場合は、
メンバ変数のgetterを追加したり、privateメソッドををprotectedメソッドにしたり、
テストクラスをfriendクラスにしたりとか。
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変なんだが
に対するレスであって、それを一般論に敷衍して揚げ足とられてもちと困る。
単独で動かせない、つまり結合度が高く凝集度が低いということだから、
その反対のコードを書けと言っただけの話だ。
結合度が低く凝集度が高ければ、一般にxUnitでもテストし易いと俺は思ってるが、
確かにテストしづらい局面もあることは認めるよ。
俺の場合は、自動テストとテスト容易性を何よりも優先するので、設計を崩す場合もある。
自分で一から書く場合はほとんどやらないが、他人のコードをメンテナンスする場合は、
メンバ変数のgetterを追加したり、privateメソッドををprotectedメソッドにしたり、
テストクラスをfriendクラスにしたりとか。
ミスリードって誤読じゃないよ
つーか、昔と同じく普通に網羅テストを実施して足りなければ
アサートでも仕込んどけば済む話なのに、ソースを改変してまでxUnitテストに拘る奴ってアホなの？
当然、網羅テストも別に工数を取ってやるつもりなんだろ？
アサートでも仕込んどけば済む話なのに、ソースを改変してまでxUnitテストに拘る奴ってアホなの？
当然、網羅テストも別に工数を取ってやるつもりなんだろ？
その網羅テストは、どうやって実行するんだ？
それと、アサーションはテストの代わりにはならないよ。特にC++では。
それと、アサーションはテストの代わりにはならないよ。特にC++では。
>>582
具体的に話そうぜ。
お前の「昔のやり方」がわからないから話が紛糾してるんだよ。
それから、俺はお前にxUnitを使えと説得してるわけじゃないよ。
使いたくなければ使わなければ良いだよ。俺は便利だから使ってるけど。
逆に、何で自分では使わないxUnitにこだわってるのか不思議だ。
アサートでは、たとえば「有効な通貨単位が与えられなかったときに例外をスローする
通貨返還クラス」のテストは出来ないよね。
具体的に話そうぜ。
お前の「昔のやり方」がわからないから話が紛糾してるんだよ。
それから、俺はお前にxUnitを使えと説得してるわけじゃないよ。
使いたくなければ使わなければ良いだよ。俺は便利だから使ってるけど。
逆に、何で自分では使わないxUnitにこだわってるのか不思議だ。
アサートでは、たとえば「有効な通貨単位が与えられなかったときに例外をスローする
通貨返還クラス」のテストは出来ないよね。
網羅テストって何？
C0カバレッジのこと？
C1カバレッジのこと？
C0カバレッジのこと？
C1カバレッジのこと？
>>586
だーかーらー、昔のやり方ってのは、世界共通の唯一無二のものじゃないんだから、
昔のやり方でやろうと言われてもわからないんだよ。
ちなみに俺は、自前のテストハーネス＆スタブ＆シミュレータでやってたよ。
だーかーらー、昔のやり方ってのは、世界共通の唯一無二のものじゃないんだから、
昔のやり方でやろうと言われてもわからないんだよ。
ちなみに俺は、自前のテストハーネス＆スタブ＆シミュレータでやってたよ。
まだ理解出来ない奴がいるな、個別に説明してやるよ
>>575
>>君の本来の主張は
俺の主張は>>561だ、読めば分かるだろう？つまり
>>281に対して>>283の回答が間違っていると言うことだ 281はxUnitの上手いやり方を聞いている
それに対して、283は「凝集度を上げ、結合度を下げる」と書いている、こんなのはxUnitを使ったことが
ある人間なら絶対に書かない、良い悪いは別にして「テストが簡単になる」ことは絶対にない
ただの本の受け売りで「凝集度を上げ、結合度を下げるとテストが容易になる」をバカの一つ覚えで書いている
理解出来たか？
>>576
>nUnit使う事によって時間的なコストがかかるなら、あらかじめそれをコストに含めればいいだけの話なのに、なにがそんなに嫌なんだ？めんどくさいだけか？
だから、「テストが簡単になる」ことは絶対にないと言うことだろう
>>577
>ひとつ聞くが、どのようなテストなら簡単だと言ってる？
逆だ、俺は「テストが簡単になる」とは、一回も言っていない、「テストが簡単になる」と言っている奴に、アホだとは言っているが
>>579,581
>ずっとテストをする＝xUnitテストをすると
>わざとミスリードしてる奴が多いけど
>>281と>>283を読めばわかるんじゃないか？
>>578,580
>単独で動かせない、つまり結合度が高く凝集度が低いということだから、
>その反対のコードを書けと言っただけの話だ。
本当に、「結合度」と「凝集度」が理解出来ているのか？
「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事
初期化から何もかも、つまり単独で動かし易い事もある
だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして
>>575
>>君の本来の主張は
俺の主張は>>561だ、読めば分かるだろう？つまり
>>281に対して>>283の回答が間違っていると言うことだ 281はxUnitの上手いやり方を聞いている
それに対して、283は「凝集度を上げ、結合度を下げる」と書いている、こんなのはxUnitを使ったことが
ある人間なら絶対に書かない、良い悪いは別にして「テストが簡単になる」ことは絶対にない
ただの本の受け売りで「凝集度を上げ、結合度を下げるとテストが容易になる」をバカの一つ覚えで書いている
理解出来たか？
>>576
>nUnit使う事によって時間的なコストがかかるなら、あらかじめそれをコストに含めればいいだけの話なのに、なにがそんなに嫌なんだ？めんどくさいだけか？
だから、「テストが簡単になる」ことは絶対にないと言うことだろう
>>577
>ひとつ聞くが、どのようなテストなら簡単だと言ってる？
逆だ、俺は「テストが簡単になる」とは、一回も言っていない、「テストが簡単になる」と言っている奴に、アホだとは言っているが
>>579,581
>ずっとテストをする＝xUnitテストをすると
>わざとミスリードしてる奴が多いけど
>>281と>>283を読めばわかるんじゃないか？
>>578,580
>単独で動かせない、つまり結合度が高く凝集度が低いということだから、
>その反対のコードを書けと言っただけの話だ。
本当に、「結合度」と「凝集度」が理解出来ているのか？
「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事
初期化から何もかも、つまり単独で動かし易い事もある
だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして
だから今までそれぞれがやってた問題が出なかったテストでいいだろ
ってレベルの話なんだがw
例えば関数ごとにinoutで
単体テストしてるんでもいいしな
問題が出まくりのところはxUnitテストを導入しても
どうせバグりまくりだろ？w
ってレベルの話なんだがw
例えば関数ごとにinoutで
単体テストしてるんでもいいしな
問題が出まくりのところはxUnitテストを導入しても
どうせバグりまくりだろ？w
結局、この手の○○を使えば超簡単とか言う
詐欺的手口にすぐに引っ掛かる連中は
元からテストとか考察が必要な作業は出来ないという事だな
詐欺的手口にすぐに引っ掛かる連中は
元からテストとか考察が必要な作業は出来ないという事だな
592 ：仕様書無しさん：2009/12/12(土) 14:36:52
すごい、個別に一つ一つ回答してるが一つもかみ合ってない…
>>589
どうでもいいけど、昔のやり方とやらを早く書け
どうでもいいけど、昔のやり方とやらを早く書け
テストうんぬんの前にへぼな設計書が出来てるとか？
>>593
悪いが頭が悪い奴の道楽に付き合う暇はない
悪いが頭が悪い奴の道楽に付き合う暇はない
>>589
> 本当に、「結合度」と「凝集度」が理解出来ているのか？
> 「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事
いや、全く同じ認識だけど違うように読めた？
> 初期化から何もかも、つまり単独で動かし易い事もある
そういう場合もあるだろうね。
でも>>281は
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変
と言ってるよ？
> だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして
見解の相違だね。俺ならこう言うよ。
「凝集度が高ければ、一般にUnitTestは簡単になる」
俺に言わせれば、これを認めない奴はほんとにxUnit使ってるのか？ってことになる。
ちなみに俺は9年くらい使ってるよ。
> 本当に、「結合度」と「凝集度」が理解出来ているのか？
> 「凝集度が低い」という子とは、つまり一つのメソッドでなんでもやる事
いや、全く同じ認識だけど違うように読めた？
> 初期化から何もかも、つまり単独で動かし易い事もある
そういう場合もあるだろうね。
でも>>281は
>メソッド単位のテストだと、メソッド単独で動かせるようにする初期化が大変
と言ってるよ？
> だから、「凝集度が高い」方が「テストが簡単になる」とは言えない、もちろん”良い悪い”は別にして
見解の相違だね。俺ならこう言うよ。
「凝集度が高ければ、一般にUnitTestは簡単になる」
俺に言わせれば、これを認めない奴はほんとにxUnit使ってるのか？ってことになる。
ちなみに俺は9年くらい使ってるよ。
つーか、個人的に趣味で使ってる話を
書いてないか？
そんなもんはどうとでも言えるんだがw
書いてないか？
そんなもんはどうとでも言えるんだがw
前提も滅茶苦茶だし論理も滅茶苦茶だし
やりやすいように好きにすればいいじゃん
それで問題ないならそれでいいじゃん
無理に導入されてイラついてるならそこの上司に訴えればいいだけ
××はダメだなんて啓蒙活動になぜ必死になるかわからん
それこそミスリードすればいくらでも騙されてヒートアップするタイプのアホの発想だろ
やりやすいように好きにすればいいじゃん
それで問題ないならそれでいいじゃん
無理に導入されてイラついてるならそこの上司に訴えればいいだけ
××はダメだなんて啓蒙活動になぜ必死になるかわからん
それこそミスリードすればいくらでも騙されてヒートアップするタイプのアホの発想だろ
安っぽい持論だからとうとう崩壊しちゃったなw
はぁ？
>>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
それは、何と何の結合を、何結合から何結合に下げたのですか？
この辺をを参考にして、明示してください。
（どれもググった上位のページ）
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
>>598
誰宛のレス？
誰宛のレス？
アホっぽいのが何人いるのか知らないけど、みんななぜだか文体が同じだよね。
みずほ証券の株誤発注裁判、東証は控訴せず
ttp://itpro.nikkeibp.co.jp/article/NEWS/20091214/342100/
>重要な論点のほぼすべてにおいて当取引所の主張が認められながらも当取引所に
>賠償責任があるとされたことは残念ではあるが
自分とこのソフトのバグで取り消し処理が受け入れられずに被害が拡大したのに、
なんで残念とかまだ言ってるんだこいつは
ttp://itpro.nikkeibp.co.jp/article/NEWS/20091214/342100/
>重要な論点のほぼすべてにおいて当取引所の主張が認められながらも当取引所に
>賠償責任があるとされたことは残念ではあるが
自分とこのソフトのバグで取り消し処理が受け入れられずに被害が拡大したのに、
なんで残念とかまだ言ってるんだこいつは
意外だけど、東証に取り消し処理をする義務はないらしいよ
>>604
何故こっちが、回答しないといけないのか理解出来ない、一応回答はするが
内容結合 →（制御結合、スタンプ結合、データ結合）
こっちは答えた、そっちも「xUnitテストが簡単になる」理由を説明してくれ
何故こっちが、回答しないといけないのか理解出来ない、一応回答はするが
内容結合 →（制御結合、スタンプ結合、データ結合）
こっちは答えた、そっちも「xUnitテストが簡単になる」理由を説明してくれ
>>609
何と何の結合を？
何と何の結合を？
やっぱ、答えなくていいや。
public変数をprivateにその他の変更一切なしで変更できるとするなら、
それはクラス内メソッド間で共有するだけの変数だから、その二つの
メソッド間の結合度は変わっていない。
クラス外部から変更/参照するためのpublic変数（class Foo対 class
Barの結合）だとするなら、単純にprivateに持って行くことはできず、
他クラスからアクセスするためのアクセッサを追加する必要がある。
なので、テストメソッドからも容易にアクセスできるはず。
テスト対象クラスとテストクラス間の結合の話なら、>>580で俺のスタンスは
回答済み。
そもそも、>>281で初期化が大変なメソッドのテストをするという話で、
初期化が大変なら初期化しなければいいじゃないということ。
つまり、テスト対象メソッドと、初期化メソッドの結合度を下げましょうねってこと。
どうやればいいかは、>>326読め。
もう君の相手するの飽きたので、何言われても回答しないよ。
public変数をprivateにその他の変更一切なしで変更できるとするなら、
それはクラス内メソッド間で共有するだけの変数だから、その二つの
メソッド間の結合度は変わっていない。
クラス外部から変更/参照するためのpublic変数（class Foo対 class
Barの結合）だとするなら、単純にprivateに持って行くことはできず、
他クラスからアクセスするためのアクセッサを追加する必要がある。
なので、テストメソッドからも容易にアクセスできるはず。
テスト対象クラスとテストクラス間の結合の話なら、>>580で俺のスタンスは
回答済み。
そもそも、>>281で初期化が大変なメソッドのテストをするという話で、
初期化が大変なら初期化しなければいいじゃないということ。
つまり、テスト対象メソッドと、初期化メソッドの結合度を下げましょうねってこと。
どうやればいいかは、>>326読め。
もう君の相手するの飽きたので、何言われても回答しないよ。
要するにxUnitテスト使いたいから
俺はソースを改変しまくるおw
ってだけの話じゃねーかwww
俺はソースを改変しまくるおw
ってだけの話じゃねーかwww
>>611
「結合度」が理解出来ていないのは分かった
「結合度」は、モジュールの独立性を測る為のもの
外部モジュールから「結合」可能なものの中で一番高いものが、その「結合度」になる
お前の理屈だと、ローカル変数をグローバル変数にしても内部メソッドからしか呼ばなければ「データ結合」だと言う理屈になる
本来「結合度」と言うのは、知らない内に、別モジュールからアクセスされる事を”制限する為の尺度”で、実際の別モジュールとの関係ではない
>クラス外部から変更/参照するためのpublic変数（class Foo対 class
>Barの結合）だとするなら、単純にprivateに持って行くことはできず、
>他クラスからアクセスするためのアクセッサを追加する必要がある。
>なので、テストメソッドからも容易にアクセスできるはず。
だから、”テストメソッドからも容易にアクセスできるはず。”では
ただの現状維持で簡単になってはいない、お前が言ったのは「xUnitテストが簡単になる」だ
>もう君の相手するの飽きたので、何言われても回答しないよ。
分かっている、間違っているから回答出来る訳がない
「結合度」が理解出来ていないのは分かった
「結合度」は、モジュールの独立性を測る為のもの
外部モジュールから「結合」可能なものの中で一番高いものが、その「結合度」になる
お前の理屈だと、ローカル変数をグローバル変数にしても内部メソッドからしか呼ばなければ「データ結合」だと言う理屈になる
本来「結合度」と言うのは、知らない内に、別モジュールからアクセスされる事を”制限する為の尺度”で、実際の別モジュールとの関係ではない
>クラス外部から変更/参照するためのpublic変数（class Foo対 class
>Barの結合）だとするなら、単純にprivateに持って行くことはできず、
>他クラスからアクセスするためのアクセッサを追加する必要がある。
>なので、テストメソッドからも容易にアクセスできるはず。
だから、”テストメソッドからも容易にアクセスできるはず。”では
ただの現状維持で簡単になってはいない、お前が言ったのは「xUnitテストが簡単になる」だ
>もう君の相手するの飽きたので、何言われても回答しないよ。
分かっている、間違っているから回答出来る訳がない
勝利宣言で終了ですな。
もうお前来なくていいよ。
もうお前来なくていいよ。
xUnitは、それなりの設計スキルが無い奴が使うと、工数がかかるばかりで却って害悪。
その意味では、xUnitを使えばUnitTestが楽になるというのは嘘。
xUnitでなくともきちんとUnitTestを行える人間が使って初めてメリットがある。
その意味では、xUnitを使えばUnitTestが楽になるというのは嘘。
xUnitでなくともきちんとUnitTestを行える人間が使って初めてメリットがある。
つーか、クラス書いてゴニョゴニョやるようなw
プログラム言語用のテスト用ツールなだけなのに
すごい信仰が厚い奴がいるってだけの話
プログラム言語用のテスト用ツールなだけなのに
すごい信仰が厚い奴がいるってだけの話
信仰に厚い奴がいるんじゃなくて、熱心なアンチがいるの間違いでしょ
xUnitでメリットを感じてるって言ってるのに、
「いや、お前が感じているメリットはメリットではない」
とか言い出すから荒れるんだよ。
「いや、お前が感じているメリットはメリットではない」
とか言い出すから荒れるんだよ。
xUnitテストを使うまで単体テストをしてない連中じゃあ
浮かれるのも仕方ないかもな
浮かれるのも仕方ないかもな
浮かれてるし、信仰が厚いと言うことにしたいのですね
少なくともツールの受け売りしてる側なのは事実だな
使ってみてだから、受け売りじゃないだろ、アホ
もう何が何でもxUnitを使ってる連中を下に見ないと、自己を保てなくなってる段階。
久しぶりに、よさげな本が発売されてます。
『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド
(IT Architects’Archive ソフトウェア開発の実践)』
2009/11/28発売
http://www.amazon.co.jp/dp/4798119970/
『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド
(IT Architects’Archive ソフトウェア開発の実践)』
2009/11/28発売
http://www.amazon.co.jp/dp/4798119970/
>>624
伝書鳩だけが受け売りじゃないだろ、アホ
伝書鳩だけが受け売りじゃないだろ、アホ
受け売りじゃないとは例えば言語ツールで言えば
他の言語を使用して同プロジェクトを実行した場合の
長所短所を具体的にかつ数字ベースで示す事
xUnitテストいいよー、簡単になるよー
xUnitテストで上手くいかない奴はソースを改変するか
xUnitを使うための設計をした方がいいよー
では、まさに受け売りをしている事になる
控えめにみても信者だ
他の言語を使用して同プロジェクトを実行した場合の
長所短所を具体的にかつ数字ベースで示す事
xUnitテストいいよー、簡単になるよー
xUnitテストで上手くいかない奴はソースを改変するか
xUnitを使うための設計をした方がいいよー
では、まさに受け売りをしている事になる
控えめにみても信者だ
アジる人々のスレ
受け売りの意味がわからない馬鹿
>>627
意味がわからん
意味がわからん
>>628
こいつリファクタリングしたことなさそうだな
こいつリファクタリングしたことなさそうだな
>>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のことじゃないかとも思えるが、それでも何を言いたいのか良くわからない。
どう見ても結合度がわかってないのはお前の方なんだが。
>本来「結合度」と言うのは、知らない内に、別モジュールからアクセスされる事を”制限する為の尺度”で、実際の別モジュ
>ールとの関係ではない
Wikipediaの一行目にもこう書かれている。
>In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.
お前が言いたいのはscopeのことじゃないかとも思えるが、それでも何を言いたいのか良くわからない。
>>636
英語が理解出来ないのか、それとも日本語が理解出来ないのか？
英語が理解出来ないのか、それとも日本語が理解出来ないのか？
物事が理解出来ないじゃないのｗ
LoginForm form = new LoginForm();
form.setUserId("user1");
form.setPassword("password1");
form.execute();
String message = form.getMessage();
これアサーションでどうやってテスト書くの？
ちなみに、ログインに成功すると「こんにちは、user1さん」というメッセージが返り、
失敗するとUserInputExceptionがthrowされ、ex.getMesssage()で
「ユーザIDまたはパスワードが違います」が返される。
form.setUserId("user1");
form.setPassword("password1");
form.execute();
String message = form.getMessage();
これアサーションでどうやってテスト書くの？
ちなみに、ログインに成功すると「こんにちは、user1さん」というメッセージが返り、
失敗するとUserInputExceptionがthrowされ、ex.getMesssage()で
「ユーザIDまたはパスワードが違います」が返される。
つーか、アサーションでテストなんて論外。
駄目なところ：
1. テストに失敗するとそこで止まってしまう
2. 失敗したときの具体的な値がわからない（わかる言語もある？）
3. C++だとデバッグビルドの場合しかアサーションが有効にならない
駄目なところ：
1. テストに失敗するとそこで止まってしまう
2. 失敗したときの具体的な値がわからない（わかる言語もある？）
3. C++だとデバッグビルドの場合しかアサーションが有効にならない
641 ：仕様書無しさん：2009/12/21(月) 15:01:13
オマエラどーでもいいが、知識がない事を
わざわざ晒してどーする？w
わざわざ晒してどーする？w
>>641
知識のあるとこ見せてくれよ
知識のあるとこ見せてくれよ
643 ：仕様書無しさん：2009/12/21(月) 19:44:58
見せたらショックのあまりお前らが自殺するからダメ
2chだから正直に言うけど、俺もxUnitテスト不要派だなあ。
確かにxUnitテストをするとデグレ発生率が低くなるというメリットはある。
だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
確かにxUnitテストをするとデグレ発生率が低くなるというメリットはある。
だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
不要な奴は使わなければいい。
ただそれだけ。
ただそれだけ。
>>644
こいつリファクタリングしたことなさそうだな
こいつリファクタリングしたことなさそうだな
リファクタリングによるバグはxUnitテストをしても100%防げるわけじゃないんだよ？
した方がより防げるだろ。
>>644
> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
というほどきちんとした設計ができているのに、
> だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
というのは、よほどコーディング能力が劣ってるんだろうな。
まぁ、そのレベルならxUnit使っても意味ないね。
> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
というほどきちんとした設計ができているのに、
> だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
というのは、よほどコーディング能力が劣ってるんだろうな。
まぁ、そのレベルならxUnit使っても意味ないね。
>>644
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
それは、何か変更したときに、網羅的なテストは必要ないってことかな？
そういうプロジェクトもあるだろうけど、リリース後バグが発見されたらどえらい工数が
かかるプロジェクトもあるんだよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
それは、何か変更したときに、網羅的なテストは必要ないってことかな？
そういうプロジェクトもあるだろうけど、リリース後バグが発見されたらどえらい工数が
かかるプロジェクトもあるんだよ。
なんつーか、「名も知れないこいつより俺の方がすごい自慢」して、むなしくならんのかね。
たとえここで誰かをやりこめても、それが一体何になるというのだ。
たとえここで誰かをやりこめても、それが一体何になるというのだ。
>>644
> だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
例えば、コーディング＋単体テストで3ヶ月かかるところが、6ヶ月～1年かかるってこと？
それはいくらなんでもかかりすぎでは・・・。
> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
そういう断言しちゃうから叩かれるんだって・・・。
> だけどそのために工数（人件費）が2～4倍になるんじゃコスト対効果が釣り合わないと思う。
例えば、コーディング＋単体テストで3ヶ月かかるところが、6ヶ月～1年かかるってこと？
それはいくらなんでもかかりすぎでは・・・。
> ぶっちゃけ、後から機能を追加する際の影響範囲なんてそれほど広くないよ。
> デグレ確認用のPGが必要になるなら、それは大本の設計がおかしい。
そういう断言しちゃうから叩かれるんだって・・・。
>>644
その考えは間違っている、たしかに言っている事は分かる
xUnitより通常のデバッガの方が機能も上だし、そちらを使った方が
効率的にテストが出来る、もちろんデグレも
設計(凝集度・;結合度)やアーキテクチャー(分散技術DLL・COMなど)が正しければ
影響範囲が絞らるから、”デグレ確認用のPG”の必要性は低い
しかし、それは優秀な人材がそろっているプロジェクトだけの話だ
いろいろな人間（アホ・バカ・新人）がいるプロジェクトでは
”テスト用のPG”を書かせて、正しく通ることを確認出来るようにして、平均値を上げるしかない
もちろん優秀な人間には苦痛だが、プロジェクト全体で考えれば仕方がない
その考えは間違っている、たしかに言っている事は分かる
xUnitより通常のデバッガの方が機能も上だし、そちらを使った方が
効率的にテストが出来る、もちろんデグレも
設計(凝集度・;結合度)やアーキテクチャー(分散技術DLL・COMなど)が正しければ
影響範囲が絞らるから、”デグレ確認用のPG”の必要性は低い
しかし、それは優秀な人材がそろっているプロジェクトだけの話だ
いろいろな人間（アホ・バカ・新人）がいるプロジェクトでは
”テスト用のPG”を書かせて、正しく通ることを確認出来るようにして、平均値を上げるしかない
もちろん優秀な人間には苦痛だが、プロジェクト全体で考えれば仕方がない
実装継承して機能を拡張していくポリシーの奴とか、知らない間にデグレしてる危険線がおおありなんだが
>>650
>それは、何か変更したときに、網羅的なテストは必要ないってことかな？
網羅的なテストをやるかどうかはバグの内容によるでしょう。
大きい修正の場合は、結局他のテストも必要になるし。
>>652
>例えば、コーディング＋単体テストで3ヶ月かかるところが、6ヶ月～1年かかるってこと？
いや、単体テストは除外して
A.コーディング
B.コーディング + xUnit用コーディング
の比較で2～4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位？
>>653
しかしダメなプログラマほどテストコードがザルになる罠…
出来る人間を集めましょう。
>>654
何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。
>>655
そんなバグの出やすいポリシーってどうなの
>それは、何か変更したときに、網羅的なテストは必要ないってことかな？
網羅的なテストをやるかどうかはバグの内容によるでしょう。
大きい修正の場合は、結局他のテストも必要になるし。
>>652
>例えば、コーディング＋単体テストで3ヶ月かかるところが、6ヶ月～1年かかるってこと？
いや、単体テストは除外して
A.コーディング
B.コーディング + xUnit用コーディング
の比較で2～4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位？
>>653
しかしダメなプログラマほどテストコードがザルになる罠…
出来る人間を集めましょう。
>>654
何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。
>>655
そんなバグの出やすいポリシーってどうなの
いやもう君や君のチームでxUnitが有効じゃないのはわかったから、何も言わなくていいよ。
>>656
> いや、単体テストは除外して
> A.コーディング
> B.コーディング + xUnit用コーディング
> の比較で2～4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位？
え、3ヶ月でコーディングできるものに対して9ヶ月もテストコード書くの？
おおげさじゃないとしたら、レベルが低すぎる。
> >>654
> 何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。
それ、テストを書き慣れていないということじゃないのなら、設計が悪いか、
テストコードの書き方が悪いか、コーディング能力が低いかのどれかだよ。
> いや、単体テストは除外して
> A.コーディング
> B.コーディング + xUnit用コーディング
> の比較で2～4倍。平均と思ってたけど遅いのかな。そっちの現場ではどの位？
え、3ヶ月でコーディングできるものに対して9ヶ月もテストコード書くの？
おおげさじゃないとしたら、レベルが低すぎる。
> >>654
> 何か変更がある度にテストコードまで直さないといけないのは結構苦痛だ。
それ、テストを書き慣れていないということじゃないのなら、設計が悪いか、
テストコードの書き方が悪いか、コーディング能力が低いかのどれかだよ。
xUnitに嵌れなかった奴は、嵌れた奴がうらやましくてしかたないんだよ。
で、FUD流したり釣り発言したり。ルサンチマン炸裂だな。
で、FUD流したり釣り発言したり。ルサンチマン炸裂だな。
それ、嵌れた奴は嵌れなかった奴を見下したくてしかたがないとも言えるよ。このスレでは。
マーチン・ファウラーも言ってたけど、デバッグ用のprintfやデバッガ用のコードを書く暇があったら、
テストメソッド書けというくらい、単純な短い軽いメソッドでいいんだよ。
それと、基本I/Fに対してテストするってことね。これがわかってなくて、内部のvectorをpublicにして、
その内容を確認するでかいテストメソッドを書く奴とかがいる。で、hashに変えることになって死ぬと。
テストメソッド書けというくらい、単純な短い軽いメソッドでいいんだよ。
それと、基本I/Fに対してテストするってことね。これがわかってなくて、内部のvectorをpublicにして、
その内容を確認するでかいテストメソッドを書く奴とかがいる。で、hashに変えることになって死ぬと。
いつまでxUnitの話してんだよ・・・
スレ住民をテスト中
しかし、xUnitの話はxUnitのツールの話か
それともTDDみたいな開発手法の話をしているのか？
それともTDDみたいな開発手法の話をしているのか？
>>326読み終わったけど、すげーおもしろかったわ。
マジでおすすめだな。
マジでおすすめだな。
まぁリファクタリングに関してどれか一冊というならリファクタリング本しか無いんだろうけど、
10年前の本だから古くさいってのも事実。GoFもそうだな。
レガシーコードの方はリファクタリングの本じゃないから、比較はできない。
10年前の本だから古くさいってのも事実。GoFもそうだな。
レガシーコードの方はリファクタリングの本じゃないから、比較はできない。
「コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介」
って内容じゃん
リファクタリング"だけ"の本じゃないよ
って内容じゃん
リファクタリング"だけ"の本じゃないよ
むしろ『リファクタリング : プログラミングの体質改善テクニック』の方が
テストを扱っていないので為にはならんのでは？
テストを扱っていないので為にはならんのでは？
>>670
>リファクタリング"だけ"の本じゃないよ
>>671
>テストを扱っていないので為にはならんのでは？
『リファクタリング : プログラミングの体質改善テクニック』がリファクタリングだけの本で
テストを扱っていない
この人たちは、何で読んでもいない本を読んだと言っているのか？
>リファクタリング"だけ"の本じゃないよ
>>671
>テストを扱っていないので為にはならんのでは？
『リファクタリング : プログラミングの体質改善テクニック』がリファクタリングだけの本で
テストを扱っていない
この人たちは、何で読んでもいない本を読んだと言っているのか？
『リファクタリング』は、既存のコードを改善するのが目的なのに対して、『レガシーコード改善ガイド』は、
既存のコードを改善するのが目的ではない。だから比べられない。
『レガシーコード改善ガイド』は、書名が良くないね。元はWorking Effectively With Legacy Codeなのに。
全然駄目っていう人もいるけど、『レガシーコード改善ガイド』や『Working Effectively With Legacy Code』で
ググれば、世間の評判がわかるし、ここで議論するほどのことでもないよ。
既存のコードを改善するのが目的ではない。だから比べられない。
『レガシーコード改善ガイド』は、書名が良くないね。元はWorking Effectively With Legacy Codeなのに。
全然駄目っていう人もいるけど、『レガシーコード改善ガイド』や『Working Effectively With Legacy Code』で
ググれば、世間の評判がわかるし、ここで議論するほどのことでもないよ。
引用して批判しようね
テクノロジックアートじゃあるまいし。
多少変なとこがあるのかもしれんが、全体を通して駄目ってことはない。
誤訳があるなら指摘しましょう。
多少変なとこがあるのかもしれんが、全体を通して駄目ってことはない。
誤訳があるなら指摘しましょう。
訳が駄目だからリファクタリングの方が良いってのはどういうロジックだ。
>>673
結局読んでないのか、情けないｗ
結局読んでないのか、情けないｗ
バカだね、こいつ”レガシーコード改善ガイド”なんてマーチンのパクリじゃんｗ
本当に教養ないバカは困るわｗ
でも、なんでそんなにムキになるんだ？326=665がバレるぞｗ
お前は何がしたいんだｗ
本当に教養ないバカは困るわｗ
でも、なんでそんなにムキになるんだ？326=665がバレるぞｗ
お前は何がしたいんだｗ
このキチガイ、いつまでこのスレに粘着するつもりなんだ
682 ：仕様書無しさん：2010/02/10(水) 16:27:36
プログラマーにとってのテストの重要性
http://www.publickey.jp/blog/10/post_92.html
http://www.publickey.jp/blog/10/post_92.html
バグ出しなんか中国人にやらせろ
仕様わかってなきゃできねーだろ
コード書いてるやつも仕様なんてわかってねえよ
テストが仕様書(ｷﾘｯ
ならコード書く側の人間はかなり楽になるだろうな
とりあえずテスト通るようにすりゃいいんだから
ならコード書く側の人間はかなり楽になるだろうな
とりあえずテスト通るようにすりゃいいんだから
ユニットテストがあるから安心してリファクタリングできるってのがよく分からんわ
お前が書いたそのテストコードってそんなに信頼できるもんなの？
お前が書いたそのテストコードってそんなに信頼できるもんなの？
>686
テストファーストがそれに近い考えかたぢゃね
>687
とにかく俺様専用テストが通れば問題ないんです(ｷﾘｯ)
テストファーストがそれに近い考えかたぢゃね
>687
とにかく俺様専用テストが通れば問題ないんです(ｷﾘｯ)
仕様をコードで書けば（・∀・）。
ｘUnit で書いてるようなコードを「テスト」って言うから誤解が生じるんだろ
693 ：仕様書無しさん：2010/02/11(木) 23:25:09
誤解してるのはお前の方なんですが
>>687
確かにその通りだな、もともとリファクタリングが簡単に出来ないソースを書いた奴の
テストなんて絶対信用しないしなｗ
>>689
>じゃあ他に何でテストしたことを客観的に証明するんだ？
アホか？ テストコードが客観的に証明になると思っているのか
証明出来たからには、絶対にそのプログラムではバグが無いんだな
>>690
>テストコードもない状態でリファクタリング始めるよりは3万倍くらいマシ
3万倍の客観的な証拠は？ 精神的に良いぐらいの価値しかないぞｗ
>>692
そうだな、あれはテストじゃなくコーディングの一部だと理解出来てない奴が多いな
>>693
お前、自分の知識の無さが恥ずかしくないかｗ
確かにその通りだな、もともとリファクタリングが簡単に出来ないソースを書いた奴の
テストなんて絶対信用しないしなｗ
>>689
>じゃあ他に何でテストしたことを客観的に証明するんだ？
アホか？ テストコードが客観的に証明になると思っているのか
証明出来たからには、絶対にそのプログラムではバグが無いんだな
>>690
>テストコードもない状態でリファクタリング始めるよりは3万倍くらいマシ
3万倍の客観的な証拠は？ 精神的に良いぐらいの価値しかないぞｗ
>>692
そうだな、あれはテストじゃなくコーディングの一部だと理解出来てない奴が多いな
>>693
お前、自分の知識の無さが恥ずかしくないかｗ
>>694
> >じゃあ他に何でテストしたことを客観的に証明するんだ？
> アホか？ テストコードが客観的に証明になると思っているのか
> 証明出来たからには、絶対にそのプログラムではバグが無いんだな
まあ、落ち着けｗ
コミュニケーションが成り立ってないぞ。
俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。
あと、テストしたという証明は、バグがないという証明のことではないからな。
> >じゃあ他に何でテストしたことを客観的に証明するんだ？
> アホか？ テストコードが客観的に証明になると思っているのか
> 証明出来たからには、絶対にそのプログラムではバグが無いんだな
まあ、落ち着けｗ
コミュニケーションが成り立ってないぞ。
俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。
あと、テストしたという証明は、バグがないという証明のことではないからな。
>>694
お前はもういいったら。
お前はもういいったら。
xUnitって、Unit Testing Frameworkなんだけど、この'Testing'ってどういう意味？
プログラムの完全性を証明するようなたぐいの「テスト」の話なんか誰もしてなくて、
リファクタリングを安心して行えるに足る「テスト」の話をしているのに、xUnit大嫌い
馬鹿がまたもや大暴れの予感。
リファクタリングを安心して行えるに足る「テスト」の話をしているのに、xUnit大嫌い
馬鹿がまたもや大暴れの予感。
多い日も安心！
>>700
お前まだ理解してないみたいだなｗ
リファクタリングって何かわかってるのか？外部から見たプログラムの動きを変えずに、
プログラムの中身を変える（改良する）ことだぞ。
どんなにすばらしいテストを考えたとしてもそれを実施しなければ意味がない。
プログラム修正前、まずテストを実施する。リファクタリングで
プログラムを修正したら、まったく同じテストをしないといけない。
テスト項目が数える程度しかないのなら簡単だろうが、何十、何百もあるような場合、
テストコードを使う以外で、まったく同じテストを漏れなく実行しましたと
どうやって自信を持っていえるんだ？本当にしたとしても時間がかかるだろ。
テストコードがあれば、一瞬で安心することができる。
リファクタリング前にやったテストに、リファクタリングしても合格しましたと。
お前まだ理解してないみたいだなｗ
リファクタリングって何かわかってるのか？外部から見たプログラムの動きを変えずに、
プログラムの中身を変える（改良する）ことだぞ。
どんなにすばらしいテストを考えたとしてもそれを実施しなければ意味がない。
プログラム修正前、まずテストを実施する。リファクタリングで
プログラムを修正したら、まったく同じテストをしないといけない。
テスト項目が数える程度しかないのなら簡単だろうが、何十、何百もあるような場合、
テストコードを使う以外で、まったく同じテストを漏れなく実行しましたと
どうやって自信を持っていえるんだ？本当にしたとしても時間がかかるだろ。
テストコードがあれば、一瞬で安心することができる。
リファクタリング前にやったテストに、リファクタリングしても合格しましたと。
インスペクションみたいな高コストなモン、うちじゃ滅多にやらんなぁ。
でもxUnitかどうかによらず、テストの項目、手順と結果のレビューはやるだろ。
近辺だと実装者以外がxUnitやって、2人でターゲットコードのレビューと
テストコードのレビューを同時にやるのとか多い。
もう一人、第三者欲しいけどそんな余裕は無い。
まぁxUnitで安心かどうか分からんけど、コード修正したら
PTからやり直さにゃならんわけで・・・
なんか良い方法ない？
俺は別にxUnit好きじゃないし。
むしろウザいが、まだ他よりマシって感じ。
でもxUnitかどうかによらず、テストの項目、手順と結果のレビューはやるだろ。
近辺だと実装者以外がxUnitやって、2人でターゲットコードのレビューと
テストコードのレビューを同時にやるのとか多い。
もう一人、第三者欲しいけどそんな余裕は無い。
まぁxUnitで安心かどうか分からんけど、コード修正したら
PTからやり直さにゃならんわけで・・・
なんか良い方法ない？
俺は別にxUnit好きじゃないし。
むしろウザいが、まだ他よりマシって感じ。
>>687
お前には、プログラマとしての決定的な何かが欠けてるので、誰がどんなに説明してもわからんだろう。
お前には、プログラマとしての決定的な何かが欠けてるので、誰がどんなに説明してもわからんだろう。
>>695
すまん、勘違いした
>俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
>君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。
別にリファクタリングでテストが必須とは限らない、逆になるべくテストしないで済む方法で行う
>>700
安心に行う方法は、リファクタリング支援機能を使うのが一番安全に出来る
今は色々言語用のツールも揃っているし、機能も豊富になってきた
自動でリファクタリングしたものはリファクタリング前の機能と同一だからテスト不要（ツールにバグがある場合知らんが）
>>702
>プログラムを修正したら、まったく同じテストをしないといけない。
お前知識が浅いな、リファクタリング支援ツールも知らないのかｗ
すまん、勘違いした
>俺の質問は、「他に何を使ったらテストしたことを客観的に証明できるか。」だ。
>君が答えるべきなのは、テストコード以外の何かをいえばいいのだ。
別にリファクタリングでテストが必須とは限らない、逆になるべくテストしないで済む方法で行う
>>700
安心に行う方法は、リファクタリング支援機能を使うのが一番安全に出来る
今は色々言語用のツールも揃っているし、機能も豊富になってきた
自動でリファクタリングしたものはリファクタリング前の機能と同一だからテスト不要（ツールにバグがある場合知らんが）
>>702
>プログラムを修正したら、まったく同じテストをしないといけない。
お前知識が浅いな、リファクタリング支援ツールも知らないのかｗ
君のところのSQA審査は楽そうで良いな。
まぁ落ち着けよ。
きっとそういうツールがあるんだよ。
IF仕様を元にモジュール内を最適化してくれるようなツールが。
俺は知らんけど、多分浅いからだ。
きっとそういうツールがあるんだよ。
IF仕様を元にモジュール内を最適化してくれるようなツールが。
俺は知らんけど、多分浅いからだ。
> どんなにすばらしいテストを考えたとしてもそれを実施しなければ意味がない。
糞のような勘違いテストを何千回実行しても意味なくね？
糞のような勘違いテストを何千回実行しても意味なくね？
>>710は俺ね
>>703
なるほどやっぱりレビュー的なものは要るよね
なるほどやっぱりレビュー的なものは要るよね
>>710
勘違いテストをお前はそのままにしておくのか？
遅かれ早かれ直すもんだろ。
直した後は、正しいテストを何千回も実行できるって気づかない？
勘違いテストを直す→バグ発見→修正
コード修正しちゃったよね？
コード修正した状態で、今までやった他のテストが全部ちゃんと動くって
どうやって自信をもって言えるのさ。
少なくとも影響するであろう他のテストを全部やりおえるまで自信は持てないはずだが？
勘違いテストをお前はそのままにしておくのか？
遅かれ早かれ直すもんだろ。
直した後は、正しいテストを何千回も実行できるって気づかない？
勘違いテストを直す→バグ発見→修正
コード修正しちゃったよね？
コード修正した状態で、今までやった他のテストが全部ちゃんと動くって
どうやって自信をもって言えるのさ。
少なくとも影響するであろう他のテストを全部やりおえるまで自信は持てないはずだが？
変更に強いコードの書き方は理解できるのに、
変更に強い開発の仕方は理解できないのか。
変更に強い開発の仕方は理解できないのか。
何かかみ合って無いなー
俺の勘違いだったらすまんが、不毛過ぎて見てられん。
687が疑問なのは「どういうプロセスで勘違いに気付くのか」でしょ。
687はxUnitを実施することだけでは、その勘違いを見つけられない、
だから「xUnitをすることでは安心できない」って言ってるんじゃないかね。
対して710が言ってるのはxUnitの「再テストの容易性」についてだと思う。
多分710的には「xUnitをする」ということにテストコードの
検証フェイズが自明に含まれてるんじゃないかな？
（善意に見すぎか？）
それとも、710としてはxUnitのフレームワークでテストすることで
テストの品質そのものが確保出来ると考えてるの？
それならそれで、その説を聞きたいかも知れん。
俺の勘違いだったらすまんが、不毛過ぎて見てられん。
687が疑問なのは「どういうプロセスで勘違いに気付くのか」でしょ。
687はxUnitを実施することだけでは、その勘違いを見つけられない、
だから「xUnitをすることでは安心できない」って言ってるんじゃないかね。
対して710が言ってるのはxUnitの「再テストの容易性」についてだと思う。
多分710的には「xUnitをする」ということにテストコードの
検証フェイズが自明に含まれてるんじゃないかな？
（善意に見すぎか？）
それとも、710としてはxUnitのフレームワークでテストすることで
テストの品質そのものが確保出来ると考えてるの？
それならそれで、その説を聞きたいかも知れん。
ゴフぅっ・・・
長々と書いてたら簡潔に本人に先越される始末・・・orz
長々と書いてたら簡潔に本人に先越される始末・・・orz
テストが勘違いだとわかるのは突然でもレビューでもなんでもいいんだよ。
問題は、それでわかった後どうするんだってこと。
テストコードにするだろ。
テストが間違いでしたってわかってテストを修正して、はいおわりじゃ意味がない。
そのあと修正したテストにちゃんと既存のコードが通るかテストしないといけない。
まあ、もともとが間違ったテストで通ったコードだ。当然コードにバグが見つかるわな。
そのあとコードを修正するだろ。ある意味リファクタリングと同じようなことをしているわけだ。
ここでテストコードがなければどうなるか。修正した結果他のバグが発生するかもしれない。
今まで動いていた、できていたはずなのに動かなくなる。これが「安心して修正できない」ってことだよ。
テストは考えただけじゃだめだ。ちゃんとテストにコードが通るか実際に動かしてみないといけない。
それも何度も、コードに修正が入るたびにだ。テストコードでやる以外に他にどんな手段があるよ。
問題は、それでわかった後どうするんだってこと。
テストコードにするだろ。
テストが間違いでしたってわかってテストを修正して、はいおわりじゃ意味がない。
そのあと修正したテストにちゃんと既存のコードが通るかテストしないといけない。
まあ、もともとが間違ったテストで通ったコードだ。当然コードにバグが見つかるわな。
そのあとコードを修正するだろ。ある意味リファクタリングと同じようなことをしているわけだ。
ここでテストコードがなければどうなるか。修正した結果他のバグが発生するかもしれない。
今まで動いていた、できていたはずなのに動かなくなる。これが「安心して修正できない」ってことだよ。
テストは考えただけじゃだめだ。ちゃんとテストにコードが通るか実際に動かしてみないといけない。
それも何度も、コードに修正が入るたびにだ。テストコードでやる以外に他にどんな手段があるよ。
それから、テストは日本語で紙に書いたって終わりじゃないからな。
テストをレビューという内容が、人間の言葉で書かれた文章が正しいかをチェックする程度じゃ
まだたりない。
その文章どおりちゃんとテストしたかをレビューしないといけない。
つまりだ「テスト項目 このフィールドは入力できる文字が数値三桁である」
こういう内容のテスト仕様書だとか確認表だとかあるだけじゃだめということだ。
なぜなら、テストをサボるかもしれないだろ？
（他にも勘違いで正しく実行してないかもしれない。日本語があいまいかもしれない。）
本当にこのテスト項目を正しく実施したかという証明が必要。
「本当にテストしたのか？」なんていわれたくないだろう。
テストコードってのは、この内容のテストをここに書かれているとおりにテストしました。
「これが私がやったテストです。」という証拠だよ。
やった内容が記録されているから「間違ったテスト」をやってしまったという事実でさえ記録される。
人間の言葉でテスト内容を書き、人間がそれを解釈して動いていたら、テストするたびに人間の不具合が混入する。
テストをレビューという内容が、人間の言葉で書かれた文章が正しいかをチェックする程度じゃ
まだたりない。
その文章どおりちゃんとテストしたかをレビューしないといけない。
つまりだ「テスト項目 このフィールドは入力できる文字が数値三桁である」
こういう内容のテスト仕様書だとか確認表だとかあるだけじゃだめということだ。
なぜなら、テストをサボるかもしれないだろ？
（他にも勘違いで正しく実行してないかもしれない。日本語があいまいかもしれない。）
本当にこのテスト項目を正しく実施したかという証明が必要。
「本当にテストしたのか？」なんていわれたくないだろう。
テストコードってのは、この内容のテストをここに書かれているとおりにテストしました。
「これが私がやったテストです。」という証拠だよ。
やった内容が記録されているから「間違ったテスト」をやってしまったという事実でさえ記録される。
人間の言葉でテスト内容を書き、人間がそれを解釈して動いていたら、テストするたびに人間の不具合が混入する。
いやいやいや分かった後の話じゃなくってｗｗｗｗ
どうやって分かんのかってことなんだけど
どうやって分かんのかってことなんだけど
>>707
>お前、リファクタリングツールでできる範囲の話しかしてないのか？
まずは、支援機能で出来る事はやるのが鉄則
手動でリファクタリングするのは手動でしか出来ない場合だけ
なんでもかんでもxUnitをすれば良いと考えるのは無知な技術者
>アルゴリズムの変更などは、リファクタリングツールで自動的に変更なんて
>できないんだが。
アルゴリズムの変更は、一般的にレスポンス改善の場合に行う事が多いが
その場合、他メソッドのタイミングバグをxUnitでは検出するのが難しい
また、そのメソッド自身のテストコードも使い物にならないのが普通
本来xUnitのテストは、「「失敗の恐れがのある境界条件を考えて、そこを集中的にテストせよ」だ
アルゴリズム変更で、その境界条件は変ってしまう
お前リファクタリングをとやった事あるのか？ その前に本当に理解しているのか？ 根本的に間違ってないか？
>>708
>きみんちでリファクタリングと呼ばれてるものは世間様と違うようだ
>あまり家の外でリファクタリングという言葉を使わないほうがいいぞ
心配するな、俺はマーチンが書いた物の受け売りしているだけだ
知識が無い奴には分からんと思うが、まっ、お前は自分だけ正しいと思っていろｗ
>>709
>IF仕様を元にモジュール内を最適化してくれるようなツールが。
>俺は知らんけど、多分浅いからだ。
707もそうだが、リファクタリングを本当に理解出来ているのか
アルゴリズムの変更や、モジュール内を最適化は”性能改善”だ
xUnitのテストだけで済むと思っているのか？
リファクタリングの主な目的はプログラムの劣化を防ぐ事だと思っているが
お前らは、リファクタリング＝性能/機能改善と考えているのか？
>お前、リファクタリングツールでできる範囲の話しかしてないのか？
まずは、支援機能で出来る事はやるのが鉄則
手動でリファクタリングするのは手動でしか出来ない場合だけ
なんでもかんでもxUnitをすれば良いと考えるのは無知な技術者
>アルゴリズムの変更などは、リファクタリングツールで自動的に変更なんて
>できないんだが。
アルゴリズムの変更は、一般的にレスポンス改善の場合に行う事が多いが
その場合、他メソッドのタイミングバグをxUnitでは検出するのが難しい
また、そのメソッド自身のテストコードも使い物にならないのが普通
本来xUnitのテストは、「「失敗の恐れがのある境界条件を考えて、そこを集中的にテストせよ」だ
アルゴリズム変更で、その境界条件は変ってしまう
お前リファクタリングをとやった事あるのか？ その前に本当に理解しているのか？ 根本的に間違ってないか？
>>708
>きみんちでリファクタリングと呼ばれてるものは世間様と違うようだ
>あまり家の外でリファクタリングという言葉を使わないほうがいいぞ
心配するな、俺はマーチンが書いた物の受け売りしているだけだ
知識が無い奴には分からんと思うが、まっ、お前は自分だけ正しいと思っていろｗ
>>709
>IF仕様を元にモジュール内を最適化してくれるようなツールが。
>俺は知らんけど、多分浅いからだ。
707もそうだが、リファクタリングを本当に理解出来ているのか
アルゴリズムの変更や、モジュール内を最適化は”性能改善”だ
xUnitのテストだけで済むと思っているのか？
リファクタリングの主な目的はプログラムの劣化を防ぐ事だと思っているが
お前らは、リファクタリング＝性能/機能改善と考えているのか？
>>723
709だが。
レスの流れ上そう取られても仕方ないかも知れないが、
xUnitすれば十分とは言ってない。
お前の言うリファクタリングはツールだけで
完結するのか？と言っている。
何というツールを使えばコードの劣化が防げるんだ？
個人的にはリファクタリングは再設計だ。
最適化というのは処理を速くする事ではない。
無駄な処理を除いたり、構造を綺麗にしたり、
プログラムを今の目的にマッチさせることだ。
再設計の範囲次第でxUnitのコードがそのまま
使えることもあれば使えないこともある。
が、少なくともテストしなくて良いということはない。
709だが。
レスの流れ上そう取られても仕方ないかも知れないが、
xUnitすれば十分とは言ってない。
お前の言うリファクタリングはツールだけで
完結するのか？と言っている。
何というツールを使えばコードの劣化が防げるんだ？
個人的にはリファクタリングは再設計だ。
最適化というのは処理を速くする事ではない。
無駄な処理を除いたり、構造を綺麗にしたり、
プログラムを今の目的にマッチさせることだ。
再設計の範囲次第でxUnitのコードがそのまま
使えることもあれば使えないこともある。
が、少なくともテストしなくて良いということはない。
>>723
> xUnitのテストだけで済むと思っているのか？
お前はどんなものがxUnitではすまないと思っているのだ？
お前が何か答えたとしよう。
じゃあ俺はこう答える。
お前が言ったそのテストをxUnitで実行すればいいだけの話だと。
> xUnitのテストだけで済むと思っているのか？
お前はどんなものがxUnitではすまないと思っているのだ？
お前が何か答えたとしよう。
じゃあ俺はこう答える。
お前が言ったそのテストをxUnitで実行すればいいだけの話だと。
xUnitが人間がぽちぽちやって確かめるテストと
まったく同じことをやっているってわかってないのかな？
まったく同じことをやっているってわかってないのかな？
>>725のトコだとITやSTもxUnit？
それともリファクタリングにゃそういうテストはいらんのかい？
それともリファクタリングにゃそういうテストはいらんのかい？
>>724
俺とはリファクタリング・xUnitの考えが違うみたいだな
俺の考えは
リファクタリング：
長年の改修で、劣化したコードを保守し運用コストを下げる行為
改修との違いは、改修が機能・性能改善、または機能追加・削除する為のものに対して
リファクタリングはリファクタリング前後でも等価であること
また、行う時期についても違い、改修が外部的要因で行うのに対して
リファクタリングは、プログラマの主観で行う
品質についても、リファクタリングは動いている物を修正するのだがら
改修より、厳しい品質が求められる、ユーザーに取って見れば
わざわざ動いている物を、修正してバグが出る何て許されない行為だ
xUnit：
コーディングコストを下げる為に、コーディングにテストを導入したもの
したがって、テストは別に行なう、例えばテストファーストなど
先にテストコードを書いて失敗させる、これはテストが目的じゃなく
コーディングが目的の為、またテストが全ての機能をテストするのに対して
xUnitは失敗の恐れがある所を重点に行い、単純な機能はテストしない
簡単に書くとこんな感じだ
俺とはリファクタリング・xUnitの考えが違うみたいだな
俺の考えは
リファクタリング：
長年の改修で、劣化したコードを保守し運用コストを下げる行為
改修との違いは、改修が機能・性能改善、または機能追加・削除する為のものに対して
リファクタリングはリファクタリング前後でも等価であること
また、行う時期についても違い、改修が外部的要因で行うのに対して
リファクタリングは、プログラマの主観で行う
品質についても、リファクタリングは動いている物を修正するのだがら
改修より、厳しい品質が求められる、ユーザーに取って見れば
わざわざ動いている物を、修正してバグが出る何て許されない行為だ
xUnit：
コーディングコストを下げる為に、コーディングにテストを導入したもの
したがって、テストは別に行なう、例えばテストファーストなど
先にテストコードを書いて失敗させる、これはテストが目的じゃなく
コーディングが目的の為、またテストが全ての機能をテストするのに対して
xUnitは失敗の恐れがある所を重点に行い、単純な機能はテストしない
簡単に書くとこんな感じだ
xUnitはテストツールだろ。
テストファーストを行うときに使うツール。
別にテストファースト専用というわけではなく、
自動テストや回帰テストを行うときにも使える。
人間の言葉で書かれたテスト仕様書をコンピュータで実行できる形にしたもの。
それがテストコードで、xUnitはテストコードを楽に作成するときに使うツールの一つ
テストファーストを行うときに使うツール。
別にテストファースト専用というわけではなく、
自動テストや回帰テストを行うときにも使える。
人間の言葉で書かれたテスト仕様書をコンピュータで実行できる形にしたもの。
それがテストコードで、xUnitはテストコードを楽に作成するときに使うツールの一つ
リファクタリングツールが使えない開発環境のことなんか、これっぽっちも頭に浮かばないんだろうか。
edしかないような環境でプログラミングしなければならない場合も充分に考慮に入れなければなりませんよね！
紙の上でコーディングしてそれをedを使って延々と打ち込むだけの簡単なお仕事
UnixでJavaだけどvi
>具体的に何がどう違うのなんて聞こうと思わないでね。それ甘えだから。
無知な奴の新たなる予防線か
こう書けば突っ込まれて恥をかく必要はなくなるよな
ない知恵絞っていい事思いついたじゃねーか
無知な奴の新たなる予防線か
こう書けば突っ込まれて恥をかく必要はなくなるよな
ない知恵絞っていい事思いついたじゃねーか
×わらん
○わからん
○わからん
>>731-734
別に支援機能が無くても、カタログ通りやれば問題ない
>>736
xUnitは品質の為にやるものでなく、プログラマの生産性を向上するもの
つまり目的が違う、コーディングで時間が掛かるのはある程度
プログラムが正しく動くようにすること、その為にｘUnitを使う
その為、上でも書いたが全てのメソッドをテストをするので無く
重要な部分だけをテストする
品質の為に行っているわけではない
>>738
ツールだけで、リファクタリングが完結するとは言っていないし、上でも書いたが
リファクタリングはプログラマーの主観で行うもの、何を持って完結と言っているのか？
別に支援機能が無くても、カタログ通りやれば問題ない
>>736
xUnitは品質の為にやるものでなく、プログラマの生産性を向上するもの
つまり目的が違う、コーディングで時間が掛かるのはある程度
プログラムが正しく動くようにすること、その為にｘUnitを使う
その為、上でも書いたが全てのメソッドをテストをするので無く
重要な部分だけをテストする
品質の為に行っているわけではない
>>738
ツールだけで、リファクタリングが完結するとは言っていないし、上でも書いたが
リファクタリングはプログラマーの主観で行うもの、何を持って完結と言っているのか？
という自説にすぎないってのに、いい加減気づこうね。
xUnit使うと生産性が落ちるって言う奴がほとんどなのに。
それはプログラマがテストしてないんだろ。
したとしてもちょっと動かしてみて終わり
あとはテスターにやらせてバグ見つけてもらう。
バグ修正したら、またテスターにやらせる。
たしかに、自分のところだけ見れば、生産性はいいだろうねｗ
したとしてもちょっと動かしてみて終わり
あとはテスターにやらせてバグ見つけてもらう。
バグ修正したら、またテスターにやらせる。
たしかに、自分のところだけ見れば、生産性はいいだろうねｗ
>>740
>という自説にすぎないってのに、いい加減気づこうね。
と自説を言うまえに本を読め
>>741
>xUnit使うと生産性が落ちるって言う奴がほとんどなのに。
だから、生産性を落とすまでxUnitをやる必要は無い
重要だと思う所だけ適用すれば良い
>>742
お前は馬鹿
>という自説にすぎないってのに、いい加減気づこうね。
と自説を言うまえに本を読め
>>741
>xUnit使うと生産性が落ちるって言う奴がほとんどなのに。
だから、生産性を落とすまでxUnitをやる必要は無い
重要だと思う所だけ適用すれば良い
>>742
お前は馬鹿
xUnit使ってコーディングした後に品質のための単体テストやんのか。
別に悪いとは言わないけど、珍しいプロセスだね。
別に悪いとは言わないけど、珍しいプロセスだね。
コーディングの為の単体テスト(ｷﾘｯ
>>743
重要じゃないところはテストしないの？
重要じゃないところはテストしないの？
自明な部分はテストしない
>>743
> >>740
> >という自説にすぎないってのに、いい加減気づこうね。
> と自説を言うまえに本を読め
お前の自説を裏付ける書籍があるならあげてみろ。
俺の反証はXP本全般とTDD本だ。
> >>740
> >という自説にすぎないってのに、いい加減気づこうね。
> と自説を言うまえに本を読め
お前の自説を裏付ける書籍があるならあげてみろ。
俺の反証はXP本全般とTDD本だ。
一人で開発してるんだろうから、自分が必要と思うとこだけテスト書けばいいと結論付けてるんだろう。
形式的手法が適用できる所以外は全部テスト書く
なんでそれを除外するのかわからん。
xUnitというのは、何かのテストをするための手段にすぎないというのがわかってない奴が多いな。
各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。
コーディングの助けになる程度の使い方でも良いし、品質向上のために使っても良い。
どちらも正しい。
各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。
コーディングの助けになる程度の使い方でも良いし、品質向上のために使っても良い。
どちらも正しい。
>>694
つまり、コードレビューのかわりに、テストコードを見るひがやすを氏は馬鹿だと。
つまり、コードレビューのかわりに、テストコードを見るひがやすを氏は馬鹿だと。
>>744
是非試してくれ、多分試した方が
俺の言いたい事が良く分かると思う
>>746
テストはする、xUnitはしない
>>748
>俺の反証はXP本全般とTDD本だ。
自慢か？ だから本を読め、お前の「本を見ている」だけだ
本当に駄目な奴だな、いいかマーチンも
「プログラムの生産性が向上するために行うもの、品質保証部門が満足しても、それは副作用に過ぎない」と言っている
>>749
だから、テストは全てするxUnitは重要な部分を重点的に行う
>>752
>形式的手法が適用できる所以外は全部テスト書く
形式的手法か、テストのスレらしくなってきたなｗ
つまり、ホーア論理で数学的に証明出来ない部分、例えば例外処理とかをテストするのか？
良い方法だと思う、が！ ハードルが高すぎないか？ 会社とか集団だと、かなりレベルの高い人材がいないと
>>752
>各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。
その通りだ、だからxUnitは品質の為に使うと言っているが、間違っていると言っている
本来はプログラムの生産性が向上する為のもの、本来の使い方を否定するなと言っている
>>754
地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
単体はこれで充分
是非試してくれ、多分試した方が
俺の言いたい事が良く分かると思う
>>746
テストはする、xUnitはしない
>>748
>俺の反証はXP本全般とTDD本だ。
自慢か？ だから本を読め、お前の「本を見ている」だけだ
本当に駄目な奴だな、いいかマーチンも
「プログラムの生産性が向上するために行うもの、品質保証部門が満足しても、それは副作用に過ぎない」と言っている
>>749
だから、テストは全てするxUnitは重要な部分を重点的に行う
>>752
>形式的手法が適用できる所以外は全部テスト書く
形式的手法か、テストのスレらしくなってきたなｗ
つまり、ホーア論理で数学的に証明出来ない部分、例えば例外処理とかをテストするのか？
良い方法だと思う、が！ ハードルが高すぎないか？ 会社とか集団だと、かなりレベルの高い人材がいないと
>>752
>各個人がどのような目的で使おうがかまわないし、それを他人が「使い方がおかしい」と言うのも変。
その通りだ、だからxUnitは品質の為に使うと言っているが、間違っていると言っている
本来はプログラムの生産性が向上する為のもの、本来の使い方を否定するなと言っている
>>754
地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
単体はこれで充分
名前を直すの忘れた
755=694
755=694
>>739
混乱してきた。ユニットテストってのがなんなのか分からなくなってきた
混乱してきた。ユニットテストってのがなんなのか分からなくなってきた
>>752
テストっていうのは品質向上のためにやるもんだって大前提がおかしかったってことか
テストっていうのは品質向上のためにやるもんだって大前提がおかしかったってことか
品質は上がるよ
結果として
結果として
やっぱよく分からんわ・・・
品質のためじゃない xUnit の使い方ってのがピンとこない
品質のためじゃない xUnit の使い方ってのがピンとこない
Money::add(Money&)とかのコードが自明でテストコードを省略したとすると、第三者はそれが自明かどうか
メソッドのコードを見に行くしかないよね。
んで、テストコードのメソッドの網羅率が60%くらいだったらもううんざりだよね。
メソッドのコードを見に行くしかないよね。
んで、テストコードのメソッドの網羅率が60%くらいだったらもううんざりだよね。
自明な部分でもテストは書く
ただし人間の手で書くのでは無くて自動生成する
ただし人間の手で書くのでは無くて自動生成する
>>755
ありがとう。
けどうちの場合、そういう方法と検討した結果xUnitを選択したんで、
あんま参考にならんっぽい。
>>760
そもそもxUnitをテストに使ってないのと違うかな。
ドライバとスタブの作成フレームワークとしてxUnitを使ってるだけ、と。
極端な話、テストケース1件、確認項目0件でも、
ドライバからメソッドを呼べて、それがスタブを使って駆動できればOK、
ちゅーレベル。
ありがとう。
けどうちの場合、そういう方法と検討した結果xUnitを選択したんで、
あんま参考にならんっぽい。
>>760
そもそもxUnitをテストに使ってないのと違うかな。
ドライバとスタブの作成フレームワークとしてxUnitを使ってるだけ、と。
極端な話、テストケース1件、確認項目0件でも、
ドライバからメソッドを呼べて、それがスタブを使って駆動できればOK、
ちゅーレベル。
自明な部分はテストしない。
自明じゃない部分はテストする。
そのテストをxUnitを使って行う。
xUnitを使わないところは、そもそもテストをしないところだ。
それで話は終わりだろ？
自明じゃない部分はテストする。
そのテストをxUnitを使って行う。
xUnitを使わないところは、そもそもテストをしないところだ。
それで話は終わりだろ？
>>755
> 地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
> 単体はこれで充分
それ、プログラムが修正されるたびに全部ちゃんとやってるか？
それともサボっているか？
どっちか答えよ。
> 地味にステップ実行で、カバレッジ・条件網羅を行う、もちろん全ての変数の値も確かめながらやる
> 単体はこれで充分
それ、プログラムが修正されるたびに全部ちゃんとやってるか？
それともサボっているか？
どっちか答えよ。
テストを書く→プログラムを作る。
これをTDDと呼ぶのに対して、
プログラムを作る→ステップ実行でテストする→テストが完了する→リファクタリング支援ツールでプログラムを作る→テストが不要になる。
これを、リファクタリング支援ツール駆動開発と呼ぶ。
これをTDDと呼ぶのに対して、
プログラムを作る→ステップ実行でテストする→テストが完了する→リファクタリング支援ツールでプログラムを作る→テストが不要になる。
これを、リファクタリング支援ツール駆動開発と呼ぶ。
ステップ実行(笑)
>>768
ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。
ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。
ステップ実行もxUnitも
やっていることは一緒、
ならなぜxUnitが必要なのか？
やっていることは一緒、
ならなぜxUnitが必要なのか？
xUnitをやれば完璧。
なぜなら自明じゃないところはテストしなくて良いし、
自明じゃないところだけxUnitをすればいいから。
なぜなら自明じゃないところはテストしなくて良いし、
自明じゃないところだけxUnitをすればいいから。
「なぜなら」の前後が芸術的なまでに関係ねーなw
xUnitを単体テストに使っている奴が多いみたいだが
それで上手く行っているなら、良い事だと思うが３つ教えてくれ
①条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか？
それとも、それ以外か？
②システムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
そのテストコード自身の信頼性はどうしてる？
>>771
>ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。
もちろん、こんなアホな考えはしない、xUnit自身の信頼性はあると思っているが
しかしテストコードは、人間がやるコーディングだからミスはあると思うが？
※①で機能でテストコードの場合は、③は無視してくれ
③単体はホワイトボックステストで行う事が多いと思っている（俺的には単体＝ホワイトボックステスト）
xUnit単体では、ホワイトボックステストでの確認が出来ないが、それについて
どのように考えるのか？ 割り切っているのか？
俺的には特別なツールを使わないでテストする場合、ステップ実行しか確認方法は無いと思っている
つまり、単体＝ホワイトボックステスト＝ステップ実行だから、単体＝ステップ実行となる
それで上手く行っているなら、良い事だと思うが３つ教えてくれ
①条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか？
それとも、それ以外か？
②システムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
そのテストコード自身の信頼性はどうしてる？
>>771
>ダウト。 自動的に修正されたものが正しいことを確認しないと意味がない。
もちろん、こんなアホな考えはしない、xUnit自身の信頼性はあると思っているが
しかしテストコードは、人間がやるコーディングだからミスはあると思うが？
※①で機能でテストコードの場合は、③は無視してくれ
③単体はホワイトボックステストで行う事が多いと思っている（俺的には単体＝ホワイトボックステスト）
xUnit単体では、ホワイトボックステストでの確認が出来ないが、それについて
どのように考えるのか？ 割り切っているのか？
俺的には特別なツールを使わないでテストする場合、ステップ実行しか確認方法は無いと思っている
つまり、単体＝ホワイトボックステスト＝ステップ実行だから、単体＝ステップ実行となる
>>776
１．両方
機能からテストケース起こして、1回目実行でカバレッジ計測。
その後詳細設計とテストケースの見直し。
２．レビュー
この辺はxUnitでもステップ実行でも変わらんやろ。
３．何が聞きたいのか意味分からん。
網羅性気にしてる時点でホワイトボックスだけど。
ホワイトボックステストが何かを誤解しとるのと違うか？
１．両方
機能からテストケース起こして、1回目実行でカバレッジ計測。
その後詳細設計とテストケースの見直し。
２．レビュー
この辺はxUnitでもステップ実行でも変わらんやろ。
３．何が聞きたいのか意味分からん。
網羅性気にしてる時点でホワイトボックスだけど。
ホワイトボックステストが何かを誤解しとるのと違うか？
xUnitとステップ実行の一番の違いは、ｘUnitはバッチ等に組み込んで
自動で繰り返し実行できること。
antみたいなビルドツールでまとめてとか、HudsonみたいなCIサーバを使って
ソース管理にコミットされた時に自動で走らすとが出来るのはそれなりの
メリットではある。
そういう自動化を使わない、考慮しない環境ならステップ実行でもそんなに
変わるわけじゃないからね。 繰り返し試験を行わない、それほどバグが出ない
とかほとんど使われない機能とかの場合はxUnitだとコード書く分のコストが
かかるからやらない方がいいこともある。
自動で繰り返し実行できること。
antみたいなビルドツールでまとめてとか、HudsonみたいなCIサーバを使って
ソース管理にコミットされた時に自動で走らすとが出来るのはそれなりの
メリットではある。
そういう自動化を使わない、考慮しない環境ならステップ実行でもそんなに
変わるわけじゃないからね。 繰り返し試験を行わない、それほどバグが出ない
とかほとんど使われない機能とかの場合はxUnitだとコード書く分のコストが
かかるからやらない方がいいこともある。
>>775
それが成立するには第三者とやらから完全に信用を得ないと駄目だな
それが成立するには第三者とやらから完全に信用を得ないと駄目だな
は？
ステップ実行でテストとは、よっぽど信用ないのね
テストコードの正当性を第三者のレビューでチェックするというのはちょっと「？」だ。
もし自分が他人のテストコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか？
無理とは言わないが、それは第三者にとって相当な負担になる気がする。
もし自分が他人のテストコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか？
無理とは言わないが、それは第三者にとって相当な負担になる気がする。
一人で開発する時はどうするの？て話にもなるな。
それはある。完璧だと思ってても意外と見落としてたりする。
>>783
コードの正当性を第三者のレビューでチェックするというのはちょっと「？」だ。
もし自分が他人のコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか？
無理とは言わないが、それは第三者にとって相当な負担になる気がする。
って言われたらどうする？
コードの正当性を第三者のレビューでチェックするというのはちょっと「？」だ。
もし自分が他人のコードを見せられたとして、そのコードを書いた本人より的確にチェックできるだろうか？
無理とは言わないが、それは第三者にとって相当な負担になる気がする。
って言われたらどうする？
レビューというものを軽く考えてる気がする
そりゃお遊戯会みたいなのもあるが、たいていは参加者全員がコードの大部分を理解しないとどうにもならんのだぞ
それだけの労力を毎回ゼロから生成するとかありえん
そりゃお遊戯会みたいなのもあるが、たいていは参加者全員がコードの大部分を理解しないとどうにもならんのだぞ
それだけの労力を毎回ゼロから生成するとかありえん
>>788
何を言いたいのか良くわからん。
何を言いたいのか良くわからん。
>>783
「気がする」ってことは、実際に他人が書いたテストコードを見たこと無いわけだね。
だから「相当な負担になるかもしれない」なんて思うんだよ。
あるいは、君が書くテストコードがあまりにひどくて、他人もそんなテストコードを書いてると思ってるとか。
「気がする」ってことは、実際に他人が書いたテストコードを見たこと無いわけだね。
だから「相当な負担になるかもしれない」なんて思うんだよ。
あるいは、君が書くテストコードがあまりにひどくて、他人もそんなテストコードを書いてると思ってるとか。
なんかxUnitのテストをオオゲサに考えてる人がいるみたいだけど、基本はこんな感じだよ。
cppunit内の自分自身をテストするコードのひとつ。
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/examples/cppunittest/TestTest.cpp?revision=343&view=markup
これ読むのそんなに負担か？
cppunit内の自分自身をテストするコードのひとつ。
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/examples/cppunittest/TestTest.cpp?revision=343&view=markup
これ読むのそんなに負担か？
>>776
お前はxUnitを使わないんだよな？
俺も聞きたいことがあるんだが。
> ①条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか？
> それとも、それ以外か？
条件網羅で、お前はどうやってテストしているんだ？
作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか？
修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか？
> ②システムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
> そのテストコード自身の信頼性はどうしてる？
xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
そのテスト項目の信頼性はどうしてる？ 人間が間違いなくテストを行ったと信じる根拠は何？
お前はxUnitを使わないんだよな？
俺も聞きたいことがあるんだが。
> ①条件網羅でテストコードを書くのか、それとも機能でテストコードを書くのか？
> それとも、それ以外か？
条件網羅で、お前はどうやってテストしているんだ？
作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか？
修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか？
> ②システムの単体をxUnitで行うとなると、大量のテストコードを作成すると思うが
> そのテストコード自身の信頼性はどうしてる？
xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
そのテスト項目の信頼性はどうしてる？ 人間が間違いなくテストを行ったと信じる根拠は何？
>>791
テストコードのコードが
普通のプログラミングのコードみたいに複雑だと
勘違いしているみたいだね。
テストコードでかかれるコードは、すごく単純。
Aを入れたらBが返る。
Aを入れたらオブジェクトの状態がBになる。
人間の言葉でテスト内容を書くのと大差ないレベルなんだよね。
テストコードのコードが
普通のプログラミングのコードみたいに複雑だと
勘違いしているみたいだね。
テストコードでかかれるコードは、すごく単純。
Aを入れたらBが返る。
Aを入れたらオブジェクトの状態がBになる。
人間の言葉でテスト内容を書くのと大差ないレベルなんだよね。
xUnit使ってる奴で自明な部分はテストを書かないって奴は、カバレッジツールとか使わないのかな？
カバレッジツール使うと、少なくともメソッド網羅率100%にしないと、どのテストが書かれてないかが
分かりづらいし、そもそも100%になってないと非常に気持ちが悪い。
「自明」って言うくらいなんだから、テストメソッド書くのも一瞬でしょ。
カバレッジツール使うと、少なくともメソッド網羅率100%にしないと、どのテストが書かれてないかが
分かりづらいし、そもそも100%になってないと非常に気持ちが悪い。
「自明」って言うくらいなんだから、テストメソッド書くのも一瞬でしょ。
TDDでやってるから、テストが無いメソッドなど存在しない
これぐらいテスト無くても良いだろうと思って作っていると、
ある程度大きくなってちゃんと作りたくなってくると、
やっぱりテスト書いとけばよかったってなってくる。
ある程度大きくなってちゃんと作りたくなってくると、
やっぱりテスト書いとけばよかったってなってくる。
複雑であるべき理由がないなら教育して書き直させるだけ。
理由があるならレビュアが頑張って理解するしかないだろね。
今んとこ、お目にかかったことないけど。
理由があるならレビュアが頑張って理解するしかないだろね。
今んとこ、お目にかかったことないけど。
>>796
あるある
あるある
とりあえず xUnit を使おうが使うまいがレビューは必要だってことは分かりました
>>777
>１．両方
それは駄目だろう
>２．レビュー
それだと、単体テスト自体もレビューで良いと言う事にならないか？
なぜ、同じ人間が同じ言語で書いたのに、コードはテストして
テストコードはレビューで良いとなる理屈が分からん？
>ホワイトボックステストが何かを誤解しとるのと違うか？
何かホワイトボックステストを勘違いしている奴が多過ぎる
ホワイトボックステストは、プログラムの内部構造を元にテストするもの
したがって、「シーケンス制御」も確認する
つまり、動作を順序が正しいか、ステップ実行で確かめる、xUnitじゃ確認出来ないぞ
>>792
>条件網羅で、お前はどうやってテストしているんだ？
まず、チェックリストを作る、この時コード１行毎の「シーケンス制御」・「変数値」も明記する、それでステップ実行で確認
>作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか？
なんで、途中でテスト終了と言う話になるんだ、条件網羅が理解出来ているか？
>修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか？
もちろん、単体は追加分だけだ、修正が無いコードは単体では影響がない
>xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
>そのテスト項目の信頼性はどうしてる？ 人間が間違いなくテストを行ったと信じる根拠は何？
お前は馬鹿か？ 条件網羅だと言っているからカバレッジである程度の信頼性はあるだろう
機能テストを行なうと言っている訳じゃない、条件網羅だから機械的にテストケースは考えられる
本当に何も分かってないだろう
>１．両方
それは駄目だろう
>２．レビュー
それだと、単体テスト自体もレビューで良いと言う事にならないか？
なぜ、同じ人間が同じ言語で書いたのに、コードはテストして
テストコードはレビューで良いとなる理屈が分からん？
>ホワイトボックステストが何かを誤解しとるのと違うか？
何かホワイトボックステストを勘違いしている奴が多過ぎる
ホワイトボックステストは、プログラムの内部構造を元にテストするもの
したがって、「シーケンス制御」も確認する
つまり、動作を順序が正しいか、ステップ実行で確かめる、xUnitじゃ確認出来ないぞ
>>792
>条件網羅で、お前はどうやってテストしているんだ？
まず、チェックリストを作る、この時コード１行毎の「シーケンス制御」・「変数値」も明記する、それでステップ実行で確認
>作りながらテストして、うごくっぽいと思ったらそこでテスト終了で何のテストをしたかなど書かないのか？
なんで、途中でテスト終了と言う話になるんだ、条件網羅が理解出来ているか？
>修正があったら、追加分だけテストして、今までのコードは動くだろうということでテストしないのか？
もちろん、単体は追加分だけだ、修正が無いコードは単体では影響がない
>xUnitを使わなくても、テストすべき数はテストコードを書いた場合と同じだけ存在するはずだが、
>そのテスト項目の信頼性はどうしてる？ 人間が間違いなくテストを行ったと信じる根拠は何？
お前は馬鹿か？ 条件網羅だと言っているからカバレッジである程度の信頼性はあるだろう
機能テストを行なうと言っている訳じゃない、条件網羅だから機械的にテストケースは考えられる
本当に何も分かってないだろう
テストコードはシンプルだからレビューは簡単という意見はおかしくないか？
仕様を把握するだけでも面倒なのにそれを一つずつ照らし合わせていくんだよ？
本当に実務でレビューしたことあるの？
仕様を把握するだけでも面倒なのにそれを一つずつ照らし合わせていくんだよ？
本当に実務でレビューしたことあるの？
>>802
もう相手は馬鹿だ合戦はやめにしない？なんの生産性もないよ？
ところで、xUnitに限らず自動テストがステップ実行に勝る点は、別環境でも時間をかけずにテスト
できるというのもあげられる。
自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
したんだけど、自動テストは大いに役立ったよ。
それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。
もう相手は馬鹿だ合戦はやめにしない？なんの生産性もないよ？
ところで、xUnitに限らず自動テストがステップ実行に勝る点は、別環境でも時間をかけずにテスト
できるというのもあげられる。
自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
したんだけど、自動テストは大いに役立ったよ。
それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。
>>803
レビュー実行の容易性について考えると、テストコードがあれば簡単にレビューできるということで、
対象のテストコードやプロダクトの複雑さは言及してなかったつもりだが、言葉が足りなかったかもしれない。
もちろん、そこにテストコードがあるから誰もが内容を容易に理解できるわけではない。
レビュー実行が簡単かどうかの比較対象は、古くからの「入力データと出力データのエビデンスと
テスト内容のチェック」や「ステップ実行によるテスト」など。後者はそもそもレビュー不可能。
レビュー実行の容易性について考えると、テストコードがあれば簡単にレビューできるということで、
対象のテストコードやプロダクトの複雑さは言及してなかったつもりだが、言葉が足りなかったかもしれない。
もちろん、そこにテストコードがあるから誰もが内容を容易に理解できるわけではない。
レビュー実行が簡単かどうかの比較対象は、古くからの「入力データと出力データのエビデンスと
テスト内容のチェック」や「ステップ実行によるテスト」など。後者はそもそもレビュー不可能。
プログラマーの書くテストについては気休め程度に考えるのが良い気がしてきた。
テストコードの信頼性まで厳密にチェックしようとすると会社が回んないと思う。
もちろん品質管理部門でしっかりしたテストを行うことが前提だけどね。
テストコードの信頼性まで厳密にチェックしようとすると会社が回んないと思う。
もちろん品質管理部門でしっかりしたテストを行うことが前提だけどね。
俺も>>807と同じ意見だ。
>>806
エビデンスよりテスト項目のレビューが重要
エビデンスよりテスト項目のレビューが重要
つか、xUnitだけやってテスト終わりましたとか言われて納品されても契約で
そこまでとしてない限りは受け取らないだろ。
そこまでとしてない限りは受け取らないだろ。
>>805
>自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
>したんだけど、自動テストは大いに役立ったよ。
なるほど、64bitはやった事が無いが単体でも違いが出そうな気がする、例えば整数型は
CPUのレジスタに依存する場合が多い、だから2^32か2^64だと動きも違ってくるか？
今まで聞いた中で一番、xUnitの良い使い方だと思う
>それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。
何か俺とは前提が違う気がする、そろそろ話を整理しないか？ まずはテストの範囲から
俺が行なっているテストの範囲は
・単体テスト：コードの正しさをテストする、機能が間違っていても構わないコードの正しさのみ求める
・結合テスト：機能の正しさをテストする、機能間の整合性を中心にテストする
・総合テスト：異環境でも正しく動く事をテストする、OS・他アプリ・セキュリティ絡みをテストする
このやり方だから、開発環境が無いPCは総合テストの時に行なう、それとも総合でxUnitを使っているのか？
>自前のプロダクトがWindows 7の各エディションの32/64bitでちゃんと動くかどうか、こないだ検証
>したんだけど、自動テストは大いに役立ったよ。
なるほど、64bitはやった事が無いが単体でも違いが出そうな気がする、例えば整数型は
CPUのレジスタに依存する場合が多い、だから2^32か2^64だと動きも違ってくるか？
今まで聞いた中で一番、xUnitの良い使い方だと思う
>それともう一つのメリットは、開発環境が無いPCでも実行できるとこ。まぁ言わずもがななんだけど。
何か俺とは前提が違う気がする、そろそろ話を整理しないか？ まずはテストの範囲から
俺が行なっているテストの範囲は
・単体テスト：コードの正しさをテストする、機能が間違っていても構わないコードの正しさのみ求める
・結合テスト：機能の正しさをテストする、機能間の整合性を中心にテストする
・総合テスト：異環境でも正しく動く事をテストする、OS・他アプリ・セキュリティ絡みをテストする
このやり方だから、開発環境が無いPCは総合テストの時に行なう、それとも総合でxUnitを使っているのか？
>>809
> エビデンスよりテスト項目のレビューが重要
もちろんそれは大事。
だけど、xUnit（というか自動テスト）じゃない場合に、どうやって「テスト実行のレビュー」をするのかということ。
xUnit（というか自動テスト）だったら楽だよねということ。
>>810
> 実行してる内容の正当性をどうやって確保してんのかなって話じゃん。
ん？だから、正当性を知りたければ、テストコードを見れば良いという話。
>>812
実行できるEXEやLMがそこにあるなら動かして、その範囲で正しく動いてるのが確認できるなら実行しない手はないでしょ。
それと、総合テストでもxUnitを使っても何ら問題ないし、受け入れテストで使っても何の問題もないよ。
> エビデンスよりテスト項目のレビューが重要
もちろんそれは大事。
だけど、xUnit（というか自動テスト）じゃない場合に、どうやって「テスト実行のレビュー」をするのかということ。
xUnit（というか自動テスト）だったら楽だよねということ。
>>810
> 実行してる内容の正当性をどうやって確保してんのかなって話じゃん。
ん？だから、正当性を知りたければ、テストコードを見れば良いという話。
>>812
実行できるEXEやLMがそこにあるなら動かして、その範囲で正しく動いてるのが確認できるなら実行しない手はないでしょ。
それと、総合テストでもxUnitを使っても何ら問題ないし、受け入れテストで使っても何の問題もないよ。
「xUnitは品質を担保するものではない」って言ってる人は、多分こんなことを考えてるんだと思う。
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等）
http://d.hatena.ne.jp/goyoki/20100223/1266939139
厳密に言うと、「TDDでxUnitを使う場合は、そのテストコードは品質を担保するものではない」ってこと。
単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等）
http://d.hatena.ne.jp/goyoki/20100223/1266939139
厳密に言うと、「TDDでxUnitを使う場合は、そのテストコードは品質を担保するものではない」ってこと。
単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。
>>807
いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
ざっとレビューすりゃいいじゃん。
ひょっとして>>791が読めないの？
それともこれまで通り、Excelにずらずら書かれた単体テスト仕様書みたいなものを
レビューして、結果にはメクラ判を押すのかな？あるいは「単体はステップ実行で
終わりましたー。」「おつかれさん」レベル？
いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
ざっとレビューすりゃいいじゃん。
ひょっとして>>791が読めないの？
それともこれまで通り、Excelにずらずら書かれた単体テスト仕様書みたいなものを
レビューして、結果にはメクラ判を押すのかな？あるいは「単体はステップ実行で
終わりましたー。」「おつかれさん」レベル？
TDDについて
http://togetter.com/li/6923
http://togetter.com/li/6923
>>814
一般的な単体テストはまた別にやるってことだな。
一般的な単体テストはまた別にやるってことだな。
単体テストって言葉が複数の意味で使われてるから訳わかんなくなるんだよ
単体でテストすれば、一応は単体テストだからな
TDD/BDDなんかで書いたような「コーディング途中で検証に使った」テストも単体テストに入る
TDD/BDDなんかで書いたような「コーディング途中で検証に使った」テストも単体テストに入る
複数の意味にうまいこと別名をつけてください
一般的な単体テスト→単体テスト
設計目的の単体テスト→設計
設計目的の単体テスト→設計
単体テスト→コードテスト
結合テスト→機能テスト
結合テスト→機能テスト
xUnitをテストに使ってる奴で、まともな反論も出来ない奴ばかりだな
もともと、xUnitや単体テストを正しく理解していない
>>813
やっぱり、コイツ駄目だな
>>814
>単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。
既存のテスト方法並に、品質が担保出来るか？
>>815
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが？
逆に複雑だとテストコードもテストするのか？
もともと、xUnitや単体テストを正しく理解していない
>>813
やっぱり、コイツ駄目だな
>>814
>単体テスト目的でxUnitでテストを書くのは、もちろん品質を担保するため。
既存のテスト方法並に、品質が担保出来るか？
>>815
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが？
逆に複雑だとテストコードもテストするのか？
>>815
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
ざっとレビューって具体的にはどうするの？
それでテストコードの信頼性を厳密にチェックできるの？
>いやだからあのね、単体レベルのテストコードなんて>>791みたいなものなんだから、
>ざっとレビューすりゃいいじゃん。
ざっとレビューって具体的にはどうするの？
それでテストコードの信頼性を厳密にチェックできるの？
>>824
> ざっとレビューって具体的にはどうするの？
ちょっと意味がわからないです。
「コードレビューって具体的にはどうするの？」と聞かれても、「えっと、コードを見ます」
以外に答えようがないというか。
> それでテストコードの信頼性を厳密にチェックできるの？
そこに書かれている範囲で、確かに動作するということは確認できます。
それが「既存のテスト方法」（ってステップ実行のこと？）との違いです。
> ざっとレビューって具体的にはどうするの？
ちょっと意味がわからないです。
「コードレビューって具体的にはどうするの？」と聞かれても、「えっと、コードを見ます」
以外に答えようがないというか。
> それでテストコードの信頼性を厳密にチェックできるの？
そこに書かれている範囲で、確かに動作するということは確認できます。
それが「既存のテスト方法」（ってステップ実行のこと？）との違いです。
>>823
>それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが？
一般に、テスト対象のコードより、テストコードの方が簡潔で分り易いです。
（ド下手なテストコードということも考えられますが、それは例外として。）
例えば>>791で主にテストされているTestPathクラスのソースは
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/src/cppunit/TestPath.cpp?revision=441&view=markup
なんですが、このコードから帰納的にテストコードで記述されている仕様を得るのは
時間がかかると思いませんか？
>それだと、プログラムのコードも、単純ならレビューで良いと言う事になるが？
一般に、テスト対象のコードより、テストコードの方が簡潔で分り易いです。
（ド下手なテストコードということも考えられますが、それは例外として。）
例えば>>791で主にテストされているTestPathクラスのソースは
http://cppunit.svn.sourceforge.net/viewvc/cppunit/trunk/cppunit/src/cppunit/TestPath.cpp?revision=441&view=markup
なんですが、このコードから帰納的にテストコードで記述されている仕様を得るのは
時間がかかると思いませんか？
「既存のテスト方法並に、品質が担保出来る」根拠がわからない。
というか、既存のテスト方法ってなんだ？
というか、既存のテスト方法ってなんだ？
なんだか良くわからない文章だったので訂正。
>「既存のテスト方法並に、品質が担保出来る」根拠がわからない。
↓
既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。
>「既存のテスト方法並に、品質が担保出来る」根拠がわからない。
↓
既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。
>>816,825
読みごたえあるね。このスレの糞な奴らとは大違いｗ
読みごたえあるね。このスレの糞な奴らとは大違いｗ
xUnitの問題点を挙げているが、それ以上に問題点が多いのが、
手動によるステップ実行。そういう結論だよ。
人間は間違いを犯す。
手動だと時間がかかる。特に再テストする場合。
手動でテストするためにチェックリストを作ったとして、そのチェックリスト内容を本当に実行したという担保が無い。
リストだけ立派で、それ本当にテストしたんですか？ということがおきる。
ステップ実行テストを後からレビューすることができない。録画すればできるか？ｗ やってないだろうけど。
つまりは、チェックリストのレビューと、チェック作業のレビューが必要になる。
本質的には同じことをしているのに、無駄に重複してしまう。
ある関数を修正したら、その関数を使用している関数（こっちは修正なし）もすべてテストしなければいけないというのがわかっていない。
手動でこれを実際にやったら大変だからテストをサボる。
xUnitのテストコードが簡単だということが理解できていない。複雑なテストコードもある？
あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になるってことが理解できていない。
手動によるステップ実行。そういう結論だよ。
人間は間違いを犯す。
手動だと時間がかかる。特に再テストする場合。
手動でテストするためにチェックリストを作ったとして、そのチェックリスト内容を本当に実行したという担保が無い。
リストだけ立派で、それ本当にテストしたんですか？ということがおきる。
ステップ実行テストを後からレビューすることができない。録画すればできるか？ｗ やってないだろうけど。
つまりは、チェックリストのレビューと、チェック作業のレビューが必要になる。
本質的には同じことをしているのに、無駄に重複してしまう。
ある関数を修正したら、その関数を使用している関数（こっちは修正なし）もすべてテストしなければいけないというのがわかっていない。
手動でこれを実際にやったら大変だからテストをサボる。
xUnitのテストコードが簡単だということが理解できていない。複雑なテストコードもある？
あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になるってことが理解できていない。
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%
- テスト駆動開発（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%
>>831
> あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になる
世界を構築するような複雑な前処理が必要でも、ステップ実行だと、目的の行にブレークポイントを
おけば良いので、関係ないんです。
逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。
> あったとして複雑なテストコードが必要になるのなら、それを手動のテストでやるともっと複雑になる
世界を構築するような複雑な前処理が必要でも、ステップ実行だと、目的の行にブレークポイントを
おけば良いので、関係ないんです。
逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。
ステップ実行テストとかしているやつは、
ショッピングカートに商品を入れて、
住所氏名など入力して、購入完了！
あっ、在庫減らす処理忘れていた。
ってとき、また在庫戻して、購入履歴消して
データベースの状態を同じに戻して、
また最初っからショッピングカートに商品入れて
・・・ってところからはじめるの？（笑）
そういう一連の動きのテストやらないの？
もしかして、言われた関数だけ作るアルバイトかな？
ショッピングカートに商品を入れて、
住所氏名など入力して、購入完了！
あっ、在庫減らす処理忘れていた。
ってとき、また在庫戻して、購入履歴消して
データベースの状態を同じに戻して、
また最初っからショッピングカートに商品入れて
・・・ってところからはじめるの？（笑）
そういう一連の動きのテストやらないの？
もしかして、言われた関数だけ作るアルバイトかな？
同じようなことをいつまでグダグダ言ってんだよ。
xUnit派の俺様でも、さすがにあきれるよ。
xUnit派の俺様でも、さすがにあきれるよ。
>>832
底辺PGだらけのカス企業でもメトリクス取ってみてほしいわ
底辺PGだらけのカス企業でもメトリクス取ってみてほしいわ
>>802
>>１．両方
>それは駄目だろう
なんで？
>>２．レビュー
>それだと、単体テスト自体もレビューで良いと言う事にならないか？
極端に言えばその通り。
ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
おらんので、テストせざるを得んだけ。
>何かホワイトボックステストを勘違い云々
ホワイトボックスとは何かはさておき、言いたいことは分かった。
ような気がする。
シーケンスって処理フローのことよな？
簡単に言うと、関数の外部に関係するフローはITで見る。
内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。
>>１．両方
>それは駄目だろう
なんで？
>>２．レビュー
>それだと、単体テスト自体もレビューで良いと言う事にならないか？
極端に言えばその通り。
ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
おらんので、テストせざるを得んだけ。
>何かホワイトボックステストを勘違い云々
ホワイトボックスとは何かはさておき、言いたいことは分かった。
ような気がする。
シーケンスって処理フローのことよな？
簡単に言うと、関数の外部に関係するフローはITで見る。
内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。
.NET でカバレッジ計測するいいツールない？
どのみちITとSTはやるでしょ。
で、品管に回すのってSTまで終わってからじゃないの？
まぁITもxUnit的な方法かも知れないけども。
で、品管に回すのってSTまで終わってからじゃないの？
まぁITもxUnit的な方法かも知れないけども。
>>834
＞そういう一連の動きのテストやらないの？
＞もしかして、言われた関数だけ作るアルバイトかな？
それを単体テストと位置づけてるか、位置づけていないかの違い。
xUnitでも上記の条件のような試験はできるけど、そういうテストコード書くくらい
なら、もう少し実装に近い機能単位でテストコードを書くようにして、複雑な条件が
必要なテストは結合とかのもう少し後工程のテストでやるって考えかな。
＞そういう一連の動きのテストやらないの？
＞もしかして、言われた関数だけ作るアルバイトかな？
それを単体テストと位置づけてるか、位置づけていないかの違い。
xUnitでも上記の条件のような試験はできるけど、そういうテストコード書くくらい
なら、もう少し実装に近い機能単位でテストコードを書くようにして、複雑な条件が
必要なテストは結合とかのもう少し後工程のテストでやるって考えかな。
>>839
> 826は実装者の書いたテストとは別に品質管理部門のテストがあるという前提？
いえ、そのような前提はありません。
品質管理部門があろうがなかろうが、後続のテストプロセスがどのようなものだろうと、
目の前のテストコードを読む方法はかわりません。
（review methodが変わらないということではなく、code reading methodが変わらない
ということ）
その意味で>>824の
>ざっとレビューって具体的にはどうするの？
は、意味がわからないのです。
ひょっとして>>824は、code reading methodではなくてreview methodの話だったんでしょうか。
さらに言えば、誰かがレビューしようとしまいと、現実に存在するテストコードは
そこに書かれている範囲でテスト対象コードの動作を保証しています。
そこに書かれているテストコードが信頼できるものかどうかを知りたいなら、
内容を読めばわかります。このことのどこに疑問が沸くのかわからないのです。
> 826は実装者の書いたテストとは別に品質管理部門のテストがあるという前提？
いえ、そのような前提はありません。
品質管理部門があろうがなかろうが、後続のテストプロセスがどのようなものだろうと、
目の前のテストコードを読む方法はかわりません。
（review methodが変わらないということではなく、code reading methodが変わらない
ということ）
その意味で>>824の
>ざっとレビューって具体的にはどうするの？
は、意味がわからないのです。
ひょっとして>>824は、code reading methodではなくてreview methodの話だったんでしょうか。
さらに言えば、誰かがレビューしようとしまいと、現実に存在するテストコードは
そこに書かれている範囲でテスト対象コードの動作を保証しています。
そこに書かれているテストコードが信頼できるものかどうかを知りたいなら、
内容を読めばわかります。このことのどこに疑問が沸くのかわからないのです。
>>842
例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ？
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
ハードコーディングしない場合でもリソース番号1番のところを2番と勘違いしてる場合とかね。
例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ？
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
ハードコーディングしない場合でもリソース番号1番のところを2番と勘違いしてる場合とかね。
>>843
>でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
いまいち質問の意図がわからないのですが･･･。
要求仕様との適合性をレビューで確認できるかということでしたら、
その仕様を知っており、なおかつ仕様との適合性をチェックしようと
いう意志を持ってレビューすれば確認できるとしか言えません。
>でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
いまいち質問の意図がわからないのですが･･･。
要求仕様との適合性をレビューで確認できるかということでしたら、
その仕様を知っており、なおかつ仕様との適合性をチェックしようと
いう意志を持ってレビューすれば確認できるとしか言えません。
>>844
「えっと、コードを見ます」と言うからコードしか見ないんだと思ってたよ。
>その仕様を知っており、なおかつ仕様との適合性をチェックしようと
>いう意志を持ってレビューすれば確認できるとしか言えません。
そこをきっちりやるなら問題ないと思う。
ただUTレビュー段階でそこまでやるのは大変だと思うけど。
「えっと、コードを見ます」と言うからコードしか見ないんだと思ってたよ。
>その仕様を知っており、なおかつ仕様との適合性をチェックしようと
>いう意志を持ってレビューすれば確認できるとしか言えません。
そこをきっちりやるなら問題ないと思う。
ただUTレビュー段階でそこまでやるのは大変だと思うけど。
話がかみあったのかどうか自信がありませんが、良しとしましょう。
「自然言語で書かれたテストケースの（テスト仕様書）の品質を確認するために
レビューしましょう」と言うと、おそらく誰からも異論も疑問も出ないと思うんですが、
「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
反発や疑問が出るのが不思議です。
「自然言語で書かれたテストケースの（テスト仕様書）の品質を確認するために
レビューしましょう」と言うと、おそらく誰からも異論も疑問も出ないと思うんですが、
「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
反発や疑問が出るのが不思議です。
そんな話なの？
わざわざ「レビューする」に「ざっと」とか付けてたから
「おおまかにコードをナナメ読みして問題がなさそうならOK」
と読んだよ。（俺は、だが）
テストコードの検証ってそんなんでいいの？って話じゃないの？
わざわざ「レビューする」に「ざっと」とか付けてたから
「おおまかにコードをナナメ読みして問題がなさそうならOK」
と読んだよ。（俺は、だが）
テストコードの検証ってそんなんでいいの？って話じゃないの？
>>847
テストコードのレビューがすごく大変って言っている奴がいるから、
別に大変じゃない。レビューといえないぐらいのレベルで終わるって反論されてるだけだろ。
話を摩り替えるなよ。
それで、xUnitのテストコードのレビューに対抗して、
じゃあ手動テストのレビューはどうすんの？って問いの答えはどうなったんだ？
テストコードのレビューがすごく大変って言っている奴がいるから、
別に大変じゃない。レビューといえないぐらいのレベルで終わるって反論されてるだけだろ。
話を摩り替えるなよ。
それで、xUnitのテストコードのレビューに対抗して、
じゃあ手動テストのレビューはどうすんの？って問いの答えはどうなったんだ？
>>843
> 例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ？
> でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
じゃあその話を手動テストに置き換えてみましょうか？
例えばファイルに"apple"と出力するメソッドの手動コードは"apple"の文字列を確認するでしょ？
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
手動テストにすることで何か解決しましたか？
間違ったテストをしてしまいましたね。
でも手動だから間違ったテストをしたという記録が残りませんね。
どんなテストをしたかの記録が無いまま、テストはOKとして扱われるわけです。
> 例えばファイルに"apple"と出力するメソッドのテストコードは"apple"の文字列を確認するでしょ？
> でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
じゃあその話を手動テストに置き換えてみましょうか？
例えばファイルに"apple"と出力するメソッドの手動コードは"apple"の文字列を確認するでしょ？
でも仕様では"apple"じゃなくて"lemon"かもしれない。その確認はどうするの？
手動テストにすることで何か解決しましたか？
間違ったテストをしてしまいましたね。
でも手動だから間違ったテストをしたという記録が残りませんね。
どんなテストをしたかの記録が無いまま、テストはOKとして扱われるわけです。
>>850
意図的に議論をややこしくしてるだろ？
意図的に議論をややこしくしてるだろ？
その話が終わってるのが理解できてないだけじゃない？
>>847
>「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
>反発や疑問が出るのが不思議です。
「品質管理部門が使うテストコードを厳密にレビューしましょう」なら反発されないと思うよ。
「TDDで実装者が書くテストコードを厳密にレビューしましょう」だと反発されるだろうね。
あと843と694は別人なのであしからず。
>「xUnitで書かれたテストコードの品質を知りたいなら、レビューしましょう」と言うと、
>反発や疑問が出るのが不思議です。
「品質管理部門が使うテストコードを厳密にレビューしましょう」なら反発されないと思うよ。
「TDDで実装者が書くテストコードを厳密にレビューしましょう」だと反発されるだろうね。
あと843と694は別人なのであしからず。
>>829
>既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。
条件網羅が確認出来る
>>831
論理がアホだな
>>832
だから、TDDはテストか開発か？ と言う事だ
それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
http://www.aerith.net/design/risk_analysis-j.html#american_japanese
>>833
>逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。
難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない
>>834
取り合えず勉強しろよ、アホが
>>837
>なんで？
なぜテストが単体・結合・総合と別れてテストするのか考えろ
>ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
複雑かどうかの基準は、人間の主観にすぎない
>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。
"カバレッジ以上には検証は必要ない"もお前の主観でしかない
テストとは、客観的でなくてわならない
>>845
>何でも良いですが、そこにxUnitで書かれたテストコードがあるなら、>>775が
>言えるという、ただそれだけのことです。
xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
>既存のテスト方法で担保できるという品質があるとするなら、それを担保できる根拠がわからない。
条件網羅が確認出来る
>>831
論理がアホだな
>>832
だから、TDDはテストか開発か？ と言う事だ
それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
http://www.aerith.net/design/risk_analysis-j.html#american_japanese
>>833
>逆に言うと、彼らはステップ実行だと簡単だけれど、テストコードを書くのは難しいと思ってる。
難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない
>>834
取り合えず勉強しろよ、アホが
>>837
>なんで？
なぜテストが単体・結合・総合と別れてテストするのか考えろ
>ただ、複雑な系をきっちり理解して漏れなくレビュー出来るような人は
複雑かどうかの基準は、人間の主観にすぎない
>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。
"カバレッジ以上には検証は必要ない"もお前の主観でしかない
テストとは、客観的でなくてわならない
>>845
>何でも良いですが、そこにxUnitで書かれたテストコードがあるなら、>>775が
>言えるという、ただそれだけのことです。
xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
> xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
一度しか行わないテストはまず無いから。
プログラムは作っていくと必ず変更がある。
直接は変更されなくても、そこで使用している関数が
変更される場合がある。
バグはどこにあるかわからない。バグを修正する行為も
プログラムの修正と同じ。
こうなった場合、同じテストを再度テストする必要がある。
それをしなかったら、手抜きという。大幅な時間短縮が可能
なぜ、時間短縮したら良いのか？ 残業代が減るだけではないのか。
という疑問がわくのなら話にならないなｗ
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
一度しか行わないテストはまず無いから。
プログラムは作っていくと必ず変更がある。
直接は変更されなくても、そこで使用している関数が
変更される場合がある。
バグはどこにあるかわからない。バグを修正する行為も
プログラムの修正と同じ。
こうなった場合、同じテストを再度テストする必要がある。
それをしなかったら、手抜きという。大幅な時間短縮が可能
なぜ、時間短縮したら良いのか？ 残業代が減るだけではないのか。
という疑問がわくのなら話にならないなｗ
>>854
> 難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない
なぜ内部変数を確認しないといけないのか。
「シーケンス制御」はなんかお前間違った用語の使いかたしてないか？
普通はハードウェアの制御のことを言うんだぞ。
> 難しいと言うか、不可能だと言っている「シーケンス制御」「内部変数」xUnitで確認出来ない
なぜ内部変数を確認しないといけないのか。
「シーケンス制御」はなんかお前間違った用語の使いかたしてないか？
普通はハードウェアの制御のことを言うんだぞ。
最初に、名前を直し忘れてア854=694だから
>>855
>プログラムは作っていくと必ず変更がある。
コーディング中と言う事か？
>直接は変更されなくても、そこで使用している関数が
>変更される場合がある。
具体的に単体（コード）テストで、修正個所以外でどのような影響が出る？
何べんも書くが単体（コード）テストでだぞ
>>856
>「シーケンス制御」はなんかお前間違った用語の使いかたしてないか？
「シーケンスの制御」で良いか？ シーケンス図とか知ってるか？
>なぜ内部変数を確認しないといけないのか。
処理後の結果だけ確認して正しければ、 バグじゃないが
想定していた値と違う値、それはコーディングミスになるが、バグじゃないから良しとするのか？
もう一度聞くが、単体で反復実行が可能だと何が良いのか詳しく説明してくれ
あと、例えばあるメソッドの機能が「日本の国コードを取得する」ものだったとする
内部では、RDBから日本の国コードを問い合わせ、その値(49)を戻り値に設定する仕様だ
この場合、xUnitではそのメソッドを実行し、その戻り値が49か確かめるシンプルなテストコードになる
その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
シンプルだからソースレビューで大丈夫だと言っている奴はどう考える？
>>855
>プログラムは作っていくと必ず変更がある。
コーディング中と言う事か？
>直接は変更されなくても、そこで使用している関数が
>変更される場合がある。
具体的に単体（コード）テストで、修正個所以外でどのような影響が出る？
何べんも書くが単体（コード）テストでだぞ
>>856
>「シーケンス制御」はなんかお前間違った用語の使いかたしてないか？
「シーケンスの制御」で良いか？ シーケンス図とか知ってるか？
>なぜ内部変数を確認しないといけないのか。
処理後の結果だけ確認して正しければ、 バグじゃないが
想定していた値と違う値、それはコーディングミスになるが、バグじゃないから良しとするのか？
もう一度聞くが、単体で反復実行が可能だと何が良いのか詳しく説明してくれ
あと、例えばあるメソッドの機能が「日本の国コードを取得する」ものだったとする
内部では、RDBから日本の国コードを問い合わせ、その値(49)を戻り値に設定する仕様だ
この場合、xUnitではそのメソッドを実行し、その戻り値が49か確かめるシンプルなテストコードになる
その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
シンプルだからソースレビューで大丈夫だと言っている奴はどう考える？
>>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をテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
自分がコードを変更したときに便利なのは言わずもがなだが、以下のような時にも便利。
・使用している同じプロジェクト内の第三者のコードが変更されたとき、自分が書いたコードが
今まで通り動くかどうか確認する
・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
自分が書いた（以下略）
・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
> 複雑かどうかの基準は、人間の主観にすぎない
そうでもない。こことか参照。
http://ja.wikipedia.org/wiki/%E5%BE%AA%E7%92%B0%E7%9A%84%E8%A4%87%E9%9B%91%E5%BA%A6
> テストとは、客観的でなくてわならない
「ステップ実行しました」ということは、客観的には検証できない。
> xUnitをテストで使うと言う奴は、”反復実行が可能”ばかり言うが、
> それなら、なぜ単体で反復実行が可能だと良いのか詳しく説明してくれ
自分がコードを変更したときに便利なのは言わずもがなだが、以下のような時にも便利。
・使用している同じプロジェクト内の第三者のコードが変更されたとき、自分が書いたコードが
今まで通り動くかどうか確認する
・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
自分が書いた（以下略）
・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
>>857
> 「シーケンスの制御」で良いか？ シーケンス図とか知ってるか？
シーケンス図的な意味のシーケンスの確認であれば、xUnitでもテストできる。
> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードが正しかったことの証明になる。
> それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
ステップ実行の時は149になるのを確認するのと同様、テストコードを149に変えるだけだが。
> 「シーケンスの制御」で良いか？ シーケンス図とか知ってるか？
シーケンス図的な意味のシーケンスの確認であれば、xUnitでもテストできる。
> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
それはテストコードが正しかったことの証明になる。
> それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
ステップ実行の時は149になるのを確認するのと同様、テストコードを149に変えるだけだが。
>>857
> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
> それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
よく考えたら、そのようなテストコードは単体テストレベルでは書かないということに気づいた。
xUnitでは、自分の力の及ばない値とのアサーションは基本的に行わない。
この場合のメソッドは、「データベースから値を取得してそれをそのまま返す」というメソッドの
はずだから、テストコードも当然それを確認するコードになる。
そして、その取得元のデータは、テストコードのあずかり知らない所で設定されてはならない。
つまり、テストコードで値を設定すべき。
> その仕様変更があり、アジアは先頭に1を付加する仕様になった、日本の国コードは149になる
> 修正個所は、RDBの値を49から149を変更するのみ、この場合にxUnitを修正せず実行するとエラーになるが
> それはテストコードのバグだ、こんな場合をどう考える？ xUnitは仕様をしらないと正しいか判断出来ないが？
よく考えたら、そのようなテストコードは単体テストレベルでは書かないということに気づいた。
xUnitでは、自分の力の及ばない値とのアサーションは基本的に行わない。
この場合のメソッドは、「データベースから値を取得してそれをそのまま返す」というメソッドの
はずだから、テストコードも当然それを確認するコードになる。
そして、その取得元のデータは、テストコードのあずかり知らない所で設定されてはならない。
つまり、テストコードで値を設定すべき。
わかるだろうが、>>858-861はずっと俺ということでよろしく。
そもそも単体テストだと、fakeクラスやmockオブジェクトを使って、データベースとは
接続しない派も多いんじゃなかろうか。Slow Testsになるし。
ちなみに俺はDBアクセスするテストとそうじゃないテストを別のLMに分けてる。
接続しない派も多いんじゃなかろうか。Slow Testsになるし。
ちなみに俺はDBアクセスするテストとそうじゃないテストを別のLMに分けてる。
>>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内のすべてのメソッドに影響を及ぼすが、それでも
他のメソッドはすべて正しく動くと言えるか？
> 具体的に単体（コード）テストで、修正個所以外でどのような影響が出る？
> 何べんも書くが単体（コード）テストでだぞ
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内のすべてのメソッドに影響を及ぼすが、それでも
他のメソッドはすべて正しく動くと言えるか？
ｘUnitに限らず、ツールとかを使うものってのは完全なものではなく、今までの
作業の肩代わりを若干してくれて、手間が多少減らせるってものだよな。
銀の弾丸は無いといいますが、これだけやってれば問題ない完璧な解決策
なんてものは無いから、使えそうなものを上手に利用して、それで
作業の肩代わりを若干してくれて、手間が多少減らせるってものだよな。
銀の弾丸は無いといいますが、これだけやってれば問題ない完璧な解決策
なんてものは無いから、使えそうなものを上手に利用して、それで
ステップ実行派は、レガシーコード改善ガイドを読んで、将来お前の書いたコードをメンテナンスする奴が、どんな
悲惨な目にあうのか気づいてくれ。
悲惨な目にあうのか気づいてくれ。
>>854
> それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
マイヤーズ本と、基礎から学ぶソフトウェアテスト、体系的ソフトウェアテスト、
Effective Software Testing、Automated Software Testingあたりを読んでから
寝言はほざけ
> それに、アメリカは品質について日本とは考え方が違う、アメリカ人の言う品質は取り合えず使えるレベル
マイヤーズ本と、基礎から学ぶソフトウェアテスト、体系的ソフトウェアテスト、
Effective Software Testing、Automated Software Testingあたりを読んでから
寝言はほざけ
Boris Beizerの方がいいと思うよ。
「ソフトウェアテスト技法」と「実践的プログラムテスト入門」。
「ソフトウェアテスト技法」と「実践的プログラムテスト入門」。
>>694って>>281じゃないの？
文章の感じが似てるし、句点打たないし、なによりステップ実行派ってのが共通してる。
まぁ>>281はxUnitのことはTDD本でしか勉強してないとのことだが。
あと、>>694はC++が読めるのかどうかはっきりしてくれ。
文章の感じが似てるし、句点打たないし、なによりステップ実行派ってのが共通してる。
まぁ>>281はxUnitのことはTDD本でしか勉強してないとのことだが。
あと、>>694はC++が読めるのかどうかはっきりしてくれ。
C++とテストってなんか関係あんの？
>>861
>つまり、テストコードで値を設定すべき。
>>863
>そもそも単体テストだと、fakeクラスやmockオブジェクトを使って、データベースとは
>接続しない派も多いんじゃなかろうか。Slow Testsになるし。
つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが．．．
それじゃ設定を変える、49をコンストで定義していたとする
日本の国コードを印刷用形式で取得するメソッドが有ったする
内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△49”と編集して戻り値に設定する
これのテストコードは？ また４９が１４９に変更された時のテストコードは？
xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
不正になる場合なんて、よくあると思うが．．．
>>864
>で、foo,barがbazを使っているときに、bazを変更したらどのようなときでもfooとbarは正しく動くと言えるか？
具体的に書いてくれ、単体レベルで修正した以外のメソッドで、どんなバグが出る？
>さらには、bazがconstではない場合、foo,bar以外のFoo内のすべてのメソッドに影響を及ぼすが、それでも
>他のメソッドはすべて正しく動くと言えるか？
フィールドの値が変ったからと言って、それが単体レベルで、どんなバグになるのか？
>>867-868
アホ、自分が見て書籍を出して知識をひけらかすな
具体的な自分の意見を書け
>つまり、テストコードで値を設定すべき。
>>863
>そもそも単体テストだと、fakeクラスやmockオブジェクトを使って、データベースとは
>接続しない派も多いんじゃなかろうか。Slow Testsになるし。
つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが．．．
それじゃ設定を変える、49をコンストで定義していたとする
日本の国コードを印刷用形式で取得するメソッドが有ったする
内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△49”と編集して戻り値に設定する
これのテストコードは？ また４９が１４９に変更された時のテストコードは？
xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
不正になる場合なんて、よくあると思うが．．．
>>864
>で、foo,barがbazを使っているときに、bazを変更したらどのようなときでもfooとbarは正しく動くと言えるか？
具体的に書いてくれ、単体レベルで修正した以外のメソッドで、どんなバグが出る？
>さらには、bazがconstではない場合、foo,bar以外のFoo内のすべてのメソッドに影響を及ぼすが、それでも
>他のメソッドはすべて正しく動くと言えるか？
フィールドの値が変ったからと言って、それが単体レベルで、どんなバグになるのか？
>>867-868
アホ、自分が見て書籍を出して知識をひけらかすな
具体的な自分の意見を書け
>>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を単体テストに使用するコストに見合うのか？
>そうでもない。こことか参照。
>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を単体テストに使用するコストに見合うのか？
>>874
> 内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△49”と編集して戻り値に設定する
> これのテストコードは？
assert(日本の国コードを取得() == ”△49”)
> また４９が１４９に変更された時のテストコードは？
assert(日本の国コードを取得() == ”149”)
こういう意味か？ 人間の言葉でテスト仕様を書くと、あいまいでわからん。
テストコードで話してくれｗ
assert(国コードを取得(日本) == ”△49”)
こっちの可能性もあるな。
> xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
> 不正になる場合なんて、よくあると思うが．．．
xUnitわかってないじゃんｗ
最初にテストコードを修正するんだよ。
そのあとテストを失敗させてから
プログラムを修正する
> 内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△49”と編集して戻り値に設定する
> これのテストコードは？
assert(日本の国コードを取得() == ”△49”)
> また４９が１４９に変更された時のテストコードは？
assert(日本の国コードを取得() == ”149”)
こういう意味か？ 人間の言葉でテスト仕様を書くと、あいまいでわからん。
テストコードで話してくれｗ
assert(国コードを取得(日本) == ”△49”)
こっちの可能性もあるな。
> xUnitを使っていると、プログラムを修正してプログラムは正常だがテストコードだけ
> 不正になる場合なんて、よくあると思うが．．．
xUnitわかってないじゃんｗ
最初にテストコードを修正するんだよ。
そのあとテストを失敗させてから
プログラムを修正する
>>874
> つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そんなこと言ってない。
> そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが．．．
後付けで品質保証目的の網羅的な単体テストレベルのテストスィートを書いても
全然問題ない。俺は先にテストするが。
> それじゃ設定を変える、49をコンストで定義していたとする
> 日本の国コードを印刷用形式で取得するメソッドが有ったする
> 内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△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");
>また４９が１４９に変更された時のテストコードは？
追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
> つまり、単体では外部DBアクセルなどは、テスト用のメソッドを使うってテストしないって事だな
そんなこと言ってない。
> そもそもテストを後回しするのは、xUnitの使い方として間違っていると思うが．．．
後付けで品質保証目的の網羅的な単体テストレベルのテストスィートを書いても
全然問題ない。俺は先にテストするが。
> それじゃ設定を変える、49をコンストで定義していたとする
> 日本の国コードを印刷用形式で取得するメソッドが有ったする
> 内部で日本の国コード取得メソッドを呼び出し、４９を取得し３桁右寄せで”△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");
>また４９が１４９に変更された時のテストコードは？
追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
>>875
> なるほど、そんな基準もあるのか、しかし、テストするしないの基準をどこに決めるのは主観だと思うが？
え？条件網羅でテストするってのは、C1カバレッジかC2カバレッジ100%を目指すってことでしょ？
循環的複雑度はまさにその客観的な指標となる値だろ。
> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
正直、お前とそれ話し合うの気が進まない。
影響が無いと思うならそれでいいじゃん、って気持ち。（投げやり）
> >・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
> > 自分が書いた（以下略）
> >・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
> それは、メリットがあると思う、32bitOSから64bitOSへの変更もそうだし、使用言語のVerUpもそうだと思う
> が、そんな事は頻繁に無いし、xUnitで大丈夫でも最終確認は総合テスト実施で行なう
> それを考えた場合、xUnitを単体テストに使用するコストに見合うのか？
人・プロダクト・環境・組織それぞれで違うので一概には言えない。
ただ一つ言えることは、10秒で終わる1万個のテストケースは、なにをするにも10秒で終わると言うことだ。
> なるほど、そんな基準もあるのか、しかし、テストするしないの基準をどこに決めるのは主観だと思うが？
え？条件網羅でテストするってのは、C1カバレッジかC2カバレッジ100%を目指すってことでしょ？
循環的複雑度はまさにその客観的な指標となる値だろ。
> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
正直、お前とそれ話し合うの気が進まない。
影響が無いと思うならそれでいいじゃん、って気持ち。（投げやり）
> >・使用しているフレームワークやライブラリ、ミドルウェアが不可抗力的にアップデートされたとき、
> > 自分が書いた（以下略）
> >・使用しているフレームワークやライブラリ、ミドルウェアをアップグレードしても良いかを調べるとき
> それは、メリットがあると思う、32bitOSから64bitOSへの変更もそうだし、使用言語のVerUpもそうだと思う
> が、そんな事は頻繁に無いし、xUnitで大丈夫でも最終確認は総合テスト実施で行なう
> それを考えた場合、xUnitを単体テストに使用するコストに見合うのか？
人・プロダクト・環境・組織それぞれで違うので一概には言えない。
ただ一つ言えることは、10秒で終わる1万個のテストケースは、なにをするにも10秒で終わると言うことだ。
自動化されたテストはバックグラウンドでやらせればいいから
作業時間は実質0という考え方もあるな。
作業時間は実質0という考え方もあるな。
>>876
>assert(日本の国コードを取得() == ”△49”)
>> また４９が１４９に変更された時のテストコードは？
>assert(日本の国コードを取得() == ”149”)
変更・バグの無いメソッドも、テストコードのみ修正すると言う事だな
つまり、テストコードのバグだな
>>877
>>また４９が１４９に変更された時のテストコードは？
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か？ 出力値・桁数＝３桁のチェックのみと言う事か？
それだと、出力値が”４９△”でも正常だと判定するのか？
>>878
>> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
>正直、お前とそれ話し合うの気が進まない。
>影響が無いと思うならそれでいいじゃん、って気持ち。（投げやり）
一人逃げたな
もう一度話を整理する、xUnitを単体テストで使うメリットは”反復実行可能”と言う事だが
疑問点
１．修正メソッドはもちろん単体テストをするが、それ以外のメソッドは単体テストが本当に必要か？
２．その場合、修正メソッド以外のメソッドが、単体テストレベルでバグになるケースは？
３．修正メソッド以外のメソッドでxUnitを実行した場合、メソッドは正常でもテストケースがバグるケースは無いのか？
４．３が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える？
>assert(日本の国コードを取得() == ”△49”)
>> また４９が１４９に変更された時のテストコードは？
>assert(日本の国コードを取得() == ”149”)
変更・バグの無いメソッドも、テストコードのみ修正すると言う事だな
つまり、テストコードのバグだな
>>877
>>また４９が１４９に変更された時のテストコードは？
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か？ 出力値・桁数＝３桁のチェックのみと言う事か？
それだと、出力値が”４９△”でも正常だと判定するのか？
>>878
>> 修正個所以外のメソッドが、単体レベルで、どのような影響があるのかを聞いている
>正直、お前とそれ話し合うの気が進まない。
>影響が無いと思うならそれでいいじゃん、って気持ち。（投げやり）
一人逃げたな
もう一度話を整理する、xUnitを単体テストで使うメリットは”反復実行可能”と言う事だが
疑問点
１．修正メソッドはもちろん単体テストをするが、それ以外のメソッドは単体テストが本当に必要か？
２．その場合、修正メソッド以外のメソッドが、単体テストレベルでバグになるケースは？
３．修正メソッド以外のメソッドでxUnitを実行した場合、メソッドは正常でもテストケースがバグるケースは無いのか？
４．３が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える？
>>880
> ・バグの無いメソッドも、テストコードのみ修正すると言う事だな
> つまり、テストコードのバグだな
テストが失敗するのはバグとは言わんよ。
それを、わかってないだろ？
テストコードを修正するのは、仕様が変わったとき。
仕様が変わったのだから、テストも変わるのは当たり前。
お前が言ってるのは仕様が変わった＝バグだなっていっているのと同じこと。
少しは考える頭を持てよ。
> ・バグの無いメソッドも、テストコードのみ修正すると言う事だな
> つまり、テストコードのバグだな
テストが失敗するのはバグとは言わんよ。
それを、わかってないだろ？
テストコードを修正するのは、仕様が変わったとき。
仕様が変わったのだから、テストも変わるのは当たり前。
お前が言ってるのは仕様が変わった＝バグだなっていっているのと同じこと。
少しは考える頭を持てよ。
> １．修正メソッドはもちろん単体テストをするが、それ以外のメソッドは単体テストが本当に必要か？
必要じゃない場合もあるが、必要な場合もある。
修正メソッドを使用しているメソッドはテストをしないといけない。
そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。
必要じゃない場合もあるが、必要な場合もある。
修正メソッドを使用しているメソッドはテストをしないといけない。
そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。
> ２．その場合、修正メソッド以外のメソッドが、単体テストレベルでバグになるケースは？
他のメソッドが修正メソッドを呼ばれている場合はすでに書いた。
それ以外の場合でもバグになるケースもある。
クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。
「修正メソッド」のコードが修正され、status=2の状態が追加される。
「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。
他のメソッドが修正メソッドを呼ばれている場合はすでに書いた。
それ以外の場合でもバグになるケースもある。
クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。
「修正メソッド」のコードが修正され、status=2の状態が追加される。
「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。
> ３．修正メソッド以外のメソッドでxUnitを実行した場合、メソッドは正常でもテストケースがバグるケースは無いのか？
それは、正しくテストを行っていない状態 という。
> ４．３が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える？
テストはちゃんとしないといけない。
テストをサボりたいならテストケース消せば？ｗ
それは、正しくテストを行っていない状態 という。
> ４．３が前提だが、その場合の修正があるとバグがないメソッドでもテストケースのみ修正する事になるが、そのコストはどう考える？
テストはちゃんとしないといけない。
テストをサボりたいならテストケース消せば？ｗ
>>880とかそれ絡み
主張する人らの間で何を単体とするかが違って無いか？
特に864と880。
具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。
ちょっと例を挙げると、以下辺りの認識の違い。
・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか
主張する人らの間で何を単体とするかが違って無いか？
特に864と880。
具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。
ちょっと例を挙げると、以下辺りの認識の違い。
・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか
>>881
アホだなｗ。
アホだなｗ。
>>881
お前はず～っと馬鹿だな、ちゃんと読め
>テストコードを修正するのは、仕様が変わったとき。
>仕様が変わったのだから、テストも変わるのは当たり前。
修正していないメソッドの話で、自動的に反復テストが可能だと言う
xUnitの利点として．．．もぅい実行
お前はず～っと馬鹿だな、ちゃんと読め
>テストコードを修正するのは、仕様が変わったとき。
>仕様が変わったのだから、テストも変わるのは当たり前。
修正していないメソッドの話で、自動的に反復テストが可能だと言う
xUnitの利点として．．．もぅい実行
>>887は俺が書いている途中、間違って書きこんだが、まっ、>>881には充分だなｗ
>>882
>修正メソッドを使用しているメソッドはテストをしないといけない。
>そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。
単体で必要か？
>>883
>クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
>「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。
>「修正メソッド」のコードが修正され、status=2の状態が追加される。
>「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。
修正漏れか、その場合でも、そのメソッドに単体が必要か？
status=0とstatus=１は正しく動いているし、status=2の処理が、そのメソッドで必要かは
結合テスト（機能の確認）じゃないと判断出来ないだろう
>>884
>それは、正しくテストを行っていない状態 という。
？？？
>テストはちゃんとしないといけない。
>テストをサボりたいならテストケース消せば？ｗ
意味の無い事をやるよりは、結合テスト以降を重点的にやれと言うことだ
>>885
>具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。
俺の単体は、コードテストと上でも書いている、xUnitもメソッド単位で書くだろう
>・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
>・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか
意味がわからん、メソッドを実行して、戻り値・フィールドを確認するだけだろう？
俺はステップ実行で、内部変数も確認するが
>>882
>修正メソッドを使用しているメソッドはテストをしないといけない。
>そのとき、修正されたメソッドを使っているメソッドを探すなんて作業は現実的ではない。
単体で必要か？
>>883
>クラスの状態をあらわす変数statusがある。「修正メソッド」はstatusの状態を0か1に変更する。
>「修正メソッド以外のメソッド」はstatusが0と1の状態を判断して処理を行う。
>「修正メソッド」のコードが修正され、status=2の状態が追加される。
>「修正メソッド以外のメソッド」はstatus=2を知らないからバグになる。
修正漏れか、その場合でも、そのメソッドに単体が必要か？
status=0とstatus=１は正しく動いているし、status=2の処理が、そのメソッドで必要かは
結合テスト（機能の確認）じゃないと判断出来ないだろう
>>884
>それは、正しくテストを行っていない状態 という。
？？？
>テストはちゃんとしないといけない。
>テストをサボりたいならテストケース消せば？ｗ
意味の無い事をやるよりは、結合テスト以降を重点的にやれと言うことだ
>>885
>具体的には、単体とはクラスであるのか、クラスのメソッドであるのか。
俺の単体は、コードテストと上でも書いている、xUnitもメソッド単位で書くだろう
>・あるクラスのメソッドからの同じクラスのメソッド呼び出しが単体の出力かどうか。
>・あるクラスのメソッドから参照変更される同じクラスの属性が単体の入出力かどうか
意味がわからん、メソッドを実行して、戻り値・フィールドを確認するだけだろう？
俺はステップ実行で、内部変数も確認するが
長々書いてたら長すぎと怒られてもた。
>>854
>なぜテストが単体・結合・総合と別れてテストするのか考えろ
結合するとあるパスを通すテストが困難になる場合があるから。
問題があった時テスト対象が小さい方がと原因の解析が簡単だから。
結合する範囲が大きくなるほどスケジュール調整が大変になるから。
で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ？
>複雑かどうかの基準は、人間の主観にすぎない
テストコードだからコードが簡単でレビューで大丈夫なんじゃなくて、
レビューで十分なようにテストコードを簡単にするんよ。
うちでは幾つかルールを決めてる。
具体的な話は長かったので割愛。
>>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。 検証しないと書いたけど、よく考えたらしとることに気付いた。
後出しですまんけど、xUnitのアサートでの確認項目じゃないんで頭から漏れてた。
静的解析ツールと動的解析ツールを併用しとるわ。
たまたま動くケースは、コードレビューとあわせてほぼ潰せる。
細かい話は長かったので割愛。
で、xUnitでは内部で閉じたフローは検証しない。（出来なくて良い）
テストケースが十分かどうかの指標の1つにカバレッジを利用する。
>"カバレッジ以上には検証は必要ない"もお前の主観でしかない
>テストとは、客観的でなくてわならない
これで良しとしてる判断基準は、過去のバグについての
原因と実装への手戻り件数の分析結果から。
テストミスも含めて過去に発見されたバグの原因を
フォロー出来るように、テスト方法を改善していってる。
>>854
>なぜテストが単体・結合・総合と別れてテストするのか考えろ
結合するとあるパスを通すテストが困難になる場合があるから。
問題があった時テスト対象が小さい方がと原因の解析が簡単だから。
結合する範囲が大きくなるほどスケジュール調整が大変になるから。
で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ？
>複雑かどうかの基準は、人間の主観にすぎない
テストコードだからコードが簡単でレビューで大丈夫なんじゃなくて、
レビューで十分なようにテストコードを簡単にするんよ。
うちでは幾つかルールを決めてる。
具体的な話は長かったので割愛。
>>内部で閉じたフローは、カバレッジ以上には検証は必要ないとしてる。 検証しないと書いたけど、よく考えたらしとることに気付いた。
後出しですまんけど、xUnitのアサートでの確認項目じゃないんで頭から漏れてた。
静的解析ツールと動的解析ツールを併用しとるわ。
たまたま動くケースは、コードレビューとあわせてほぼ潰せる。
細かい話は長かったので割愛。
で、xUnitでは内部で閉じたフローは検証しない。（出来なくて良い）
テストケースが十分かどうかの指標の1つにカバレッジを利用する。
>"カバレッジ以上には検証は必要ない"もお前の主観でしかない
>テストとは、客観的でなくてわならない
これで良しとしてる判断基準は、過去のバグについての
原因と実装への手戻り件数の分析結果から。
テストミスも含めて過去に発見されたバグの原因を
フォロー出来るように、テスト方法を改善していってる。
俺が本当の861。
>>880
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か？ 出力値・桁数＝３桁のチェックのみと言う事か？
"149"は"123"と同値クラスだからテストの追加はしない。
また、値のチェックもやってるだろ。
>CPPUNIT_ASSERT_EQUAL("123", c.GetPrintableCountryCode("some country");
>それだと、出力値が”４９△”でも正常だと判定するのか？
意味がわからない。ちゃんとテストしてるだろ。
>CPPUNIT_ASSERT_EQUAL("△49", c.GetPrintableCountryCode("日本");
ところで、C++のコードが読めるのかどうかはっきりしてくれ。
あと、お前のデグレードの定義とリグレッションテストの定義と意義も知りたいところだ。
>>880
>追加しない。印刷用のメソッドではMax3桁ということなので、すでに3桁のテストコードがあるはず。
桁数のチェックしかしないと言う事か？ 出力値・桁数＝３桁のチェックのみと言う事か？
"149"は"123"と同値クラスだからテストの追加はしない。
また、値のチェックもやってるだろ。
>CPPUNIT_ASSERT_EQUAL("123", c.GetPrintableCountryCode("some country");
>それだと、出力値が”４９△”でも正常だと判定するのか？
意味がわからない。ちゃんとテストしてるだろ。
>CPPUNIT_ASSERT_EQUAL("△49", c.GetPrintableCountryCode("日本");
ところで、C++のコードが読めるのかどうかはっきりしてくれ。
あと、お前のデグレードの定義とリグレッションテストの定義と意義も知りたいところだ。
さて、>>694がなかなか使用言語をあかさないので書かなかったが、Visual StudioのC++の場合、
ステップ実行できるのはDebugモードだけだという致命的な問題がある。
俺は、単体レベルはReleaseモードの出力を使うべき派。
ステップ実行できるのはDebugモードだけだという致命的な問題がある。
俺は、単体レベルはReleaseモードの出力を使うべき派。
>>889
> status=0とstatus=１は正しく動いているし、status=2の処理が、そのメソッドで必要かは
> 結合テスト（機能の確認）じゃないと判断出来ないだろう
どうして結合テストでないと判断できないのか理解不能。
そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
status = 2の時に各メソッドの振る舞いが変わるかどうかは、status = 2となる修正を行う時に
わかるはずだ。
それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
status = 2で他のメソッドを呼べば簡単に落ちる。
> status=0とstatus=１は正しく動いているし、status=2の処理が、そのメソッドで必要かは
> 結合テスト（機能の確認）じゃないと判断出来ないだろう
どうして結合テストでないと判断できないのか理解不能。
そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
status = 2の時に各メソッドの振る舞いが変わるかどうかは、status = 2となる修正を行う時に
わかるはずだ。
それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
status = 2で他のメソッドを呼べば簡単に落ちる。
>>880
> そのコストはどう考える？
まだ
テストコードの修正＆実行のコスト>>>>>>ステップ実行のコスト
だと思い込んでるようだな。
テストコードの修正＆実行=ステップ実行のコスト
となるケースはおろか、
テストコードの修正＆実行<<<<<ステップ実行のコスト
になる場合だってあるってのが、これまでのテストコード例でわかんないの？
> そのコストはどう考える？
まだ
テストコードの修正＆実行のコスト>>>>>>ステップ実行のコスト
だと思い込んでるようだな。
テストコードの修正＆実行=ステップ実行のコスト
となるケースはおろか、
テストコードの修正＆実行<<<<<ステップ実行のコスト
になる場合だってあるってのが、これまでのテストコード例でわかんないの？
昨日、Rubyのリファクタリング本を買ってきたら、1章で死ぬほどテストしろって書いてるんだけど、
本家リファクタリング本ではテストしろって書いてないの？
本家リファクタリング本ではテストしろって書いてないの？
>>889
間違えた861→694
>>890
>結合するとあるパスを通すテストが困難になる場合があるから。
違う、それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする
>で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ？
コーディングのミスと機能の間違いは別の観点、テストも別
>レビューで十分なようにテストコードを簡単にするんよ。
何時でも簡単に出来るのか？ オブジェクトの作成・入力データの設定は
大変じゃないのか？ 特にオブジェクト作成は、正しいオブジェクト指向設計だと
複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが
>これで良しとしてる判断基準は、過去のバグについての
>原因と実装への手戻り件数の分析結果から。
統計からの基準と言う事か？ 数学を知っていれば分かると思うが
統計は、個々のシステムには通用しない、統計じゃなく経験則だと言うなら、それは主観だ
間違えた861→694
>>890
>結合するとあるパスを通すテストが困難になる場合があるから。
違う、それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする
>で、なんで機能とカバレッジの両方からテストケースを検討するのがダメなんよ？
コーディングのミスと機能の間違いは別の観点、テストも別
>レビューで十分なようにテストコードを簡単にするんよ。
何時でも簡単に出来るのか？ オブジェクトの作成・入力データの設定は
大変じゃないのか？ 特にオブジェクト作成は、正しいオブジェクト指向設計だと
複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが
>これで良しとしてる判断基準は、過去のバグについての
>原因と実装への手戻り件数の分析結果から。
統計からの基準と言う事か？ 数学を知っていれば分かると思うが
統計は、個々のシステムには通用しない、統計じゃなく経験則だと言うなら、それは主観だ
>>892-894
お前とは話が噛み合わん、ちゃんと読め
>>895
>どうして結合テストでないと判断できないのか理解不能。
上でも書いたが、それぞれのテストは観点が違う、単体ではコードが正しいかの観点だ
>そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
上からの流れを読め、プログラムを修正した時の話だ、元を誰が作ったのか限定していない
それに、修正漏れをしている以上、修正した本人は影響を認識していないと言う事だろう
お前も話が噛み合わない
>それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
>status = 2で他のメソッドを呼べば簡単に落ちる。
意味が分からん、なんで”statusが0か1しか取らないという前提”で配列を使うんだ？ 整数型でいいだろう
”要素数2個の固定長配列”には何が設定されるんだ？ 本当に、お前も話が噛み合わない
>>896
アホ
>>897
本家は１０ページぐらい(全体で４００ページぐらい)
お前とは話が噛み合わん、ちゃんと読め
>>895
>どうして結合テストでないと判断できないのか理解不能。
上でも書いたが、それぞれのテストは観点が違う、単体ではコードが正しいかの観点だ
>そのクラスはお前が実装したもので、お前は今ホワイトボックス視点でテストをしているはずだ。
上からの流れを読め、プログラムを修正した時の話だ、元を誰が作ったのか限定していない
それに、修正漏れをしている以上、修正した本人は影響を認識していないと言う事だろう
お前も話が噛み合わない
>それから、statusが0か1しか取らないという前提で、要素数2個の固定長配列を使っていた場合、
>status = 2で他のメソッドを呼べば簡単に落ちる。
意味が分からん、なんで”statusが0か1しか取らないという前提”で配列を使うんだ？ 整数型でいいだろう
”要素数2個の固定長配列”には何が設定されるんだ？ 本当に、お前も話が噛み合わない
>>896
アホ
>>897
本家は１０ページぐらい(全体で４００ページぐらい)
>>899
>それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする
それこそ違う。
単体テストは単体の仕様に基づいて行われるから単体テストなんだ。
>コーディングのミスと機能の間違いは別の観点、テストも別
何言ってんのかよく分からんが、うちのxUnitの目的としては、基本的には
関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
と思って貰って良いよ。
>オブジェクト云々
C言語ですけど何か？
>統計からの基準と言う事か？
プロセス改善のための定量的なメトリクスってそういうモンよ。
逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの？
または、テスト方法が改善されたと判断するのよ？
>経験則だと言うなら、それは主観だ
そういう面もあるけど、過去事例と言って貰いたい。
今回はこういう問題が出ました。（検出出来なかったバグがあった）
原因はこれです。（例えば解析ツールの機能不足、など）
ですので今後はこのようにします。
（例えばその種のバグが検出可能な新規ツールの導入、など）
そういう改善。
例でいうと、次から同種のバグが単体テストで
発見出来るようになってれば、改善されたとみなす。
バグがなければ評価保留。再発したら効果無し。
>それぞれのテストは観点が違う、いろいろな角度からプログラムをテストする
それこそ違う。
単体テストは単体の仕様に基づいて行われるから単体テストなんだ。
>コーディングのミスと機能の間違いは別の観点、テストも別
何言ってんのかよく分からんが、うちのxUnitの目的としては、基本的には
関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
と思って貰って良いよ。
>オブジェクト云々
C言語ですけど何か？
>統計からの基準と言う事か？
プロセス改善のための定量的なメトリクスってそういうモンよ。
逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの？
または、テスト方法が改善されたと判断するのよ？
>経験則だと言うなら、それは主観だ
そういう面もあるけど、過去事例と言って貰いたい。
今回はこういう問題が出ました。（検出出来なかったバグがあった）
原因はこれです。（例えば解析ツールの機能不足、など）
ですので今後はこのようにします。
（例えばその種のバグが検出可能な新規ツールの導入、など）
そういう改善。
例でいうと、次から同種のバグが単体テストで
発見出来るようになってれば、改善されたとみなす。
バグがなければ評価保留。再発したら効果無し。
なんか必死な奴がいるなぁｗ
>>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を取り得ることになると落ちるってことだ。
これ、システムテストまでテストしないの？
> >>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を取り得ることになると落ちるってことだ。
これ、システムテストまでテストしないの？
>>899
> >レビューで十分なようにテストコードを簡単にするんよ。
> 何時でも簡単に出来るのか？ オブジェクトの作成・入力データの設定は
> 大変じゃないのか？ 特にオブジェクト作成は、正しいオブジェクト指向設計だと
> 複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが
やっぱお前>>281じゃないの？ちゃんと答えてくれよ。
リファクタリング、リファクタリングって言ってるけど、本当に日常的にリファクタリング
してるのか疑うよ。
テストし辛いのは、元コードが駄目コードだから。それと、お前がxUnitを使い慣れて
なくて、fakeもmockも知らないから。
（そして>>281からの議論へとループ）
> >レビューで十分なようにテストコードを簡単にするんよ。
> 何時でも簡単に出来るのか？ オブジェクトの作成・入力データの設定は
> 大変じゃないのか？ 特にオブジェクト作成は、正しいオブジェクト指向設計だと
> 複雑になる事が多いが、Gofの振る舞いパターンなど知っていれば分かると思うが
やっぱお前>>281じゃないの？ちゃんと答えてくれよ。
リファクタリング、リファクタリングって言ってるけど、本当に日常的にリファクタリング
してるのか疑うよ。
テストし辛いのは、元コードが駄目コードだから。それと、お前がxUnitを使い慣れて
なくて、fakeもmockも知らないから。
（そして>>281からの議論へとループ）
>>861は言ってることはまともなんだが、昼間書き込んでるのが・・・
>>906
お前マ板初めてか力抜いてどっか行けよ
>>907
本家 Refactoring: Ruby Edition は肥溜めのよーな本だともっぱらの評判
ttp://www.amazon.com/dp/0321603508/
お前マ板初めてか力抜いてどっか行けよ
>>907
本家 Refactoring: Ruby Edition は肥溜めのよーな本だともっぱらの評判
ttp://www.amazon.com/dp/0321603508/
>>910
俺以外全員アホなのは間違いない
俺以外全員アホなのは間違いない
>>908
うわ、コードは読み飛ばしてたからバグがあるのかどうか気づかなかったよ。
ちなみに、日本語訳はいまのとこまとも。
リファクタリングカタログの所拾い読みしてるけど、一つのリファクタリングを
三つくらいのステップに分けて実行するとき、一つ一つのステップでしつこいほど
テストやれって書いてる。本当に本家リファクタリングはテストやれって書いてないの？
うわ、コードは読み飛ばしてたからバグがあるのかどうか気づかなかったよ。
ちなみに、日本語訳はいまのとこまとも。
リファクタリングカタログの所拾い読みしてるけど、一つのリファクタリングを
三つくらいのステップに分けて実行するとき、一つ一つのステップでしつこいほど
テストやれって書いてる。本当に本家リファクタリングはテストやれって書いてないの？
「のか？」でこのスレを検索して、ヒットしたレスのほとんどが多分>>694
ニカ？で検索して、ヒットしたものが・・・
一人が一年かけて作った、とある計測器制御＆測定値分析のアプリを引き継いで
機能拡張をまかされた。
今時VB6ってのもアレなんだが、我慢してソースざっとみたら、ボタンとかのイベント
ハンドラに処理をガンガン書いてて、おまけにGPIBコマンドが直接いたるところに
ばらまかれてた。
作った奴はもうすぐやめるんだけど、とっつかまえてどうやってテストしたのかって
聞いたら、現地に行って計測器借りてデバッグしてたらしい。
つか、あんたほとんど社内にいたじゃん・・・
機能拡張をまかされた。
今時VB6ってのもアレなんだが、我慢してソースざっとみたら、ボタンとかのイベント
ハンドラに処理をガンガン書いてて、おまけにGPIBコマンドが直接いたるところに
ばらまかれてた。
作った奴はもうすぐやめるんだけど、とっつかまえてどうやってテストしたのかって
聞いたら、現地に行って計測器借りてデバッグしてたらしい。
つか、あんたほとんど社内にいたじゃん・・・
測定器相手だから、測定レンジ切り替えたときとかに測定値がふらつくから
微妙にSleepしないといけないし、余分なSleep入れると測定時間が何時間にも
なるってのはわかる。それは実機が無いとわからないだろう。
でも、GPIBボードがないと起動すら出来ないってひどいよ・・・
微妙にSleepしないといけないし、余分なSleep入れると測定時間が何時間にも
なるってのはわかる。それは実機が無いとわからないだろう。
でも、GPIBボードがないと起動すら出来ないってひどいよ・・・
よくある話
>>901
>単体テストは単体の仕様に基づいて行われるから単体テストなんだ。
単体の仕様？ それが単体の観点じゃないのか？
>関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
>と思って貰って良いよ。
仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ
例えば郵便番号判定の関数があったとする、数値はOKで数値以外でもXXX-XXXXみたいなハイフンはOK
それ以外はNGの関数を作ったとする
１：戻り値＝True
２：if (入力値 <> 数値) then
３： 戻り値＝ハイフン判定関数（入力値）
と関数が有ったとする、これに”△１２３４５６７”と入力値を設定した場合
処理が１→２→３と処理され戻り値にTrueが設定されたとする
しかし、PGの考えでは処理が１→２で終了してTrueが設定されることを想定していた
つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなｗ
>逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの？
その考えが間違っている、テストに良いも悪いもない、色々な観点のテストを行なう
それに品質管理を考えるなら、それは設計やコーディングから始まっている
>単体テストは単体の仕様に基づいて行われるから単体テストなんだ。
単体の仕様？ それが単体の観点じゃないのか？
>関数の機能が関数仕様の通りに実現出来てるかどうかを確認するテスト
>と思って貰って良いよ。
仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ
例えば郵便番号判定の関数があったとする、数値はOKで数値以外でもXXX-XXXXみたいなハイフンはOK
それ以外はNGの関数を作ったとする
１：戻り値＝True
２：if (入力値 <> 数値) then
３： 戻り値＝ハイフン判定関数（入力値）
と関数が有ったとする、これに”△１２３４５６７”と入力値を設定した場合
処理が１→２→３と処理され戻り値にTrueが設定されたとする
しかし、PGの考えでは処理が１→２で終了してTrueが設定されることを想定していた
つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなｗ
>逆に聞きたいけど、そっちでは何をもって「良いテスト」とするの？
その考えが間違っている、テストに良いも悪いもない、色々な観点のテストを行なう
それに品質管理を考えるなら、それは設計やコーディングから始まっている
>>903
>いやいや、俺が書いた内容をちゃんと読んでないのはお前の方だよ。
>お前は、「仕様変更の対応で、データベースの設定内容を変更したとき」の話をしていて、
>それに対して俺はテストコードの変更の必要もないし、テスト実行の必要も無いと言ってるんだよ。
アホちゃんと読め
>>874
>それじゃ設定を変える、49をコンストで定義していたとする
>例えばそのstatusがON/OFFを表すものだとして、ONのときとOFFのときに何かの値を保存する
>必要があったら、somedata[2]とすることだってあるだろ。で、somedata[status] = hoge;で
>statusが2を取り得ることになると落ちるってことだ。
>これ、システムテストまでテストしないの？
それ関数がstatus=2の時に呼ばれるのか？ 呼ばれない場合はバグじゃない 呼ぶ呼ばないは仕様だ
単体と結合を一緒にするな
あと、俺は単体にxUnitを使わないが、xUnitを使って自動化していても
その関数のテストコードではバグは発見出来ないだろう、修正していない関数をいままでのテストコードを流しても正常のままだと思うが
結局結合以降のテストで発覚する
>いやいや、俺が書いた内容をちゃんと読んでないのはお前の方だよ。
>お前は、「仕様変更の対応で、データベースの設定内容を変更したとき」の話をしていて、
>それに対して俺はテストコードの変更の必要もないし、テスト実行の必要も無いと言ってるんだよ。
アホちゃんと読め
>>874
>それじゃ設定を変える、49をコンストで定義していたとする
>例えばそのstatusがON/OFFを表すものだとして、ONのときとOFFのときに何かの値を保存する
>必要があったら、somedata[2]とすることだってあるだろ。で、somedata[status] = hoge;で
>statusが2を取り得ることになると落ちるってことだ。
>これ、システムテストまでテストしないの？
それ関数がstatus=2の時に呼ばれるのか？ 呼ばれない場合はバグじゃない 呼ぶ呼ばないは仕様だ
単体と結合を一緒にするな
あと、俺は単体にxUnitを使わないが、xUnitを使って自動化していても
その関数のテストコードではバグは発見出来ないだろう、修正していない関数をいままでのテストコードを流しても正常のままだと思うが
結局結合以降のテストで発覚する
>>907-909
お前達、アホか？
リファクタリングの話なんてして無いぞ、今の話は改修の話だ
リファクタリングが理解出来てないだろうｗ
>>910-911
意見が違うだけで、まともな奴もいる
でも、お前達はアホｗ
お前達、アホか？
リファクタリングの話なんてして無いぞ、今の話は改修の話だ
リファクタリングが理解出来てないだろうｗ
>>910-911
意見が違うだけで、まともな奴もいる
でも、お前達はアホｗ
>>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の単体レベルの話。
>それじゃ設定を変える、49をコンストで定義していたとする
テストを実行するとテストは失敗するけど、それは別にテストのバグじゃないよ。
逆にテストが正しいことを証明している。
> それ関数がstatus=2の時に呼ばれるのか？ 呼ばれない場合はバグじゃない 呼ぶ呼ばないは仕様だ
> 単体と結合を一緒にするな
実際に呼ばれるかどうかは関係ないし、これは単体レベルの話だ。
インスタンスメソッドに取ってはフィールドは外部入力と同じなので、それが取り得る範囲すべてで
正しく動作しなければならない。
・Foo::statusはFoo::foo()でしか設定しなくて、仕様変更でstatus=2になる場合が増えた
・一方Foo::bar()はstatus=2の時に呼ばれると落ちる
・Fooのクライアントコードを全部調べたが、status=2でFoo::bar()を呼んでいるコードは今のところ無い
これ、いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちたら、それはクライアント
コードのバグ？
そうじゃないよね。Fooのバグ。つまりFooの単体レベルの話。
>>918
「トリムするのを忘れた」というのが、どのレイヤーの話なのかいまいちわからないが、
言わんとしてることはわかった。
その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。
>>920
>リファクタリングの話なんてして無いぞ、今の話は改修の話だ
なんだか話が良くわからないけど、そもそも>>687で
>ユニットテストがあるから安心してリファクタリングできるってのがよく分からんわ
>お前が書いたそのテストコードってそんなに信頼できるもんなの？
に同意した>>694が、このスレだかこの話題だかの君の初登場じゃないの？
で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの？
何のためにxUnitの話をしてたのかわからん。
「トリムするのを忘れた」というのが、どのレイヤーの話なのかいまいちわからないが、
言わんとしてることはわかった。
その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。
>>920
>リファクタリングの話なんてして無いぞ、今の話は改修の話だ
なんだか話が良くわからないけど、そもそも>>687で
>ユニットテストがあるから安心してリファクタリングできるってのがよく分からんわ
>お前が書いたそのテストコードってそんなに信頼できるもんなの？
に同意した>>694が、このスレだかこの話題だかの君の初登場じゃないの？
で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの？
何のためにxUnitの話をしてたのかわからん。
>.>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使うから、そんなメソッド書かないし、上のようなテストもしないがなｗ
その関数を実際に実装したとして、入力候補には次のような物が考えられるんだけど、
ステップ実行だとどれくらいかかる？
テストコードだと、まあ言語にもよるけど、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使うから、そんなメソッド書かないし、上のようなテストもしないがなｗ
あー、あと、
"12-34567", "1234-567", "-1234567"
もあるな。
ほら、テストケースを思いついた場合、テストコードがあれば1分で上の3つを追加して実行できちゃうぞｗ
"12-34567", "1234-567", "-1234567"
もあるな。
ほら、テストケースを思いついた場合、テストコードがあれば1分で上の3つを追加して実行できちゃうぞｗ
あー、まだあった（俺しつこいｗ
"12345678", "123-45678",
"123--456"
"12345678", "123-45678",
"123--456"
んでさ、こんなテストやりましたってExcelかなんかに書くとするわな。
それ何分かかる？
テストコードがあれば、こんなのやりましたってコードみせればいいじゃん。
それ何分かかる？
テストコードがあれば、こんなのやりましたってコードみせればいいじゃん。
お前さー、xUnit使って無いのにどうしてxUnit使うときの工数がわかるわけ？
神様？ｗ
神様？ｗ
"１２３４５６７"
"１２３-４５６７"
"１２３－４５６７"
というのもあるな。
"１２３-４５６７"
"１２３－４５６７"
というのもあるな。
まぁコード書いた本人がホワイトボックス視点で単体テストをするわけだから
もう少しケースは絞り込めるかもしれないが、それでもマニュアルテストは
めんどくさすぎる。
もう少しケースは絞り込めるかもしれないが、それでもマニュアルテストは
めんどくさすぎる。
Java JUnit で private メソッドをテストする
http://www.horse-water.mydns.jp/tips/tips_P00015.html
http://www.horse-water.mydns.jp/tips/tips_P00015.html
>>919
>テストを実行するとテストは失敗するけど、それは別にテストのバグじゃないよ。
>逆にテストが正しいことを証明している。
メソッドはバグが無いのに、テストコードがバグだと判定している状態で、何で”テストが正しいことを証明している”だ？
>これ、いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちたら、それはクライアント
>コードのバグ？
>そうじゃないよね。Fooのバグ。つまりFooの単体レベルの話。
"いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちた"だから、それが仕様だろう
仕様が変ったから呼ばれし、呼ぶ方も改修が入るから、修正漏れでバグは結合テストで検出する
もとろん、その前に検出出来ても問題ないが、本来は設計段階か結合以降で検出
>>922
>その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。
俺はxUnitを信用してない訳じゃない、単体テストをxUnitで行なう事に問題があると言っている
>で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの？
>何のためにxUnitの話をしてたのかわからん。
いまの流れは>>776からだ、お前もリファクタリングと改修の区別がつかんのか？ >>728を読め
いまの例題は、修正前後が機能的に等価じゃないだろう
>>923-927
アホ、お前だけレベルが違いすぎる、俺に絡むな
>神様？ｗ
俺が神じゃなく、お前のレベルが低いだけだ
>テストを実行するとテストは失敗するけど、それは別にテストのバグじゃないよ。
>逆にテストが正しいことを証明している。
メソッドはバグが無いのに、テストコードがバグだと判定している状態で、何で”テストが正しいことを証明している”だ？
>これ、いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちたら、それはクライアント
>コードのバグ？
>そうじゃないよね。Fooのバグ。つまりFooの単体レベルの話。
"いつの日か誰かがstatus=2の状態でFoo::bar()を呼んで落ちた"だから、それが仕様だろう
仕様が変ったから呼ばれし、呼ぶ方も改修が入るから、修正漏れでバグは結合テストで検出する
もとろん、その前に検出出来ても問題ないが、本来は設計段階か結合以降で検出
>>922
>その例をもって、xUnitは全く信用ならんというなら、まぁそれも良しだと思うよ。皮肉抜きで。
俺はxUnitを信用してない訳じゃない、単体テストをxUnitで行なう事に問題があると言っている
>で、xUnitのテストがあればリファクタリングも安心派と、全く安心できない派の争いじゃなかったの？
>何のためにxUnitの話をしてたのかわからん。
いまの流れは>>776からだ、お前もリファクタリングと改修の区別がつかんのか？ >>728を読め
いまの例題は、修正前後が機能的に等価じゃないだろう
>>923-927
アホ、お前だけレベルが違いすぎる、俺に絡むな
>神様？ｗ
俺が神じゃなく、お前のレベルが低いだけだ
>>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自身の責任。
> メソッドはバグが無いのに、テストコードがバグだと判定している状態で、何で”テストが正しいことを証明している”だ？
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自身の責任。
C++の話なので理解できるかどうかわからないが（いい加減C++が読めるかどうか教えてくれ）、
最近ム板でこんなことがあった。
初心者らしきプログラマが先輩に「お前の作ったライブラリ使うと落ちる」と文句を言われたという
レスをした。その原因は、ポインタをメンバーに持っているクラスのインスタンスのコピーを作り、
その一方をdeleteしたら、もう一方のポインタがダングリングポインタになってしまった。
その初心者らしきプログラマ曰く「それは使い方が悪い」と主張。
だが普通のC++プログラマなら、コピー禁止にしておくか、deep copyすべきだと答えるはず。
このケースで悪いのは、使った方？使われたクラスを書いた方？
最近ム板でこんなことがあった。
初心者らしきプログラマが先輩に「お前の作ったライブラリ使うと落ちる」と文句を言われたという
レスをした。その原因は、ポインタをメンバーに持っているクラスのインスタンスのコピーを作り、
その一方をdeleteしたら、もう一方のポインタがダングリングポインタになってしまった。
その初心者らしきプログラマ曰く「それは使い方が悪い」と主張。
だが普通のC++プログラマなら、コピー禁止にしておくか、deep copyすべきだと答えるはず。
このケースで悪いのは、使った方？使われたクラスを書いた方？
>>931
>constで49を指定する場合、仕様変更で49を149に変えるのなら、コードとテストコードの*両方*を変更する
>必要がある。
だから、変更して無いメソッドの話だろう、変更したメソッドのテストコードを修正するのは当たり前だし
影響があるメソッドのテストコードを修正出来るのなら、修正漏れは起きないだろう
>俺が言ってるのは、constを149に変えてそのままテストが失敗したら、それは「仕様変更以前は正しく日本の
>国コードのチェックをしていた」ことの証明になるということ。
それを証明して何になるんだ？ 修正前のメソッドは動いているのは当たり前だろう
>そういうことを言ってるんじゃない。
>今誰かが呼んでいて落ちるのからバグで、今は誰も呼んでないからバグではないと判定するのは誤りだと
>いっている。
>今は呼ばれていないが将来誰かが呼んで落ちるのかにかかわりなく、Fooクラスは自分の取り得る状態で
>自分の公開メソッドが正しく動くのはFooクラス自身の責務であって、それをテストするのは単体テストレベル
>だということ。
まず一点目、例え今回のクラスが共通クラスで、どのプロジェクトから使われるのかも解らなかったとする
その場合でも、バグはバグになった時点からバグだ、０と１で使われている限りバグじゃない
二点目、”Fooクラス自身の責務”この考えは一つの考えにしかすぎない、使う方でそのオブジェクトを使う条件に
合わせると言う考えもある、つまりこのメソッドは０と１以外の時は使わない、もちろん０と１の時は
仕様を満たす事を保証する、システム工学では後者の方が主流だ、どんな値でも対応するのでなく
決められた前提条件の時のみ、機能を保証する（契約プログラム）
>constで49を指定する場合、仕様変更で49を149に変えるのなら、コードとテストコードの*両方*を変更する
>必要がある。
だから、変更して無いメソッドの話だろう、変更したメソッドのテストコードを修正するのは当たり前だし
影響があるメソッドのテストコードを修正出来るのなら、修正漏れは起きないだろう
>俺が言ってるのは、constを149に変えてそのままテストが失敗したら、それは「仕様変更以前は正しく日本の
>国コードのチェックをしていた」ことの証明になるということ。
それを証明して何になるんだ？ 修正前のメソッドは動いているのは当たり前だろう
>そういうことを言ってるんじゃない。
>今誰かが呼んでいて落ちるのからバグで、今は誰も呼んでないからバグではないと判定するのは誤りだと
>いっている。
>今は呼ばれていないが将来誰かが呼んで落ちるのかにかかわりなく、Fooクラスは自分の取り得る状態で
>自分の公開メソッドが正しく動くのはFooクラス自身の責務であって、それをテストするのは単体テストレベル
>だということ。
まず一点目、例え今回のクラスが共通クラスで、どのプロジェクトから使われるのかも解らなかったとする
その場合でも、バグはバグになった時点からバグだ、０と１で使われている限りバグじゃない
二点目、”Fooクラス自身の責務”この考えは一つの考えにしかすぎない、使う方でそのオブジェクトを使う条件に
合わせると言う考えもある、つまりこのメソッドは０と１以外の時は使わない、もちろん０と１の時は
仕様を満たす事を保証する、システム工学では後者の方が主流だ、どんな値でも対応するのでなく
決められた前提条件の時のみ、機能を保証する（契約プログラム）
>>931
>今回の仕様変更からちょっと離れて考えて欲しい。
>二つの公開メソッドA、BがあるクラスFooで連続して同じメソッドを呼ばない呼び出しパターンは、
>「A」「B」「AB」「BA」の4つある。
>これらのどのパターンでも正しく動作するのはFooの責任でしょ？Fooが保証しなくて誰が保証するの？
>そこにBを変更すべき仕様変更が発生した。
>Bの変更後、やはり「A」「B」「AB」「BA」のどれもが正しく動くのはFoo自身の責任。
だから、単体じゃないと言っているだけで、その保証は結合テストで行なえばいいだろう
メソッドの組み合わせのテストは結合以降だと思っている
>>933
>C++の話なので理解できるかどうかわからないが（いい加減C++が読めるかどうか教えてくれ）、
C++は、ほぼやってない（必要に迫られて何回か修正した事はあるが）
>このケースで悪いのは、使った方？使われたクラスを書いた方？
上でも書いたが、俺が書いているのは単体レベルだと言う事、また、そのメソッドが仕様を満たしていないならバグだ
このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思うが、statusはの場合は明らかに仕様だ
仕様の場合は、０と１以外はエラーで構わない、使う方が悪いと俺は思う、それが契約プログラムの考えだ
C++は契約プログラムをサポートしていないが、UMLでOCLを書けば実装出来ると思う、その方が品質は上がる
>今回の仕様変更からちょっと離れて考えて欲しい。
>二つの公開メソッドA、BがあるクラスFooで連続して同じメソッドを呼ばない呼び出しパターンは、
>「A」「B」「AB」「BA」の4つある。
>これらのどのパターンでも正しく動作するのはFooの責任でしょ？Fooが保証しなくて誰が保証するの？
>そこにBを変更すべき仕様変更が発生した。
>Bの変更後、やはり「A」「B」「AB」「BA」のどれもが正しく動くのはFoo自身の責任。
だから、単体じゃないと言っているだけで、その保証は結合テストで行なえばいいだろう
メソッドの組み合わせのテストは結合以降だと思っている
>>933
>C++の話なので理解できるかどうかわからないが（いい加減C++が読めるかどうか教えてくれ）、
C++は、ほぼやってない（必要に迫られて何回か修正した事はあるが）
>このケースで悪いのは、使った方？使われたクラスを書いた方？
上でも書いたが、俺が書いているのは単体レベルだと言う事、また、そのメソッドが仕様を満たしていないならバグだ
このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思うが、statusはの場合は明らかに仕様だ
仕様の場合は、０と１以外はエラーで構わない、使う方が悪いと俺は思う、それが契約プログラムの考えだ
C++は契約プログラムをサポートしていないが、UMLでOCLを書けば実装出来ると思う、その方が品質は上がる
修正
「契約プログラム」⇒「契約プログラミング」
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
「契約プログラム」⇒「契約プログラミング」
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
>>918
>単体の仕様？ それが単体の観点じゃないのか？
そっちがどういう意味で「観点」って言ってんのか分からん。
プログラムが概ね組み上がってから単体テストを始めるの？
うちとしては、プログラムに対する観点とかどうでも良くて、
結合に入る前に単体実装フェイズのアウトプットを検証してるだけ。
>仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ
わりとどうでもいい。
>例えば～～
単体仕様の捉え方が違いすぎて何が言いたいかよく分からん。
うちとしては下のような単体仕様。
「入力値が数値である場合、Trueを返す。
入力値が数値でない場合、入力値を引数にハイフン判定関数を呼び出し、
その戻り値を返す。」
例の場合の問題は、ハイフン判定関数が呼び出されたかどうかの
結果確認で発見される。
ハイフン判定関数が実はベタ書きだとして、
そこで違うパスを通ってTrueを返したとして、
カバレッジの正当性チェックレビューとテスト項目結果から見た
詳細設計(単体仕様)レビューをすり抜けたとして、
それで後々どういう問題が起こるのよ？
>色々な観点のテストを行なう
それらの観点で単体検証は必要十分である、という判断は何が基準？
ある観点ついて正しく検証出来ている、とう判断は何が基準？
なんか「客観的に、客観的に」言うてる割には、
言ってることが全部主観的に見えて、すごく説得力に乏しい。
>単体の仕様？ それが単体の観点じゃないのか？
そっちがどういう意味で「観点」って言ってんのか分からん。
プログラムが概ね組み上がってから単体テストを始めるの？
うちとしては、プログラムに対する観点とかどうでも良くて、
結合に入る前に単体実装フェイズのアウトプットを検証してるだけ。
>仕様を満たせばいいと言う考えは間違っている、レベルの低い技術者の考えだ
わりとどうでもいい。
>例えば～～
単体仕様の捉え方が違いすぎて何が言いたいかよく分からん。
うちとしては下のような単体仕様。
「入力値が数値である場合、Trueを返す。
入力値が数値でない場合、入力値を引数にハイフン判定関数を呼び出し、
その戻り値を返す。」
例の場合の問題は、ハイフン判定関数が呼び出されたかどうかの
結果確認で発見される。
ハイフン判定関数が実はベタ書きだとして、
そこで違うパスを通ってTrueを返したとして、
カバレッジの正当性チェックレビューとテスト項目結果から見た
詳細設計(単体仕様)レビューをすり抜けたとして、
それで後々どういう問題が起こるのよ？
>色々な観点のテストを行なう
それらの観点で単体検証は必要十分である、という判断は何が基準？
ある観点ついて正しく検証出来ている、とう判断は何が基準？
なんか「客観的に、客観的に」言うてる割には、
言ってることが全部主観的に見えて、すごく説得力に乏しい。
>>934
>仕様の場合は、０と１以外はエラーで構わない、使う方が悪いと俺は思う
お前がそう思うことは理解した。もうお互いこの件については、話し合う価値ないよな。
>どんな値でも対応するのでなく
>決められた前提条件の時のみ、機能を保証する
どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
いつ誰が動作保証すべきかって話なんだが。
>このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思う
つまり、このケースでも単体テストで保証すべき問題ではないということだな。
根本的に話が合わないということを思い知らされた。
呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。
>仕様の場合は、０と１以外はエラーで構わない、使う方が悪いと俺は思う
お前がそう思うことは理解した。もうお互いこの件については、話し合う価値ないよな。
>どんな値でも対応するのでなく
>決められた前提条件の時のみ、機能を保証する
どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
いつ誰が動作保証すべきかって話なんだが。
>このケースでは、仕様に書かれない技術的な事だから使われた方のバグだと思う
つまり、このケースでも単体テストで保証すべき問題ではないということだな。
根本的に話が合わないということを思い知らされた。
呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。
契約プログラミングについて。
俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。
俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。
>>931
> アホ、お前だけレベルが違いすぎる、俺に絡むな
> >神様？ｗ
> 俺が神じゃなく、お前のレベルが低いだけだ
最近書き込んでる奴でレベルが違いすぎるのはお前だアホ。
・都合の悪いことには一切答えない
・曖昧な例を曖昧な日本語で説明し、それを根拠として論を展開
・それらしきテクニカルタームを出すが、具体的な記述は一切無し
・技術的背景を明確にしない
スキルがあるというなら、これJavaでもいいから書いてみろよ。
> １：戻り値＝True
> ２：if (入力値 <> 数値) then
> ３： 戻り値＝ハイフン判定関数（入力値）
当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
書けたら少しは認めてやる。
逃げるなよｗ
> アホ、お前だけレベルが違いすぎる、俺に絡むな
> >神様？ｗ
> 俺が神じゃなく、お前のレベルが低いだけだ
最近書き込んでる奴でレベルが違いすぎるのはお前だアホ。
・都合の悪いことには一切答えない
・曖昧な例を曖昧な日本語で説明し、それを根拠として論を展開
・それらしきテクニカルタームを出すが、具体的な記述は一切無し
・技術的背景を明確にしない
スキルがあるというなら、これJavaでもいいから書いてみろよ。
> １：戻り値＝True
> ２：if (入力値 <> 数値) then
> ３： 戻り値＝ハイフン判定関数（入力値）
当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
書けたら少しは認めてやる。
逃げるなよｗ
694の主張内容は、物事が良くわかってない管理者が、「xUnitでテストした？信用できん。
全てステップ実行でC2カバレッジやれ」と言ってるのとなんら変わりないんだよね。
このスレの住人をひれ伏させるような論理展開やコードの一つも示してみろ。
あー、どのパターンのどのクラスがテストやりづらいのかを理由とともに書くってのもいいぞ。
GoFのクラス名でいいから書いてみそｗ
全てステップ実行でC2カバレッジやれ」と言ってるのとなんら変わりないんだよね。
このスレの住人をひれ伏させるような論理展開やコードの一つも示してみろ。
あー、どのパターンのどのクラスがテストやりづらいのかを理由とともに書くってのもいいぞ。
GoFのクラス名でいいから書いてみそｗ
あー、status=2の件で、契約プログラミングを実コードで示すってのでもいいぞ。
>>694の主張をまとめるとこうだ。
自らの変更によって、あるメソッドを変更したとき、そのクラス内の他のメソッドが
動かなくなったとしても、それは単体テストではテストしなくて良い。
なぜなら、自分では動かなくなるような呼び方はしないからだ。
動かなくなるような呼び方をするようなクライアントコードがあったとしたら、
それは結合テストで検出されるべきだ。
第三者が検証できなくとも、単体テストではステップ実行以外にテストする方法は無い。
他者の単体テスト実行品質の客観的評価は出来ない。なぜならステップ実行するからだ。
どんなに工数が掛かろうと、ステップ実行でしか単体テストはできない。他の方法では
コードが正しく実装されているかどうかを検出できないからだ。
こんなところか。むちゃくちゃだな。
自らの変更によって、あるメソッドを変更したとき、そのクラス内の他のメソッドが
動かなくなったとしても、それは単体テストではテストしなくて良い。
なぜなら、自分では動かなくなるような呼び方はしないからだ。
動かなくなるような呼び方をするようなクライアントコードがあったとしたら、
それは結合テストで検出されるべきだ。
第三者が検証できなくとも、単体テストではステップ実行以外にテストする方法は無い。
他者の単体テスト実行品質の客観的評価は出来ない。なぜならステップ実行するからだ。
どんなに工数が掛かろうと、ステップ実行でしか単体テストはできない。他の方法では
コードが正しく実装されているかどうかを検出できないからだ。
こんなところか。むちゃくちゃだな。
これも追加してくれ。
一度ステップ実行で単体テストがOKになったメソッドは、単体テスト期間中に繰り返しテストする必要はない。
いつの間にか壊れてたとしても俺の知ったこっちゃないし、結合テストで検出されるだろう。
繰り返しテストできるxUnitとかいうものがあるそうだが、繰り返しテストする意味がわからない。
一度ステップ実行で単体テストがOKになったメソッドは、単体テスト期間中に繰り返しテストする必要はない。
いつの間にか壊れてたとしても俺の知ったこっちゃないし、結合テストで検出されるだろう。
繰り返しテストできるxUnitとかいうものがあるそうだが、繰り返しテストする意味がわからない。
それからこんなことも主張してるな。
xUnitでテストを書いて、それで安心してリファクタリングする奴は馬鹿。
俺のコードは複雑で簡単に初期化なんてできないんだから、xUnitで簡単にテストできるはずがない。
俺は統合環境のリファクタリング支援機能でしかリファクタリングしなから、テストなんて不要。
なにせその機能は100%安全だからな。
xUnitでテストを書いて、それで安心してリファクタリングする奴は馬鹿。
俺のコードは複雑で簡単に初期化なんてできないんだから、xUnitで簡単にテストできるはずがない。
俺は統合環境のリファクタリング支援機能でしかリファクタリングしなから、テストなんて不要。
なにせその機能は100%安全だからな。
>>938
>どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
>いつ誰が動作保証すべきかって話なんだが。
だから、”取り得る状態が増えた”かどうかは仕様だと言っている
>呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
>阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。
落ちるとは限定していなが 上ではエラーと書いた、基本、正しい動作を保証しないと言う事だ、それが契約プログラミングだと思う
まっ、それはどっちでもいいが、考え方の違いしか言いようがないな
>俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。
statusは、publicじゃない、と言っても俺の場合は多分privateじゃなくprotectedにすると思うが（これは俺の趣味だ）
しかし、俺の例題が悪いとは思うが、setter・getterは使わないのか？ そこでのチェックとかは？
また、継承も使わないのか？ 俺の場合、多分status=0or1は既存メソッド
status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
正しく動いている物に、出来るだけ手をいれないようにしている
>>940-945
低いな、レベル
>どんな値でもなんて言ってない。自分のクラスの取り得る状態が増えたなら、その増えた分は
>いつ誰が動作保証すべきかって話なんだが。
だから、”取り得る状態が増えた”かどうかは仕様だと言っている
>呼ばれ方によってはガンガン落ちるかもしれないクラスを集めて結合テストしたら、
>阿鼻叫喚に包まれると俺は思うが、まぁそう思わないんじゃしかたない。
落ちるとは限定していなが 上ではエラーと書いた、基本、正しい動作を保証しないと言う事だ、それが契約プログラミングだと思う
まっ、それはどっちでもいいが、考え方の違いしか言いようがないな
>俺はstatusはprivateだという前提で話していたが、お前はpublicという前提で話していたということか。
statusは、publicじゃない、と言っても俺の場合は多分privateじゃなくprotectedにすると思うが（これは俺の趣味だ）
しかし、俺の例題が悪いとは思うが、setter・getterは使わないのか？ そこでのチェックとかは？
また、継承も使わないのか？ 俺の場合、多分status=0or1は既存メソッド
status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
正しく動いている物に、出来るだけ手をいれないようにしている
>>940-945
低いな、レベル
>>946
> だから、”取り得る状態が増えた”かどうかは仕様だと言っている
俺がこの件の最初の発言者じゃないんだが、なんか話がずれてきてる（のか、最初からずれてたか）。
そもそもは、コードを変更したときに変更箇所以外のテストは必要なのかという話だったはず。
多分俺も含めて、Foo::bar()を変更したときにFoo::foo()に影響を及ぼす可能性があるならテストする
というスタンスだろうが、その変更が仕様変更によるものかどうかなんて関係ないんだよ。
インクリメンタルにコーディングしてるから。
この話の結論はこうじゃないの？
俺：Foo内に変更があった場合は、Foo全体の動作保証は単体テストでやるべき。
お前：Foo内に変更があって、仮に動作しない場合があったとしても、単体テストではテストしない。
シンプルに言えば、こういうことだよな？
> しかし、俺の例題が悪いとは思う
え？何の話？>>883が出した例じゃないの？
クラスの状態を表す変数なんだから、外部には出さないよ。
> だから、”取り得る状態が増えた”かどうかは仕様だと言っている
俺がこの件の最初の発言者じゃないんだが、なんか話がずれてきてる（のか、最初からずれてたか）。
そもそもは、コードを変更したときに変更箇所以外のテストは必要なのかという話だったはず。
多分俺も含めて、Foo::bar()を変更したときにFoo::foo()に影響を及ぼす可能性があるならテストする
というスタンスだろうが、その変更が仕様変更によるものかどうかなんて関係ないんだよ。
インクリメンタルにコーディングしてるから。
この話の結論はこうじゃないの？
俺：Foo内に変更があった場合は、Foo全体の動作保証は単体テストでやるべき。
お前：Foo内に変更があって、仮に動作しない場合があったとしても、単体テストではテストしない。
シンプルに言えば、こういうことだよな？
> しかし、俺の例題が悪いとは思う
え？何の話？>>883が出した例じゃないの？
クラスの状態を表す変数なんだから、外部には出さないよ。
>>940
> 当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
> 書けたら少しは認めてやる。
これは俺も見たい。
xUnitでは検出できないケースがあるんなら、ちゃちゃっとコードで書いてみせてよ。
> 当然のことながら、>>923-925のテストは全てパスし、なおかつ致命的なロジックミスがあるコードだぞ。
> 書けたら少しは認めてやる。
これは俺も見たい。
xUnitでは検出できないケースがあるんなら、ちゃちゃっとコードで書いてみせてよ。
「単体テスト」の定義って難しいな
>>946
> setter・getterは使わないのか？ そこでのチェックとかは？
前述したとおり、公開しない性質のメンバ/プロパティだということが前提。
> また、継承も使わないのか？ 俺の場合、多分status=0or1は既存メソッド
> status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
> 正しく動いている物に、出来るだけ手をいれないようにしている
ケースバイケースだとしか言えないが、status=0, 1, 2の処理それぞれが処理内容的に
同じレベルの処理だろうから継承はしない。（でなければ同じstatusで状態を表現しないだろうから）
あえて言うなら、status=2の処理をべた書き（クラス内にコードを追加）するか、
StateパターンかStrategyパターンで、status=0, 1, 2を全部外に出すか、そんな感じだと思う。
このスレはテストスレだから、設計の話はこの辺で。
テスタビリティを高める設計の話なら大歓迎。
> setter・getterは使わないのか？ そこでのチェックとかは？
前述したとおり、公開しない性質のメンバ/プロパティだということが前提。
> また、継承も使わないのか？ 俺の場合、多分status=0or1は既存メソッド
> status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
> 正しく動いている物に、出来るだけ手をいれないようにしている
ケースバイケースだとしか言えないが、status=0, 1, 2の処理それぞれが処理内容的に
同じレベルの処理だろうから継承はしない。（でなければ同じstatusで状態を表現しないだろうから）
あえて言うなら、status=2の処理をべた書き（クラス内にコードを追加）するか、
StateパターンかStrategyパターンで、status=0, 1, 2を全部外に出すか、そんな感じだと思う。
このスレはテストスレだから、設計の話はこの辺で。
テスタビリティを高める設計の話なら大歓迎。
>>946
逃げたか。恥ずかしくないんかなこいつ。
>status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
そんな糞コード書くからテストやりづらくなる一方なんだよｗ
>正しく動いている物に、出来るだけ手をいれないようにしている
そしてつぎはぎだらけの糞の山ができあがるんだよｗ
逃げたか。恥ずかしくないんかなこいつ。
>status=2は継承メソッドで処理をすると思う、もちろん機械的にいつでもそうしている訳じゃないが良く使う手だ
そんな糞コード書くからテストやりづらくなる一方なんだよｗ
>正しく動いている物に、出来るだけ手をいれないようにしている
そしてつぎはぎだらけの糞の山ができあがるんだよｗ
ぬるほ
ぬるほ
ぬるほ
>>946
> 正しく動いている物に、出来るだけ手をいれないようにしている
自動テストで得られる程度の安心感もないから、手を入れるのを躊躇するんじゃないの？
つか、テストも無しでどんどんリファクタリングしてますってのが信じられないんだけど。
その安心感はどこから来てるんだろう？
> 正しく動いている物に、出来るだけ手をいれないようにしている
自動テストで得られる程度の安心感もないから、手を入れるのを躊躇するんじゃないの？
つか、テストも無しでどんどんリファクタリングしてますってのが信じられないんだけど。
その安心感はどこから来てるんだろう？
多分>>694は、基本、ツールを使ったコードの移動系のリファクタリングしかしないんでしょ。
とすると、デザインパターンを導入するようなリファクタリングはコードの構造を変えるものなので
到底受け入れられないということになる。
だから、継承で差分プログラミングするんでしょ。
とすると、デザインパターンを導入するようなリファクタリングはコードの構造を変えるものなので
到底受け入れられないということになる。
だから、継承で差分プログラミングするんでしょ。
すげー伸びてるな。
まさか、
>>857
> 具体的に単体（コード）テストで、修正個所以外でどのような影響が出る？
のオチが、
コードの修正で他に影響が出る場合もあるが、それは単体テストでは
テストしないので、「単体テストの範囲では修正箇所以外には影響は出ない」。
影響が出ないのだから、繰り返しテストする必要はない
ということだったなんて想像出来なかった。
まさか、
>>857
> 具体的に単体（コード）テストで、修正個所以外でどのような影響が出る？
のオチが、
コードの修正で他に影響が出る場合もあるが、それは単体テストでは
テストしないので、「単体テストの範囲では修正箇所以外には影響は出ない」。
影響が出ないのだから、繰り返しテストする必要はない
ということだったなんて想像出来なかった。
しつこいぞ
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト
http://d.hatena.ne.jp/hyoshiok/20100312#p1
http://d.hatena.ne.jp/hyoshiok/20100312#p1
テスト駆動開発の効果はどのくらいある？
http://www.publickey.jp/blog/10/post_99.html
http://www.publickey.jp/blog/10/post_99.html
>>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
>俺がこの件の最初の発言者じゃないんだが、なんか話がずれてきてる（のか、最初からずれてたか）。
>そもそもは、コードを変更したときに変更箇所以外のテストは必要なのかという話だったはず。
必要ないとは言ってない、なぜ必要かの理由を聞いている
>この話の結論はこうじゃないの？
>俺：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
>>952-956
相変わらず、アホだな
しかし、xUnitを単体に使うと言う奴は、どんな書籍を読んでいるんだ？
マーチンやケントは、そんな事をは書いていないが
あと、お前ら本当にxUnitの使い方が分かっているのか？
修正個所と関係ないメソッドをxUnitでテストしてどうする？
SetUp・TearDownが何故あるのか、理解出来るか？
テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
ケントも
「テストの結合は、コードが正しくても、１つのテストの失敗が次の１０個の
テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
と言っている、俺が出した例題もこれだ、分かる奴がいるかと思ったが
話さえ通じん、本当にxUnitをやっているのか？
相変わらず、アホだな
しかし、xUnitを単体に使うと言う奴は、どんな書籍を読んでいるんだ？
マーチンやケントは、そんな事をは書いていないが
あと、お前ら本当にxUnitの使い方が分かっているのか？
修正個所と関係ないメソッドをxUnitでテストしてどうする？
SetUp・TearDownが何故あるのか、理解出来るか？
テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
ケントも
「テストの結合は、コードが正しくても、１つのテストの失敗が次の１０個の
テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
と言っている、俺が出した例題もこれだ、分かる奴がいるかと思ったが
話さえ通じん、本当にxUnitをやっているのか？
>>960
アホか。
>１：戻り値＝True
>２：if (入力値 <> 数値) then
>３： 戻り値＝ハイフン判定関数（入力値）
のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。
>修正個所と関係ないメソッドをxUnitでテストしてどうする？
リグレッション。
>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
いきなり何を言い出すんだ？
>「テストの結合は、コードが正しくても、１つのテストの失敗が次の１０個の
> テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
>と言っている、
テストの結合って何？
>俺が出した例題もこれだ、
どれ？
>分かる奴がいるかと思ったが
>話さえ通じん、本当にxUnitをやっているのか？
話が通じないのは、お前がxUnitについて何もわかってないから。
アホか。
>１：戻り値＝True
>２：if (入力値 <> 数値) then
>３： 戻り値＝ハイフン判定関数（入力値）
のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。
>修正個所と関係ないメソッドをxUnitでテストしてどうする？
リグレッション。
>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
いきなり何を言い出すんだ？
>「テストの結合は、コードが正しくても、１つのテストの失敗が次の１０個の
> テストを失敗させる原因となるという点で、明らかに悪影響をもたらす」
>と言っている、
テストの結合って何？
>俺が出した例題もこれだ、
どれ？
>分かる奴がいるかと思ったが
>話さえ通じん、本当にxUnitをやっているのか？
話が通じないのは、お前がxUnitについて何もわかってないから。
xUnit は caller での assertion なので white box testing には使えない。
こんなの考えるまでもないと思うが。
まぁ、俺なんか最右翼だから、
white box testing が必要だと感じるほど複雑な method は分割せよ
って言っちゃうけどな。
> SetUp・TearDownが何故あるのか、理解出来るか？
> テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
理解は出来るが現実は厳しい。
これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。
こんなの考えるまでもないと思うが。
まぁ、俺なんか最右翼だから、
white box testing が必要だと感じるほど複雑な method は分割せよ
って言っちゃうけどな。
> SetUp・TearDownが何故あるのか、理解出来るか？
> テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
理解は出来るが現実は厳しい。
これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。
>>964
お前もxUnitがわかってねーわ
お前もxUnitがわかってねーわ
>>921
>・Foo::statusはFoo::foo()でしか設定しなくて、仕様変更でstatus=2になる場合が増えた
>・一方Foo::bar()はstatus=2の時に呼ばれると落ちる
Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
それは Foo::bar() も「修正メソッド」だということでは。
>・Foo::statusはFoo::foo()でしか設定しなくて、仕様変更でstatus=2になる場合が増えた
>・一方Foo::bar()はstatus=2の時に呼ばれると落ちる
Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
それは Foo::bar() も「修正メソッド」だということでは。
test case 内で function ではなく process を call すれば CT の自動化に応用できるし、
callee に trace 吐かせて、それを expected な内容と比較すれば white box testing にも使えるだろう。
そんなのは各自で工夫すればいいんじゃないかな。xUnit とは無関係な話だが。
callee に trace 吐かせて、それを expected な内容と比較すれば white box testing にも使えるだろう。
そんなのは各自で工夫すればいいんじゃないかな。xUnit とは無関係な話だが。
ルー大柴は芸能界にお帰りください。
>>964
> まぁ、俺なんか最右翼だから、
> white box testing が必要だと感じるほど複雑な method は分割せよ
> って言っちゃうけどな。
なんだろう。何かの自慢なのかな。
それ、リファクタリングって言うんですよ。
> > SetUp・TearDownが何故あるのか、理解出来るか？
> > テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
>
> 理解は出来るが現実は厳しい。
> これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。
xUnit使ってる人はなら、大体理解も実践もしてると思うけど。
あと、TDDじゃなくてもxUnit使いますから。
> まぁ、俺なんか最右翼だから、
> white box testing が必要だと感じるほど複雑な method は分割せよ
> って言っちゃうけどな。
なんだろう。何かの自慢なのかな。
それ、リファクタリングって言うんですよ。
> > SetUp・TearDownが何故あるのか、理解出来るか？
> > テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
>
> 理解は出来るが現実は厳しい。
> これを意識することで良い OOD が導かれるというのが TDD の最大の恩恵とも言える。
xUnit使ってる人はなら、大体理解も実践もしてると思うけど。
あと、TDDじゃなくてもxUnit使いますから。
>>967
> Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
問題ならって、問題以外の何者でもないですねぇ。
> それは Foo::bar() も「修正メソッド」だということでは。
あたりまえじゃないですか。
> Foo::bar() が Foo::status = 2 で呼ばれて落ちるという挙動が問題なら
問題ならって、問題以外の何者でもないですねぇ。
> それは Foo::bar() も「修正メソッド」だということでは。
あたりまえじゃないですか。
>>776
xUnit を UT に使う現場の場合、そもそも white box testing を行っていないのではないか。少なくとも俺はそうだ。
正確に言えば、必要に応じて C2 が 100% になる「だろう」test case を用意はするが、その実行を trace することはしない。
実際に検証するのは、あくまでも coverage と output だけだ。
その意味で
> 割り切っているのか？
yes.
割り切って良しとする根拠は
white box testing が必要だと感じるほど複雑な method は分割せよ
ということになる。
xUnit を UT に使う現場の場合、そもそも white box testing を行っていないのではないか。少なくとも俺はそうだ。
正確に言えば、必要に応じて C2 が 100% になる「だろう」test case を用意はするが、その実行を trace することはしない。
実際に検証するのは、あくまでも coverage と output だけだ。
その意味で
> 割り切っているのか？
yes.
割り切って良しとする根拠は
white box testing が必要だと感じるほど複雑な method は分割せよ
ということになる。
>>972
何言ってるのか理解できん。
ホワイトボックスしない、処理のパスはトレースしない。
にもかかわらずカバレッジは検証するという。
トレースしないのにカバレッジが出るのか、そもそもトレースとは何か、
カバレッジについてどんな検証するのか、辺りを教えてくれんか？
何言ってるのか理解できん。
ホワイトボックスしない、処理のパスはトレースしない。
にもかかわらずカバレッジは検証するという。
トレースしないのにカバレッジが出るのか、そもそもトレースとは何か、
カバレッジについてどんな検証するのか、辺りを教えてくれんか？
>>972
お前の言うホワイトボックステストというのは、どうやって実行するものなんだ？
お前の言うホワイトボックステストというのは、どうやって実行するものなんだ？
>>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 で検出される。
なぜ 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 で検出される。
テスト以前に書き方を一からやり直したら
それから、>>694は早いとこxUnitでは検出できないバグを含む>>918の実コードを示してくれ。
xUnitでは検出できないケースがあるのだからステップ実行しなければならないということなんだろ？
まあ俺的にはなんでxUnitを毛嫌いするのかわからんが、xUnitでテストコード書いて
最初の一回はステップ実行で確認して、あとは自動テストじゃいけないんだろうか。
SCMが甘くてデグレしたなんてアホなことやらかすのを除いても、デグレはまあありうる
ことだし、コストをかけずに繰り返しテストできる意味がわからないというのが
意味がわからない。
xUnitでは検出できないケースがあるのだからステップ実行しなければならないということなんだろ？
まあ俺的にはなんでxUnitを毛嫌いするのかわからんが、xUnitでテストコード書いて
最初の一回はステップ実行で確認して、あとは自動テストじゃいけないんだろうか。
SCMが甘くてデグレしたなんてアホなことやらかすのを除いても、デグレはまあありうる
ことだし、コストをかけずに繰り返しテストできる意味がわからないというのが
意味がわからない。
>>962
>> １：戻り値＝True
>> ２：if (入力値 <> 数値) then
>> ３： 戻り値＝ハイフン判定関数（入力値）
> のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。
まったく、上でも書いただろう理解出来ないのか？
>>918
>つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
>PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
>あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなｗ
つまり、PGの書きたかったコードは、これだ
１：戻り値＝True
２：if (TRIM(入力値) <> 数値) then
３： 戻り値＝ハイフン判定関数（入力値）
本来PGは２：で終了し、戻り値＝Trueとする所を、ハイフン判定関数に助けられて
バグになっていない状態の事を言っている
>>修正個所と関係ないメソッドをxUnitでテストしてどうする？
>リグレッション。
もう一度書く、リグレッションを”xUnitでテストしてどうする？”
>>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
>いきなり何を言い出すんだ？
本当にxUnitを理解してないな
>テストの結合って何？
明日本屋に行け
>> １：戻り値＝True
>> ２：if (入力値 <> 数値) then
>> ３： 戻り値＝ハイフン判定関数（入力値）
> のようなコードを書いたときに、正しく実装できているかどうかわからないという話だったはずだ。
まったく、上でも書いただろう理解出来ないのか？
>>918
>つまり、PGはトリムするのを忘れたがハイフン判定関数が救ってくれ関数の仕様を満たしているが
>PGの考えとは違う、つまりコーディングミスだ、単体はコードが思っている通り実行するかを確認する
>あと、例題に文句を付けるなよ、解り易いように単純化している アホは直ぐいちゃもんを付ける、それぐらいしか能が無いからなｗ
つまり、PGの書きたかったコードは、これだ
１：戻り値＝True
２：if (TRIM(入力値) <> 数値) then
３： 戻り値＝ハイフン判定関数（入力値）
本来PGは２：で終了し、戻り値＝Trueとする所を、ハイフン判定関数に助けられて
バグになっていない状態の事を言っている
>>修正個所と関係ないメソッドをxUnitでテストしてどうする？
>リグレッション。
もう一度書く、リグレッションを”xUnitでテストしてどうする？”
>>テストコードは他のテストコードに影響しないように作るもんだ理解出来るか？
>いきなり何を言い出すんだ？
本当にxUnitを理解してないな
>テストの結合って何？
明日本屋に行け
>>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の使い方が書いてある書籍を教えて欲しいが
お前らケントの”独立したテスト”が理解出来ているのか？
>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の使い方が書いてある書籍を教えて欲しいが
お前らケントの”独立したテスト”が理解出来ているのか？
>>979
> いいな、簡単なプログラムしか作った事が無い人間は
そうだな。同意する。
俺は十人並みの平凡な programmer なので簡単な仕事しか経験してしない。
医療機器の制御も飛行機を飛ばすこともない。俺の話はその範囲にしか適用できないものと考えてもらってよい。
そもそも大規模で複雑な仕事への適用は TDD ひいては agile の課題なのではないかとも思う。
俺が扱うような簡単な仕事なら
> ２：if (TRIM(入力値) <> 数値) then
この condition clause を別の method に切り出して、その method を test する。
> いいな、簡単なプログラムしか作った事が無い人間は
そうだな。同意する。
俺は十人並みの平凡な programmer なので簡単な仕事しか経験してしない。
医療機器の制御も飛行機を飛ばすこともない。俺の話はその範囲にしか適用できないものと考えてもらってよい。
そもそも大規模で複雑な仕事への適用は TDD ひいては agile の課題なのではないかとも思う。
俺が扱うような簡単な仕事なら
> ２：if (TRIM(入力値) <> 数値) then
この condition clause を別の method に切り出して、その method を test する。