テストツールについて語るスレ

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

31 ：デフォルトの名無しさん：03/01/09 00:35

ひろゆき～、どうか俺にもレスくれ

　（;´Д｀）　　ｺﾉﾄｳﾘﾀﾞ､ﾀﾉﾑ!
　（　八)
　　　〉〉

32 ：デフォルトの名無しさん：03/01/09 00:57

なるほど。理解しましたよ(￣ー￣)ﾆﾔﾘ

33 ：デフォルトの名無しさん：03/01/09 01:18

寒くて電車が止まる国らしいからな。さいたまは。

34 ：デフォルトの名無しさん：03/01/09 01:30

>>513
中の人などいない！

35 ：IP記録実験：03/01/09 01:58

36 ：デフォルトの名無しさん：03/01/09 02:04

速い

37 ：デフォルトの名無しさん：03/01/09 02:47

大阪ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

38 ：デフォルトの名無しさん：03/01/09 03:33

透明削除でずれたりしませんか？

39 ：デフォルトの名無しさん：03/01/09 12:26

http://live2.2ch.net/test/r.i/news/1042008602/34-

40 ：デフォルトの名無しさん：03/01/09 18:08

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

41 ：デフォルトの名無しさん：03/01/09 23:57

>713　ほう・・・

42 ：デフォルトの名無しさん：03/01/10 08:50

とりあえずこのスレが1000まで行ったら旅立とう、、、

普通の話は出来ないししたくもないからな、、、

43 ：デフォルトの名無しさん：03/01/10 10:10

>>70
わかった。何度説明しても駄目だな。こりゃ。

44 ：デフォルトの名無しさん：03/01/10 10:50

＞某○○
こいつって・・・

45 ：デフォルトの名無しさん：03/01/10 12:05

2ちゃんねる　が衰退していく

あるネット関連会社の社長は、
「いずれにしても2ちゃんねるは資金が底をつけば終わり。
あまり知られていないことだが、2ちゃんねる内部関係者によると今、
大手通信会社系が調査費名目で資金提供している。
だが、それが止まれば続けてはいけないだろう」
と証言する。
2ちゃんねるが判決によって力を失った場合、
資金提供の打ち切りも予想される。

http://ascii24.com/news/reading/causebooks/2002/07/01/636911-000.html

46 ：デフォルトの名無しさん：03/01/10 12:34

　　　　もう２ちゃんは終わった。　時代はふたば！

　　　　　　　　　

47 ：デフォルトの名無しさん：03/01/10 13:27

>>475　ﾜﾛﾀ

48 ：デフォルトの名無しさん：03/01/10 15:49

おぉ～　教祖がこんなとこにまで･･･

49 ：デフォルトの名無しさん：03/01/10 17:15

お疲れ様です

50 ：デフォルトの名無しさん：03/01/10 23:36

ひろゆきは大人になりましたとさ・・・

51 ：デフォルトの名無しさん：03/01/10 23:44

今のところ実験ですが
うまく動いていますよ

これからトラブルは当事者間で解決してもらう方針です。

52 ：デフォルトの名無しさん：03/01/11 01:00

マン喫からテスト

53 ：デフォルトの名無しさん：03/01/11 01:12

削除板に書き込む時いちいち設定し直すのが面倒臭いから

54 ：デフォルトの名無しさん：03/01/11 10:32

IPアドレスを記録してるログでしょ？(^_^;)

55 ：デフォルトの名無しさん：03/01/11 11:06

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

56 ：デフォルトの名無しさん：03/01/11 11:57

別に逮捕されるような事は言わないから大丈夫。とは言っても
怖いものは怖いなぁ・・・
悪いものは悪いと言いたいよ(´・ω・｀)

57 ：デフォルトの名無しさん：03/01/11 12:35

元よりIPは取られてる事を前提に書いてきた人間が大多数なんじゃないの

58 ：デフォルトの名無しさん：03/01/11 13:57

「○○人は～」
「×△国は～」
の類は名誉毀損にはならない罠。

59 ：デフォルトの名無しさん：03/01/11 15:39

うざ

60 ：デフォルトの名無しさん：03/01/11 15:40

復活してちょっとうれしい今日の漏れ

61 ：デフォルトの名無しさん：03/01/11 16:48

(´-`).｡oO(早くが浮かばれますように。

62 ：デフォルトの名無しさん：03/01/11 23:43

トリップ公開時期

63 ：デフォルトの名無しさん：03/01/11 23:53

鈍舞ですわ。＞マァヴさん

64 ：デフォルトの名無しさん：03/01/12 02:32

777

65 ：デフォルトの名無しさん：03/01/12 02:37

俺が見てるスレで、いつも「うんこ」って書いて荒らしてる奴が、
「うんきお」に変わってた

66 ：デフォルトの名無しさん：03/01/12 10:04

どうでもいいけど、明日のお昼はカレーにしよう。

67 ：デフォルトの名無しさん：03/01/12 20:52

エｽﾊﾟｰ伊東

68 ：デフォルトの名無しさん：03/01/12 20:55

名誉毀損ってのは "事実" であっても該当するのは周知の事実ですよね。
（ただし、公共の利益になる場合はこの限りではないのだけど）

事実誤認のレスで名誉を毀損された =営業的な不利益が生じたのであれば
確かにレスが事実誤認であることを証明するのは原告側。

しかし　その反証の場が 2ch でなくてはならないというのは　？　です。

今や 2ch は管理人の個人サイトとは判断されないほどメディアとしての
認知・影響力が裁判所で認定されているですから
公序良俗に反する情報発信は情報の発信者が責任を負うべきでしょう。
その発信者の情報をわざと特定させないのは　
ある意味、確信犯的な共犯者と見なされても仕方ないでしょ。

（もちろん、Internet の匿名性については十分、議論の余地はあります。）

69 ：デフォルトの名無しさん：03/01/12 21:04

引き続き　gamble 行きます。

70 ：山崎渉：03/01/13 18:42

（＾＾）

71 ：デフォルトの名無しさん：03/01/13 22:42

つまんね

72 ：山崎渉：03/01/16 03:17

（＾＾）

73 ：山崎渉：03/01/23 22:09

（＾＾）

74 ：デフォルトの名無しさん：03/01/26 18:42

ぷららADSLテスト。

75 ：デフォルトの名無しさん：03/02/03 14:35

age

76 ：デフォルトの名無しさん：03/02/20 11:35

IPアドレスを記録してるログでしょ?(^_^;)

77 ：デフォルトの名無しさん：03/03/29 01:30

CppUnit

78 ：デフォルトの名無しさん：03/03/29 02:14

xUnitはオブジェクト指向が前提
流行りだからって関数型プロラマーがとびついても意味なし

79 ：山崎渉：03/04/17 15:48

（＾＾）

80 ：山崎渉：03/04/20 04:17

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

81 ：デフォルトの名無しさん：03/05/01 07:06

..\\\\\\\\\

82 ：デフォルトの名無しさん：03/05/20 00:14

xUnitのテストケースって、大体どんな基準で計上してますか？

83 ：デフォルトの名無しさん：03/05/20 00:20

計上ってどういう意味で？

84 ：山崎渉：03/05/28 13:10

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

85 ：デフォルトの名無しさん：03/06/23 00:33

>713 ほう・・・

86 ：デフォルトの名無しさん：03/07/17 14:36

元よりIPは取られてる事を前提に書いてきた人間が大多数なんじゃないの

87 ：デフォルトの名無しさん：03/07/17 16:00

>>65
切ないですね・・・

88 ：山崎渉：03/08/02 02:36

（＾＾）

89 ：山崎渉：03/08/15 17:11

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

90 ：デフォルトの名無しさん：03/09/14 13:49

ユニットテストって死滅しちゃったの？

91 ：デフォルトの名無しさん：03/09/26 01:38

VB.NETで静的ソースコード解析したいんですが
　.TESTってどうなんでしょう。
ttp://www.techmatrix.co.jp/asq/dottest/index.html
　ユーザが定義した命名規約に従っているか、を
メインにテストしたいんですが。

92 ：デフォルトの名無しさん：03/11/20 01:53

93 ：デフォルトの名無しさん：04/01/01 11:28

Canooってどうなのかな？
http://www.webplanet.co.jp/technical/canoo/index.html

HttpUnitと違って、テストの大部分はXMLで定義できて
Javaコードをほとんど記述する必要がないのが特徴
みたいだけど。

94 ：デフォルトの名無しさん：04/01/03 02:32

海外掲示板用オフラインリーダーを作るスレ
http://pc2.2ch.net/test/read.cgi/tech/1072883528/

海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。

必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用

95 ：デフォルトの名無しさん：04/04/15 18:29

glib やそのデータ構造などをバリバリ使ったモジュールに便利な
ユニットテスティングツールってないかな？

96 ：デフォルトの名無しさん：04/04/15 18:35

自己レス。
灯台下暗しというか、まさかあるわきゃないだろうなあと思いつつ、
"GUnit" でぐぐったらありました。
これで良いのかな？
とりあえず試してみます。

97 ：デフォルトの名無しさん：04/04/15 18:49

GNOME で動くということのようです (必須？) 。
そんなのインスコしてられないので却下しますた。

98 ：デフォルトの名無しさん：04/05/12 05:47

スレタイに含む文字を数えてみた。

C 70
Java 56
C++ 37
.NET 33
Delphi 21
VB 15
OO 10
オブジェクト 8
C# 6
ブラウザ 6
HSP 5
アルゴリズム 5
Eclipse 3
COBOL 2
XML 2
エディタ 2
テスト 2
デバッグ 2
ポインタ 2

Cは別の語の一部もひっかかってる気がしなくもないが、
なんにしても、テストスレ人気ないすぎage

99 ：デフォルトの名無しさん：04/05/12 07:26

test

100 ：100：04/05/12 17:27

100

101 ：(゜Jし゜)：04/06/04 08:18

TestCaseToolってどうよ。
WebPG板に逝けって？

http://www5f.biglobe.ne.jp/~webtest/testcasetool/ja/

102 ：デフォルトの名無しさん：04/06/04 09:55

>>101
見た感じ、かなりよさげだよね。
JAVA以外で開発している人にはけっこういいのでは？
今度試して見るよ。

103 ：デフォルトの名無しさん：04/06/05 01:08

WinRunner、何であんなに高いんだろ
評価版どっかに落ちてないかな・・・

104 ：デフォルトの名無しさん：04/06/08 14:15

オープンソース系のテストツールのリスト

ttp://www.opensourcetesting.org/

105 ：デフォルトの名無しさん：04/06/11 22:18

>>104
なかなかいいサイトだね。　アリガト！

106 ：デフォルトの名無しさん：04/06/15 11:23

TestRunner for NUnitってインストールに何か必要なものある？
PrevもLatestもインストールに失敗した…

107 ：デフォルトの名無しさん：04/07/04 00:51

>>104のサイトが更新チェッカで検出されまくるようになったんで、よくよく調べてみると、
サイトに訪れる度に、テストツールをランダムで4つ、トップページに表示するように変更されてるみたい。

108 ：デフォルトの名無しさん：04/07/05 03:53

>>107
そういうことするサイト嫌い。　かえって見たくなくなるよね。

109 ：デフォルトの名無しさん：04/07/23 11:13

みなさん、テスト対象プログラムと、テストプログラムって、
同じディレクトリに置いてますか？それとも分けてますか？

自分は、今、同じディレクトリに置いて、提供時には、
*Test* を含むファイルを弾く、ってな使い方をしてますが、
ディレクトリあたりのファイル数がほぼ２倍になるし、
たまに、テスト対象プログラムと、テストプログラムを間違えて開いたりするしで、
分離しようかとも考えてるんですが、それはそれで面倒がありそうで迷っています。

110 ：デフォルトの名無しさん：04/07/23 11:39

>>109
なんで？
わけるの当たり前だし、べつに分けたことによる手間もそんなに増えないし。

111 ：デフォルトの名無しさん：04/07/23 11:53

>>109
>なんで？
いや、分けたことがないのでよくわからないんですが。

>べつに分けたことによる手間もそんなに増えないし。
ということであれば、やってみます。

112 ：デフォルトの名無しさん：04/07/23 14:20

別のクラスとか構造体とかを引数に取る関数の
テストってめんどくさい。

113 ：デフォルトの名無しさん：04/07/23 14:25

そこでDIコンテナですよ。

114 ：デフォルトの名無しさん：04/08/06 23:56

テストケースとテストデータ分けるのにどうやってます？
JXUnitって使えます？あんまり紹介してるウェブサイト見つからなかったので流行っては
いないのですがねぇ？

115 ：デフォルトの名無しさん：04/09/29 23:50:12

市販の負荷テストツールで、安価かつ高機能なのはどこのメーカーのだろう？

116 ：デフォルトの名無しさん：04/09/30 10:24:40

超亀レスですが
>>114
分けません。コピペしてコードに埋め込み。
テストがDBに依存する場合のみ、DbUnitのXMLファイルを別途用意。
JXUnit見てみましたが、テストケースを書くためにXML書かなきゃならないのが面倒ですね。
流行らないのも当然かと。

117 ：デフォルトの名無しさん：04/09/30 21:15:22

JUnitで、protectedやprivateなメソッドをテストするには、どうすればいいんでしょう？

118 ：デフォルトの名無しさん：04/09/30 21:20:41

>>117
・テストケースを同一パッケージで宣言。（protected、パッケージプライベートのみ）
・リフレクション
・そもそも作らない。
・テストしない。

119 ：デフォルトの名無しさん：04/09/30 21:41:33

どこで読んだか忘れたけど、
コード：テスト用コード＝３：１とか言っている人が居た。

これって妥当ですか？

120 ：デフォルトの名無しさん：04/09/30 21:57:14

>>118
ありがとう！
やってみます。

121 ：デフォルトの名無しさん：04/09/30 22:02:51

>>119
それだとテスト用コードが少ない気がする。

122 ：デフォルトの名無しさん：04/09/30 22:38:46

>>121
どの位が妥当ですか？

123 ：デフォルトの名無しさん：04/09/30 22:44:39

↓通り一遍な回答

124 ：デフォルトの名無しさん：04/09/30 23:02:39

カバレッジの方が重要で、コード量を気にするのは本末転倒な気がする。
「うーむ、2:1 か。テストが多過ぎるな。削ろう」ってナンセンスでしょう？

125 ：デフォルトの名無しさん：04/09/30 23:30:40

たしかにナンセンスなんですが、

皆さん、どの位テストコードを書いているのかな？という素朴な疑問
＋コード量からカバレッジ率の逆算みたいな事も出来るのかな～という思い付きで
こんな質問になりました。

どうでしょうか？

126 ：デフォルトの名無しさん：04/10/01 00:21:28

C1-100%とか達成しようとするとテスト用コードの方が少ないというのは稀だと思われ。

127 ：デフォルトの名無しさん：04/10/05 13:17:30

既にあるクラスにテストを作ろうと思ってるんですけど、
一番最初のテストを全部エラーにするってのが結構面倒なんですよね。
なんかいい方法ある人います？

128 ：デフォルトの名無しさん：04/10/05 16:50:42

それはtestを先に作る時の手法じゃないのか？

129 ：デフォルトの名無しさん：04/10/05 18:42:47

>>127
既にあるクラスのコードを修正して、テストケースが正しく実装できた時に
エラーが起きるようにしたらどうでしょう？
最初はエラーってのは、テストケースの妥当性を検証するため。
つまり間違ったコードで実行したときにエラーが検出できればOK。

でないと、作ったテストケースは本当に正しいのかという疑問が当然のように湧いてきますからね。
完全な検証は無理といえば無理なんですが。

130 ：デフォルトの名無しさん：04/10/05 22:34:08

なんでそんなに教条主義的なんですか？

131 ：デフォルトの名無しさん：04/10/05 22:53:34

無難だから。保守的に行こうぜ。

132 ：デフォルトの名無しさん：04/10/06 18:29:01

てかAMD64や、これから出るインテルCPUの
NX機能が本当に効いているのか
試せるツールがほしい

てまえら作れよ

133 ：マイク ◆yrBrqfF1Ew ：04/10/06 19:13:54

スタックとヒープにコードを入れて実行を試みてりゃいいんじゃねか？

134 ：デフォルトの名無しさん：04/10/06 20:00:52

実際にバッファオーバーフローなexploitで攻撃してみりゃいいじゃん。

135 ：デフォルトの名無しさん：04/10/06 20:54:23

↑スレ間違えてるよ
http://pc5.2ch.net/test/read.cgi/tech/1090324689/

136 ：デフォルトの名無しさん：04/10/07 17:18:55

あった

ttp://user.cs.tu-berlin.de/~normanb/
紹介されてた
ttp://pcweb.mycom.co.jp/special/2004/winxpsp2/008.html

でも一回やったら「フーン」で終わり

137 ：デフォルトの名無しさん：04/11/15 00:23:21

JTestの体験版使ってみた人います？
体験版のパスワードを申し込んだら、入社以来３年間一通もSPAMの来なかったメールアドレスに、
週に2、3通くらい、いろいろなところから英語のSPAMが届くようになった・・・

138 ：デフォルトの名無しさん：04/11/20 02:19:36

ファイルに文字列を出力するクラスのテストケースってどのように書くのでしょうか？

テストコード
・ファイルへメッセージ出力するクラスのインスタンス作成
・ファイルへメッセージ出力
・FileReaderなんかで、出力したファイルを読込み
・assertequals

ってな感じなんでしょうか？

139 ：デフォルトの名無しさん：04/11/20 02:46:25

それでいんでね？

140 ：デフォルトの名無しさん：04/11/20 14:50:26

>ファイルに文字列を出力するクラスのテストケース

0.5 事前に用意した文字列が書き込まれているファイルを読み込んで、確認できるかを確認
1. メモリ上へ意図した文字列が出力できるか確認
2. 文字列をファイルへ出力し、それを読み込んで確認

だな

141 ：デフォルトの名無しさん：04/11/21 18:27:11

>>139　さん
>>140　さん

138です。アドバイスありがとうございます。

最近になってJUnitを知りました。戻り値が返ってくるやつは簡単ですけど、
DBとか、ファイルに出力とか、どうやってテストすんの？って疑問でした。

やっぱ内製は無理かなぁ・・・。モノ作りは社外にお願いするしかないかぁ。

142 ：デフォルトの名無しさん：04/11/22 03:42:07

>>141
DBはDBUnitで

143 ：デフォルトの名無しさん：04/11/22 03:52:44

>>141
出力データ生成部分は、別のメソッドに分離
通常どおりテスト
ファイル出力を作成
出力されるべきファイルをエディタで作成
そのファイルとプログラムで生成したファイルを比較するテストを作成

めんどうなバイナリファイルで、テストをデグレード対策と割り切るなら、比較用ファイルはうまく動くと確認できたときの生成ファイルを使う

144 ：デフォルトの名無しさん：04/12/09 14:55:15

jMock 使ってる人います？

145 ：デフォルトの名無しさん：04/12/09 15:00:21

TestNGってどうなの？

146 ：デフォルトの名無しさん：04/12/09 15:38:11

jMock で質問です。
↓みたいなクラス Hoge があったときに、Hoge の Mock オブジェクトを作ろうとしてますが、

public class Hoge {
public Hoge(String name) {

}
}

以下のエラーが出ます。
Mock hoge = new Mock(Hoge.class);

java.lang.IllegalArgumentException: Superclass has no null constructors but no arguments were given

引数無しのコンストラクタが定義されてないと Mock が作れないみたいなんですが、回避策どなたかわかりますか？

147 ：デフォルトの名無しさん：05/01/19 01:34:28

GUI開発ばっかりやってんだけど、
GUIをテストツール使ってテスト
してる人いる？

148 ：デフォルトの名無しさん：05/01/23 23:00:00

>>138
自分は二つのファイルを比較するメソッドと
ファイルと文字列の配列を比較するメソッド作った。

149 ：デフォルトの名無しさん：05/01/24 13:01:03

>>147
俺も興味ある。

150 ：デフォルトの名無しさん：05/01/25 09:37:54

あげてみるテスト

151 ：デフォルトの名無しさん：05/01/25 12:00:27

Cactusって使ってる人居る？
もし居たら、参考になるようなサイトを教えて欲しい。

てか、引数に色んなデータを含むオブジェクトを渡すメソッドの
テストって難しいね・・・。

152 ：デフォルトの名無しさん：05/01/25 15:11:37

ソフトウェアの品質向上は今日のシステム開発ではごくあたりまえの要求と
なっており、その実現には効果的なテストプロセスの確立が重要です。
プロジェクトの成熟度によって実践レベルはさまざまですが、あらゆるシーンで
常に中心的な役割を担うのは開発者でしょう。
そこで、開発者を軸にしたテストプロセスの実践方法として、
優れた機能と高い実績を持つテストツールの使い勝手のよさが
システムの品質向上や短期開発にインパクトをもたらしていきます。

153 ：デフォルトの名無しさん：05/01/25 15:12:40

ソフトウェアテストは開発に比べて、地味で低いレベルのスキルだと思われています。
しかし開発力が高いエンジニアはテストも達者だ、というのも事実です。テストの
スキルは、地味な確認作業の積み重ねではなく、開発力を表す指標に他なりません。
「テスト道」を極めていくと、そもそもバグを作り込まない開発に近づいていくのです。

154 ：デフォルトの名無しさん：05/01/25 17:58:07

>>151
あえてMockObjectsを薦めてみる。
ttp://www.mockobjects.com/FrontPage.html
Cactusみたいなインコンテナ・アプローチを採っているものは、
実際のサーバが必要なので、テストの実行が重くてかなわん。
Mockアプローチならサーバ無しでテストできるしね。設定も楽チン。

155 ：デフォルトの名無しさん：05/01/25 19:07:39

＞＞GUI開発ばっかりやってんだけど、
＞＞GUIをテストツール使ってテスト
＞＞してる人いる
昔visual Testというツールがあったがｒational に売却されてその後
アボーン。vs2005に似たようなのがつくらしい。
製品はむちゃくちゃ高いよね。ＧＵＩテストツールて
なにかの雑誌で見た

156 ：デフォルトの名無しさん：05/01/25 19:11:38

WindowsはAvalonからGUIがXMLで記述できるようになるから
単なるマウス･キーボードエミュレーションツール以上のものが出来るんじゃないのかな。
と期待してみる。

157 ：デフォルトの名無しさん：05/01/25 19:19:54

Viusl Testはいいとおもったのだが
ＭＳは何を思ったか売却。
スクリプトがエクセルマクロみたいに自動的に生成されるのが気に入っていたのだが
インタネット接続ツールにもつ使われていたのだが

158 ：デフォルトの名無しさん：05/01/25 19:29:25

>>147
テストツールではないけど、やり方は無きにしもあらず。

Web開発だったらWSHと"InternetExplorer.Application"を使って同値分割や境界値のテストぐらいは全てできる。
やろうと思えば、負荷テストも出来なくは無い。(信頼性の保証が出来なかったからやった事無いけど）
必ずキャプチャーと連携させて、画面イメージをとっておくのが良い感じ。
私の場合、DBのテーブルをCSV出力するツールも連携させてテストした。

Windowsアプリの場合は、Spy++で全てのダイアログのIDやらを調べてから
MFCで作った簡単なツールでCSV連携テスト。単純。SendMessageが分れば30分で作れる。
これもキャプチャがあると信頼性が上がる。

ツール買う金がない香具師と、xUnitが受けいられない香具師は試されよ。

159 ：デフォルトの名無しさん：05/01/25 19:34:14

漏れはわりとメンドクサイUIを作ることが多いんだけど、
・GUI を用いたアプリの機能テスト
・GUI 要素そのものの動作にかんするテスト
のうち後者はなかなか自動化できない・・・
マウスをトラッキングしている最中にボタンの表示が適切に変わるか、
ドラッグ中のアイコンにオーバーレイイメージがきちんと表示されるか、
とかそういうの。

160 ：デフォルトの名無しさん：05/01/25 20:08:12

>>159
>>158

161 ：159：05/01/25 20:21:47

>>160
もちろん158は読んでるけど・・・？
SendMessageじゃUI要素の動作テストまでは自動化しにくいと思う。

162 ：デフォルトの名無しさん：05/01/25 20:22:05

>>ツール買う金がない香具師と、xUnitが受けいられない香具師は試されよ。
でもねその方法　普通のＶＢプログラマには無理だよ
エクセルマクロみたいに自動的に操作をスクリプトに
書き出してくれるツールがないと。
そう、
visual testみたいなの１０年前からあるのに進化してないみたいだな
このツール。

163 ：デフォルトの名無しさん：05/01/25 21:21:11

>>161
o.R.z.　　　　　　　　ヽ(´Д`；)ノ

164 ：デフォルトの名無しさん：05/01/29 18:05:57

http://www.kumei.ne.jp/c_lang/sdk2/sdk_164.htm

165 ：テストファーストしてますか？：05/02/14 23:19:31

皆さんに質問
コードを書く前にテストコードを書いてますか？
　a. きちんと分析してからテストファーストでやっている。
　b. コードを書いた後にテストコードを書いてテストすることが多い。
　c. 実行してからレグレッションテストのためにテストコードを書く
　d. 最初に書いたテストコードより、手動テストの過程で見つかったバグで
　　都度テストケースを追加していることが多い。
　e. 申し訳程度に書いていて、いちいちバグが見つかるたびに追加してられない。
　f. 最初だけで後は放ったらかしでテストケースのメンテナンスなどできない。

166 ：デフォルトの名無しさん：05/02/15 00:58:18

>きちんと分析してから

意味不明分析って？
単純にテストから作るってだけぢゃねーのか？

167 ：デフォルトの名無しさん：05/02/15 01:24:34

>>165
「テストファースト」という言葉に惑わされているかのような選択肢だ。わざと？
テストファーストというかテスト駆動開発では、テストコードとコードを並行して実装する。
どちらが先かと敢えて言えば、テストコードの方がちょっとだけ早いくらいか。
よってaからfのいずれでもない。
まあでも、機能テストの段階で見つかったバグを直す過程でテストケースを追加することはあるな。

168 ：デフォルトの名無しさん：05/02/22 15:24:58

struts test case for junit

ふぉぉぉぉぉ、どこの設定がまずいのか、初期化担当のサーブレットが呼び出されないorz
setUp()でweb.xml呼んでやってくれるんじゃないのくわぁ

169 ：デフォルトの名無しさん：05/02/25 22:21:48

これﾜﾗﾀ。

ユニットテーストユニットテスト♪
すべてのテストを自動で実行するんだぜ！って言うじゃな～い？

でもあんたのテスト、2個失敗してますから！
・・・・・(fail)
でもあんたのテスト、2個失敗してますから！
・・・・・(fail)

残念！
4個のテストで、エラー2個、失敗2個、斬り！

ユニットテーストユニットテスト♪
すべてのテストを自動で実行するんだぜ！って言うじゃな～い？

・・・・・（fail が1個もない場合）

拙者、ダミーの実装のままリリースしたこと2回ありますから。
切腹！

http://akiyah.bglb.jp/blog/484

170 ：デフォルトの名無しさん：05/03/06 07:41:55

基本はGUI書いてるクラスからからGUIと直接関係ない処理を徹底的に
ひっぱがすことなんだけど、そういうコーディング規約って
案外少ないんだよな・・・
そうすりゃGUI部分は簡単なスタブ使えばいいし、処理部分はテストツール
使って自動化できるしかえって楽だと思うんだが。

171 ：デフォルトの名無しさん：05/03/07 02:31:08

こっちがちゃんとオブジェクトを設計してやらんとね。

オブジェクト指向言語でスパゲッティ指向設計しちゃ意味がない。

172 ：デフォルトの名無しさん：2005/03/22(火) 20:52:31

solexってどうですか？

message body contentのビューでエラーがでまくるんですが。
なにが間違っているのだろうか？仕様？

173 ：デフォルトの名無しさん：2005/03/30(水) 18:59:47

JMeterのHTML リンクパーサが機能してないようにみえるんですが
使いこなせてる人いますか？

174 ：デフォルトの名無しさん：2005/03/31(木) 02:57:59

>169
引用まちがってるぢゃん

-----
ユニットテーストユニットテスト♪
すべてのテストを自動で実行するんだぜ！って言うじゃな～い？
:
でもあんたのテスト、2個エラー発生してますから！
:
でもあんたのテスト、2個失敗してますから！
:
残念！
4個のテストで、エラー2個、失敗2個、斬り！
-----

エラーと失敗は区別しとけ

175 ：デフォルトの名無しさん：2005/04/28(木) 21:09:39

>>8 で紹介されてる

JUnit 実践講座
を書いてた人が、JR事故の犠牲になったんだって…
(-人-)

ttp://www.hyuki.com/diary/20050426132119

176 ：メモ：2005/05/02(月) 23:23:16

Software Testing
ttp://www.swtest.jp/

177 ：デフォルトの名無しさん：2005/05/24(火) 21:57:12

無償で商用で使えるJavaのカバレッジツールを探してるんですが、JCoverageとEmmaってのみつけました。
機能の違いってなんですか？
JCoverageって商用利用でもGPLが選べるんですか？
他にカバレッジツールあれば、教えてください。

178 ：デフォルトの名無しさん：2005/05/25(水) 13:22:06

>>177
今、Emmaを使ってますが、JCoverageと比較したときの特徴を以下に挙げます。

・instrumentコードを加える事前準備をしなくてもテストできる。
その場合、独自のクラスローダを使用してクラスのロード時にinstrumentコードを加えます。
ただし、Webアプリケーションのようにコンテナが提供するクラスローダを使用する場合は
この特徴はあまり役に立ちませんが。
もちろん、JCoverage同様に事前にinstrumentコードを加えてから実行することもできます。

・レポートが（ちょっとだけ）カスタマイズできそう。
レポートに入れる列とか、順番とか、変更できます。詳しくはドキュメントを。
http://emma.sourceforge.net/reference/ch02s04s02.html
JCoverageでもできるのかもしれませんが。

JCoverageの商用利用ですが、私は使えると判断しましたが、最初の頃は不安だったので
Emmaを選びました。EmmaはCPLなので安心だと思います。

他にGloboCoverageとかいろいろ調べましたが、やり方がまずかったのか動きませんでした。
今はEmmaです。快適。

179 ：177：2005/05/25(水) 14:59:59

どもです。
EmmaもJCoverageもC0ですよね。
Emmaって、検査結果のマージってできるんでしょうか？
たとえば操作系でのテストとJUnitでのテストをあわせてカバレッジが見たいときとか。

とりあえず調べるときにひっかかったカバレッジツールはこんな感じでした。
使ってみたのはEmmaとJCoverageだけですが。
・Emma
・JCoverage
・Clover
・GloboCoverage(GloboUtils)
・Hansel
・Jester

180 ：178：2005/05/25(水) 16:42:13

>>179
検査結果のマージはできます。
カバレッジ測定時にマージする（<instr>タスクの属性merge="true"を指定）か、
測定後に個々の結果をマージする（<merge>タスクを使用）かの２通り提供されています。

181 ：177：2005/05/25(水) 20:16:58

サンキューデス
しばらくEmma使ってみることにします。

182 ：デフォルトの名無しさん：2005/05/27(金) 22:27:10

JCoverageのGPL版は、Coberturaとして開発が続けられてるらしい。
ttp://www-6.ibm.com/jp/developerworks/java/050527/j_j-cobertura.html

183 ：デフォルトの名無しさん：2005/05/28(土) 06:46:23

テストについての疑問。
１．xUnitでできるテストは、いわゆる単体テストがメイン？
２．xUnitを使ったテストは、テスト仕様書にどう書くのか。
３．データアクセス層のテストはどうやるのか（.net向け）
仕事でNUnitを使い始めたんだが、２と３をどうするか悩み中。
アドバイスきぼん。

184 ：デフォルトの名無しさん：2005/05/28(土) 18:05:05

1. ある程度の結合テストならつかえるんじゃねの？
2. ？意味不明。ある条件でこの関数を動かすと結果がこうなる、って書けば
3. 格納と読み出しをペアで

185 ：デフォルトの名無しさん：2005/05/28(土) 18:11:58

>183
>テスト仕様書
ttp://www.freia.jp/taka/blog/67
か？

186 ：183：2005/05/28(土) 22:26:52

>>184
２．とあるSIerの仕事では、テスト成績書はEXCELで作成。
　テスト項目を箇条書きしてエビデンスとして画面コピーを貼り付けって感じで作ってた。
　これに結構馬鹿にならない工数かかってたんで、なんとか楽にならないかなあと。
３．ちょっと言葉が足りなかった。
　DBにアクセスするメソッドのテストについて悩み中。
　JavaならDBUnitとかあるけど.netにはないからどうやるのかなあと。
　とりあえずそこら辺のことが書いてあるっぽい「.NETでのテスト駆動開発」を注文した。
　今日届いたのでこれから読みます。

>>185
なるほど、xUnitが出力するXMLを使うのか。
それは思いつかなかった。THX

187 ：デフォルトの名無しさん：2005/05/29(日) 09:49:01

>>183
>３．データアクセス層のテストはどうやるのか（.net向け）

テスト用のインスタンスを用意して、
テストの最初にクリア、その後
データの追加・更新、データの取得を交互に書いてテストする。

188 ：デフォルトの名無しさん：2005/06/10(金) 01:16:30

テストファーストってテストコードを作る＆テストするタイミングが
コーディング時と一緒になるだけで、工数は増えないよねって
思うんだけど、違うの？

189 ：デフォルトの名無しさん：2005/06/10(金) 03:13:30

保守まで考慮に入れると、工数は劇的に減ってるんでないか？

190 ：デフォルトの名無しさん：2005/06/10(金) 11:09:18

そうとは限らない。

191 ：デフォルトの名無しさん：2005/06/10(金) 13:30:14

>>190
なぜか教えてけろー
いや、現実減ってないのは実感できているんだけど・・・

192 ：デフォルトの名無しさん：2005/06/10(金) 21:10:01

テストは本当はしないから

193 ：デフォルトの名無しさん：2005/06/10(金) 23:13:52

>>191
まず、自分の業務と環境を書け。
話はそれからだ。

194 ：デフォルトの名無しさん：2005/06/11(土) 01:17:00

テストファーストは、仕様を決めて、その仕様をテストとして記述して、それから実装なんだけど、実際は仕様があらかじめ決まらず変化していくから、テストは重荷になるというのが一点。
むしろ、試しに動かしてみてから仕様が決まることも多い。
特に、難しいものになるとメソッドの仕様は動かしてから決めていくことになりがち。

195 ：デフォルトの名無しさん：2005/06/11(土) 02:09:50

>>193
げろ、、多種多様でたくさんのデータを管理する共通ライブラリの開発。
Solarisで言語ジャヴァ、そんなに大きくはない。
こんなんでおｋ？

196 ：デフォルトの名無しさん：2005/06/11(土) 02:39:13

>>194
> むしろ、試しに動かしてみてから仕様が決まることも多い。
> 特に、難しいものになるとメソッドの仕様は動かしてから決めていくことになりがち。

その辺のアタリをつけるのもテストの効能に含まれてたと思うけど。

197 ：デフォルトの名無しさん：2005/06/11(土) 04:41:18

>>196
簡単なものにしか有効じゃないきがす。
だから、でかい流れ作っててちょっと難しい部分をメソッドとして抜き出すときに、テストを先に作るのは有効だと思うけど、そのでかい流れ自体のテストを先につくるのはあまり有効じゃないと思われ。

198 ：197：2005/06/11(土) 04:50:27

あ、そうか。
ライブラリみたいに、プログラムに閉じてるものだといいと思う。
メソッド呼び出してプログラムの内部事情が変わるけど外界に変化がないとき。
入出力があると、テストファーストは難しくなってくる。

だからなるべく分離していって、単体でテストしやすいようにしていくって話だったよね。
テストしやすいところだけテストファースト。
なるべくテストしやすいところを抜き出していく。

でも、雑誌とかで「テストしやすいところだけでおｋ」とか書くと全然テストしない人続出だから、一般に触れる文書だと「おまえら、とりあえず全部テストファーストしてください」ってことになるのかなと。

199 ：デフォルトの名無しさん：2005/06/11(土) 11:33:36

>実際は仕様があらかじめ決まらず変化していくから、
それは"変化することを"前提に考えればよろしい
確かにテストケースから作り直すような変化だと手間といえば手間だが
後の安心感が違う

200 ：197：2005/06/11(土) 14:14:05

それでも、手間は手間だから、変更をやりにくくする圧力にはなる。

201 ：デフォルトの名無しさん：2005/06/11(土) 18:11:03

テストファーストしない部分は、例えばJUnit使わないの？
自分で言っててよくわからんけど

202 ：デフォルトの名無しさん：2005/06/11(土) 21:44:17

テストファーストって、JUnitに限らないと思うよ。
基本的には、V字型のテストモデルで仕様と一緒にテストも(仕様の具体例として)作ろうという感じだと思う。

JUnitもテストファーストに限らないし。
テストファーストせず、仕様が固まってからJUnitでテストを作ることはよくある。

203 ：デフォルトの名無しさん：2005/06/12(日) 01:39:07

やっぱそうだよね。
逆にJUnit使わない場合でも普通にテストプログラム書くよね？

204 ：デフォルトの名無しさん：2005/06/12(日) 04:04:44

テストって、どういう基準で自動化するか、それよりテスト自体を行うかとかが、モノによるからねぇ。
管理者から見ればメソッドとテストが同時にあがってくれば、どっちが先に作られたかは関係ない気がする。
プログラマからすれば、小さくてプログラムロジック的なメソッドはテストファーストで、UIやらDBとからむようなテストはアフターで構わないんじゃないかと。
Webでテスト書くなら、Seleniumがいいね。

205 ：デフォルトの名無しさん：2005/06/17(金) 13:17:15

Seleniumってフレーム使いまくりんぐな画面でも使いやすい？

206 ：デフォルトの名無しさん：2005/06/17(金) 22:48:16

それはちょっと。
topに表示するようにすると、seleniumの画面つぶれるし。
それと、文字列があるかどうかのチェックが、うまく働いてなかった。

207 ：デフォルトの名無しさん：2005/07/03(日) 02:18:24

ソフトウェア・テスト PRESS Vol.1
http://www.gihyo.co.jp/magazines/testpress
B5判／ 136ページ／ 2005年6月29日発売

　　バグを見つけ出すことは価値ある投資である、という認識が広まりつつある今、
　　ソフトウェア・テストに光を当てた技術専門誌。テストの技法やテストプロセスの管理手法、
　　ソフトウェアの品質に関するいろんな話題などを取り上げます。
　　テストという作業が本来、創造的で魅力あるものであるということを、誌面全体を使ってお伝えします。

【特集1】「プロセス」と「技法」ですっきりわかる
　　ソフトウェアテスト入門
【特集2】コンサルタント直伝！“漏れのないテスト設計”のノウハウ
　　テストケース設計術虎の巻
【特集3】xUnitの使い方とテスト項目の抽出方法
　　単体テストの体系的＆実践技法

【一般記事】
　　■どこでテストをやめるか？
　　　　収束を使ったテスト終了判定の実際
　　■アフター・ザ・ゴールド・ラッシュ
　　　　テストほど知的で創造的な仕事はない
　　■バグを生み出す心理
　　　　“想定外”の誤りを克服する
　　■Bugzillaと不具合管理
　　　　バグの“少ない”ソフトウェアをつくるために
　　■LoadRunnerを使った負荷テスト
　　　　マーキュリー・インタラクティブのJ2EE診断ソリューション
　　■短納期対応型のテストプロセス管理
　　　　現役マネージャが明かす“最速のテスト管理”手法

208 ：デフォルトの名無しさん：2005/07/03(日) 12:48:03

>>207
さらっと流し読みしただけど、その雑誌にはがっかりした。
結構期待してただけに残念だ。
いまさらxUnitの使い方を紹介されてもって感じ。
通常のxUnitじゃ実現できないテストの自動化とかやってほしかった。

209 ：デフォルトの名無しさん：2005/07/03(日) 13:30:35

ソフトウェア・テストPRESS(激藁

なんでもPRESSにしちまうなぁ～技評わ・・・
話題的には4～5年前の内容の気もするが(LoadRunnerやらBugzillaやら)。

数年前からWebやGUIやOO設計と連携したソフトウェアテスト手法/ツール類の話が出てた中、
このスレが立ったのも随分遅い時期だったと記憶しているが(藁、
よーするにようやく、世の中の底辺まで新しいテスト手法が普及し始めたって感じか。

210 ：デフォルトの名無しさん：2005/07/18(月) 00:17:41

VS.NET2005にテストツールが含まれるらしいが
ベータ版で使ったことある人いる？

(Visual Studio Team Edition for Software Testers)

211 ：デフォルトの名無しさん：2005/07/18(月) 19:26:21

テストツールしろーとのオレに教えてくれ
プログラムなんて千差万別なのになぜ型にはめたツールだか
でテストできるんじゃあ？

212 ：デフォルトの名無しさん：2005/07/18(月) 19:42:26

>>210
http://pc8.2ch.net/test/read.cgi/tech/1113305966/l50
こっちを盛り上げてﾎｽｲ
ちなみに.NETは名前に入ってない

213 ：デフォルトの名無しさん：2005/07/18(月) 19:42:54

テストできるところをテストする。

214 ：デフォルトの名無しさん：2005/07/18(月) 20:13:03

たいていのプログラムは入力を与えると処理をして何か出力する

もっとも単純なテストは
範囲外の入力を与えて、エラー等が返る
事を確認する
これ

215 ：デフォルトの名無しさん：2005/07/18(月) 20:30:01

でもさあ、入力の形式は千差万別でしょ？　出力だってそう。

そのつどテストコード組んだり、オペレータの操作が
必要になると思うのに、なんで汎用化できるんだあ？？

ﾌｼｷﾞ

216 ：デフォルトの名無しさん：2005/07/18(月) 20:51:51

いや、どうして汎用化できると勘違いしてるのかのほうが不思議。

217 ：デフォルトの名無しさん：2005/07/18(月) 21:00:21

汎用化できるからツールって呼ばれてんじゃないの？

218 ：デフォルトの名無しさん：2005/07/18(月) 21:13:47

汎用化しなくてもツールだろ。
どんなテストでもできるとは謳ってないだろ。

219 ：デフォルトの名無しさん：2005/07/18(月) 21:42:55

>>215
現実的でないけど、
オペレータの操作全てをテストデータにすれば、良いってこと？

喪前がいつも行ってるテストってどんなの？
# もしかして人の手で...

220 ：デフォルトの名無しさん：2005/07/18(月) 21:47:50

人の手でやってますorz

221 ：デフォルトの名無しさん：2005/07/18(月) 22:50:37

>>219
だからさぁ、「全て」っていうのがどこから出てくるのかと。

222 ：デフォルトの名無しさん：2005/07/18(月) 23:03:59

おいらのところでは
・テスト項目を挙げやすいように
・ツールでテストしやすいように
設計を工夫してます

まさにテスト駆動です

223 ：デフォルトの名無しさん：2005/07/18(月) 23:08:10

テストを書き、そのテストがパスするようにコードを記述する

設計を先にするのはテスト駆動とは言わない

224 ：デフォルトの名無しさん：2005/07/18(月) 23:19:18

> 設計を先にするのはテスト駆動とは言わない

んなバカな

225 ：デフォルトの名無しさん：2005/07/18(月) 23:21:21

>>223
先に何をしたいかじゃないの？先に設計しないと
おれにはテストコード（毎度書く）を作れないよ…

226 ：デフォルトの名無しさん：2005/07/18(月) 23:24:44

>>221
すべてじゃなくてもいいけど、どうやって一部でも半自動化とかしてんの？
おれにはテストコードを自動生成というのが想像付かん。

それこそプログラムそのものを生成できるほどの人工知能がいると思うんだが。

227 ：デフォルトの名無しさん：2005/07/18(月) 23:25:01

#設計という工程名の指示対象の違いが

228 ：デフォルトの名無しさん：2005/07/18(月) 23:52:56

>>226
条件網羅とかなら、それなりに自動生成できると思うけど。

229 ：デフォルトの名無しさん：2005/07/19(火) 00:30:54

>>227
どの設計でも同じことなんだな、これが

230 ：デフォルトの名無しさん：2005/07/19(火) 00:43:34

ひとりよがりで意味がわからん。

231 ：デフォルトの名無しさん：2005/07/19(火) 01:04:35

テストと一口にいってもいろいろあるからなぁ。

単体テスト、結合テスト、総合テスト、運用テスト

学生気分の派遣野郎にテスト頼んだら中間テストや期末テストについてぐだぐだ語りやがったし。

232 ：デフォルトの名無しさん：2005/07/19(火) 09:09:46

>>215
> なんで汎用化できるんだあ？？
できないよアフォ。
千差万別の仕様に応じた千差万別のテストケースを書くんだよアフォ。
テストの自動化はテストの全自動化とイコールじゃないんだよアフォ。
お前の言う汎用的なテストができるころには設計から納品まで全部自動化されて全員失業だよアフォ。

233 ：デフォルトの名無しさん：2005/07/19(火) 11:00:06

やっぱできないんだ。
そんならテストツールなるものはいったい何をしてくれるものなの？

＞千差万別のテストケースを書くんだよアフォ
それじゃ毎度全部手でやるのと変わらないじゃん

234 ：デフォルトの名無しさん：2005/07/19(火) 11:06:46

>>233
> それじゃ毎度全部手でやるのと変わらないじゃん

なんでそうなる？
一度書けばあとは自動でやってくれるテストと、毎回手でやるテスト、一緒か？

235 ：デフォルトの名無しさん：2005/07/19(火) 11:17:13

ちがう、手でやるとは手でテストコード書くという意味で言ってるつもり

結局何？　毎度テストコードを手動で書かなきゃいけないというのを
軽減してくれる画期的な手法じゃないということか。

それだったら前からやってるが（普通誰でもやる）、例によってご大層に
名前付けただけなんか

236 ：デフォルトの名無しさん：2005/07/19(火) 11:40:48

とりあえず、

>でもさあ、入力の形式は千差万別でしょ？　出力だってそう。

に関しては方法論がある。
つまり、「全ての場合」をいちいち全部書かなくても、
最低限のテスト記述で充分な効果を上げられるような手法がいくつかある。
「テスト設計」などで検索してみるとよい。

これはテストツールとは独立した問題のような気がする。

237 ：デフォルトの名無しさん：2005/07/19(火) 11:45:45

>それだったら前からやってるが（普通誰でもやる）、例によってご大層に
>名前付けただけなんか

問題は、そうやって作ったテストプログラムを、
自動実行したり、他の人に渡したり、といったことが簡単にできるか、
ということ。

テストツールのありがたさは、そういった部分が統一されているということ。
反復開発などを導入すると、開発が進むに従って、テストがどんどん増えてくる。
同じテストを繰り返し何度も何度も実行することになる。
そのときに、毎回手作業で勝手気ままに作った、起動方法も、合否判定方法も違う
テストケプログラムをいちいち動かして結果を調べたりしてらんないということ。

238 ：223：2005/07/19(火) 12:24:18

要求分析　　　テスト3
　仕様化　　テスト2
　　設計　テスト1
　　　実現

設計はテスト1を考えてからだが、何か？

239 ：デフォルトの名無しさん：2005/07/19(火) 12:41:28

あー。V字モデル

240 ：デフォルトの名無しさん：2005/07/19(火) 12:55:25

テストコード先に書くのがテストツール？

241 ：デフォルトの名無しさん：2005/07/19(火) 12:57:39

テストツール使ってテストするなり

242 ：デフォルトの名無しさん：2005/07/19(火) 14:33:51

>>240
そんなこたぁない。
ツールはあくまでもツール。
テストファースト（テストを先に作ること）は手法。

243 ：デフォルトの名無しさん：2005/07/19(火) 14:38:12

おすすめテストツールｷﾎﾞﾝ

244 ：デフォルトの名無しさん：2005/07/19(火) 14:45:30

CUnit

245 ：デフォルトの名無しさん：2005/07/19(火) 14:49:27

NUnit
とtestdriven.net
これ最強

246 ：デフォルトの名無しさん：2005/07/19(火) 15:03:38

CUnit for Mr.Ando
ttp://park.ruru.ne.jp/ando/work/CUnitForAndo/html/index_ja.html
CppUnit-xをベースにしたC言語テスティングフレームワーク。
CUnitよりもシンプルでプアな環境でも使用できる

247 ：デフォルトの名無しさん：2005/07/19(火) 20:04:04

> .a/.soライブラリなどC言語技術者にとって複雑な機構を持たないこと。
わろす

248 ：デフォルトの名無しさん：2005/07/22(金) 16:31:35

書き込んでリンクして組み込むってのが、ツールっぽくない

249 ：デフォルトの名無しさん：2005/07/22(金) 23:49:15

やっぱboos::testtじゃないの？流れ的には。

250 ：デフォルトの名無しさん：2005/08/21(日) 12:47:50

テストコードいちいち用意するのがﾏﾝﾄﾞｸｾ

251 ：デフォルトの名無しさん：2005/08/29(月) 10:15:50

テストツール比較の記事が出てたので参考までに。
http://www.c-sq.com/modules/article/article27.html
(閲覧には無料の会員登録必要)

252 ：デフォルトの名無しさん：2005/08/31(水) 09:52:13

Jtest 使ってる方、いらっしゃいませんか？

いくらぐらいで購入したか教えていただけると嬉しいです。

253 ：デフォルトの名無しさん：2005/08/31(水) 10:28:46

ワレモノ

254 ：デフォルトの名無しさん：2005/08/31(水) 10:36:48

それはイカンね

255 ：デフォルトの名無しさん：2005/09/03(土) 13:09:26

JUnit用でテストするために、ユーザーを管理するクラスのテストケースを書いてます。
ユーザーを検索するメソッドと、パスワードを認証するメソッドが分かれています。
ユーザー検索のメソッドで取得させたユーザーオブジェクトを、パスワード認証のメソッドで使い回ししたいと考えているのですけど、

public UserObj testFindUser(){
......// test code
return userObj
}

public boolean testAuthPass(){

UserObj userObje = testFindUser();
// ......
return ....
}

という感じに書くのは、JUnit的にどうなんでしょうか？TestRunnerからはtestFindUserが２回呼ばれるので
好ましくない希ガス…。ユーザーを検索するロジックだけを共通化させておくべきですかね？

256 ：デフォルトの名無しさん：2005/09/03(土) 13:46:41

>>255
あるテストから別のテストを呼び出すのはよくない。
全テストで必要なものはsetUpで準備するが、原則として
同じ処理があっても個々のテストケースにコピペする。
理由はまさーるさんのページを読んでみて。

ObjectClub - JUnit 実践講座 - プログラミングスタイルガイド
http://www.objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/junit/programming-style-guide.html

> テストコードではリファクタリングを行うべきではないのです．共通部分が
> あるからといってまとめてメソッドにしてしまうと，特殊解，つまりテストデー
> タが見えにくくなり，テストデータを修正することが困難になります．

257 ：255：2005/09/03(土) 15:43:41

なるほど、スッキリしました。ありがとうございます。
なんか非生産的な感じもしますが、まぁ致し方ないでしょう。もちっと勉強します。

258 ：名無しさん＠そうだ選挙に行こう：2005/09/11(日) 12:36:43

JUnit でテストを実行してて、そのテストクラスのすべてのテストメソッドが終わったことを捕まえたいんだが、
どういう方法があるでしょう？（そのテストクラスが終わったあとのゴミ掃除をしたい）
tearDown はメソッドごとに呼ばれてしまうけど……TestSuiteのサブクラスでそれぞれのテストを実行したあとに独自に
実行という感じなのかな？

259 ：名無しさん＠そうだ選挙に行こう：2005/09/11(日) 14:38:11

staticな生成カウンタでも持ったら

260 ：デフォルトの名無しさん：2005/09/12(月) 21:44:23

UWSC

261 ：デフォルトの名無しさん：2005/09/12(月) 23:11:37

U:うんこが
W:ワイルドに
S:しょんべんと
C:ちびった

262 ：デフォルトの名無しさん：2005/09/12(月) 23:13:07

2chはIPが記録されてるよ
プロバイダもログ取ってるよ
あんまアホな書き込みしないほうがいいよ

263 ：デフォルトの名無しさん：2005/09/13(火) 21:34:29

>>262
こういう正義ぶってるやつダイダイだーーーいっきらい。

264 ：デフォルトの名無しさん：2005/09/14(水) 00:26:55

>>263
おれはおまえのことが好きだ

265 ：デフォルトの名無しさん：2005/09/14(水) 03:07:27

正義って？
まさよし君ってことか？

266 ：デフォルトの名無しさん：2005/09/14(水) 19:50:04

EclipseでJUnitを使っております。

JUnitについて質問です。
JUnitで例外が投げられたかどうかをテストしたいのですが、
どのようにしてテストコードassert系メソッドをつかえばいいでしょうか？

やはりif文で制御するしかないのでしょうか？
例外が投げられると、その時点でJUnitが終了してしまいます。

267 ：デフォルトの名無しさん：2005/09/14(水) 21:36:40

catchの中で使えばいいんちゃう・・・・？

268 ：デフォルトの名無しさん：2005/09/14(水) 21:46:46

try{
manko.chinko();
}catch(ぬるぽ e){
e.printStackTrace();
assertTrue(true);
}

269 ：デフォルトの名無しさん：2005/09/14(水) 21:56:10

>>268
それだと、Exception が出なかったときに何事もなく終わってしまうぞ。

try{
manko.chinko();
fail();
} catch(Exception e) {
assertTrue( e instanceof ExpectationException );
}

270 ：デフォルトの名無しさん：2005/09/14(水) 22:44:13

>>269
ちがう、ちがう。つっこむ場所がｗ

>>268 ｶﾞｯ

271 ：デフォルトの名無しさん：2005/09/14(水) 23:45:26

JUnitインアクション読んだ人に質問。
みんな本に書いてある事ありのままに実践してる？
自分の場合やっぱり納得できるところだけ取り入れて実践してるんだけど、
テストの検証のためにテスト対象のクラスにメソッドを追加する・・とか
やってない。
あと、テストファーストもしてない。

272 ：デフォルトの名無しさん：2005/09/17(土) 11:52:05

んなこた同僚にでも聞けよ

273 ：デフォルトの名無しさん：2005/09/17(土) 15:55:09

>>271
漏れは>>272みたいな社会性の無い糞で屑なエンジニアじゃないから、こたえてあげますね('∀`)

本の書いたままに実行はしてない。そういう現場もあまり観たこと無い。
packageごとに機能をわけていたとした場合、入り口となるクラスのテストや
ユーティリティクラスのテストがほとんどだよ。外部からアクセスできないクラスや
privateメソッドのテストをまじめに書いているところはわずか（というか言葉は悪いがエンジニアのこだわり程度で書いてる）という感じだ。
もちろん、プロジェクトの方向性によってまちまちだ、というのは付け加えておく。
テストファーストは漏れの現場では出来るだけ書くようにとエンジニアには教育している。
テストを先に書くメリットとデメリットを常に天秤にかけているようにしてる、つもり。
参考になれば幸いデス。

274 ：デフォルトの名無しさん：2005/09/17(土) 16:06:01

>>266
ん。NUnitだと、

[Test]
[ExpectedException(typeof(ぬるぽ))]

みたいに属性を指定すればいいんだけど、
JUnitで同様のことはできないの？

275 ：デフォルトの名無しさん：2005/09/17(土) 16:08:29

>>276
JUnit4からなら。

276 ：デフォルトの名無しさん：2005/09/17(土) 16:12:21

>>273
すみません、Privateメソッドのテストってどうやって書くのでしょう？
よくわかんないから、
Private hoge()
のテストは、クラスのケツに

Public hogePublicForTest(){hoge()}
みたいなのをまとめて作って、これをテストしてるんだけど、
普通はどうやるのかな。

277 ：デフォルトの名無しさん：2005/09/17(土) 16:17:12

273じゃないけど、 JUnitXが使える。

278 ：デフォルトの名無しさん：2005/09/17(土) 17:21:06

>>276

リフレクション使ってたたくのが一般的かな。
でもprivate メソッドのテストは本当に必要かどうかを検討する。privateメソッドはそのクラスのどこかで使われるわけだから、
そのメソッドのテストを書くのが良い。

リフレクション使って書くと可視性落ちるし書くのが面倒。なので漏れのところはprivateメソッドのテストは書いてない。

279 ：デフォルトの名無しさん：2005/09/17(土) 19:43:27

private は内部ロジックに属する問題だからな。
ホワイトボックステストになってしまう。
デバッグでのロジック検証に使うような状況では必要かもしれんけど。

チューニングやアルゴリズム改良で仕様を変えたり、
消したりするかもしれんものに、いちいちテスト作ってもなあ。

280 ：デフォルトの名無しさん：2005/09/18(日) 03:19:34

Publicは、複雑なPrivateを山ほど叩いた後で最終結果をちょろっと出力するだけ
みたいな場合は、ホワイトボックステストにしないとキツいですよ。

別々に４種類の条件処理があるPrivateメソッドを３つ使うPublicをテストする場合、
Privateテストなら、４＋４＋４で、テストケース１２種類。
Publicテストなら、４×４×４で、テストケース６４種類。

281 ：デフォルトの名無しさん：2005/09/18(日) 09:54:08

272の立場ねぇなぁ www

282 ：デフォルトの名無しさん：2005/09/18(日) 10:59:26

>>272
こういうことが聞ける同僚がいたらどんなにすばらしいか。。
羨ましいです。

>>273
なかなか参考になりました。というか、少し楽になったというべきか。。
（本当は自問しまくりで少し疲れていました）

>>280
privateをリフレクション使ってテストする人っているんだ。
だけど、たしかに>>280のような状況ならメリットすごくあるかもね。
（４＋４＋４ですべてOKかっていうとちょっと異論あるけど、そこは置いておいて）

テストの話と離れちゃうけどprivateがたくさんあるメソッドについて、
設計が悪いってよく言われるけど、ホントにそうなんかな～？って
いつも考えてる。
答えはまだでてないけど、なんだか騙されてる気がするだよね～。

もっとクラス抽出できるはずって考えても、結局抽出しても他でそのクラス使わない
可能性が高いのならあんまり意味ないし、そこまでする事のメリットが薄いと
思うんだよな～。
仮に他でも使うにしても、小さなものなら設計じゃなくてもうユーティリティクラスに
してしまう事が多いよ。大きなものなら、privateで構造化にしてしまう。
そこまで考えたくないし、そう設計しても誰も特別喜ばない気がするし、
現実とって割り切りたい。

283 ：デフォルトの名無しさん：2005/09/18(日) 21:00:56

Apache MavenでJava5のGenericsがつかわれた
コードをtestゴールでテストしようとすると
テストに失敗するぞ？
失敗というか、エラーになるんだけど。

Eclipse3.1のJUnitではエラーもフェイリャーもなくテストにちゃんと成功する。

で、MavenでGenericsのコードの部分をコメントアウトするとテストに成功する。
なんでだろー

284 ：デフォルトの名無しさん：2005/09/18(日) 21:40:40

>>283
俺んとこでは上手くいっているとだけ言っておこう。

285 ：383：2005/09/18(日) 21:46:28

>>284
えーなんでだろー
C:\Documents and Settings\user\.maven\cache/maven-test-plugin
を削除してもだめだったなんでだろー
C:\Documents and Settings\user\.maven\repository/junit
を削除したら

==========================================================

NOTE: Targetting JVM 1.5, classes
will not run on earlier JVMs

==========================================================

こんなメッセージがなんでだろー

286 ：283：2005/09/19(月) 04:06:01

__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to C:\Documents and Settings\user\workspace\HtmlImageTagGenerator/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
test:test:
[junit] Running パッケージ名.テストクラス名
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.25 sec
[junit] [ERROR] TEST パッケージ名.テストクラス名 FAILED
Total time: 13 seconds
Finished at: Mon Sep 19 04:02:57 JST 2005

BUILD FAILED
File...... C:\Documents and Settings\user\.maven\cache\maven-test-plugin-1.6.2\plugin.jelly
Element... fail
Line...... 181
Column.... 54
There were test failures.

だめだこれ。 plugin.jellyは削除してから自動生成されたものだし、
一体何処に原因が・・・・？

287 ：283：2005/09/19(月) 04:07:31

project.propertiesに以下を追加したら
==========================================================

NOTE: Targetting JVM 1.5, classes
will not run on earlier JVMs

==========================================================
が表示されなくなった。
maven.compile.source = 1.5
maven.compile.target = 1.5

だが上記(>>286)のエラーはまだ消えず。

288 ：283：2005/09/19(月) 04:10:44

jellyのエラーヶ所はここだってメッセージがでているけど
${context.getVariable('maven.test.failure.ignore') がtrueじゃなかったら
失敗したことにしろってなってる。

<j:if test="${maven.test.failure}">
<j:if test="${context.getVariable('maven.test.failure.ignore') != 'true'}">
<fail message="There were test failures."/>
</j:if>
</j:if>

これどうすりゃいいんだろう。ignoreをtrueにして無視しろって？
何か不安だ。EclipseのJUnitだけで検査すればいいとはいえ。

289 ：デフォルトの名無しさん：2005/09/19(月) 08:56:35

>>288
target/test-reports/TEST-パッケージ名.テストクラス名.txt
target/test-reports/TEST-パッケージ名.テストクラス名.xml
には、何か出ていないのか？

290 ：デフォルトの名無しさん：2005/09/19(月) 14:55:19

>>288
maven-jcoverage-plugin 使ってません？
jcoverage が Java5 の文法にまだ対応してないので、
Generics なんか使ってると、こいつのせいでテストが失敗した記憶があります。

291 ：283：2005/09/19(月) 18:00:27

>>289-290

申し訳ない。
自分の勘違いが含まれていたようだ。
Eclipseのほうで動かしたらfailureが出た。
で、それを直してからMavenてtestゴールしたら動いた。
JVM1.5がどうだこうだというおも関係ないみたいだ
だから、↓を追加してもしなくても動いた。
maven.compile.source = 1.5
maven.compile.target = 1.5
maven.test.source = 1.5

jellyファイルも何も弄る必要は無かったようだ。
その代わり、.maven直下のcache, repositoryはすべて削除してから
実行しなおした。

みんなサンクス。

292 ：デフォルトの名無しさん：2005/09/19(月) 18:04:02

>>289
そうか、そのファイルに詳細がかかれているのか、
参考になった。
>>290も参考になった。サンクス。

ついでに、Checkstyleもversion4.0になってもまだJava5の新文法には
対応していないみたいだ。
Eclipse3.1でCheckstyleプラグインをつかってみたが
Genericsのところで容赦なく警告が大量に出た。

293 ：デフォルトの名無しさん：2005/09/30(金) 17:43:40

漏れはいまだにVB6だ。VB6系のテストツールは高くて買えん(TT)。

294 ：デフォルトの名無しさん：2005/10/01(土) 18:18:26

>293

とりあえず VBUnit の free 使っとけ
テストドリブン汁!

295 ：デフォルトの名無しさん：2005/10/03(月) 21:46:07

>>293
ま、VBUnitというところなんだろうが。
とはいえ、GUI系のテストはxUnit全般の難所だから、クリックイベントのプロシージャなんかにロジックをギチギチに詰め込んでたりするとかなり苦戦するぞ。警告しておこう。

296 ：デフォルトの名無しさん：2005/10/03(月) 22:23:50

jameleon使った事ある人います？
ttp://jameleon.sourceforge.net/

ちょっと試してるんだど、Jiffie-Plugin使った場合日本語のページが文字化けして
まともにテストできないんですよ。
テスト対象ページの文字コードってどうやって指定すれば良いのかなぁ。
デフォルトでUTF-8が使われるって書かれているような気がするが、変更方法がわからん。

HttpUnit-plugin使ったテストは動かせたけど、内部的にIE使ってるJiffieの方が
使いたいんだよねぇ。テスト時の見た目もかっこいいし。

297 ：デフォルトの名無しさん：2005/10/04(火) 09:44:23

>>295
なんか前提がおかしいような。
ｘUnit使う場合、テストケースの設計をするうえでモジュール化されるよ半強制されるようなものじゃないか？
だから、ボタンイベントにロジック詰め込んでるつくりってのが場面としておかしい。

298 ：デフォルトの名無しさん：2005/10/05(水) 20:18:17

>>297
ま、>>295のソフトの作り方がテストファーストじゃないだけだろ。
ただ、確かににおまえさんの言うとおり、xUnit使用を前提とすると、クラス・モジュール設計の根幹はひっくりかえるよな。
俺も最初は悩まされたもん(TT)。

299 ：デフォルトの名無しさん：2005/10/05(水) 20:28:03

馬鹿じゃねーのＸＰは元から破綻してんだよ

300 ：デフォルトの名無しさん：2005/10/06(木) 10:56:05

300get

301 ：デフォルトの名無しさん：2005/10/06(木) 16:12:05

これどうよ？。GUIテストで使ってる椰子おらんか？。
つttp://www.h5.dion.ne.jp/~hogeneko/ft/

302 ：デフォルトの名無しさん：2005/10/06(木) 21:57:51

フリーでもっと全然いいツールがあるよ

303 ：デフォルトの名無しさん：2005/10/06(木) 22:08:11

全然いいの「全然」は否定するときにつかうから、この場合は

・フリーでもっと凄いツールがあるよ
・フリーでもっと使えるツールがあるよ

などが良いと思われるが、キミはどう思うかね？>>302

304 ：デフォルトの名無しさん：2005/10/06(木) 23:58:00

>>303
ここが2ちゃんねるであるにも関わらず正しい日本語を要求するのは噴飯ものではないかと思うのだが、
キミはどう思うね？

305 ：デフォルトの名無しさん：2005/10/07(金) 01:40:33

肯定文脈で「全然」を使うのは明治時代ごろには普通のことで夏目漱石も使ってるけどスレ違いではないかと思うのだがキミはどう思うね？

306 ：デフォルトの名無しさん：2005/10/07(金) 10:33:13

たしか、森鴎外も使ってたな。

307 ：301：2005/10/07(金) 11:12:25

>>302
そのフリーのツールを教えてくれぽ。
（日本語論議は文学板でもいってやってくれ）

308 ：デフォルトの名無しさん：2005/10/07(金) 14:00:53

「噴飯ものではないかと思う」
なんて言い回しは日本語としてどうよ？

309 ：デフォルトの名無しさん：2005/10/11(火) 01:30:37

DbUnitを最近使い始めたんだが、exportしたデータをそのままinsertする際に
外部参照制約に引っかからないようにする方法がわからん。

以下のどれかが可能ならなんとかなりそうなんだが、だれかわかりませんか？

・依存性を考慮したexport
・exportするテーブルの出力順を明示的に指定
・insertでformat="csv"として、insertするファイルの順序を明示的に指定
・insertでformat="csv"の際、srcにディレクトリではなくファイルを指定

310 ：デフォルトの名無しさん：2005/10/13(木) 15:59:21

＞privateで構造化にしてしまう
あんまし宜しくない作り方かと思う

311 ：デフォルトの名無しさん：2005/11/03(木) 02:09:26

やっぱＧＵＩに自動的に入れてくれるテストツールが必要
３万ぐらいで。
マーキュリ高すぎ。だれが買うか

312 ：デフォルトの名無しさん：2005/11/03(木) 03:44:04

> ＧＵＩに自動的に入れてくれるテストツールが必要
意味が分からないんだが、誰か翻訳してくれ。

313 ：デフォルトの名無しさん：2005/11/03(木) 11:36:56

エロすぎ

314 ：デフォルトの名無しさん：2005/11/03(木) 13:59:23

>>312
GUIで、なんかしらんけど自動的に必要なテストデータとか
つくってテストしてくれるツールが必要ってことじゃない？

315 ：デフォルトの名無しさん：2005/11/03(木) 14:25:59

試用版あるから色々使ってみれば？

316 ：デフォルトの名無しさん：2005/11/03(木) 21:14:36

>>312
「ＧＵＩで」じゃなくて、「ＧＵＩに」と書いてるから、テストされるプログ
ラムのＧＵＩ (テキストボックスとか) に、データを入れてくれるツールが欲
しいってことだろ。

よくは知らんが、WinRunner とかのフリー版もしくは廉価版が欲しいってこと
だと思う。

317 ：デフォルトの名無しさん：2005/11/03(木) 21:46:15

文がめちゃくちゃだから「で」って書きたかった可能性あり。

318 ：デフォルトの名無しさん：2005/11/03(木) 22:35:52

マーキュリーってんだから、WinRunnerみたいなやつだろ。

319 ：デフォルトの名無しさん：2005/11/03(木) 22:43:31

eclipse TPTPのAutomated GUI Recorderは？
http://www.eclipse.org/tptp/test/documents/userguides/Intro-Auto-GUI.html

まだ、TechnologyPreviewだけど。
おれ、つかったことないけど。

320 ：デフォルトの名無しさん：2005/11/05(土) 03:27:15

>>319
いいみたいだね。昔のvisual Testみたいなやつがいいのだが。
このツールジャストのプロバイダ設定するのにも使っていた記憶がある
なんでＭＳは売ったのだろう。？

321 ：デフォルトの名無しさん：2005/11/06(日) 21:56:07

>>309
もう解決しちゃったかな？
おれは、エクスポートしたXMLファイルのレコードを入れ替えて制約にかからないようしてる。そのまま
エクスポート/インポートをしたいのであれば、
> ・exportするテーブルの出力順を明示的に指定
じゃないかな？エクスポート時に自動的に制約を考慮してやってくれるようなオプションっておれの探した範囲ではな
かった。

322 ：デフォルトの名無しさん：2005/11/07(月) 13:00:07

すみません。質問というか相談です。

コードがジャングルのように入り組んでしまった、瀕死のプロジェクトがあり
まして、もちろんテストクラスは一つも作られていないのですが、これに少し
ずつテストクラスを加えていって、リファクタリングしていくことは可能でしょ
うか？

コード作成者はもういないので、コードを読んで保守、改修しているのですが、
あまりにも理解できないコードで、全く作業がすすみません。おそらく書いた
当人も理解せずに書いたらしい、ただ偶然動いているだけのコードなのです。

出来るなら全部作り直してしまいたいぐらいなのですが、仕様自体も入り組ん
でいるので、ヘタにいじると動かなくなってしまいます。すでに曲がりなりに
も稼動中なので、完全に作り直すことは難しいです。

リファクタリングをするためには、その修正個所すべてに自動的な単体テスト
が用意されるべきだと聞きました。ということで、今からテストクラスを作っ
ていくことで、リファクタリングが出来ないかと考えました。ただ、メソッド
の一つ一つが巨大なので、テストクラスを組むのも難しそうなのですが。

ということで、既存のプロジェクトにあと付けでテストケースを組み、リファ
クタリングをすることは現実的に可能でしょうか？また参考になる資料はない
でしょうか？

323 ：デフォルトの名無しさん：2005/11/07(月) 13:29:43

仕様自体が曖昧ならテストしようがないと思うが。
単体テストというのはあくまで各メソッドが仕様（事前条件、事後条件etc）通りに
動作するのを保証するためにやるものでは？

その仕様がはっきりしてるのなら、後付けでテストケースを組んでリファクタリング
後にデグレードがないかを確認するのは問題ないと思う。

324 ：デフォルトの名無しさん：2005/11/07(月) 14:17:54

仕様に記述されていない振る舞いに依存してるコードとかあると大変。

325 ：322：2005/11/07(月) 16:22:19

コメント、ありがとうございます。

仕様ははっきりしていません。仕様書も存在しません。SE氏とプログラマが相
談しながら作ったコードで、そのコード以外に資料はありません。SE氏はまだ
在籍していますが、細かいことは忘れていますし、他プロジェクトで忙しいの
です。そのコード自体の挙動もおかしく、お客様からバグ修正依頼がたくさん
来ます。

誰か天才が書き直してくれればよいのですが、そういう人はいません。こうい
う場合、どうやったら常人の手に負えるプロジェクトになるんでしょう？XP
という手法を聞いて、部分的にでもそれを取り入れたらこのプロジェクトを改
善できないかと思ったのですが、途中からはじめても無理でしょうか？

Kent Beck氏はプロジェクトを途中から立て直したみたいですが、どうやっ
たのか大変知りたいです。ただ Beck氏のプロジェクトは、何だかんだ言って
一定水準以上のプログラマしかいなかったようですが。
http://www-06.ibm.com/jp/developerworks/java/030926/j_j-beck.html

326 ：デフォルトの名無しさん：2005/11/07(月) 17:09:07

＞ただ Beck氏のプロジェクトは、何だかんだ言って
＞一定水準以上のプログラマしかいなかったようですが。

これに尽きる。ｗ

途中で立て直したと言っても、リリース後バクだらけ・ドキュメントなし・ソースはスパゲッティ・
作った奴は行方不明という状態を救ったわけじゃないんじゃないのかい？

327 ：デフォルトの名無しさん：2005/11/07(月) 18:34:54

テストを書きながら仕様を再構築するしかないんじゃないの・・・。

328 ：デフォルトの名無しさん：2005/11/07(月) 19:00:20

とりあえずBeck氏にならって顧客をヒキズリコメｗ。
それが出来ないなら>>327氏の方法になるかな

329 ：デフォルトの名無しさん：2005/11/07(月) 19:03:31

もっとも >>327 はモチベーション維持が大変な茨の道だが。

新し物好きの天才肌ほどモチベーション低下が著しい。

330 ：322：2005/11/07(月) 19:50:59

いろいろありがとうございます。
顧客様は、費用、人材の追加にはともに大変否定的で（システムの現状からし
て当たり前ですが）、しかも新幹線で行くような遠隔地にいらっしゃいます。

モチベーションですが、私は天才肌でもなんでもありませんが、このシステム
に関わってから、心身ともにぼろぼろになってしまい、何とかモチベーション
をアップできないか、このプロジェクトに関わった人が皆で幸せになれないか、
と考えてXPに興味を持ったのです。この上モチベーションの下がるようなこと
は、なかなかきびしいです…。

331 ：デフォルトの名無しさん：2005/11/07(月) 19:57:53

>>1->>330は勘違いしてる。開発というのは
設計→実験→実装→テスト　の繰り返しだ。
短いスパンでこれを繰り返したプロジェクトのみが成功する。

332 ：デフォルトの名無しさん：2005/11/07(月) 20:26:11

>>331
だからこそテストツールが重要なんだろうが

333 ：デフォルトの名無しさん：2005/11/07(月) 20:28:49

>>330
つうか>>325に出てくるＳＥ氏をみんなでシバき上げてストレス発散するのが一番じゃ？
プログラマと組んで仕事していながら、ドキュメント一つ残してないとはリンチもんだろ

334 ：322：2005/11/07(月) 23:03:01

殴って済むならそうしたいところですが、それで仕事がはかどるわけでもあり
ませんし、SE氏もドロドロになるまで働いていたのを私も知っておりますので、
あんまり殴りたくはありません。プロジェクトがこうなったのには、いろいろ
な事情があったのです。

それにしても、何か手は無いものでしょうか…。

335 ：デフォルトの名無しさん：2005/11/07(月) 23:29:18

> SE氏もドロドロになるまで働いていた
｢無能な働き者は間違った方向に努力して手遅れなことになるまえに銃殺してしまえ｣という名言があってな

336 ：デフォルトの名無しさん：2005/11/07(月) 23:43:57

リファクタリングは諦めて、機能仕様観点で

１．仕様を洗う
２．それに対するテストを追加する

地道にコレを少しずつ進めていく。
そうすれば、改修で正常系のデグレードを防げる確率が着実に上がる。
この際、テストも細かい異常系テストとか割り切るところは割り切る。
もっともデグレード防止に効果的だと思われる部分のみに着目して
テストを増やしていく。
幸せにはほど遠いけど、少しはマシになるんじゃないかと思う。

337 ：322：2005/11/07(月) 23:54:54

ゼークトの言に従うなら、まず私が死んだほうがよさそうです。
個人的には前任のプログラマを道連れにしたいところですが。
http://www.geocities.jp/asamayamanobore/AA/jinbutu/ze-kuto.html

ただ私は、プログラマに天才も超人的努力も要求しないXPという方法論には、
凡人がこの苦境を打開するヒントが内包されてはいないかと思ったのです。

結局は、>>327しかないのかもしれません。うう、やるしかないか。

338 ：デフォルトの名無しさん：2005/11/08(火) 00:08:28

「何か手は無いものでしょうか」と表明しても、素晴らしいアイディアが涌いて出てくるわけはないことはわかるよね。
原因を述べるなら現在の状態となるまで放置した（貴方が所属する）会社の管理体制の不備だろう。
現在の担当者が貴方であったとしても貴方の責任ではない。貴方の取るべき行動は「上司に相談する」だ。
テストツールについて語るスレで質問をして、技術面での解決を計ろうとしても
その行動自体が有効だとは思えないが。
#親切な人が沢山いて回答をしてくれているけど
#「ここはプログラム技術板だから板違いだよ」と言っているのだよ

339 ：322：2005/11/08(火) 00:17:55

>>336
失礼、先のを書き込むのに躊躇しているうちに、新しいレスが。
いただいたアドバイスは、まさに私が望んでいたもののようです。
作業料も目標も、何とか現実的なものにできそうです。

どこかで「スパゲッティコードをユニットテストで封じ込める」という表現を
目にしたのですが、なるほど、こういうことなのですね。ありがとうございます。

こういう方向での実践の参考になる資料はないものでしょうか？XP実践者のレポ
は目に付くのですが、デスマーチ脱出のノウハウは、WEBでも書籍でも見たことが
無いのです。

340 ：322：2005/11/08(火) 00:47:06

ごめんなさい、急に処理しなければならない用件が重なってしまいまして、
レスが行き違ったり、いろいろ失礼をしてしまったようです。

少なくともスレ違いではあるようですので、様子を見て他スレに移ります。
http://pc8.2ch.net/test/read.cgi/tech/1091773629/l20

※プロジェクト管理はSE板（情報システム板）なのでしょうが、あそこは
正直、行く気がしません。

341 ：デフォルトの名無しさん：2005/11/11(金) 14:54:25

>>322
参考になるかどうかは分からないが
ttp://japanese.joelonsoftware.com/Articles/Rubadubdub.html
を読んでみれ。

> いずれにしても、ゼロから始める代わりに、私はコードを完全に磨きあげるの
> に３週間費やす価値があると考えました。Rub a dub dub（コードをきれいに
> しましょう）。リファクタリングの原理にもとづき、これを実行するために私
> はいくつかのルールを作りました。
> 1.　新しい機能は、どんなに小さくても追加はしない
> 2.　いつでも、どのチェックインでも、コードは完璧に稼動する
> 3.　行うことはすべて論理的な変換－ほとんど機械的なことでで、コードの
> 動きをかえないとすぐ確信できる、そういう類の物のみ

テストがなくても、こういう作戦もあるらしい。
ところで、ソースコード管理ツールはもちろん導入済みだよね？

342 ：デフォルトの名無しさん：2005/11/11(金) 18:39:59

それをやるための強力な支援というか安全装置としてテストが欲しいという話でしょ

343 ：デフォルトの名無しさん：2005/11/12(土) 11:52:29

> 2.　いつでも、どのチェックインでも、コードは完璧に稼動する

もまえ、テストなしでどうするつもりだったんだ？

344 ：デフォルトの名無しさん：2005/11/12(土) 14:35:29

テストはするんじゃない？
自動化するしないは別として。:-P

あとこのケースの場合、xUnitである必要は全くないというか、
できあがってしまったプログラムの挙動に変化がないかを
テストするのに xUnit は役に立たない。

今あるプログラムの動作仕様がです、なんだから、
プログラムを動作させてその挙動を記録する
タイプのテストツールじゃないと厳しいんじゃない？

345 ：デフォルトの名無しさん：2005/11/12(土) 21:33:05

>>344
つ分割統治

開発途中で変更してはテストを繰り返すのに、時間かけてられないから
プログラム全体の動作検証なんて限られた正常系しか相手にできないよ。

346 ：デフォルトの名無しさん：2005/11/13(日) 02:52:11

>>345
いつまでプログラマ視点なんだ？

347 ：デフォルトの名無しさん：2005/11/13(日) 03:35:52

フリーでコンパイルできて実行もできるツールを教えてくださいませ

348 ：デフォルトの名無しさん：2005/11/13(日) 10:06:46

テスト項目管理ツールを使いたいのですが、
フリーで日本語のものってありますか?

Test Case Managerってテスト項目管理ツールの
日本語の辞書ファイルって
誰か持ってたりしますか?

349 ：デフォルトの名無しさん：2005/11/13(日) 10:28:08

>>348
普通にExcelつかっとけ。

350 ：デフォルトの名無しさん：2005/11/16(水) 23:41:05

俺はfree mindでテスト書いてる

351 ：デフォルトの名無しさん：2005/11/18(金) 17:49:41

質問です。
Eclipse上で Cactus を動かしたいのですが、しばらく前から Eclipse の
Cactus Runner プラグインが入手できなくなっています。現在はどのような使
い方が標準的なのでしょうか？いろいろ調べてみましたがよく分かりません。

http://blog.mag2.com/m/log/0000166561/106390244
http://blog.mag2.com/m/log/0000166561/106414834
このあたりを見ると、
・Jetty 統合などはしない。
・Tomcat は事前に立ち上げておく。テストのためにわざわざ起動、終了はしない。
・通常のJUnitテストとして実行する。
というやり方が書かれています。

手元の書籍『JUnit インアクション』とはだいぶ違っていますが、このやり方は
Eclipse スレの過去ログでも推奨されていました。
http://makimo.to:8000/2ch/pc5_tech/1089/1089456669.html#355

また、野村総研のサイトで、Ant との連携が紹介されていましたが、
http://works.nri.co.jp/solution/index4-2.html
http://works.nri.co.jp/solution/open_pdf/AntonEclipseG2.pdf
これは一括でのテストには向いていても、TDDには向かないようです。

皆さんはどのようなやり方でやっていらっしゃいますか？

352 ：デフォルトの名無しさん：2005/11/18(金) 19:46:59

WTPでやるんかなぁ。
サーブレットテストケースのウィザードもあるし、[実行]→[サーバで実行]で実行できるし。

353 ：351：2005/11/18(金) 22:27:50

>>352
ありがとうございます。WTP はこれのことだと思うのですが、
http://www.eclipsewiki.net/eclipse/?Eclipse%20Web%20Tools%20Platform

これが Cactus と関係しているとは知りませんでした。調べてみます。

354 ：デフォルトの名無しさん：2005/11/22(火) 12:45:36

すみませんが、質問です。
データベース関連のテストは、どのようにやっていらっしゃいますか？

ドメインロジックとSQL - テストの容易性（Testability）
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL#l10
→「データベース環境でテストできるxunitツールがいくつかあったはずだ」

このxunitツールとは、DBUnitなどのことなのでしょうか？

http://www.techscore.com/tech/Others/DBUnit/index.html
ここを見たのですが、決して簡単にテストができるわけではないと感じました。
お使いになっている方はいらっしゃいますか？

355 ：デフォルトの名無しさん：2005/11/23(水) 11:59:02

>>354
きみの言う「簡単に」とは具体的にどういうことかを考えて書いてくれれば、
新しいアイディアになるかもしれんし、別のツールを紹介できるかもしれん。

356 ：354：2005/11/23(水) 15:27:26

>>355 ありがとうございます。
私の悩みは、どのようにしたら複雑なSQLを能率よくテストできるか、という
ことなのです。

Java のコードは、テスト項目を洗い出すことが比較的容易です。分岐やルー
プがあれば、大抵その条件をそのままテスト項目にできます。しかし SQL の
場合、なかなかテスト項目を抽出しにくいと私は感じます。どのようなデータ
とテストを用意すれば必要十分なのか、分かりづらいのです。特に、リンク先
に載っているような、サブクエリ等を使った複雑なSQLの場合は。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL#l7

しかし、先のリンク先でも、ファウラー氏は「テストが容易なSQLを作ること
は、確実に出来る。…」等の発言をしており、それを難しいものだと感じてい
ないようです。しかし、例えばリンク先のSQLなど、DBUnit でどのようなテス
トをすれば良いのでしょうか？

私は単に不慣れなだけかもしれませんが、皆さんの体験とノウハウを伺えたら、
と思います。

357 ：デフォルトの名無しさん：2005/11/23(水) 17:08:04

>>356
>私は単に不慣れなだけかもしれませんが、
いや、単に考えないで楽しようとしてるだけ。

>皆さんの体験とノウハウを伺えたら、
>と思います。
俺、虫のいい奴嫌いなんだよね。体験とノウハウを手軽に
貰うってあんまりすぎねーか？知ってる知らないくらいの話なら
良いんだけど。自分の飯の種くらい自分で始末しろ。

358 ：デフォルトの名無しさん：2005/11/23(水) 18:23:51

激しく同意。

359 ：デフォルトの名無しさん：2005/11/23(水) 19:24:47

>>357
器の小さいやつだなぁ。
すぐに人に抜かれるような技術力しかない奴が必死になるのはわからんでもないが。

360 ：デフォルトの名無しさん：2005/11/23(水) 19:26:45

>>359
煽っても何も出ませんよ

361 ：デフォルトの名無しさん：2005/11/23(水) 22:28:17

>>359
すぐに人に抜かれるような技術力を「ノウハウ」っていうのか？
ふ～ん、ノウハウの意味初めて知ったよ。ありがとう。

それに、>>357は
>知ってる知らないくらいの話なら良いんだけど
って言ってるじゃん。ちゃんと理解してから煽ってる？

362 ：354：2005/11/23(水) 23:42:51

すみません、私の質問は厚かましかったようです。スレが荒れ気味になってし
まいました。申し訳ありません。

お詫びになるかは分かりませんが、少しでも役立つ情報を。

「プログラマのためのSQL 第2版」
http://www.amazon.co.jp/exec/obidos/ASIN/4894714809

ご存知の方も多いでしょうが、これはSQLのバイブルのように言われる本です。
一般的にはRDBでは困難とされるような処理、例えばツリー型データ構造の処
理なども、鮮やかな技巧でSQLで記述してしまうのです。私は大きな影響を受
けました。

しかし今にして思えば、これらの技巧はパズルのように難解で、XPの立場から
は推奨されないものが多いようです。また、コードの読みやすさ、保守性、そ
してテストの容易さという観点も完全に抜け落ちています。ただ、それらに留
意して読むならば、やはり優れた本だと思います。

では失礼します。ご迷惑をおかけしました。

363 ：デフォルトの名無しさん：2005/11/23(水) 23:49:57

>>362
きにすんな。おまえはマトモだよ。

>>357 みたいなのが日本のエンジニア界現場をおかしくしてんの。

364 ：デフォルトの名無しさん：2005/11/23(水) 23:55:16

SQLの規格のpdfってどこかにない？

365 ：デフォルトの名無しさん：2005/11/24(木) 00:03:10

>>356
実装の知識を全く使わないブラックボックステストを書く練習をすると良いかもね。
今までのレス読むと、何をテストすれば良いのかわからないって感じに見えたから。

366 ：デフォルトの名無しさん：2005/11/24(木) 09:15:25

>>363
おまえはクレクレ君に対して肯定的なんだな。

367 ：デフォルトの名無しさん：2005/11/24(木) 09:42:01

>>366
自分がクレクレ君だからだろ。

368 ：デフォルトの名無しさん：2005/11/24(木) 09:54:12

おまえらなんかけちくせーなー
>>362
最初は一回正面突破試みましたか？これやらないでいいアイデアは
でないよー

369 ：363：2005/11/24(木) 09:54:45

そうだな三十路ぐらいまで米国でPGやっていたせいか正当なるクレクレ君には肯定的だな。
ここまでやってみた、だけどココをどうすればいいのだろう、アイデア持ってる香具師おらんかね
というコミュニケーションがあたりまえの世界だったからな。
362のは無条件にオレだけに教えてクレクレ君じゃないとみるからな。

日本人は職人気質みたいにオレのワザ盗めとか自分で全部まかなえという空気が現場レベルでも往々にしてあるが
かえって全体品質を落としていることと国際的にみると日本人エンジニアのレベルをも落としていることに全く気づいてない罠。

たかだかテストケースの書き方、テクニックぐらいでなんだよ。企業秘密でも何でもあるまい。

＃しかし漏れはDBUnitとかはいじったことないからナニも答えられないんだよなｗｗｗ

370 ：デフォルトの名無しさん：2005/11/24(木) 10:17:54

まぁ、「テストツールについて語るスレ」だからな
ごちゃごちゃ言わずにテストツールについて語れよ

で、今年の9月にリリースされたDDStepsについてなにか情報持っている奴はいないか？
http://www.ddsteps.org/

ドキュメントのこの図を見ると結構期待できそうなんだが……。
http://www.ddsteps.org/images/ddsteps_overview.png

371 ：368：2005/11/24(木) 10:19:52

じゃーちょっとだけ書いてみます
DBUnit使ったことあります。354に挙げてあるxunitがそうであるかどうかは読んでないから分からん
DBUnitは便利だと思う。データを準備しなきゃならんのはめんどくさいかもしれんけど
それによってリグレッションテストができるメリットは大きい。（きっとそこは同意してもらえると思うけど）
おれは普通にいくつかのテストケースを用意してやってるけど
「テストが容易なSQLを作ること」と「テストを楽にする」のは異なることだし
> Java のコードは、テスト項目を洗い出すことが比較的容易です。分岐やルー
> プがあれば、大抵その条件をそのままテスト項目にできます。しかし SQL の
>場合、なかなかテスト項目を抽出しにくいと私は感じます。どのようなデータ
xunitの目指すとこではこの内部の分岐からケースを考えるってのがあんまり
適切な考え方じゃないような気がする。何をテストするかを考えるべきではないかと思ってる
> とテストを用意すれば必要十分なのか、分かりづらいのです。特に、リンク先
必要十分というのがどういうことなのか？というのを調べて確認してみるとか？
（すでに知ってるんだﾎﾞｹｪだったらごめん）よく、「XXX網羅」って言ってるはず
後最後に、ここ2chですから下手に出すぎると煽られますので、「やいてめーらおしえろよ」ぐらいでいいでしょう（実社会じゃやっちゃだめ）
ついでに上げ

372 ：デフォルトの名無しさん：2005/11/24(木) 11:22:58

まぁ煽ってんのは毎回同じ人物だったりするんだろうけどねｗ

373 ：デフォルトの名無しさん：2005/11/24(木) 11:47:03

>>369

> 日本人は職人気質みたいにオレのワザ盗めとか自分で全部まかなえという空気が現場レベルでも往々にしてあるが
> かえって全体品質を落としていることと国際的にみると日本人エンジニアのレベルをも落としていることに全く気づいてない罠。

おお、それ俺も前から思ってた。よく変な先輩や年長者に騙されて、車輪の再発明
にそっくりなことのためにかなり時間を無駄に過ごしてきた気がするよ。
年長者とはお互いに違うことをやれば生産性が上がるのに、年長者が、「俺とおなじことをしろ。
ただしやり方は教えない。さもないと教育によくなく学習しなくなるから。」とか言いだして。
車輪の再発明みたいな無駄なことのために一から作り直すのではなく既存のものを
改良できるような仕組みを用意した方が効率がよいのだが。
それをいうと連中は精神論を語り出して、若い奴はだらしないとかわけのわからないこと言って。
まったく、儒教精神とか武士道精神って奴は悪いことばかりでどうにかならないのかね。
「日本人は真似ばかりしてるから独創性が無い」とか言われてきたが
それを勘違いして曲解してる香具師が沢山いる。実際には真似しなければ応用なんてできないのにな。
まず真似、模倣することから初めて真似・模倣したものを応用することで
オリジナリティや新たな発明、発見ができるのにな。

バイト先でもさ、古い考え方、とくに未だにステップ数やウォータフォールにとらわれて
ソフトの品質をいっこうにあげられないってのも情けないね日本のＩＴ業界は。
常に「お客様は神様だ」と言い張ってどんなに効率の悪いことでも言われたとおりにやろうとする。
こちらから客に提案することも、客にとってプラスになることがあるのにそれができない馬鹿が実に多いことか。
テストの自動化も理解できていないし、時間が無いから単体テストはするなとか言いだすし。品質は下がるわけだ。
日本のIT企業の大半がCMMレベルが1や2程度のばかりだってことがよくわかるよ。

374 ：デフォルトの名無しさん：2005/11/24(木) 11:58:09

>>373
饒舌だねｗ。総論同意。だけど一つだけ。
CMM自体も単なる一つの側面にしか過ぎないという認識／意識がないと
>ステップ数やウォータフォールにとらわれて
という人達と同じになってしまうから気をつけた方が良いよ

375 ：デフォルトの名無しさん：2005/11/24(木) 11:58:29

次世代JUnitであるTestNG使ってる香具師いる？

これ、Java SE 5 Tiger に対応しており
アノテーションを使っているため、Ｃ＃の属性のように
アノテーションにtestと書くだけで
テストメソッド名の頭にtestをつけなくて済むんだってさ。
C#のNUnitの影響を受け田っぽい。

メソッドの命名規則を考えずにそのまんま既存の実装メソッドを
とってきてテストできるような感じがいいね。

TestNGのEclipseプラグインもあるみたいだ。

新しいJava用テスト・フレームワーク - TestNG 2.4公開
http://pcweb.mycom.co.jp/news/2005/07/07/009.html

次世代JUnit、かと思ったら

　　一方でJUnitについては、アノテーションを導入した
　　次期バージョンである JUnit4の開発がKent Beck氏、
　　Erich Gamma氏らによって開始されている。

とかいてあった。

http://www.junit.org/ のサイトでは
これといって新しい動きと思われる情報が見あたらないな。

376 ：デフォルトの名無しさん：2005/11/24(木) 13:28:35

１から１０まで手取足取り教えなきゃ何もできねーような奴はいらねーな。
自分で動いた方が早い。

・・っておもっちゃうんだよなー。技術屋ってそういうところ無い？俺だけかな？

377 ：デフォルトの名無しさん：2005/11/24(木) 13:38:22

>>369
> たかだかテストケースの書き方、テクニックぐらいでなんだよ。
そう。「たかだか」テストケースの書き方なんだよ。
それぐらいは人様に教わらないでも出来ると思うんだよね。

378 ：デフォルトの名無しさん：2005/11/24(木) 14:01:42

>>376-377
>>369のいってること理解してねーな、おまえらみたいなのが（ｒｙ

もういいからテストツールについて語ってくれよ

379 ：デフォルトの名無しさん：2005/11/24(木) 14:14:02

>>377
> >>369
> > たかだかテストケースの書き方、テクニックぐらいでなんだよ。
> そう。「たかだか」テストケースの書き方なんだよ。
> それぐらいは人様に教わらないでも出来ると思うんだよね。

社内にできない奴がいてすごくムカツクんですけど。
奴らのせいでデスマばっかだしJUnitでテストしろと押しつけてきた顧客も
よくわかってないし。ServletをJUnitだけでテストしろと顧客が
要求してきたからJUnit知らない奴がテストケース作ったら
とんでもないことになりやがった。assert系メソッド一個も
つかってないでやがるんだよ。ただSystem.out.println()で
データベースに接続してデータを取得できたかどうかの確認を
表示してるだけにすぎず全然あてにならないテストケースを作りやがった。

で、ServletのdoPost()やservice()でHttpServletRequestオブジェクト、
HttpServletResponseオブジェクトをテストケースクラスから
取得する方法が解らずてこづってやがるし。
Cactusを勧めたが面倒くさがってわからないとかいって逃げるし。
でMockObjectも勧めたがそれを使う香具師は一人しかいないし、
ほかの奴はオブジェクト指向もServletもろくにわからんやつで
テストするたびに本番のコードを手動で修正してテストが終わったら
手動でもとに戻すという手間ばかりかけてやがった。
ホント疲れるんだよね。こういう馬鹿とプロジェクトで付き合うと。
C++ができるとかいってる奴が凄い奴かと思ったがJUnitとか
知らないでいやがる。C++ができると言っておきながらオブジェクト指向もわかってない。
だからCactusより手軽なMockObjectの使い方すらわからない馬鹿で困ったもんだ。

380 ：デフォルトの名無しさん：2005/11/24(木) 14:26:33

そりゃあんたがそういうバカがいるところに居るようなバカだからいけないんじゃないかね？

381 ：デフォルトの名無しさん：2005/11/24(木) 14:39:41

最近はツール自体は無料で、ノウハウやサポート等の提供で儲けるってのもあるしねぇ。

382 ：368：2005/11/24(木) 21:15:03

>>375
次世代JUnitについては、以下に記事が出てたよーん。個人的にはJUnitがJava向けてスティング
フレームワークのデファクトスタンダードでい続けてくれた方が混乱がなくていいかなと。。。
ttp://www-06.ibm.com/jp/developerworks/java/051007/j_j-junit4.shtml
>>376
我々は伝統工芸の職人じゃないからね。一人でできる仕事なんてない。もちろん伝統工芸の
世界でも漆器職人とか工程ごとに担当する職人が別れている場合もある。あと呉服とかもそうだよね。
加賀友禅だっけかな？こういった世界でも職人間でいろんな相談や話し合いはやってるはず。
>>377
もっといい方法やアイデアを持っている人がいるかもしれないとは思わない？あるいは
こう書き換えたらより便利なxunitができる、とか。日本人ソフトウェアエンジニアがこういう議論ができればも
もしかしたら、JUnitのようなものが日本発で生まれたかもしれない、と思ったりして
日本人は品質を非常に重要視する、といわれているし←ソフトウェアの世界では全然成り立ってない
ような、というのはみんなの認めるとこだろうけど

またあげっちゃうんでおまいら語れよ

383 ：デフォルトの名無しさん：2005/11/24(木) 23:51:28

んじゃ、DbUnitネタをひとつ。

DbUnitのAntタスクのformat属性には、"flat"、"xml"、"dtd"が指定出来るとドキュメントには
書いてあるけど、ソースを見ると"csv"も指定できることがわかる。

まぁ、csvファイルはデフォルトエンコーディングで読み書きされることと、nullを指定できない欠点が
あるんで、ソースに手を入れてエンコーディングの指定とnullを指定する機能を付け加えて使ってる。

テストデータをcsv形式で作成出来るんで素のまま使うより多少便利ってとこかな。

>>382
まぁ、日本のソフトウェアの品質や新しいアイデア以前に>>354の件は
「マニュアル嫁」「サンプル動かせ」「疑問があったらまず自分から動け」と言いたくなるな。

384 ：379：2005/11/25(金) 00:00:38

>>380
おれは学生バイトだから関係ねえや。
そこの会社に就職するつもりはないがな。

385 ：デフォルトの名無しさん：2005/11/25(金) 22:48:12

>>384
その割にはなんか熱く語っていたようだが？ (w

て言うか、バイト代さえちゃんとくれるんならアフォ
な会社の方が楽できるから金儲けと割り切ればいいだ
けだろ。

386 ：デフォルトの名無しさん：2005/11/26(土) 08:52:16

>>383

DbUnitのcsvは一瞬便利かと思ったけど、意外と使えないという印象だな。

せっかくテストデータを作っても、制約を考慮してくれないからうまくいかない
ことがない？テーブルのimport順を指定できるか、あるいはファイル単位での
importができれば良かったんだが。
テーブルごとにディレクトリ作ってやればなんとかなるけど、それじゃあんまり
便利じゃないしなぁ。

387 ：デフォルトの名無しさん：2005/11/26(土) 23:51:09

すみません、それ以前に、DBUnit のデータ用XMLファイルってどうやって管理
したらいいですか？

プロジェクトのルートディレクトリにどんどんXMLファイルが溜まって困ってます。
できたら、テストクラスと同じパッケージのディレクトリに収めたいんだけど…。

388 ：デフォルトの名無しさん：2005/11/27(日) 01:20:58

>>387
俺は、DatabaseTestCaseを継承したクラスを作って、setUp()実行時に
テストクラスと同じディレクトリにあって同じ名前のXMLファイルを自動的に読み込むようにしてる。
テストクラスがfoo.bar.BuzTestなら、XMLファイルはfoo\bar\BuzTest.xmlね。
他のJUnit拡張フレームワーク（Cactusとか)と併用したいときは、そういうことをしてくれる
ユーティリティクラスを作った。

389 ：387：2005/11/27(日) 02:31:06

>>388
なるほど！私は Cactus と、あと JMock を使いたいから、それぞれの継承
クラスを作ってみることにします。ありがとう！

Seasar2 の S2Dao は、テストクラスと同じ場所にデータファイルを置くのが
標準みたいですね。いいなあ。
http://www.seasar.org/testtech.html#S2DaoTestCase

390 ：デフォルトの名無しさん：2005/11/27(日) 02:48:57

関係無いけど、Cactus ってすごく遅いのね。この前初めて Tomcat で使って
ビックリ。Jetty統合だともっと速いのかな？

『JUnit イン・アクション』で、テストディレクトリを Cactus とその他で
分けることをすすめている理由がつくづくよく分かった。

もちろん、コンテナオブジェクトのモックを使うこと自体のメリットも
あるんだろうけど。

モックとスタブの違い
http://d.hatena.ne.jp/devbankh/201002
（自分には難しくてよく分からない）

391 ：デフォルトの名無しさん：2005/11/27(日) 20:32:12

モックとスタブの違いを混同したところで、あんまり困るような状況にはならない気が。
長々説明しているけど、きっとささいな違いなんでしょ？

392 ：デフォルトの名無しさん：2005/11/27(日) 22:57:19

違いがあるということにしたいキチガイが騒いでるだけだよ
きっと流行語大賞でも狙ってるんだろ

393 ：デフォルトの名無しさん：2005/11/28(月) 12:48:02

ただのバズワードだとは思わないけどなあ。

今までマーチン・ファウラーの文章をいろいろ読んできたけれど、自分に理解
できた範囲では、彼はいつでも現場のプログラマのための、地に足の着いたこ
とを書いていた。内容の無い営業向けのことを書いていたことは一度もなかっ
た。だから自分は彼のことをすごく信頼している。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/

この文章は確かに分かりにくいけれど、きっと彼の考えがまだ簡潔に表現でき
るほどまとまっていないか、もしくは自分に理解力と経験が足りないのだろう
と思う。

394 ：デフォルトの名無しさん：2005/11/29(火) 10:40:13

Armadillo: Unit Testing of inline SQL with a little help from Attributes and Reflection
ttp://www.codeproject.com/cs/database/Armadillo.asp

.NETで属性とリフレクションを駆使してメソッドが実行するSQLのシンタックスの単体テストをするツール(SQL Server専用)

1.set noexec on
2.メソッド実行
3.set noexec off

の順でクエリーを投げて例外が発生したらテスト失敗、無事に正常終了したらテスト成功って仕組みみたいだ。

395 ：デフォルトの名無しさん：2005/11/29(火) 12:23:24

>>394
これ、.NET だし、MS-SQL-Server だし、全然仕事で関わりそうにないのが残念。
Java で他のDBに対応したものが欲しいよねえ。

396 ：デフォルトの名無しさん：2005/12/03(土) 19:01:33

チューリングテストに対応したツールでオススメのものはありますか？

397 ：デフォルトの名無しさん：2005/12/03(土) 19:03:48

C++の自動テストツールってない？
完璧なテストケースを書くのがめんどくさいから
自動で適当に８０％ぐらい網羅してくれる奴。

398 ：デフォルトの名無しさん：2005/12/03(土) 19:12:30

>>397
80%？残り20%はどうするんだ？100%自動化してくれない
テストツールの方が珍しいと思うけど？
C++のテストツールだったら、C++Unitがあるよ。
結合テストしてくれるテストツールは知らん。
他の言語って結合テストしてくれるツールってあるのか？

399 ：デフォルトの名無しさん：2005/12/03(土) 20:55:12

ほとんどのバグは残り20%のところに埋もれる

400 ：デフォルトの名無しさん：2005/12/03(土) 22:13:03

>>385
時給が糞安い社長を始めとする取締役や上司らの人格に
問題があって会社の空気を悪くしてるから言ってみただけだよ。
最近では上司らの腹黒さが解ったので
こちらもこちらでそれ相応のことしかしないようにしている。
自分を安売りするようなことは決してしないように。
他のバイトに今のところよりよさげなのがあるので
新しいバイト決まるまで今の糞会社に残る予定。

401 ：デフォルトの名無しさん：2005/12/03(土) 23:37:20

『JUnit インアクション』を読み、JUnit を導入してみて、なかなか勝手が
分からずに苦労してきたのだが、最近やっと慣れてきた。
と同時に、衝撃を受けた。この自動単体テストって、単なる開発のツールじゃ
なくて、プログラミングに対する考え方そのものを変えてしまうような、もの
すごく大きいものじゃないだろうか？

・JUnit はどんなコードでもテストできるわけではない。現実的にはとてもテ
　ストできないようなコードの方が多い。
・逆に言えば、JUnit で自動テストを行うためには、テストのしやすさを強く
　意識したコードを書かなければならない。
・JUnit でテストのしやすいコードとは「粒度が高い」「疎結合」という条件
　を満たすコードのことである。
・すなわち、オブジェクト指向的に良い設計と言われるコードのことである。
・つまり「良いオブジェクト指向設計」とは「テストしやすいコード」のこと
　なのである。
・既存のコードがテストが困難だったら、リファクタリングしてテストをしや
　すいコードに書き換えなければならない。むしろその書き換えをさせること
　が、モッ　クオブジェクトの大きな存在意義である。単に受身の存在ではない。
・リファクタリングの定義は、テストしやすいコードに書き換えることである。

まだまだ続くんだけど、全く同じことを言っている人を今日知ったんで、それ
を貼っておしまいにする。

オブジェクト指向の再定義
http://www.objectclub.jp/technicaldoc/object-orientation/OO_redefine/

402 ：デフォルトの名無しさん：2005/12/04(日) 00:18:17

あらためて感動するようなもんか？
まともなプログラマなら皆やってることなんだが

403 ：401：2005/12/04(日) 00:49:23

>>402
ならば俺は今までまともなプログラマでは無かった。
俺はユニットテストを組んだことが無かった。
今までユニットテストツールについては、将来手を出してみたい新技術の一つ
だとしか認識してなかった。

ユニットテストコードを組むようになって、今までに学んだ概念が全て、実は
テストの容易さを目的として作られていたものだと、初めて気がついた。テス
トは決して周辺技術じゃない。むしろ、他の多くの技術的概念の根幹を成すコ
アだ。しかしそれは、自分でテストを組んでみるまで分からなかった。

恐る恐る言うのだが、ユニットテストを組まないプログラマは、もはやまとも
なプログラマとは言えないのかもしれない。

だけど、逆に問いたい。XUnitって、日本で色物扱いされて、認知度は非常に
低いじゃないか。ユニットテストをこれほど重要だと認識しているプログラマ
は1割もいるまい。どうしてこんなに認知度が低いんだろう？

404 ：デフォルトの名無しさん：2005/12/04(日) 01:34:49

>>403
簡単なことです。
土方現場では、実装は土方作業に例えられ、納期さえ
守られていれば上司は満足という低レベルなプロジェクト
がほとんどだからです。

405 ：401：2005/12/04(日) 02:13:34

>>404
それはそうなんだろうけど、もうちょっと突っ込んだ視点はないだろうか？

例えば、デザパタのスレだったら、この板には過去にいくつも立っていた。ホ
ントの底辺プログラマは、デザパタなんて知らないし使わない。つまり、この
板には底辺プログラマばかりがいるわけではない。

それなのに、何でテストのスレはこんなに進みが遅いんだろう？

406 ：デフォルトの名無しさん：2005/12/04(日) 08:21:21

>>405
デザパタスレみたいに厨房が押し寄せて、隔離スレが出来るような展開がお望みですか？

407 ：デフォルトの名無しさん：2005/12/04(日) 15:51:33

>>403
今頃気付いたのか。おまえのような人間ばかりだから
デスマーチができあがる。

408 ：デフォルトの名無しさん：2005/12/04(日) 16:02:21

>>407
いや、それに今頃気づくお前のような人間ばかりだから・・・(ry

409 ：デフォルトの名無しさん：2005/12/04(日) 16:14:07

>>403
おまえ、5年は遅れているぞ。

410 ：デフォルトの名無しさん：2005/12/04(日) 18:48:34

いま気づいただけでもずいぶんマシだと思う。

411 ：デフォルトの名無しさん：2005/12/04(日) 20:25:31

406-411

412 ：デフォルトの名無しさん：2005/12/04(日) 21:33:59

ユニットテストなんて書けねー
とか言っている人間はそこらじゅうにいる。
そらお前がテスト書けるような実装をしないからだろ、と何回も言ってきた。
にもかかわらず結局そのまま走って穴だらけの手動テストで時間を浪費する。

そんなうちのプロジェクトメンバを見てる私からすると
>>403は素晴らしい部類に入ります。
是非その発想の転換が行なえたときの喜びや驚きを
多くの人に伝えてあげてください。
まだまだ知らない人は沢山います。

413 ：デフォルトの名無しさん：2005/12/04(日) 21:35:58

エクストリームをまともにやれるプロジェクトもほとんど無いしな。

414 ：デフォルトの名無しさん：2005/12/04(日) 22:15:01

ユニットテストの実践についてまとめた良書ってありますか？
まだ初心者なんで、
テストの粒度・密度とか、Privateメソッドはどうするかとか、
テストパターン-コード-ドキュメントの連携はどうするかとか、
そういうあたりでいつも迷ってよくわかんなくなります。

415 ：デフォルトの名無しさん：2005/12/04(日) 22:23:26

>>414
これっきゃない。英語だけど。
JUnit Recipes: Practical Methods for Programmer Testing
ttp://www.amazon.co.jp/exec/obidos/ASIN/1932394230/

かゆいところに手が届いている。

416 ：デフォルトの名無しさん：2005/12/04(日) 22:26:58

amazon.comのレビューのほうが参考になるので、こっちも見てくれ。
ttp://www.amazon.com/gp/product/1932394230/

ManningのWeb Page
ttp://www.manning.com/books/rainsberger

417 ：デフォルトの名無しさん：2005/12/04(日) 22:45:31

.NETならこれかな。
Advanced Unit Testing Part1～5
ttp://www.codeproject.com/csharp/autp1.asp
ttp://www.codeproject.com/csharp/autp2.asp
ttp://www.codeproject.com/csharp/autp3.asp
ttp://www.codeproject.com/csharp/autp4.asp
ttp://www.codeproject.com/gen/design/autp5.asp

418 ：デフォルトの名無しさん：2005/12/04(日) 22:59:20

ユニットテストって粒度が問題にならね？
ＡＰＩ全てにユニットテスト通してたらプロジェクト御わっちまうよ

419 ：デフォルトの名無しさん：2005/12/05(月) 00:42:26

ユニットテストっていうぐらいだから1ソースファイルにテストは1つで十分

420 ：デフォルトの名無しさん：2005/12/05(月) 00:55:43

テストファーストは、プログラミングテクニックの一つぐらいに考えておいた方がいい。
実装とテストを分けて考えると>>418みたいなことを言い出す奴が出てくる。

421 ：デフォルトの名無しさん：2005/12/05(月) 05:42:44

やってあたりまえ

422 ：デフォルトの名無しさん：2005/12/05(月) 05:53:05

GUIのテストってどうやんの？

423 ：デフォルトの名無しさん：2005/12/05(月) 14:55:20

『JUnit インアクション』の訳は、自分には非常に読みづらい。
訳者がちゃんと分かってないからじゃないかと思う。

例えば７章の扉、
「成功の秘訣は誠実であることだ。軌道に乗ったら嘘をついてもよい」
これは後半が間違っていて、正しくは
「成功の秘訣は「誠実さ」である。それさえ装えれば、成功したも同然。」

要するにここは、ジャン・ジロドゥの名言を引用して、モックオブジェクトの
性質の説明をしているんだけど、書籍の訳では全然それが伝わらない。
この本に限らず、XP関連の書籍の訳は、大部分がかなりひどいと思う。

かと言って自分は英語ができないから、原書は少し読むだけで頭が混乱してくる。
『JUnit Recipes』読みたいのに。
英語がダメだとテストもできないのか。うう。

424 ：デフォルトの名無しさん：2005/12/05(月) 15:54:09

自動翻訳されたものを手直しした程度で出してるんじゃないのかな？

425 ：デフォルトの名無しさん：2005/12/05(月) 21:31:09

まあ昔に比べて、翻訳に時間をかけられないから、機械翻訳を下訳に使うのは
仕方がないだろう。だけど意味の通らない翻訳が多すぎるよ。
「JUnit イン・アクション」の翻訳の質の低さは、本邦におけるユニットテス
トの普及を少なからず妨げたと思う。

426 ：デフォルトの名無しさん：2005/12/06(火) 10:53:27

では 2ch 発で日本語による日本人のための JUnit テストツールの本を作りませんか？

427 ：デフォルトの名無しさん：2005/12/06(火) 11:00:37

>>426
電車男を見るにつけ、ひろゆきに搾取されて出した人間には一銭も入らない予感。

428 ：デフォルトの名無しさん：2005/12/06(火) 12:58:39

ゼロから本を書くんじゃなくて、例えばこのスレで『JUnit インアクション』
の分からないところを質問したり、良書を紹介したりして、情報共有する方が
効率的だと思うよ。

訳は悪くても『インアクション』は大変な名著だ。テストというものに対す
る見方ががラッと変わる。腰帯の「本書を読まずに、J2EEアプリケーションの
単体テストを行ってはいけない！」という、エリック・ガンマの言は伊達では
ないと思う。

429 ：デフォルトの名無しさん：2005/12/06(火) 13:43:32

>>426
つーか、原著読めば良くね？
英語読めない奴がどうなろうと、俺の知ったこっちゃない。

430 ：デフォルトの名無しさん：2005/12/06(火) 20:44:06

まあ、教えたい人は教えればいいし、教えたくない人は教えなければいい。

431 ：デフォルトの名無しさん：2005/12/07(水) 22:22:39

例えばGUIやディスクIOやDBアクセスがあるような「現実のプログラム」は、
どうしてもユニットテストでカバーできる部分とできない部分が出てきてしまう。
開発時テストにおいてユニットテストはあくまでも一手段であり、
すべてではないと思う。

カーニハンの著書「プログラミング作法」もテストについての章があって
参考になるよ。

432 ：名無しさん＠お腹いっぱい。：2005/12/08(木) 10:49:06

xUnitでのテストケースって、一個のテストメソッドに1個のassertXXXXX()とかfail()
を書くのが普通？

433 ：デフォルトの名無しさん：2005/12/08(木) 13:27:12

>>431
あ、その本持ってた。どんなこと書いてあったっけ。思い出せない。

434 ：デフォルトの名無しさん：2005/12/08(木) 23:37:36

>>432
別に普通じゃない。まずちゃんとした本を嫁。

435 ：デフォルトの名無しさん：2005/12/09(金) 01:21:09

JUnitインアクション隅から隅まで読んだわけじゃないが、
なんかやりすぎなような気がする手法もちらほらあるな。
モックのところとか初期化多すぎで何をテストしてるのかわからん。
テストファーストをテーマにした本なんだから、そこを強調
しているのはあたりまえだけど。
まあ参考程度に効果的に使わせてもらうよ。

436 ：デフォルトの名無しさん：2005/12/09(金) 02:20:13

機械翻訳といえば「テスト駆動開発」...ひどすぎw

437 ：デフォルトの名無しさん：2005/12/09(金) 11:39:28

>>435
いや、君は「単体テスト」というものの意味が分かっていない。
あるコードを単体テストするためには、他のコードに依存する部分を完全に切
り離さなければいけない。そうしないと、バグの原因を切り分けられないから。
それを達成するために、手間をかけてモックオブジェクトを用意する必要があ
るんだ。

438 ：デフォルトの名無しさん：2005/12/09(金) 13:02:09

webの機能テストツールって何がｵｽｽﾒですか？
とりあえずMaxQ、actiWATE、Seleniumあたりを試してみたいと思っていますが
これ使ってみれっていうのがあったら教えてやってください。

439 ：デフォルトの名無しさん：2005/12/10(土) 23:08:43

モックモックってお前らシブガキ隊を馬鹿にするな。

440 ：デフォルトの名無しさん：2005/12/10(土) 23:16:23

アフォスケジュールの時はテスト工藤開発などやってる暇が無い

441 ：デフォルトの名無しさん：2005/12/11(日) 08:40:07

とりあえず動くコード書くだけならテストツールに頼らなくても出来てしまうし
テストツールを使わなくても保守性の高いコードを書ける香具師は書ける

テストツールは素人に保守性の高いコードを書かせるための「あくまで補助的な」道具にすぎない

442 ：デフォルトの名無しさん：2005/12/11(日) 08:55:30

テストを書いてるとコメントを書くのがめんどくさくなってくる。

443 ：デフォルトの名無しさん：2005/12/11(日) 10:32:35

テスト書くのがめんどくさいんだけどテストツールなんて使えるの？
一回やってみたが書かなければいけないコードの量が3倍に増えて
品質が1/3になった。テストツール (ﾟ⊿ﾟ)ｲﾗﾈ
俺はC++だがJavaになるとまた違うのだろうか？

444 ：デフォルトの名無しさん：2005/12/11(日) 10:44:13

開発期間がある程度長くてビジネスロジックにのみテストケース書いている。
すべてのクラスに対してテストケース書いているわけじゃないよ。
あと、単体ケースの工数をテストケースを書く工数にあてている。
プロジェクトを効率よく管理できるｼﾞｬｰﾏﾈの下でないと難しいんじゃないかと思ったり。
一人か二人程度でやるプロジェクトならいらないような希ガス

445 ：デフォルトの名無しさん：2005/12/11(日) 13:07:41

>>443
元のコードの倍のテストを書いて品質が落ちるって、どんだけ下手なテストを
書いたのよ。どう考えてもネタかアホ。

446 ：デフォルトの名無しさん：2005/12/11(日) 14:36:20

人数増加＝設計期間短縮という単細胞の年寄り管理職やＰＭが
いなくならない限り、ソフトの品質は上がらない。

447 ：443：2005/12/11(日) 14:49:27

>>444
なるほど。無理してテストする必要もないのですね。
業務用とかの簡単なプログラムならともかく複雑なプログラムでは
テストケースを作れないケースも多いですからね。

>>445
テスト書くのに時間を取られてコードを書くのがおろそかになった。
コードを変えるとテストも書き直ししないといけないので、必然的に
これはまずいなーと思っていてもその場しのぎの誤魔化しが増えた。
ゆえにコードの品質が下がった。

448 ：デフォルトの名無しさん：2005/12/11(日) 15:28:34

オブジェクト指向やテストファーストの考え方をわかってない奴が
ユニットテストだけ取り入れようとするとこうなる。
という典型例だな。

449 ：デフォルトの名無しさん：2005/12/11(日) 15:33:43

と言い訳して煙に巻くパターン

450 ：デフォルトの名無しさん：2005/12/11(日) 15:36:08

>>448
上記の例ではどうすれば良かったのか、ぜひ講釈してくれ

451 ：デフォルトの名無しさん：2005/12/11(日) 15:53:21

テスト書けないような複雑なコード書いてる時点でアウトだと思う。

452 ：デフォルトの名無しさん：2005/12/11(日) 15:55:35

ここでオブジェクト指向のイロハからテストファーストの思想、
パターン別の設計のポイントまで解説しろってか？
さすが、物事や考え方をを把握することができない奴の言うことだ。
わかってないなら無理してやることないよ。何度やっても挫折と失敗を繰り返すだけだから。

453 ：443：2005/12/11(日) 15:56:48

俺はちゃんとオブジェクト指向している。
むしろオブジェクト指向だからこそ
入力ー関数ー出力
みたいな関係がないのでテストが難しい。
結局最後に人間が一気にテストするのが一番効率がいい。
>>451
それはお前さんが簡単なプログラムしか書いたことがないからだ。

454 ：デフォルトの名無しさん：2005/12/11(日) 16:08:01

>>452
おまえもしかして本に書いてある知識はあるが実践経験ないのか？ｗ

455 ：デフォルトの名無しさん：2005/12/11(日) 16:09:21

いっとくがここで言う実践経験ってのは、学生の宿題レベルや２～３人のプロジェクトじゃないからな

456 ：デフォルトの名無しさん：2005/12/11(日) 16:09:59

テストツールはあくまで道具であって、それを持っているだけで品質が良くなるような銀の弾丸じゃないんだけどな。

457 ：デフォルトの名無しさん：2005/12/11(日) 16:10:47

なんで実務経験って言わないんだろ

458 ：デフォルトの名無しさん：2005/12/11(日) 16:13:52

セミナーとか高い金出して出ても例題が実際のケースとはかけはなれ過ぎ。
やはりある程度は失敗をしながら経験値を上げるしかないと思われ。

459 ：デフォルトの名無しさん：2005/12/11(日) 16:23:09

>>453
複雑なプログラムを、テストが簡単になるようにリファクタリングしながら
テストしていくのがテスト工藤開発の勘所だよ。

難しいと感じた理由は、オブジェクトの責務の分担がうまくいってないからじゃない？

460 ：デフォルトの名無しさん：2005/12/11(日) 16:23:46

まあ、簡単なプログラムの簡単なテストが書けないPGとかが、結構ころがっているのが現実だし。

461 ：デフォルトの名無しさん：2005/12/11(日) 17:15:48

テストを前提にした設計ができてないんだろうね。
あとは、BBテストとWBテストの区別ができてないとか、
ユニットテストとデバッグの区別ができてないとか。

462 ：デフォルトの名無しさん：2005/12/11(日) 17:37:50

>>461
BBテストとWBテストって何？
とりあえず、ぐぐるさんは知らないって言ってるけど。

463 ：デフォルトの名無しさん：2005/12/11(日) 17:52:20

ブラックボックステストとホワイトボックステストなんじゃないか？

464 ：デフォルトの名無しさん：2005/12/11(日) 19:20:38

複雑なコード書かないでどうやって現実の複雑な問題に対処するんだ？ｗ

465 ：デフォルトの名無しさん：2005/12/11(日) 19:25:02

>>464
1つの複雑なコードを簡単な複数のコードに分割する。分割して統治せよ。

466 ：デフォルトの名無しさん：2005/12/11(日) 19:29:43

テストって面倒だよなー。でもテストケース書く時間とテストする人と時間も圧倒的に足りないんだよねぇ

法でなんとか整備してもらえぬものか。発注側や経営者がつけあがるだけな希ガス。

467 ：デフォルトの名無しさん：2005/12/11(日) 19:30:52

ユニットテストでテストする（べき）こととしない（べき）ことの区別もついてないのかもね。

468 ：デフォルトの名無しさん：2005/12/11(日) 19:33:01

>>464-465
単純なコード単位に落とし込むってのは良くわかるんだけど
それってテスト対象となる単位が増えるわけで、テストコード
も膨大にならないか？
バカでかいソフト作るときとか、どうやってんだろ。

469 ：デフォルトの名無しさん：2005/12/11(日) 19:35:19

法でって、どういう縛りでやんの
検査手順とかを法で定めても、その検査手順の裏かかれたら終わりだし

検査項目の数とかテストの行数でやっても無意味だろうし

470 ：デフォルトの名無しさん：2005/12/11(日) 19:37:33

ヒント：姉歯

471 ：デフォルトの名無しさん：2005/12/11(日) 19:38:26

>>465
複雑な分割になるのがオチだなｗ

472 ：デフォルトの名無しさん：2005/12/11(日) 19:41:12

>>464 の能力では、って事なら同意。

473 ：デフォルトの名無しさん：2005/12/11(日) 19:41:33

「複雑な分割」って何よ？

474 ：デフォルトの名無しさん：2005/12/11(日) 19:43:47

>>466
「テストする人と時間」という時点で、
ユニットテストの存在意義をはき違えてる希ガス。

475 ：デフォルトの名無しさん：2005/12/11(日) 19:44:32

え、だからさ、おれたちデジタル土方にとって都合のいい法をこしらえてくれそうな人を国会に送り込んで…（；´д｀）

476 ：デフォルトの名無しさん：2005/12/11(日) 19:56:18

実際人命に関わるソフトでも素人が開発してるからな

477 ：デフォルトの名無しさん：2005/12/11(日) 19:56:42

理不尽な値下げ要求禁止とかなら歓迎です。

478 ：デフォルトの名無しさん：2005/12/11(日) 23:24:11

ユニットテストって、メソッドのＩＦレベル（ブラックボックス）と、その中のロジックの分岐・繰り返しを
意識した（ホワイトボックス）だと思ってるんだけど、ち・・ちがうの？？
自信なくなってきた。

479 ：デフォルトの名無しさん：2005/12/11(日) 23:45:07

メソッドのIFレベルのブラックボックスだと思っていた方が安全だな。
ロジックのテストをするもんじゃない。
ましてやデバッグなぞ(ry

480 ：デフォルトの名無しさん：2005/12/12(月) 00:10:56

ロジックのテストってやったダメなのか・・。
自分はすっごい心配性だから何でも間でもテストしちゃう性分なんだけど。
その性で生産性はよくなく、他に迷惑かけることもあるけど・・。

481 ：デフォルトの名無しさん：2005/12/12(月) 01:17:56

「成功したテストとは、欠陥を検出したテストである」から、
なんでもかんでもテストした場合と、そうでない場合の欠陥検出率に
どれだけ違いがあるか比べてみたら？

482 ：デフォルトの名無しさん：2005/12/12(月) 01:21:37

欠陥検出率ってどう出すの？

例えば、１００個のテストパターンがパスしたがバグが見つかった。
１００個のテストパターンで５０個のバグが見つかった…

483 ：デフォルトの名無しさん：2005/12/12(月) 10:35:31

ユニットテスト(xUnit)って同じテストを繰り返し何度でもできることがメリットじゃないの？
なんか上の方で人がテストした方が早いって言ってるのがいるけど、
人間が同じテストを何十回、何百回もテストすることなんてできるん？しかもテストツール以上の早さで。
俺なら絶対できないな。
つーわけで俺はテストツールは非常に役に立ってますわ。

484 ：デフォルトの名無しさん：2005/12/12(月) 12:35:20

で、
>>483 はどんなテストツールつかってんの？

485 ：デフォルトの名無しさん：2005/12/12(月) 14:27:06

483 じゃないけど、普通にxUnit とかで 483 が言ってるレベルの効果は得られるんじゃないの。
逆にそれができないテストツールってどういうツールなのか想像できん。

486 ：デフォルトの名無しさん：2005/12/12(月) 21:28:57

テストの対象となるアプリの種類にもよるが、

人手：　テスト仕様書さえあれば比較的すぐにテストを開始できるが繰り返しに弱い

自動：　テスト仕様書とテストプログラムを準備するまでに相当時間がかかるが一度出来ると繰り返し最強

487 ：デフォルトの名無しさん：2005/12/12(月) 22:45:56

>テスト仕様書とテストプログラムを準備するまでに相当時間がかかるが

テストドリブンならそんなことはあり得ないんだが...
実コードができないはずda

488 ：デフォルトの名無しさん：2005/12/12(月) 22:57:22

つーか、大規模ソフト設計でテストドリブンで成功したプロジェクトってあるの？

489 ：デフォルトの名無しさん：2005/12/12(月) 23:32:58

３年ぐらい前から派遣で50人～100人ぐらいのプロジェクトをいくつか携わったが成功したのは見たこと無かったよ。
最後はみんなデスマ。でも漏れは途中で抜けて川口で性交。

490 ：デフォルトの名無しさん：2005/12/12(月) 23:41:53

テストドリブンは基本的には少数精鋭プロジェクトに向いていると思うな。
というのも、プロジェクト規模の問題ではなく、
テストを前提にした設計ができ、テストファーストプログラミングができる
PGをそうそう高いレベルで大量に集めるのは現実的に不可能に近いモノがあると思うから。
よくありがちな大規模プロジェクトでは、それだけのスキルを持った奴は
アーキテクト部隊など、ごく一部のみ。

491 ：デフォルトの名無しさん：2005/12/13(火) 02:51:40

ドリブンとか発してる奴、キモイ

492 ：デフォルトの名無しさん：2005/12/13(火) 02:57:55

XUnitで記述する手続きより、人間の手動操作の方が
簡単になるような単体テストってどんなもんになるのか
全く想像がつかないんだが。
XUnitにソースコード記述するのががもっともテスト準備
工数少ないんじゃないか？

上の人のいってるテストケースってどんなんだ？

493 ：デフォルトの名無しさん：2005/12/13(火) 07:13:25

そんなに素晴らしいツールなら東証に売り込みに逝けよ

494 ：デフォルトの名無しさん：2005/12/13(火) 08:04:23

ぶっちゃけスーパープログラマしか使いこなせない
プログラミング手法なんて何の役にも立たないわけですよ。
単体テストなんて馬鹿でも書けるんですよ。気持ちの問題
なわけですよ。テストファーストはデグレを発生させちゃうかもしれない
馬鹿のためにあるんですよ。なんか勘違いしてる人がいるみたいだけど。

495 ：デフォルトの名無しさん：2005/12/13(火) 08:14:53

>>492
GUI関連の操作とか・・・画像処理関連とか・・・

496 ：デフォルトの名無しさん：2005/12/13(火) 10:31:06

テストファーストは設計、製造、テストがある意味同時進行で
積み上げられていくものだと思うから
SE、PG（設計者、コーダー）って区分けされてるようなプロジェクトでは
実践不可能だろうし、自動テストを書いたとしても
コストの高い退行テストツールにしかならないのでは？

497 ：デフォルトの名無しさん：2005/12/13(火) 10:43:31

テストファーストは、テストと実装を分けて考えるのではなく
コーディングテクニックの一つぐらいに考えておくのが吉。
仕様をきちっと決めてからコードを書くから、「これでいいかな？」と
迷うこともなく、書いたコードに対して安心して「これで良し！」と思える。

498 ：デフォルトの名無しさん：2005/12/14(水) 03:31:53

ttp://www.amazon.co.jp/exec/obidos/ASIN/B00005UC51/249-2544756-7425905

499 ：デフォルトの名無しさん：2005/12/14(水) 12:37:55

>>498
ｷﾗｰﾚｽ乙

500 ：デフォルトの名無しさん：2005/12/14(水) 13:23:24

東証のシステム開発でテストツール使ってたとして、
1円株発行の特殊なケースでは取り消し出来ないのが仕様だとして、
テスト実行して「これで良し！」にしかならなかったと思う。

教訓：
仕様にバグがあるかどうかまではテストされない。

501 ：デフォルトの名無し：2005/12/14(水) 15:04:51

LMSアルゴリズムを使ってスピーカの特性を調べていますが
その評価方法がわかりません。
教えて下さい、

502 ：デフォルトの名無しさん：2005/12/14(水) 21:33:08

東証よりFUJITSUに売りに行け

503 ：デフォルトの名無しさん：2005/12/14(水) 21:37:50

>>500
そりゃそうだろｗ

504 ：デフォルトの名無しさん：2005/12/15(木) 06:05:30

>>500
与謝野金融相に仕様確認できねーしなｗ

505 ：デフォルトの名無しさん：2005/12/17(土) 19:35:08

テストツールって仕様変更に弱くね？
一度やったテストを何で２回やるの？馬鹿じゃね？
とか思う俺様でもテストツールの魅力がわかる本を教えてください。

506 ：デフォルトの名無しさん：2005/12/17(土) 19:41:46

仕様変更でまったく影響受けない部分についてはそのとおり、無駄。
でも、変更によって影響を受けるか受けないか微妙なラインの部分いついては有効。
ちょっと考えりゃ分かることだな。

507 ：デフォルトの名無しさん：2005/12/18(日) 01:55:52

影響あるかどうか人間が目視したり、仕様通りかどうか
再確認したりする手間を省けるから意味はあるよ。
ボタン1つで、前のコードのままで影響ないことが保証される。
もちろん単体レベルの話しだけどね。結合以降のテストは、また別な話。

508 ：デフォルトの名無しさん：2005/12/18(日) 03:42:29

GUIでも出来ますか？
ボタンの位置とかデザインが変わってしまっても大丈夫ですか？

509 ：デフォルトの名無しさん：2005/12/18(日) 03:56:39

単体テストで、
> ボタンの位置とかデザインが変わってしまっても大丈夫ですか？
に影響を及ぼすように書かれたプログラムってヤダなぁ。。。

510 ：デフォルトの名無しさん：2005/12/18(日) 06:58:04

メンドウでも回帰テストは重要だぞ。
影響部分を見抜けなかったら大変だ。検査制度の見直しが要る。

511 ：デフォルトの名無しさん：2005/12/18(日) 07:19:51

>>508
GUIでも、1ピクセル？単位で比較検証するツールを使えば良い。
GUIの挙動を検証したかったらマウスポインタの自動化ツールでテスト可能。
ま、まだGUI検証の分野は確立されていない部分だから、これを自動化する
手段や方法を決めて、それを実装したら、名が売れるよ。

512 ：デフォルトの名無しさん：2005/12/18(日) 09:21:08

だから正月に勉強するから入門書を教えてヽ( ﾟдﾟ)ﾉｸﾚﾖ

513 ：デフォルトの名無しさん：2005/12/19(月) 00:20:14

>>511
すべての画面遷移パターンの検証を自動化できたら神だろうけど・・・

検証ツールに比較させるためのパターンデータの作成と仕様変更時の改修に
かかるコストが大きすぎて無理っぽいな。微少なドットずれにはパターン認識で
対処させようにも、ウィンドウの表示内容に変化部分があると使えない方法だし。
ウィンドウ意匠と表示する文言が常に一定なメッセージボックスなら別だが・・・。

検証対象の画面数とパターンが少なければ人手による目視確認の方が迅速・確実だな。
それ以外でも人間の認識能力には勝てない。

514 ：デフォルトの名無しさん：2005/12/19(月) 00:40:09

>すべての画面遷移パターンの検証を自動化できたら神だろうけど・・・

>検証ツールに比較させるためのパターンデータの作成と仕様変更時の改修に
>かかるコストが大きすぎて無理っぽいな。

そのあたりの問題は、普通の単体テストでも変わらないぞ。
そのために様々なテスト最適化手法があるわけで。

515 ：デフォルトの名無しさん：2005/12/19(月) 00:56:59

>>512
「JUnit イン・アクション」なんてのはどうでしょうか？
テスト手法勉強したい方は普通には出来ると思っているので、
多少難ありとは思いますが、
読み進めることが出来ると思います。

いかかでしょうか。

516 ：デフォルトの名無しさん：2005/12/19(月) 02:42:07

>>513
そこは発想を変える必要があると思われる。
画面に表示されるものを「目視」するという先入観にとらわれすぎ。
固定概念とも言える。
画面とて、表示される前の「状態」がある。その状態と検証対象の状態を
比較できたら、パフォーマンスやコストの問題はなくなると考えられる。
うまく言えないが、どの時点で比較するかがキーとなるだろう。
目に見えるものが全てじゃないことは、俺らの方が良く知ってるはず。

517 ：デフォルトの名無しさん：2005/12/19(月) 15:24:07

>>512
http://www.amazon.com/gp/product/0131421891/qid=1134973361/sr=8-1/ref=pd_bbs_1/002-0382990-9351249?n=507846&s=books&v=glance

518 ：デフォルトの名無しさん：2005/12/19(月) 17:37:33

.NETのテストツール関係（NUnit等）の書籍は今のところ洋書しかないですかね？

519 ：デフォルトの名無しさん：2005/12/19(月) 22:47:21

テストさえも本見ないと書けないお馬鹿ちゃんなのかい？

520 ：デフォルトの名無しさん：2005/12/19(月) 23:11:03

>>518
http://www.amazon.co.jp/exec/obidos/ASIN/4891004428/

521 ：デフォルトの名無しさん：2005/12/20(火) 11:37:41

このスレでは時々 >>519 みたいな発言が出るが、理解に苦しむ。
少なくとも『JUnit インアクション』『リファクタリング』ぐらいは隅々ま
で精読しないと、まともなテストが書けるとは思えない。

単体テストツールは、従来のテスト要員の作業を自動化したものじゃない。ま
たそれらを完全に置き換えることもできない。
むしろ、設計、コーディングのための新しいツールと見るべきもので、しかも
その適切な使い方を身につけるにはかなりの努力が必要だと思う。

522 ：デフォルトの名無しさん：2005/12/20(火) 11:57:00

>>520
ttp://www.amazon.com/gp/product/0735619484/qid=1135046881
の邦訳ですよね。評価が分かれてるみたいですけど良書なんでしょうか？
520さんは読みました？

523 ：デフォルトの名無しさん：2005/12/20(火) 14:36:39

ずれているかも知れないけど。
テストで一番大事なのはテストケースの設計なのではないのですか。
従来のテスト手法にしろテスト駆動にしろ、
ツール（とか環境）はツール（とか環境）に過ぎないのでは？
品質向上という錦の御旗は、テストをきちんとすることによって発生する効果だと考えていて正しいですか？

524 ：デフォルトの名無しさん：2005/12/20(火) 14:44:04

あと、テストしやすい設計な。

525 ：デフォルトの名無しさん：2005/12/20(火) 16:32:29

まあ、そのあたりを「承知の上」で、
どういうテストケースがあって、どのように役に立つかとか、
うまく使うためのノウハウなんかを話すのがこのスレの本来の目的では？

526 ：デフォルトの名無しさん：2005/12/20(火) 16:41:06

おいらはそういう話が目的でROMってたんだが、
どうもテストをすること自体の是非(極端に言えばTDDの是非)の話が多いよねぇ。
テストツールを使うべきなのか(TDDに切り替えていいのか)悩んでいる人が多いっつー事の現れとも言えなくないだろうけど。。

527 ：デフォルトの名無しさん：2005/12/20(火) 21:19:11

テストって言うからいけないんだ、あれは動かせる仕様書なんだ、と言う意見を以前どっかの日記で見た。俺も同意する。

528 ：デフォルトの名無しさん：2005/12/20(火) 23:37:58

>>524
設計者が昔気質な組織でドキュメント無しだと最悪だ。
モノじゃなくて組織や設計者の批判になってテストにならない。

529 ：デフォルトの名無しさん：2005/12/21(水) 00:09:43

某本からの受け売りなんだが、

ＴＤＤが少人数設計に向くのは確か
大人数設計になればなるほどＴＤＤの経験者でかつしっかり理解しているプロジェクトリーダーが必須（これはＴＤＤエンジニアがまだ少ないため）
やるからには徹底的にＴＤＤしないと駄目
（中途半端な導入だと結局失敗し、およそＴＤＤではないのにＴＤＤで失敗したかのように取られ、それみろやっぱりＴＤＤは駄目という誤った先入観を生んでしまう）

上記の説明は、ＴＤＤをＸＰに置き換えてもＯＫ

530 ：デフォルトの名無しさん：2005/12/21(水) 00:15:12

オフサイドトラップの理解できないDFを入れてそれを仕掛けてはならないってことだね

531 ：デフォルトの名無しさん：2005/12/21(水) 11:54:00

>>530
なるほど～。

532 ：デフォルトの名無しさん：2005/12/26(月) 01:02:02

趣味のプログラミングにはＴＤＤがいいよ。
一人で開発するのにドキュメント整備なんかしないし、
とりあえず思いつきで作った部分でも後からの変更に耐えられるようになるし。
まさに動く仕様書。

533 ：デフォルトの名無しさん：2005/12/29(木) 15:12:39

>>532
一人で開発するにしても忘れるから
ドキュメントは必要。きっちりしたものを作る必要はない。

一人で開発って、まさかサンプルプログラムの
ことじゃないよね？300Lineくらいの。

534 ：デフォルトの名無しさん：2005/12/29(木) 17:34:03

TDDてﾅﾆよ？

535 ：デフォルトの名無しさん：2005/12/29(木) 17:36:07

>>534
http://e-words.jp/w/TDD.html

536 ：デフォルトの名無しさん：2005/12/29(木) 17:39:58

このスレで TDD ったらテスト駆動開発（test driven development）の事なんでは？

去年ぐらいからテスト駆動開発のテストは、従来のテストとは違うってんで
behaviour driven development とか呼ぼうとか言われてるらしいけど。

537 ：デフォルトの名無しさん：2005/12/29(木) 17:50:26

テスト==作ったものに対する検査
という思いこみタップリな、
頭ガチガチの奴がいると（特にマネージャや客先）
テスト駆動型開発はうまくいかない。

538 ：デフォルトの名無しさん：2005/12/31(土) 17:46:34

テストツールって戻り値しかテストできないんでしょ？
どうせデバッガーが必要になるからテストツールいらね。

539 ：デフォルトの名無しさん：2005/12/31(土) 18:19:40

　　　　　　∩ 　_,　,_ 　　
　　　　　 ⊂⌒（ﾟдﾟ）　／)　　　　
　　∩　_,　,_ ｀ヽ_つ ⊂ノ　(　⌒ヽつ　　
⊂⌒ （ﾟдﾟ）　　　　　 ⊂（ﾟдﾟ）つ. ∩　_,　,_　　
　｀ヽ._つ⊂ノ　　　　　　　　　　　　 ⊂⌒（ﾟдﾟ ´）　
　　　／) 　　　　　　　　　　　　　　／)゛｀ヽ.つ⊂ノ
　　(　⌒ヽつ　　　 ∩　_,　,_　　(　⌒ヽつ
⊂（ﾟдﾟ）つ. ⊂⌒（　ﾟдﾟ）⊂（ﾟдﾟ）つ
　　　　　　　　　｀ヽ._つ⊂ノ　

540 ：デフォルトの名無しさん：2006/01/01(日) 00:06:20

TDDにおけるテストとは実装に対する契約書なんだけどな。

ドキュメントは詳細になればなるほどソースコードの変化についていけなくなる。
そこで、ドキュメントファーストという考え方を徹底させ、全員がこれを守るとする。
すると、この問題は解決する。
ハイ！では、同じコンテキストでテストファーストについても考えてみよう。
まぁ、そういうこと。

541 ：デフォルトの名無しさん：2006/01/01(日) 00:17:46

　　　　　　　　　　　　　　　　　　　　　　　　_,
　　　　　　　　　　　　　　　　　　　　 , イ;;;;l　))
　　　　　　　＿＿　 -―‐‐､_ -ー＜　/;;;;;;|
　　　　　　＜　　　 -‐　　　　　￣:::::... /;;;;;;/
　　　　　　＼／　　　　　／　　　　 :::了;;;;;ｱ_
　　　　　／　　..:;　　../　　.::::.　　　::l;;;ﾍ;;;;;;;＞
　　　　 /　　..:::::l　/:/　　.::::;ｲ　|:.　｀l"::ﾍ_＞
　　　　ヽ　　.:::: ｲ:7尢`　.::::7''尢ア　::|::::l:::l
　　　　　＼:::::::{ jrｲ:::{ヽ ::::::lィ'::ト､　.:,':::::|:::l
　　　　　　　＼::Y　i::::::7 ＼/ !:::ゝハ/ヽ/|:::!　　　＜ほうほう　それでそれで？
　　　　　　　　|:八　`ｰ'　　　ゝｰ'　ｲ :::::::|/
　　　　　　　　|'::::::ゝ､　 r-､　　　　_/:/／
　　　　　　　　` イﾚ'　f`rー‐　'"少／＼_
　　　　　　　　 l　　　　ヽ`ー '´／　　_　　ヽ
　　　　　　　　rﾄ　l |　　　ー‐´　　lイ　　　 l
　　　　　　　 /　　ｿ　　　　　　　.:::|　　　　ｲ
　　　　　　　ヽ..:::::｢￣｀ー―― ''ﾌ　　　　 l
　　　　　　　　 {二 !┼┼ - r― 人＿　　　〉
　　　　　　　　　|　ヽ∠＿,止ｧ´_ﾐ/＿＼厂
　　　　　　　　　|　ｰ<　　　　￣｀　　/ヾ
　　　　　　　　　＼　　｀＞.､　　　 /　"ヽ
　　　　　　　　　　｀爪｀ｰ-｀＞ー'´　　仏
　　　　　　　　　　　/　　　　　　＿　- ￣　ヽ

542 ：デフォルトの名無しさん：2006/01/01(日) 01:57:56

　　　　　　　　　　　　　　　　　　　　　　　　_,
　　　　　　　　　　　　　　　　　　　　 , イ;;;;l　))
　　　　　　　＿＿　 -―‐‐､_ -ー＜　/;;;;;;|
　　　　　　＜　　　 -‐　　　　　￣:::::... /;;;;;;/
　　　　　　＼／　　　　　／　　　　 :::了;;;;;ｱ_
　　　　　／　　..:;　　../　　.::::.　　　::l;;;ﾍ;;;;;;;＞
　　　　 /　　..:::::l　/:/　　.::::;ｲ　|:.　｀l"::ﾍ_＞
　　　　ヽ　　.:::: ｲ:7尢`　.::::7''尢ア　::|::::l:::l
　　　　　＼:::::::{ jrｲ:::{ヽ ::::::lィ'::ト､　.:,':::::|:::l
　　　　　　　＼::Y　i::::::7 ＼/ !:::ゝハ/ヽ/|:::!　　　＜それだけ？
　　　　　　　　|:八　`ｰ'　　　ゝｰ'　ｲ :::::::|/
　　　　　　　　|'::::::ゝ､　 r-､　　　　_/:/／
　　　　　　　　` イﾚ'　f`rー‐　'"少／＼_
　　　　　　　　 l　　　　ヽ`ー '´／　　_　　ヽ
　　　　　　　　rﾄ　l |　　　ー‐´　　lイ　　　 l
　　　　　　　 /　　ｿ　　　　　　　.:::|　　　　ｲ
　　　　　　　ヽ..:::::｢￣｀ー―― ''ﾌ　　　　 l
　　　　　　　　 {二 !┼┼ - r― 人＿　　　〉
　　　　　　　　　|　ヽ∠＿,止ｧ´_ﾐ/＿＼厂
　　　　　　　　　|　ｰ<　　　　￣｀　　/ヾ
　　　　　　　　　＼　　｀＞.､　　　 /　"ヽ
　　　　　　　　　　｀爪｀ｰ-｀＞ー'´　　仏
　　　　　　　　　　　/　　　　　　＿　- ￣　ヽ

543 ：デフォルトの名無しさん：2006/01/03(火) 11:24:13

TDDにおけるテストとは実装に対する契約書なんだけどな。

何を実装すれば良いのか、先に取り決めするだろ？
(どうやるかは実装する側が後で考える)

まぁ、そういうこと。

544 ：デフォルトの名無しさん：2006/01/03(火) 13:00:24

どうせ
とちゅうで
仕様が
コロコロかわるんだろ

というのが現場の大方の意見ですたが、何か

545 ：デフォルトの名無しさん：2006/01/03(火) 13:11:16

仕様が変わることと何か関係があるのですか？

仕様が変わればその仕様に合ったテストケースを作って、そして実装するのがテストファースト。
たとえ仕様が変わっても、コーディングする時点では何を書くか決めなければならないでしょ？

546 ：デフォルトの名無しさん：2006/01/04(水) 11:38:19

DejaGNUってどうよ？　他に似たようなのある？

547 ：デフォルトの名無しさん：2006/01/04(水) 20:37:47

同じコンテキストでテストファーストについても考えてみた。

テストは詳細になればなるほどソースコードの変化についていけなくなる。
そこで、テストファーストという考え方を徹底させると、全員がこれを守らなくなる。
すると、このテストファーストは自壊する。
まぁ、そういうこと。

テストファーストって正常系のテストだけでいいの？

548 ：デフォルトの名無しさん：2006/01/04(水) 21:37:12

なかなかいい質問だね（ﾟ∀´）bｸﾞｯ
それはTDDを初めて知った人が一番最初に気になることなんだっ
そのためにほとんどの解説ページや書籍ではそれを一番最初に説明しているんだっ
レッツ!!エンジェイ!テストファースト・ライフ!!

549 ：デフォルトの名無しさん：2006/01/04(水) 21:47:56

>>547
結局テスト書くの人間だから
無計画なTDDは破綻以外ない

550 ：デフォルトの名無しさん：2006/01/04(水) 22:22:28

> テストファーストって正常系のテストだけでいいの？

はぁ？
例えば無効なパラメータを与えたときにあぼーんしない、とかはテストしないって事？
ばかじゃねーの？

551 ：デフォルトの名無しさん：2006/01/04(水) 22:24:41

無効なパラーメタか渡されるかどうかなんて実際わからないじゃん。
ばかじゃねーの？

552 ：デフォルトの名無しさん：2006/01/04(水) 22:34:12

ヴァカは >>551だ。
呼ばれる側の都合を考えてはいけないのが原則。

553 ：デフォルトの名無しさん：2006/01/04(水) 22:34:24

> 無効なパラーメタか渡されるかどうか

想定の範囲外のパラメータ、って意味？
確かにそれがわかるわきゃねー

ま、とりあえず想定の範囲内でテストしとけ > ばかども

554 ：デフォルトの名無しさん：2006/01/04(水) 22:35:06

そんなこともわからないなんて、
ばかじゃねーの？

555 ：デフォルトの名無しさん：2006/01/04(水) 22:35:46

ばかじゃん

556 ：デフォルトの名無しさん：2006/01/04(水) 22:41:15

そもそもテストファーストなんて御伽噺ありえないんだよ
ばかじゃねーの？

557 ：デフォルトの名無しさん：2006/01/04(水) 22:42:40

お兄ちゃんのばかーーーーっっっ！！！！

558 ：デフォルトの名無しさん：2006/01/04(水) 22:49:27

お兄ちゃんがばかなことと何か関係があるのですか？

559 ：デフォルトの名無しさん：2006/01/05(木) 01:10:13

ないのですか？

560 ：デフォルトの名無しさん：2006/01/05(木) 01:13:32

無効なパラメータを渡された場合の仕様を明確にしてあればテストするし
してなければテストしない。

561 ：デフォルトの名無しさん：2006/01/05(木) 19:18:11

なるほど。「仕様通りにテストする」というわけですな
どんなことになっても仕様書に責任を押し付けられるから安心なわけだ
・・・それで本当にいいの？

562 ：デフォルトの名無しさん：2006/01/05(木) 19:27:40

Winrunnerの値段てどれくらいですか？

563 ：デフォルトの名無しさん：2006/01/06(金) 00:39:08

>>561
仕様書に責任を押し付けるんではなく、仕様書を契約書として責任の
切り分けをはっきりつける目的でやってる。
いままでIFの仕様があいまいで想定外の作業をやらされてきたことが
たくさんあったからその自衛策のつもり。
（まぁ自分が決めた仕様があいまいだったのが悪いわけだけど・・）

564 ：デフォルトの名無しさん：2006/01/06(金) 00:53:18

>どんなことになっても仕様書に責任を押し付けられるから安心なわけ
はぁ？

「無効なパラメータ」ってのがあらかじめ分かるならな
仕様として
・無視する(何もリアクションしない)
・何かリアクションする(例外、エラーコードetc.)
以外にありえないだろ

このやろー

565 ：デフォルトの名無しさん：2006/01/08(日) 15:58:15

テストツールって何使ってる？
C++で教えて

566 ：デフォルトの名無しさん：2006/01/08(日) 16:03:47

>>565
http://www.opensourcetesting.org/unit_c.php

567 ：デフォルトの名無しさん：2006/01/11(水) 11:57:15

Canoo WebTest 試してみてるんだけど、verifytext で日本語がマッチしない
のよね。UTF-8 でも Shift_JIS でもダメポ。

誰かできたってひといないかしら?

568 ：デフォルトの名無しさん：2006/01/13(金) 02:57:17

>>565
cppunit+河童

569 ：567：2006/01/24(火) 19:00:37

Canoo WebTest 1.6 ならそのままで verifytext での日本語も動作した。

1.6 で HttpUnit ベースだったのが、1.7 になって HtmlUnit ベースに
変更されたのだが、そのときに動かなくなったようだ。仕方ないのでソ
ース持ってきて適当に直したところ、動くようにはなった。

以上、チラシの裏でした...使ってる人いないのだろうか...。

570 ：デフォルトの名無しさん：2006/02/17(金) 12:58:28

JUnit4.0 リリースage
junit.orgにはまだ書いてないけどsf.netにはあがってる。

Eclipseに入るのはいつかなぁ

571 ：デフォルトの名無しさん：2006/02/18(土) 10:11:15

>>570
JUnit4のパッケージがorg.junit.*で、
昔のパッケージjunit.framework.*になってるから、
わかりやすいと言えばやすいけど、なんか美しくないなぁ
新パッケージ側が旧パッケージ側にいろいろ依存してるし

Eclipse入りはv3.2の予定だそうな

572 ：デフォルトの名無しさん：2006/02/19(日) 20:51:44

テストツールをおべんきょしたいんだけど、
いい本ないですか？
一応C++がメイン、それ以外の言語も必要あれば使うって感じです。

573 ：デフォルトの名無しさん：2006/02/20(月) 23:35:13

なんかあってから対応すりゃいいじゃん。テスト代浮くし

574 ：デフォルトの名無しさん：2006/02/21(火) 00:22:17

事故に遭ってから保険かけりゃいいじゃん。保険料浮くし。

575 ：デフォルトの名無しさん：2006/02/21(火) 00:22:32

>>573
なんかあってからだと対応できないって。
普段から学習しとかないと。
特に泥縄は通用しない分野だなあ、と周りの人間見てて思う。

576 ：572：2006/02/21(火) 09:34:26

1. eXtreme Programmingテスト技法―xUnitではじめる実践XPプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4798101281/qid=1140481776/sr=1-1/ref=sr_1_2_1/503-8894277-0553550

2. CppUnitによるXP‐eXtreme Programming‐実践テスト技法
http://www.amazon.co.jp/exec/obidos/ASIN/4798005711/qid=1140481835/sr=1-1/ref=sr_1_2_1/503-8894277-0553550

この2つで迷ったけど1.を買うことにするですです

577 ：デフォルトの名無しさん：2006/02/21(火) 10:17:24

>>576
その本を買った人間としてお薦めできません。内容が薄すぎます。
ツールの紹介でしかなく、テストの技法についてはほとんど触れていません。
多分半月で不要になるでしょう。

私の場合、先にJavaとJUnitの理解が多少あった状態で読んだのと、
RubyやC++などの言語の記事は流し読みしていたので
そう感じたのかもしれませんが。

CppUnitについてはWeb上に結構役立ちそうなページが見つかるので、
書籍ではなくそちらを見た方がいいような気がします。

578 ：デフォルトの名無しさん：2006/02/21(火) 10:36:49

>>574
保険を引き合いに出すのはどうかと。保険は何かあったとき
金と言う形で保障してくれるが、山ほどテストやっても
後から出た不具合はフォローしてくれないよ。

>>575
そういう分野でやってる人は尊敬する。飛行機の自動運行とか
原子力発電所の制御とか、お疲れ様

579 ：デフォルトの名無しさん：2006/02/22(水) 00:06:55

>>578
自動車にかけてる保険は、自宅の火事をカバーしてくれませんがなにか？

580 ：デフォルトの名無しさん：2006/02/22(水) 10:08:07

火災保険もかければ？
ついでに地震保険や盗難保険、ガン保険にも入っとくといい。
保険は無敵

581 ：デフォルトの名無しさん：2006/02/22(水) 14:18:05

超外出臭いけど、ユニットテストって、
コピペしまくりになりがちなんだけどどうしてる？

そんで、ちょっとの仕様変更やバグで、
コピペ箇所みんな直さなくちゃいけなくなる。

582 ：デフォルトの名無しさん：2006/02/22(水) 16:50:15

>>581
テスト対象を抽象化するレイヤーを一枚はさむ。　仕様変更はその
レイヤーで吸収。　

583 ：デフォルトの名無しさん：2006/02/22(水) 19:55:40

テストしたいのなんて、マルチスレッド時の挙動がほとんどだ。
マルチスレッドのテストできるツールが欲しい。
リソースの保護し忘れとか、
デッドロックの可能性とか自動的に検出してくれるやつ。

584 ：デフォルトの名無しさん：2006/02/22(水) 19:55:58

厨小化キター━(ﾟ∀ﾟ)━!!

585 ：デフォルトの名無しさん：2006/02/22(水) 20:02:54

>>583
VTuneやスレッドアナライザーは？

586 ：581：2006/02/22(水) 22:16:52

>>582
テスト対象を抽象化するレイヤー？
仕様書としてのメリットを損なうように聞こえるけど、
もっとkwsk

587 ：582：2006/02/22(水) 22:48:39

>>586
通信機器の開発やっててテストは使う立場で自分で書いているのではないが、
うちの品質管理の連中はobjective TCLでテストを書いている。　機器の設定、
状態などを様々なTCL objectとして表し、それを操作、検査することでテストを
書いている。

実際にそれぞれのobjectがどうやってそれらを機器に反映させたり状態を引っ張って
来るかはそれぞれのobjectの実装だからそれらの仕様が変わってもトップレベルの
テストのスクリプトは大抵変える必要ない。

588 ：581：2006/02/23(木) 00:12:59

なるほどMockの話か。しかし、
Mockは地面から離陸することは出来ても、コピペ地獄にはどういう風に役に立つ？
というか、仕様変更って地面の方が変わるんじゃなくて、
自分自身以上のレベルの変更の事なんだけど。

589 ：デフォルトの名無しさん：2006/02/23(木) 01:32:17

テストケースもリファクタリング汁！
重複は悪

590 ：デフォルトの名無しさん：2006/02/23(木) 12:53:42

そのリファクタリングの勘処が分かんないんだよ
普通にやったら仕様書として訳分からなくなるし、
処理じゃなくて特定のメソッドを使うのが目的だから
普通にやってそのメソッドを使わなくなっちゃしょうがない。

591 ：デフォルトの名無しさん：2006/02/23(木) 13:37:04

Boost.Jamは結構簡単に使えた
こりゃ便利

592 ：デフォルトの名無しさん：2006/02/28(火) 04:31:19

VSのwebの自動テストは便利そうだけど

593 ：デフォルトの名無しさん：2006/03/12(日) 23:32:57

JUnit4ってEclipse3.1.xで使用する事はできますか？
その際何か特別な設定など必要でしょうか？

594 ：デフォルトの名無しさん：2006/03/13(月) 02:56:20

>>593
http://jroller.com/page/eu?entry=running_junit_4_test_cases

595 ：デフォルトの名無しさん：2006/03/13(月) 21:06:24

cgiのテストツールで
HTTPポストを簡単に送信できるのないかな？
データと項目名だけ設定して実行できる

596 ：デフォルトの名無しさん：2006/03/13(月) 21:12:15

>>595
HttpUnit

597 ：http://www.vector.co.jp/soft/win95/util/se072729.html：2006/03/18(土) 21:02:37

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

598 ：デフォルトの名無しさん：2006/03/18(土) 22:42:46

>>597
マルチ + スレ違い乙

599 ：デフォルトの名無しさん：2006/04/07(金) 19:05:09

Pythonにはdoctestって標準でよさげなのがあるんですが、
Javaでもjavadocにテスト書けるようなのってありませんか？

600 ：ハーピィ：2006/04/10(月) 22:33:46

E・∇・ﾖﾉｼ　＜600ｹﾞｯﾄ♫

601 ：デフォルトの名無しさん：2006/04/12(水) 00:35:13

↑うぜぇ

602 ：デフォルトの名無しさん：2006/04/28(金) 19:37:21

CppUnitは環境整えるのに面倒臭いんで、boost::testにしますた。
ヘッダファイルだけインクルードすりゃ使えるし、(L)GPL汚染もないし。

603 ：デフォルトの名無しさん：2006/05/06(土) 12:23:18

JUnit 4.1 release age

604 ：デフォルトの名無しさん：2006/05/09(火) 15:47:32

TDDは
Test Driven Developmentっていうより
Test Driven Designにした方が
誤解が少なくなるように思う。スレ違いだけど

605 ：デフォルトの名無しさん：2006/05/10(水) 02:04:17

別にデザインが目的じゃないからなぁ

BDD（Behavior Driven Development) の方がまだましじゃ

606 ：デフォルトの名無しさん：2006/05/11(木) 13:54:14

TDDとかBDDとか、ホントにやってる奴っているの？
無駄に工数３倍以上掛かると思うんだけど。

　・　メソッドレベルの詳細仕様なんてぐるぐる変わる
　→　その度に大量のテストコードから直すので、工数数倍

　・　そもそも、レビューちゃんとやってるから、
　　　単体テストなんて、いちいちドライバなんて作らずデバッガでさっさがやっちまう。
　→単体レベルのコーディングバグなんてほとんど無い。
　　　実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
　　　結合以後に現れる。

607 ：デフォルトの名無しさん：2006/05/11(木) 23:36:51

＞レビューちゃんとやってるから

＞単体レベルのコーディングバグなんてほとんど無い

なんだかよくわからないがすごい自信だ

608 ：デフォルトの名無しさん：2006/05/12(金) 02:27:02

>>606
>・　そもそも、レビューちゃんとやってるから、
>単体テストなんて、いちいちドライバなんて作らずデバッガでさっさがやっちまう。
なんかすげー珍妙な理屈だな。
～からの前後がまったく繋がってないように見えるんだが。
それとどれだけすげーレビューやってんだ？

>　→単体レベルのコーディングバグなんてほとんど無い。
単体のコーディングやテストの効率とか無視かい？
一度書いたらもうテスト全部パスできる自信あるのかい？違うだろ？

>　　　実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
>　　　結合以後に現れる。
単体レベルで検証しっかりしておけば
結合でしょうもないのが出るのを減らせるんじゃないの？

609 ：デフォルトの名無しさん：2006/05/12(金) 02:44:41

>　メソッドレベルの詳細仕様なんてぐるぐる変わる
抽象に依存汁！

>　そもそも、レビューちゃんとやってるから
完璧な設計が間違っている場合がある

610 ：デフォルトの名無しさん：2006/05/12(金) 02:49:03

>>608
レビューはセルフレビューと、話聞きながら勝手にソース読んで突っ込むだけ。いたって普通かと。

＞単体のコーディングやテストの効率とか無視かい？
自動で全仕様を満たすケースを実行できるようなの書くより、
デバッガで値いじったりしてやった方が圧倒的に早い。

＞一度書いたらもうテスト全部パスできる自信あるのかい
だから、レビューもするし単体テストもしないとは言ってない。
自動で全仕様を満たすケースを実行できるようなユニットテストプログラムを書かないと言ってるだけ。

＞単体レベルで検証しっかりしておけば
だから、現実のバグは単体レベルの仕様自体に既に問題があるのがほとんどなんだから、
問題がある仕様にあってることを検証しても防げない。

611 ：デフォルトの名無しさん：2006/05/12(金) 02:49:50

>>609
言ってる意味が全く分からない。

612 ：デフォルトの名無しさん：2006/05/12(金) 03:12:08

ツールを使えば手間じゃないと思うんだが。

613 ：デフォルトの名無しさん：2006/05/12(金) 03:18:10

実際のバグのうち、純粋なコーディングのミスなんて１割以下だろ。
他の部分と仕様の認識にズレがあるとか、
存在すら認識されていなかったパターンがあって仕様が対応していなかったとか、
なんらかの環境に関する問題とか、そんなんが残りの９割。

単体テストじゃこの９割は防げない。

すごく難しいアルゴリズムの塊みたいなプログラムなら違うのかも知れないけど、
普通の業務プログラムなんてこんなところだろ？

614 ：デフォルトの名無しさん：2006/05/12(金) 03:23:01

>>612
なんのツールを使うと、なにが自動化されて、なんの手間が減るの？

615 ：デフォルトの名無しさん：2006/05/12(金) 03:46:19

>>614
ちょっとは自分で調べてから質問しろよ

616 ：デフォルトの名無しさん：2006/05/12(金) 07:44:16

デバッグとテストを混同するな

617 ：デフォルトの名無しさん：2006/05/12(金) 09:25:32

TDDやBDDなんか実際にやってる所なんてないだろ
XPと同様、空想上のお話だよ

618 ：デフォルトの名無しさん：2006/05/12(金) 09:29:43

>>616
言ってる意味が不明

619 ：デフォルトの名無しさん：2006/05/12(金) 10:48:19

>>608
＞自動で全仕様を満たすケースを実行できるようなの書くより、
＞デバッガで値いじったりしてやった方が圧倒的に早い。
コードを修正する度に、毎回デバッガで値を弄ってテストするなんて、嫌過ぎ。
基本的に同じ作業を3回以上繰り返す事が判っている場合は、自動化を検討するのが賢い働き方だと思うが。

620 ：デフォルトの名無しさん：2006/05/12(金) 11:18:08

大半の箇所は3回も繰り返さないし、
3回位ならテストケースをゴリゴリ書くよりデバッガでチョコチョコやった方がはやい。

621 ：デフォルトの名無しさん：2006/05/12(金) 11:35:24

なんつーか、単体テストの自動化の是非なんて今さらじゃん

今じゃどこの現場でもJUnitかそれに準じるテストツールを使ってるよ

622 ：デフォルトの名無しさん：2006/05/12(金) 11:46:03

オレはTDDは有用だと思うからオレはやってるけど、別にこれをしないからってダメなわけじゃないよ。
TDDはあくまでも手段だから使わなくても品質のいいものが作れるならそれでいいわけだし。

だからそんなに必死になって自分を正当化しなくてもいいよ。TDDにメリットを感じなければ使わなければいいだけの話。
ここの住人も含めて誰も責めないと思うよ。

なんか見ててかわいそうになってきた。
もっとも、デバッガでちょこちょこやった程度で「テストしました。」なんてうちの部下が言ってきたらやり直しさせるけどね。
>>616ってこと。

623 ：デフォルトの名無しさん：2006/05/12(金) 12:40:48

>>621
単体テストをしない・するな、なんて言ってないよ。
詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
本当に生産的かどうかを言ってるんだよ。

本当に生産的であるという結論が出てるなら、悪いけどポイントしてくれないか？

>>622
感じるじゃなくて事実を問うているんだよ。
デバッガを使ったらデバッグなのかい？>>616の意味が分からないんだが。
で、やり直しさせる理由は？（まあ、そいつが嘘つきの場合は証拠がなくて困るけど、それは論外だろう）

624 ：デフォルトの名無しさん：2006/05/12(金) 23:22:08

>>623
デバッガでちょこっとやったとして
その場でバグとかおかしいところを見つけられるかもしれんが、
それ再現するの大変だろ？
仕様の変更があって修正とか入ってもテスト流せば
どこに影響があるとかすぐにわかるし、
客観的に検証できるじゃん。
それとも全部デバッガで手動で見るのかい？
とても繰り返しに耐えられると思えんが。

「デバッガで確認したのでバグはないです」なんて言う奴がいたら
俺なら絶対に吊るし上げする。
あんたの職場がどんなとこか知らんが、
俺はそんなところ恐くて働きたくないね。

625 ：デフォルトの名無しさん：2006/05/13(土) 01:29:10

デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
それに、仕様の変更があったら、テストケースも直さなきゃあかんだろ。影響なんてわからないじゃん。
しかも折角書いたテストケースがゴミになってまた書き直し。
そもそも、ユニットテストをかっちり書いてたら、モックとか使うから、ほかのクラスへの影響なんてわからないだろ。
（本来の意味の、仕様を変えない）リファクタリングでは確かに、自動で確認できるのはありがたいが、
実際は､レビューでそれなりのレベルになってるから現実に後になってリファクタリングなんてほとんどない。
後からの修正だって、テストなんて気休めでしかないよ。単体テストで引っかかるようなデグレをこく奴は論外だろ。
後からの修正は、熟考とレビューで少なくともコーディングレベルのデグレは殲滅させるのが普通。

で、吊るし上げる理由は？
理由も無く上司の好き嫌いで吊るし上げられるところは怖くて働きたくないなぁ。

って、別に煽るのが目的じゃなくて。
詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
本当に生産的であるっていう、根拠を教えてよ。

626 ：デフォルトの名無しさん：2006/05/13(土) 02:04:03

＞デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
それだと、誰でもいつでも同じ結果を出せるテストを実施することは難しいだろうな
xUnitを使うメリットとかその辺を知りたければ、こんなところでグズグズ言ってないで適当にググれば？

627 ：デフォルトの名無しさん：2006/05/13(土) 02:26:01

修正っていうけど
　仕様追加と仕様変更
ぢゃねの？
それ変えたくないところが確かに変わっていないことをテストなしでどうやって保証するのか知りたいな

628 ：デフォルトの名無しさん：2006/05/13(土) 03:30:56

>>627
毎回すべての項目をデバッガ使って手動テスト&目視確認なんだろ。
または、ちゃんとレビューしているという妙な自信から、思いつく部分以外は
確認しないとか。

＞デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
>>626に同意だわ。再現性の違いがわかってない奴が手動テスト&目視確認。
あーこわ。

629 ：デフォルトの名無しさん：2006/05/13(土) 11:27:00

>>625
> デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
手動で値を入力してデバッガで一々見ながら目視でチェックするのと
テストケース一発流すのとどっちが楽でかつ確実なんだ？
ちょっと考えればわかるだろう？
デバッガを否定しているわけじゃないぜ？
当然俺も使っているし。

> それに、仕様の変更があったら、テストケースも直さなきゃあかんだろ。影響なんてわからないじゃん。
> しかも折角書いたテストケースがゴミになってまた書き直し。
> そもそも、ユニットテストをかっちり書いてたら、モックとか使うから、ほかのクラスへの影響なんてわからないだろ。
> （本来の意味の、仕様を変えない）リファクタリングでは確かに、自動で確認できるのはありがたいが、
> 実際は､レビューでそれなりのレベルになってるから現実に後になってリファクタリングなんてほとんどない。
> 後からの修正だって、テストなんて気休めでしかないよ。単体テストで引っかかるようなデグレをこく奴は論外だろ。
> 後からの修正は、熟考とレビューで少なくともコーディングレベルのデグレは殲滅させるのが普通。
仕様が変わっていない部分にも影響が出てないか検証が必要だろ？
全部デバッガでがっさり確認するのか？
おんなじこと何度も書かせるなよ。
まぁレビューで検証してるからとか言って何もテストしてなさそうだな、
その書き込みを見ていると。

> で、吊るし上げる理由は？
> 理由も無く上司の好き嫌いで吊るし上げられるところは怖くて働きたくないなぁ。
お前さん個人が「デバッガで確認したのでバグはありません」
なんて言っても何の客観性も無いからって書いただろ？
ふざけるなの一言だな。

630 ：デフォルトの名無しさん：2006/05/13(土) 14:52:25

昔、オールドタイプと同じような言い争いになったな。そいつはクビになったけどｗｗｗ

631 ：デフォルトの名無しさん：2006/05/13(土) 15:51:46

すみませんが、使える派遣の見抜くためのテストツールって
どこでダウンロードできるのでしょうか？

632 ：デフォルトの名無しさん：2006/05/13(土) 15:55:53

そーすふぉーぢで探してみればどうですか

633 ：デフォルトの名無しさん：2006/05/13(土) 17:49:41

おまえら、そんないうほどちゃんとユニットテストやってんのか？
ちなみに俺は、メソッドが１パターン動かす位しかやってねぇ

634 ：609：2006/05/13(土) 18:04:16

>>611
・メソッドレベルの詳細仕様を変更すると大量のテストコードから修正が必要になるのは
呼び出す側が呼ばれる側の実装に依存しているからである
→呼び出す側は呼ばれる側の変更に影響されないように作るのが常識
　＝抽象(インタフェース)に依存させる、など

・
>実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
とあるように、単体レベルのレビューをちゃんとやってコーディングバグが0だとしても問題が発生する
　＝完璧な(単体レベルではバグがない)設計が間違っている場合をレビューでは救えない
→早い段階から設計の問題を発見するのが常識
　＝動作するテストを用いて実際に動作させながら設計を行うのがTDD(とかBDD)

結論)も前は非常識

635 ：デフォルトの名無しさん：2006/05/13(土) 20:15:04

>>634
おまえホントにTDDしてるの？あきれた。空想で語るなよ。

636 ：デフォルトの名無しさん：2006/05/13(土) 20:16:39

Ｃ++のテストツールって何使ってる？
Windows限定でお願いします

637 ：デフォルトの名無しさん：2006/05/13(土) 23:44:54

この議論、なんやかんや言って、意外に本質的なところを議論している気がする。
>>623に同意しているわけではないが、テスト対象によっては>>623の言うことが正しい場合があると思う。
なので、「何も考えずに」JUnitでテストコードを全部書くのはたぶんうまくない。

ここでの議論のようなことが、すべてのプロジェクトの内部で行われた結果、
どっちにするか決めているのであれば、それがどっちの答えになろうとも、結構正解
を選んでるんではないか。
まぁ、それをテスト戦略と呼ぶのだろうが。

638 ：デフォルトの名無しさん：2006/05/14(日) 00:23:15

経験年数を重ねてもどうしても目視で間違いを見落とす人がいるので、
時間は掛かるけど、全体で一定の品質を保つために実践してるよ。
それで、現状の課題は２つ。

　・テストコードのかきっぷり
　　複雑すぎてしまうととホントにテストできているのか確認が難しい。
　　もっとテストしやすい設計を精進すればコレはある程度解決できるかも
　　と感じてる。

　・テストに掛かる工数
　　テストコードを書いておくことによって回帰テストを行う事になった場合に
　　非常に威力を発揮するが、やはり初期工数がより多く掛かってしまう（1.5～2倍)。
　　頻繁に変わる可能性の高いものはxUnitでテスト、それ以外はデバッガとかで
　　確認とか出来れば少しはマシになるかなと思うんだけど、その基準をどうすべきか
　　悩んでる。

639 ：デフォルトの名無しさん：2006/05/14(日) 00:36:17

うちではユニットテストと搦め手、コードが動作しているか同化も検証している
網羅率って香具師

640 ：デフォルトの名無しさん：2006/05/14(日) 01:16:06

>>638
>・テストコードのかきっぷり
>　複雑すぎてしまうととホントにテストできているのか確認が難しい。
それがコードもしくは設計を見直すよいトリガになる。

>・テストに掛かる工数
その基準の悩みこそ、テスト改善のミソ。悩むべきところで悩んでいると思う。
それをしないで、どっちの方法がよい！などと断言するのは意味もないと思う。

641 ：デフォルトの名無しさん：2006/05/14(日) 02:49:45

>>638
その後、実装が頻繁に変わらないぐらいに安定したクラスに対してxUnitをつかってる。
むしろイテレーションの初期は、インテグレーションテストを自動化することに注力したほうが効率的な気がする。

642 ：デフォルトの名無しさん：2006/05/14(日) 03:08:35

なんか日本語が変だったので書き直し。

むしろ実装が頻繁に変わらないぐらいに安定したクラスに対してxUnitをつかってる。
イテレーションの初期は、インテグレーションテストを自動化することに注力したほうが効率的な気がする。

643 ：デフォルトの名無しさん：2006/05/14(日) 03:09:57

テストを書くことで人は成長するんだよ。

644 ：デフォルトの名無しさん：2006/05/14(日) 06:54:02

設計もシンプルになるしね

645 ：デフォルトの名無しさん：2006/05/14(日) 11:01:21

xUnitの怖いところは、
回帰テストが簡単にできるからと、後からの変更に妙な安心感が出来てしまうこと。
テストは、バグの存在は証明できても、バグの不在は証明できない。
テストケースの網羅性が全然低かったり、モックの動作が実際のオブジェクトとズレが出てても、
妙な安心感のため、慎重さ（ちゃんとした調査・検討）やレビューがおざなりになって、
「オールグリーン確認。問題なし！」とかなりがち。

646 ：ほそく：2006/05/14(日) 11:05:44

＞「オールグリーン確認。問題なし！」

数百、数千項目がグリーンだとなんとなく強気になるかも知れないけど、
その９割以上はもとから変更箇所と何らの絡みもない全く関係しようがないところなのにね。

647 ：デフォルトの名無しさん：2006/05/14(日) 11:09:20

シンプルって言葉も、なにかと語弊を生むよね。
粗結合・高凝集な設計を志すと個々の実装はちょっと複雑になりがちだけど
そこがシンプルっていう語感と相容れないからかな。
シンプルな設計と称して、手続き型のプログラムを書いてしまう。
そういうのが一番テストケース書きにくいプログラムなのに。

648 ：デフォルトの名無しさん：2006/05/14(日) 11:19:05

>>645
＞テストケースの網羅性が全然低かったり

そこでカバレッジ測定ツールですよ。
うちではEmma使って毎日カバレッジ測ってる。
カバレッジ低いコード書くヤツには個別指導…と、行きたいが、そんなに時間がとれないんだよね。

649 ：デフォルトの名無しさん：2006/05/14(日) 11:21:30

Javaのカバレッジはcloverで測定してるけど、実はデバッグツールとして重宝してたり。
ある経路を想定した回数通過してないのを発見したり。

650 ：デフォルトの名無しさん：2006/05/14(日) 11:41:04

カバレッジ測定ツールで測れるのは、コード行の網羅性だろ？
=と==のミスとか変数の取り違えとかそんなレベルはそれでOKだけど、
正しいと言えるには、仕様条件が網羅されないと。

651 ：デフォルトの名無しさん：2006/05/14(日) 12:18:30

ユニットテストでは、ひとつのオブジェクトに閉じて「正しさ」をテストできる。
だが、実際のプログラムでは、
オブジェクトは他の複数のオブジェクトを正しく使わねばならない。

ユニットテストでは、依存先のオブジェクトの使い方が正しいかどうかはあまりテストできない。
これがテストできなければ、そのオブジェクトの「正しさ」をちゃんとテストできてるとは言えない。

652 ：デフォルトの名無しさん：2006/05/14(日) 16:35:43

払うべきコストの妥当性は「テスト不足で発生するリスクの金額（期待値）」
事象ごとに想定損失額と確率を掛けたものを合計する。

システムの性格により、想定損失額が変わればテストの価格も変化する、
と考えるのは自然なこと。

653 ：デフォルトの名無しさん：2006/05/14(日) 19:47:03

なかなか難しそうな気が・・・

654 ：デフォルトの名無しさん：2006/05/14(日) 21:00:26

>>651
Mockじゃだめ？

655 ：デフォルトの名無しさん：2006/05/14(日) 21:48:34

>>650
コードが仕様を満たしているかどうかは、Fitとかの受け入れテストツールが向いてる。適材適所だ。

>>654
Mockを使う場合、DIできるように設計しとかないといけないからなぁ。
そういう風に設計しておけばいいんだけど。
それでもjMockとか面倒だった。

656 ：デフォルトの名無しさん：2006/05/14(日) 22:11:37

injectionのためにsetterを用意すると、
情報隠蔽が崩れ、さらに、
コンストラクトされても使えないオブジェクト状態が生まれる諸刃の剣。

そもそも、Mockが実際のオブジェクトと全く同じ振る舞いである保証は？

657 ：デフォルトの名無しさん：2006/05/14(日) 22:24:09

インターフェース一緒ぢゃん

658 ：デフォルトの名無しさん：2006/05/14(日) 22:27:36

>>657 ← こういう人ってどうしよう…。

659 ：デフォルトの名無しさん：2006/05/14(日) 22:53:43

>>656
S2のセッタインジェクションは
implの方にだけsetterを定義しておけば
自動でバインディングしてくれるので、
別に使う側から見て情報隠蔽が崩れてないんちゃう？

Springとか使ったことないのでこのへんどうか知らんけど・・・

660 ：658：2006/05/14(日) 22:54:45

>>659
なんかいまいちな説明だった。
要するに使う側から見てインターフェースは変わってないってことで。

661 ：デフォルトの名無しさん：2006/05/14(日) 23:02:31

>>652
自然なことなのにそんなこと考えてないプロジェクトの多いこと。
言うは簡単。

662 ：デフォルトの名無しさん：2006/05/14(日) 23:11:21

>>656
まさにその「コンストラクトされても使えないオブジェクト」を回避するために
コンストラクタインジェクションってのがある。

663 ：デフォルトの名無しさん：2006/05/15(月) 00:28:37

>>655
FITって使える？
自分は統合テストも結局JUnitで書いてしまっているんだけど、
FITはテストケースをプログラマ以外の人が作れるだけの
ユニットテストツールにしか思えないんだが。

664 ：デフォルトの名無しさん：2006/05/15(月) 10:25:51

>>655
単体仕様の確認は？

665 ：デフォルトの名無しさん：2006/05/15(月) 10:53:39

もう、TDD=悪と決めつけてるから何言っても無駄だな。
だいたいそんなにいやなら使わなければいいのに何でそんなにこだわってるんだ？
誰かになんか言われて悔しい思いでもしたのか？

666 ：デフォルトの名無しさん：2006/05/15(月) 12:29:05

なんでそうなるんだ？
メリットを聞いてるだけなのに。
メリット云々じゃなくて信仰って事？

667 ：デフォルトの名無しさん：2006/05/15(月) 23:52:26

TDD=悪と決め付けてる発言がどれか分からん。
そんなこと言った香具師いたの？

668 ：デフォルトの名無しさん：2006/05/15(月) 23:59:07

>>666
メリットを説明しても理解できない、お脳がスローリィな奴は黙ってろ。

669 ：デフォルトの名無しさん：2006/05/16(火) 00:03:00

そもそも、Mockが実際のオブジェクトと全く同じ振る舞いである保証は？

670 ：デフォルトの名無しさん：2006/05/16(火) 00:08:02

TDDの主たるメリットはソースコードのテスタビリティの向上。
テスタビリティの向上はリグレッションテストのカバレッジを高くする。
リグレッションテストのカバレッジが高くなるとエンバグしにくくなるし
リファクタリングがしやすくなる。
リファクタリングがしやすくなるとコードの寿命が延びる。それとコードの
改造にかかるコスト自体が安くなる。

671 ：デフォルトの名無しさん：2006/05/16(火) 00:13:01

>>669
Mockは「使われ方」をテストするためのもの
Mockの動きが実際のオブジェクトと全く同じ振る舞いである必要はない。

672 ：デフォルトの名無しさん：2006/05/16(火) 00:16:26

>>606についてはどうなんだ？それにそのメリットが投資を上回るという根拠は？
さらに、カバレッジつっても、コード行のカバー率だろ。詳細仕様のカバー率が必要だろ。

673 ：デフォルトの名無しさん：2006/05/16(火) 00:19:18

>>671
> Mockは「使われ方」をテストするためのもの
よくわからん。
例えば、あるメソッドが普段は０、特定条件では１を返すオブジェクトを、
常に０を返すモックに変えてテストしたら、特定条件の場合バグってても話下欄だろ。

674 ：デフォルトの名無しさん：2006/05/16(火) 00:23:04

>>606については散々既出だと思うが。
一人のPGが手作業＆目視で俺様流のテストをして
「大丈夫です」と言い張るのを信用できるかって話しだ。

675 ：デフォルトの名無しさん：2006/05/16(火) 00:31:23

ということは、TDDが有効なのは、
みんな嘘つきでサボる事しか考えてないやる気のない職場ということだな。

目視つうけど、ユニットテストに誤り無いなんて保証あるのか？
オマエの理屈だと、ユニットテストにもユニットテストが必要だな。
もちろんユニットテストのユニットテストにも、ユニ（以下ry

676 ：デフォルトの名無しさん：2006/05/16(火) 00:32:00

>それにそのメリットが投資を上回るという根拠は？
常に投資がメリットを上回るということではない。
自動リグレッションテストやリファクタリングが一般的になる以前は
一旦作成されたコードについてテスト工数の関係で仕様変更箇所以外の箇所に
ついてみだりに変更することが困難だった。
そういう制約の中で何度も差分開発を繰り替えすと単位機能あたりのソースコード
の修正コストはどんどん高くなっていってしまう。
それに対し今は「一定のコストを払うことでソースコードの修正コストを引き下げる
ことができる」という選択子が単純に増えたということになる。
イテレーションを何度も回さない開発の場合はテストコードを書く必要はない。

677 ：デフォルトの名無しさん：2006/05/16(火) 00:36:22

>>673
その普段は０、特定条件では１っていうのが
試験条件なんだから試験項目バグってこと。
インテグレーションテストだろうが、単体試験だろうが
試験項目がバグってたらどうにもならない。

678 ：デフォルトの名無しさん：2006/05/16(火) 00:38:25

>>675
手作業で再現性のない物と自動化された物を同一視している奴にはそのメリットは理解できんよ。
おまえにとってTDDはメリットは無い。やらなくていいよ。やるだけムダだ。工数かかるし。

679 ：デフォルトの名無しさん：2006/05/16(火) 00:43:52

>>676
それは単体テストじゃなくて機能テストが必要なのでは？
単体がみんなテストOKでも、>>373とか、>>645-646とか。

>>677
どうにもならないんじゃTDDダメじゃん。

>>678
全然回答にも否定にもなってないね。

680 ：訂正：2006/05/16(火) 00:44:43

>>676
それは単体テストじゃなくて機能テストが必要なのでは？
単体がみんなテストOKでも、>>673とか、>>645-646とか。

681 ：デフォルトの名無しさん：2006/05/16(火) 00:45:23

>>673
モックを正しく使っているかのテストであって、
モック自体をテストしているのではないですよ。

モックが０を返す限り、テスト対象のオブジェクトは
その情報に基づいて振舞うのがそのオブジェクトの役割であって、
特定条件でも正しく振舞うかテストするには、
１を返すモックで別のテストをすればいいだけかと。

682 ：デフォルトの名無しさん：2006/05/16(火) 00:47:41

>>681
そうじゃなくて、モックを作る奴が、１を返す事があると
気が付かないでやっちゃう場合の事を言ってるんだけど。

683 ：デフォルトの名無しさん：2006/05/16(火) 00:51:52

>>679
単体テストが機能テストでもどっちでもいいよ。
要は、手作業で試験するよりプログラムで試験するほうがトータルのコストが安くなる
ケースがあるってこと。

684 ：デフォルトの名無しさん：2006/05/16(火) 00:53:54

>>683
それは同意。でもTDDじゃないな。

685 ：デフォルトの名無しさん：2006/05/16(火) 00:57:24

>>682
Mockが返す値は、試験項目なんだって。
すなわちMockが返す値は試験内容によって決まる。
Mockは「正しく呼ばれたか」をテストするもの。

Mockが返す値が間違っているってのは、試験項目
誤りかまたは試験手順ミスなのだがそれは手作業で
試験をしても発生しうるよね？

686 ：658：2006/05/16(火) 01:01:24

>>682
そいつはテスト漏れちゃうの？
それともお前さんの大好きな手動テストなら
確実に0と1両方確認できるってのかい？

687 ：デフォルトの名無しさん：2006/05/16(火) 01:01:29

>>684
>>670でも書いたけど、TDDはコードのテスタビリティを向上させる
働きがある。
はじめからテストしやすいコードを書くのは実は非常に難しくて、
なんの制約もなくコードを書いた（書かせた）後、そのコードにテスト
コードを書くのはかなり骨が折れる。テストしやすいようにコードを
書き直したくなる。

であれば、逆にテストコードを先に書くことによって本編のコードを
テストしやすい形態に強制するのが効果的ってわけ。

688 ：686：2006/05/16(火) 01:02:32

>>686
あり、なんか投稿者名が・・・
すいません、自分658氏ではないです。どっちでもいいすけど。

689 ：デフォルトの名無しさん：2006/05/16(火) 01:03:03

>>685
なるほど。でも、実際のオブジェクトを使ってたら、
１の場合を見逃さずに済んだ可能性が高いじゃん？

690 ：デフォルトの名無しさん：2006/05/16(火) 01:05:23

>>685-686
しかも、手作業だとテストする人によってとかテストする度に漏れが発生したりしなかったりするしね。

691 ：デフォルトの名無しさん：2006/05/16(火) 01:06:44

無料でカバレッジ分析まで可能なやつってありますか？
C++　Windowsでお願いします

692 ：デフォルトの名無しさん：2006/05/16(火) 01:09:15

>>686
もちろん100%ではないが、１になる問題の条件が広い（＝起きやすい）ほど100%に近付く。
それに比べてモックを間違ってれば0%だろ？

>>687
それは単体テストの話ではないの？TDD的には。機能テストではなくて。
単体テストの手スタビリティと機能テストのそれは、類似性もあるがやっぱり別物。

693 ：デフォルトの名無しさん：2006/05/16(火) 01:13:38

>>690
エクセルに条件表作って、みんなちゃんとやってる。すくなくともうちは。
ユニットテストをコードで書いたら、条件が自動的に網羅されるのかい？
ユニットテストコードで、条件が網羅されてる事が保証されてるのかい？

694 ：デフォルトの名無しさん：2006/05/16(火) 01:16:48

エクセルに条件表かけるなら
ユニットテストのコードに反映できるだろ？
おまけに実施ミスもなし

695 ：デフォルトの名無しさん：2006/05/16(火) 01:17:43

>>692
あるメソッドが返しうる値の範囲が明確になっていないとすれば、
そのメソッドを使うクラスが正しく実装されている可能性もすごく低いんじゃないか？
結局メソッドの受け取るパラメータの範囲・クラスの取りうるステータス・メソッドの戻す値を
明確化しておくのは何をするのにも前提になる気がするが。

696 ：デフォルトの名無しさん：2006/05/16(火) 01:17:57

やれば出来るけど工数が勿体ない。

697 ：デフォルトの名無しさん：2006/05/16(火) 01:19:02

>>692
単体テストでもTDDでもどっちでもよいが、
それではTDDのどういうプラクティスの何が問題?

698 ：デフォルトの名無しさん：2006/05/16(火) 01:21:26

>>696
俺は694じゃないが、たぶん条件表をかかなきゃいけないほど
複雑なテストならテストコード書いたほうが早くできるケースのほうが多いよ。
慣れの問題もあるけど、イニシャルコストを払う価値はあると思う。

699 ：デフォルトの名無しさん：2006/05/16(火) 01:21:31

>>695
そのはずなのにミスってる所がバグで、そのためのテストだろうが。
テストの話をしてるのに、テストの意味がない問題ない所の話をしてどうする。

700 ：686：2006/05/16(火) 01:22:42

>>693
なんかループしてるね、この人・・・
エクセル書いたってミスする奴はミスするよ。人間だし。

>ユニットテストをコードで書いたら、条件が自動的に網羅されるのかい？
>ユニットテストコードで、条件が網羅されてる事が保証されてるのかい？
これそのまま自分たちに当てはまらないか？
俺はエクセルで全部手動の方が信頼できない。

TDDとかテストファーストとかは色々意見があるとは思うけど
ユニットテスト否定するのは久しぶりに見た。
この業界はまだまだ未知の世界があるのぅ！

701 ：デフォルトの名無しさん：2006/05/16(火) 01:25:54

>>694
落ち着いてよく読み返そうよ。
Mock側のコードがバグってても、Mockはそのバグを検出しないんだって。

702 ：デフォルトの名無しさん：2006/05/16(火) 01:28:25

>>697
>>606

>>698
そうか？？？
コードだけじゃ、都合良く条件設定しづらいし（テスタビリティとかいってMock使うと
上に書いたとおりだし、Mockかくのも大変だし）、それに、
一発で完璧なテストコード掛ければよいが、実際はつまらんミスやなんやでやり直しが出るし、
テストコードだってバグがある可能性高いし。

703 ：デフォルトの名無しさん：2006/05/16(火) 01:28:26

ごめんレスアンカー間違えた。
誤>>694
正>>699
落ち着いてないのは俺かｗ

704 ：デフォルトの名無しさん：2006/05/16(火) 01:32:48

>>702
> Mockかくのも大変だし
EasyMockとかjMock使えばいいんでない？

705 ：デフォルトの名無しさん：2006/05/16(火) 01:35:34

>>703
>>701がアンカを訂正されても意味が分からん…。

>>704
馬鹿にされるのを覚悟で聞くけど、そういうのって、
ストリームとかスゲー典型的な奴だけじゃないの？
ビジネスロジック内のアプリ固有のオブジェクトとかのモックを秒築できるの？

706 ：デフォルトの名無しさん：2006/05/16(火) 01:39:19

>>702
ちょっと今までの話とは変わるが、テストコードとテストコードを前提としたコードの記述には
まあなんていうかコツみたいなものは確かに存在して、それを
つかむまで生産性が向上したようには感じられないのは確かだと思う。
俺もそうだったし。

707 ：デフォルトの名無しさん：2006/05/16(火) 01:46:00

>>699
たぶんだけど、戻り値を返すためのコードじゃなくって
なんらかの処理の「結果として」戻り値を返すような、
設計になってるから戻り値が明確になってないんじゃない？

708 ：705：2006/05/16(火) 01:48:21

>>704
ちょっと調べてきた。俺のMock理解は相当時代遅れだったようだな。
だが逆に、こんなテストを、しかもテストコードで書いてたら、変更コスト高すぎだろ。

>>706
そうなのか…？それでもデバッガより早くなるとは思いがたいが…。

709 ：デフォルトの名無しさん：2006/05/16(火) 01:48:49

>>705
ビジネスロジック固有のオブジェクトだろうがなんだろうが
よばれた順番に決められた値を帰すのが典型的なMockだから、
そんなに実装に手間取るはずがない。
スタブと違ってインテリジェントに振舞う必要性があまりない。

710 ：デフォルトの名無しさん：2006/05/16(火) 01:51:20

>>707
上の返値の話は、わかりやすい例を書いただけで、
普段から何が帰ってくるか解らんようなコードを書いてる訳じゃないって。

711 ：デフォルトの名無しさん：2006/05/16(火) 01:53:05

>>708
同じようなテストコードを使いまわせるところ以外なら
１回だけならデバッガのがさすがに早いって。
テストコードとは棲み分けが違うよ。

712 ：デフォルトの名無しさん：2006/05/16(火) 01:55:10

>>709
俺はモックとスタブを区別できていないようだ。
ちょっと調べてくるがしかし、モックに対する見解は>>708。

713 ：デフォルトの名無しさん：2006/05/16(火) 01:59:03

俺さコードのテストツールより人間のテストツール欲しい
誰か作ってくれないかなぁ。デスマ何時間とか
ファビョ率とかさなんかそっちのほうが重要な気がしてならない

714 ：712：2006/05/16(火) 02:15:21

調べてきたがやっぱりモックスタイルに対する見解>>708は変わらんし、
実際にテスト書くにはスタブも結局は必要だし、それに対しては上で言ったとおりだなぁ。

>>711
だろ？
で、実際にデグレがない事は単体テストじゃなくて機能テストが必要。
オブジェクト同士の依存を廃してバラバラにテストするのがよい単体テストなら、なおさら。
単体テストを何回もやるって、実際の所、オブジェクトが、そしてテスト自体が独立してたら
あまり意味はないと思われ。そのために工数を割くのはどうかなぁ。
中身が複雑なFacadeとかにはイイかもしれんけど。

715 ：デフォルトの名無しさん：2006/05/16(火) 02:30:00

>>714
ちなみにあなたの機能テストの定義ってどんなんなの？
ちょっとそこらへんがずれてる気がするんで。
（いや俺だけかもしれないので。煽りじゃなく。）

いくつかオブジェクトを組み合わせて動かしてって意味で言ってるなら
それって機能テストというか
結合テストって言った方がいいんちゃうかなと思うけど。

716 ：デフォルトの名無しさん：2006/05/16(火) 03:06:44

>>714
いやいやテストコード書くことに意味がないなんて言ってねーよ。

・あまりイテレーションが多く回らない。
・オブジェクト指向でプログラム組まない。
ただ、上のどちらかならxUnitのテストにメリットがない可能性はあるかもしらんが。

717 ：デフォルトの名無しさん：2006/05/16(火) 07:14:36

理屈こねるより、実際やってみてどういう場合に有用か無用かを知るのが一番いいと思うのだが、
試験的にUnitTestを導入する手頃な案件がないのよね。

718 ：デフォルトの名無しさん：2006/05/16(火) 07:24:22

>>717がいま、TDDが成り立たないことを実証しました。
所詮、テストまわりから始めるなんてことはできないのです。

719 ：デフォルトの名無しさん：2006/05/16(火) 07:34:37

>>718
意味が分からないんだけど。馬鹿？

720 ：デフォルトの名無しさん：2006/05/16(火) 07:37:00

>>718
どうしてそういう結論になるのかまったく理解できない。

この書き込みを「実証」と呼べるような人間には
「テスト」そのものに対する理解も難しいとは思うけどね。

721 ：デフォルトの名無しさん：2006/05/16(火) 07:38:42

>>719-720
ﾈﾀにﾏｼﾞ(rya

722 ：デフォルトの名無しさん：2006/05/16(火) 23:30:57

つーか実際、ホントにTDD(テストファースト)なんて、おまえらやってないだろ。

723 ：デフォルトの名無しさん：2006/05/17(水) 00:27:19

単体テストでも機能テストするっつーの。
ま、>>715の言うとおり、単なる言葉使いの間違いかもしれんが。

724 ：デフォルトの名無しさん：2006/05/17(水) 00:34:23

>>606がTDDとかって問題にあげてるけれど、TDD関係なく
単なるユニットテストのことを問題にあげてるんだよね？

725 ：デフォルトの名無しさん：2006/05/17(水) 00:39:16

あぁ、おれもそう思った。
いわゆる「インクリメンタルテストよりもビッグバンテストの方がええわい」
という先カンブリア時代のような話をしているのではないか。

726 ：725：2006/05/17(水) 00:44:46

と、自分で書いてて思ったけど、
ビッグバンテストが完全に悪いと言えないケースも存在するのかもな。
ほとんどないと思うけど。

727 ：デフォルトの名無しさん：2006/05/17(水) 00:55:33

だって、どうせユニットテスト書いたって、
そのテスト対象を変更する事なんてあんまないし、
変更する場合はほとんどテストごと書き直しだし。
リファクタリング？完成前にレビューでほぼ完成形になっちゃうからユニットテストの意味なし。

728 ：デフォルトの名無しさん：2006/05/17(水) 00:58:31

>>606
つーかメソッドレベルの詳細仕様書ってそんなに変わるのかね？
変更がちょっと入るたびに大量のテストコードやり直しで手間が掛かるだけとか
そのへんからなんかおかしい気がするんだけど。

729 ：デフォルトの名無しさん：2006/05/17(水) 01:00:40

>>727
>リファクタリング？完成前にレビューでほぼ完成形になっちゃうからユニットテストの意味なし。
なぁ、これまじで言ってるの・・・？
レビューってソースコードレビュー？

730 ：デフォルトの名無しさん：2006/05/17(水) 01:13:02

>>728
詳細仕様「書」っちゅうか詳細仕様は、何度も修正入るだろ。
まずレビューでクラス設計にあとからケチ^H^H改善提案が付くし、
単体テスト終って結合で問題が出たら、クラスがいびつになるとか言ってまた直すし。

>>729
その後のリファクタリングの必要が減るレビューって、ソースレビュー以外に何があるんだ？

731 ：デフォルトの名無しさん：2006/05/17(水) 01:17:26

POJOとJUnitで書いたテストコードこそが最大の資産である

732 ：デフォルトの名無しさん：2006/05/17(水) 01:23:16

Seasar信者はｶｴﾚ

733 ：デフォルトの名無しさん：2006/05/17(水) 01:37:55

ユースケースと要求仕様の違いって何でしょうか？

734 ：デフォルトの名無しさん：2006/05/17(水) 02:09:38

>730
でもテストが作り直しになるような変更はそう何度もないぞ？
作り方（設計）がおかＰ
んじゃねの

735 ：デフォルトの名無しさん：2006/05/17(水) 03:10:54

>>730
なんか手戻りが多すぎね？

736 ：デフォルトの名無しさん：2006/05/17(水) 06:30:38

とりあえずコード書き始めちゃうんだろうな。
で、変更のたびに毎回レビューしてるっぽい。
このレビューだが、テストケースを書くよりも工数少ないの？

737 ：デフォルトの名無しさん：2006/05/17(水) 08:19:43

なかなか面白い議論してるな。
>>675
>目視つうけど、ユニットテストに誤り無いなんて保証あるのか？

そうなんだよな。>>674で
>一人のPGが手作業＆目視で俺様流のテストをして「大丈夫です」と言い張るのを信用できるかって話しだ。
といってるけど、これって「俺流のユニットテストを流して「大丈夫です」と言い張るのを信用できるか」と言い換えられる。

>>676
>イテレーションを何度も回さない開発の場合はテストコードを書く必要はない。

おれもそう思う。おれは頻繁にコードを修正するからxUnitを使って回帰テストしやすいようにしてるけど、
プロジェクトによってはいったんコードフリーズしたらそのあとは滅多に変更しないという戦略をとってるところもある。
その戦略自体どうよとも思うが、それはおいといて、そういうプロジェクトならユニットテストはあんまりそぐわないし、
デバッガで変数を書き換えてテストする方法でも十分いいと思うよ。

738 ：デフォルトの名無しさん：2006/05/17(水) 08:27:43

>>625
>詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
>本当に生産的であるっていう、根拠を教えてよ。

ほんとうに仕様を網羅するテストケースは、実際に作るとコストがすごくかかるし、仕様変更にも弱いから、ふつうはしないんじゃないかな。
おれは、正しい入力ひとつと、あとはエラーチェックにかかる入力をいくつか与えるくらいのテストしかしてない。可能性のある入力をすべて網羅なんて無理。
それでもxUnitによる恩恵は感じる。結局はxUnitだって道具でしかないんだし、使い方だよ。

ユニットテストはプログラム全体に渡ってバグがないことを保証するためのものじゃない。テストしたパターンではバグがないことを保証するだけ。
すべてのパターンを網羅できればそりゃ理想だけど、それは困難だし、そこまでしなくても
典型的なパターンをテストするだけでもバグはぐっと減らせる。
だから>>625が「仕様を網羅するテストケースを用意しなきゃいけない」と考えてるなら、それは行き過ぎのような気がする。
そこまでしなくてもユニットテストは効果あるし、効果ある使い方だけをすればいい。

それにしてもユニットテスト信者うぜーな。昔のEJB信者とおなじぐらいうざい。

739 ：デフォルトの名無しさん：2006/05/17(水) 09:48:58

>>736
テストケースのコードによって、
「俺流のユニットテスト」が何をするものなのか、
そしてそのテストは本当に行われたのかが
確認できる。
手作業&目視だと、出来の悪い嘘つきが、やってもいないテストを「やった」と言い張れて、
その嘘は結合テスト実行まで露見しないが、
テストケースを作る規則にしてあれば単体テストのフェーズで見つかる。

そこで次に問題になるのは、テストケースの品質だね。
極端な話、assertしないテストケースを書けばオールグリーンになるが、品質はまるで当てにならない。
テストケースの品質を保証するのは、コードレビューでもいいし、ペアプロでもいい。
うちはカバレッジ測定でやってる。
もちろんカバレッジ測定で100%保証できる訳じゃないけど、このあたりで妥協して落とし所としている。
その先の品質保証は、やっぱり結合テスト、総合テストでするよ。
ユニットテストで100%の品質保証なんてできると思ってない。
もちろん、ここにいる、「ユニットテストをコードで書く」派も、そう思ってる奴はいないんじゃないかな。

ちなみに、うちじゃコードレビューはやってないけど、コードレビュー自体は否定しないよ。
やっぱ、コード読んでると、つっこみたくなるところが出てくるしさぁ。
そういうのを言い合える機会はあるといいね。
うちでもやってみたいけど、時間がかかりそうなのでやってない。
メンバーでスケジュール調整するのも面倒だし。

740 ：デフォルトの名無しさん：2006/05/17(水) 10:51:31

>>734
TDD（テストファースト）だったらありまくりだろ。
レビューより先にテスト書いたって、どうせクラス設計は変わるし、
それにほかのオブジェクトも動くちょっと実践に近いテストでNGが出たら、
大抵、クラス設計のミスが含まれてる（誤魔化せる場合も多いが）から、また変わる。

クラス設計が変れば、ユニットテストは当然書き直しだろ。

741 ：デフォルトの名無しさん：2006/05/17(水) 11:47:04

まだやってるのかよ。もうほっとけばいいのに。

742 ：デフォルトの名無しさん：2006/05/17(水) 12:18:42

>>736
単発はともかく、なんどもテストケースを修正するよりは、レビューの方が工数は少ないだろう。
レビューは、仕様を踏まえていろんな条件を考慮して行う。さらにバグだけでなく改善も提案される。
>>738のいうように典型的なパターンのみの確認ならば、効果はとても比べられるモノじゃないだろ。

>>739
つまり、上の方にあった、「嘘つき手抜き」ばかりの現場では、デバッガじゃだめってことね。

煽る訳じゃないが、
しかし、レビュー無し・コード行カバー率利用って、
うちは、レビューで設計改善と全仕様考慮が当たり前だし、
デバッガで実オブジェクトを使ってのコード＋分岐で１００％がデフォなんだが、
うちの感覚からすると、正直な感想は、「みんなエライ適当にやってるんだな」と感じてしまう。

まとめるとこんなところか？

アジャイル………スパイラル………ｳｫｰﾀｰﾌｫｰﾙ　
←xUnitが効果的　　　　　　　　　xUnitは非効率→

クラス設計軽視（レビュー軽視）……クラス設計重視（レビュー重視）
←TDDコスト安い　　　　　　　　　　　　　　　　　　　　TDDコスト高い→

743 ：デフォルトの名無しさん：2006/05/17(水) 12:18:51

>>734
うそーん　テストが作り直しになる変更なんてしょっちゅうだよ
でもテストの作り直しはそんなに手間と思ったことはないな。
おれにとっちゃ、テストもコードの一部。仕様が変更されたら仕様書もupdateするのと同じように、
コード変更したらテストもupdateする。それだけ。
テストデータが書きやすいように工夫してるからかな。テストデータを直すのは大変だとは思わない。

これがJavaやCそのものでテストプログラム書かなきゃいけないのなら大変なんだろうけどな。
本体がCやJavaでもテストプログラムはスクリプト言語でやってるから、すげー楽。

744 ：デフォルトの名無しさん：2006/05/17(水) 12:30:16

>>743
それユニットテストじゃないんじゃないの？

745 ：デフォルトの名無しさん：2006/05/17(水) 12:34:07

>>742
ちょっと聞きたいのだが、742のことじゃレビューが終わると仕様もコードも変更されることはないの？
おれんとこじゃ、レビューするしないに関係なく、仕様変更や利ファクタリングをよくやるから、テストが自動化されてないと、とてもじゃないが品質が維持できない。

742をみると、レビューするしないとか、アジャイルかウォーターフォールかはあんまり関係なく、
仕様変更や機能拡張がどれだけ行われるかどうかが重要なんじゃね？
仕様変更や機能拡張があんまりないんなら、デバッガによるテストを一回やってOKならそれでいいけどさ、
おれんとこは仕様変更も機能拡張も結構な頻度でやってるから、そのたびに毎回デバッガ使ってなんてやってられない。

ユニットテストってそのためのもんじゃね？最初から仕様なんて決まるわけがない、仕様は作りながら徐々に固めていくものだ、
その前提で品質を保証するにはテストの工数を下げる必要がある、だから自動化しようねというのが、そもそもテストを自動化する理由だったはず。
742みてると、最初から仕様がかっちり決まってるように見えるんだよね。そんなのおれたちとは前提が全然ちがうからさ、話かみわないよ。

具体的に742のやってる開発って何よ？最初っから仕様がかっちり決められる開発なんて滅多にないと思うけど。
古いCOBOLのシステムをJavaでリプレースするときでさえ、仕様変更も機能拡張もがんがんあったぞ。

746 ：デフォルトの名無しさん：2006/05/17(水) 12:53:13

>>745
>742のことじゃレビューが終わると仕様もコードも変更されることはないの？
結合してバグが出たら当然直すよ。

>レビューするしないとか、アジャイルかウォーターフォールかはあんまり関係なく
>毎回デバッガ使ってなんてやってられない。
察しの通りうちは基本的にｳｫｰﾀｰﾌｫｰﾙ。
だが、後工程での部分仕様変更はあるし、完了後も機能拡張開発はある。
それで、デバッガで関係ないクラスまで全クラステストなんてやらないし、意味がないだろ。
修正したらどこまで影響が及ぶかを調査してその範囲をテストする。
既存で修正無しの部分は単体テストじゃなくて結合・機能テストだが。

>具体的に742のやってる開発って何よ？
フィールド案件で使い回せる共通機能ライブラリっつうかフレームワークっつうかパッケージっつうかそんな感じのモノ。

747 ：デフォルトの名無しさん：2006/05/17(水) 12:55:35

>>742
はい、適当にやってます。全コードレビューなんてやってるところに行ったら、尊敬してしまう。

ただ、これも煽る訳じゃないけど、
「そんなに手作業を信じられるの」と、逆に疑問に思ってしまう。
デバッガで実オブジェクト使ってのテストなんて、手順間違えたら終わりだし、
分岐網羅するテスト仕様を自分で考えてテストなんて、仕様の列挙間違ってたら100%にならないし。

その代わりに、
xUnitテストケース書いてテストの手順を自動化すれば、
誰でもいつでも同じ手順でテストが出来る。
カバレッジ測定すれば、テスト仕様が十分かどうかわかる。

別に、チームに嘘つきや低能がいる場合を想定している訳じゃないよ。
人間誰だってミスするし。だから人間の手作業が信じられない。自分も含めて。

さらに言うなら、結合テストは手作業でやってるけど、ここもできるなら自動化したい。
そんで、テストの正しさを測りたい。
だれか、俺たちのテストが正しいことを証明してくれ。

748 ：デフォルトの名無しさん：2006/05/17(水) 13:14:07

>>747
＞カバレッジ測定すれば、テスト仕様が十分かどうかわかる。
http://www-06.ibm.com/jp/developerworks/java/060217/j_j-cq01316.shtml

＞人間誰だってミスするし。だから人間の手作業が信じられない。
ユニットテストは、人間が手作業で書くんじゃないのか？

＞さらに言うなら、結合テストは手作業でやってるけど、ここもできるなら自動化したい。
同意というか、単体テストなんかより、結合テストこそ、できるだけ自動化してるよ。
だって、修正のホントの影響が解るのってここだから、これこそ繰り返しやる必要がある。

他意無く、正直な感想を言わせて貰うと、
「TDD・ユニットテストは、いままでろくにレビューや単体テストをしてなくて、
　ただガリガリコード書いてくっつけて確認みたいな開発をしてきた現場では、
　品質向上に役に立つ。
　それは、テスト・レビューしてなかったのをテストするようになったんだから、品質が上がるのは当たり前」
という感じ。どこか間違ってる？

749 ：デフォルトの名無しさん：2006/05/17(水) 13:53:03

>>748
うん。それは読んだ。テスト仕様が十分というのは言い過ぎだった。
が、その記事について1つ言わせてもらえるなら、
coberturaが条件網羅を測定できないのが悪いのであって、
条件網羅も測定できるツールを使えば解決する。

＞ユニットテストは、人間が手作業で書くんじゃないのか？
そう、だからテストの品質をカバレッジで測定し、保証する。
手作業の品質は、それを行った人が自分で保証するしかない。

＞結合テストこそ、できるだけ自動化してるよ。
お、そうね。やっぱそっちも大切だよね。機能テストの自動化とかね。
うちはWeb屋なんだが、HttpUnitとか試してみたいな。

それからTDDとコード化されたユニットテストの効果だけど、品質保証に加えて、
「自分の力量では実装できない複雑なビジネスロジックを設計できる」というのも挙げておく。
「何言ってるんだゴラァ」とか罵られそうだが。

まあつまりだ、「普段は消費税5%かかるけど、10万円以上になるとさらに特別地方消費税10%かかるよ」
という仕様（もちろんこれはでたらめだ）があったとして、
その仕様からコードを書けない奴がいたとしよう。
そういう奴でも、「値段が10000円の時は、売値は10500円」
「値段が99999円の時は、売値は104998円」
「値段が100000円の時は、売値は115000円」
と言う風にテストケースを増やしながらTDDさせていけば、何とか仕様通りのプログラムが書ける。
詳しくはKent BeckのTDDの本を読んで欲しい。

まぁ、正直言って、TDDが必要なほど複雑なロジック、今までお目にかかったことはないんだが。
それと、TDDの代わりに、綿密な設計と検討とレビューでだってできるだろうね。
TDDしてない人はみんなそうしてるんだし。別にTDDが最適な解と言ってる訳じゃないので。

750 ：デフォルトの名無しさん：2006/05/17(水) 13:59:33

＞正直言って、TDDが必要なほど複雑なロジック、今までお目にかかったことはないんだが。

激しく同意。
一応お目に掛かったことぐらいはあるが、普通はあんまりない。

751 ：デフォルトの名無しさん：2006/05/17(水) 14:08:23

＞＞ユニットテストは、人間が手作業で書くんじゃないのか？
＞そう、だからテストの品質をカバレッジで測定し、保証する。
だから、カバレッジは、単にそのステップが動いたというだけで、テストされた事の証明じゃねぇっつの。
例えば、assetがヌルかったりとか、スタブがバグってたりとか。
つ　jester (使ったこと無いけど)

＞HttpUnitとか試してみたいな。
seleniumお勧め。
ただし、条件分岐がないので素人にはお勧めできなくもなくもない。

＞そういう奴でも、「値段が10000円の時は、売値は10500円」
＞「値段が99999円の時は、売値は104998円」
＞「値段が100000円の時は、売値は115000円」
それは、超重要で、要するにテストの仕様網羅性をあげているわけだ。カバレッジツールじゃ測れない。
そして、ユニットテスト書いてる大抵の奴はこんなにちゃんと書いてないんじゃないか？
ちなみに、うちらは、デバッガ単体テストで境界値テストはデフォ。

752 ：デフォルトの名無しさん：2006/05/17(水) 15:08:43

>>746
>だが、後工程での部分仕様変更はあるし、完了後も機能拡張開発はある。
いやだから、その頻度が問題なのよ。仕様変更あっても十分少なければ同じじゃんん。
頻繁に起こるなら、746とは違うやり方が必要なわけ。

>それで、デバッガで関係ないクラスまで全クラステストなんてやらないし、意味がないだろ。
これは違うと思うぞ。関係ないと思ってもどこでどう関係しているかわからないのがソフトウェア。
だからテストを自動化しておいて、一カ所変更されただけでも全体をテストし直し、
関係ないと思われたクラスも本当に関係ないことを確かめるんだ。手作業じゃそれがつらいだろ。
やっぱり746の場合は変更が少ないことが前提になってると思うな。別にいやみとかじゃなくて、おれたちとはえらい違いだってこと。

>修正したらどこまで影響が及ぶかを調査してその範囲をテストする。
>既存で修正無しの部分は単体テストじゃなくて結合・機能テストだが。
広範囲に関わるような基本クラスやライブラリを変更したときはどうするんだ？それも手作業でテストするのか？この場合はテストが自動化されていた方がいいと思うのだが。
というか、そういう変更自体が発生しないようなプロジェクトなんだろうな。ある意味、正しいよ。あるべき姿かもしれん。

753 ：デフォルトの名無しさん：2006/05/17(水) 15:18:10

>>748
それはいえるかもな。今までテストはコストがかかるからおざなりにされてきた。
そこに、（習熟コストは別として）コストがあまりかかんなくてもテストできるツールが広まった。
だから、そういうツールとは別に品質を保持できる仕組みがある組織では、あんまり必要ないといえそう。

ただな、レビューってのはかなり高度な技術が必要だよ。だれもができることではない。それだけはいっておく。
それにくらべると、ユニットテストはわりとレベルが低くても実践できる。

>>751
>それは、超重要で、要するにテストの仕様網羅性をあげているわけだ。カバレッジツールじゃ測れない。
>そして、ユニットテスト書いてる大抵の奴はこんなにちゃんと書いてないんじゃないか？
これもそのとおりなんだよな。ユニットテスト書けばOKっていう風潮はおかしくて、ちゃんとしたテスト書くのってすごい難しいことなんだよな。
そして、そのへんのことは本や雑誌にも載ってない。xUnitの使い方とかばっかし。
ただまあ、テストが重要っていうふうに流れを変えてくれたのはxUnitとかアジャイル派のおかげ。それはありがたかった。
746みたいにレビューをちゃんとやらせてもらえる（そのための期間やコストを考えている）プロジェクトなんて、ごくごく少数だぜよ。世の中のバカマネージャってそんなもの。

754 ：デフォルトの名無しさん：2006/05/17(水) 15:25:47

＞関係ないと思ってもどこでどう関係しているかわからないのがソフトウェア。
「関係ないと思って」ってところがやっぱり、考え方の違いなのかな。
「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。

もちろんとても追い切れない場合もある。
それは、結合テスト・機能テストでその追い切れない影響を確認する。
だから、結合テスト・機能テストは出来るだけ自動化してる。

大体、ユニットテストは、クラス毎にバラバラにテストするのが基本だろ？
モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
それで、予想外の影響伝搬を確認するっておかしくないか？
第一、典型パターンのみの、仕様が網羅されてないテストがOKという程度じゃ、
とても恐ろしくて「影響なし」なんて判断できないよ。

余所は知らんが、ｳｫｰﾀｰﾌｫｰﾙだから、それ以外に比べたら変更自体は少ないだろうな。
だから、いちいち「関係ないことを確認して」なんて事が出来るのかも知れない。
俺以外の所は、XPみたいな週単位で仕様を追加作っていくような開発してるの？

755 ：デフォルトの名無しさん：2006/05/17(水) 18:22:56

>>754
>「関係ないと思って」ってところがやっぱり、考え方の違いなのかな。
>「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。
これ、どうなん？こんな方法でうまくいくものなのか。それってけっこう実力が高くないと難しくないか？
まず、その確認とやらがgrepぐらいで本当にできるのかという疑問。関数へのポインタとか使ってると、関数名をgrepしただけじゃ影響範囲は判定できないと思うけど。
それから、これもやっぱり変更があるたびにやるんだよな。そのコストがどうなの？という疑問。これも仕様変更やコード修正が少ないことを前提としてるとしか思えん。

>もちろんとても追い切れない場合もある。
>それは、結合テスト・機能テストでその追い切れない影響を確認する。
>だから、結合テスト・機能テストは出来るだけ自動化してる。
そうだな、単体テストを自動化してそこで見つけるか、結合テストを自動化して見つけるかの違いなんだろうか。
ただ、テスト対象が広くなるほど、不具合があった場合（テストが失敗した場合）の原因特定が難しくなるから、
おれとしては結合テストより単体テストで見つけたいところだなー。

>大体、ユニットテストは、クラス毎にバラバラにテストするのが基本だろ？
>モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
>それで、予想外の影響伝搬を確認するっておかしくないか？
予想できないから予想外なんだよ。粗結合になるように設計していても、ある箇所の変更が思わぬところに影響を与えたりする。まるで「蝶の羽ばたきがハリケーンになる」とかまさにそんな感じ。
それから、影響範囲をgrepで見つけるのもいいけど、単にユニットテスト全体をやり直してfailしたのがあればそこが影響範囲だと判断して修正している。おれんとこでは。
どっちのやり方が正しいのかわからんけど、影響範囲を調べる方法としてはgrepよりはいいんじゃないかなと思うんだけど。

756 ：デフォルトの名無しさん：2006/05/17(水) 18:23:29

つづき。

>第一、典型パターンのみの、仕様が網羅されてないテストがOKという程度じゃ、
>とても恐ろしくて「影響なし」なんて判断できないよ。
まあ、単体テストがどのくらい信用できるかについては、そのとおりだ。そもそも仕様がうまく明文化できないのが問題で、仕方ないからテスト書いてるようなものか。

>余所は知らんが、ｳｫｰﾀｰﾌｫｰﾙだから、それ以外に比べたら変更自体は少ないだろうな。
>だから、いちいち「関係ないことを確認して」なんて事が出来るのかも知れない。
たぶんそう。こっちのほうで単体テストが終わって仕様が固まってリファクタリングも済んで完成したと思ってるレベルが、そっちでのレビュー対象となるんだと思うよ。

>俺以外の所は、XPみたいな週単位で仕様を追加作っていくような開発してるの？
週単位というか、営業が客とあう単位？仕様変更じゃなくても、リファクタリングはしょっちゅうだから、やっぱりxUnitなしじゃまともな開発できねー。

757 ：デフォルトの名無しさん：2006/05/17(水) 18:28:31

つうかさ、xUnit使ったテストの自動化って、客のわがままや無能なSEのせいで仕様変更ばっかり起こって困ってるプログラマーの、
自衛のための手段なんだと思う。
世の中が仕様をきちんと決められて凍結できるようなプロジェクトばかりだったらテストの自動化は必要なかったろう。
でも実際はそんなプロジェクト滅多にないから、そういう仕様変更から自分の身を守るための手段がxUnitなんじゃなかろうか。
テストこそが仕様だというやつもいるけど、まあそのアイデア自体は悪くないと思うけど、今はまだツールがそこまで進化できていないから。

758 ：デフォルトの名無しさん：2006/05/18(木) 01:02:08

＞>「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。
＞それってけっこう実力が高くないと難しくないか？

いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るかソース読むだけ。面倒だがそんな大したことはない。

＞関数へのポインタとか使ってると、関数名をgrepしただけじゃ影響範囲は判定できないと思うけど。

関数ポインタだって代入箇所が掛かるだろ。

＞>モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
＞>それで、予想外の影響伝搬を確認するっておかしくないか？
＞予想できないから予想外なんだよ。粗結合になるように設計していても、

おいおい、話がズレてるぜ。１００の影響伝搬のうち、８０を分断してれば、
予想内だろうが予想外だろうが関係なく、完璧に仕様を網羅したユニットテスト書いた場合ですら
MAXでも２０しか影響が見つからんだろう。
だから、

＞単にユニットテスト全体をやり直してfailしたのがあればそこが影響範囲だと判断

は、正しくはないだろ。ただ、現実の妥協点としてはありかもしれんが。

＞そういう仕様変更から自分の身を守るための手段がxUnitなんじゃなかろうか。

変更が頻繁にある場合は、テストの自動化は重要性が増すな。
だがその最適な単位がユニットテストというのは、納得に値する理由は見つからないな。
影響伝搬の分断によって検出力不足だし、書き直しが頻繁に発生しすぎ（クラス設計に拘れば）。

759 ：デフォルトの名無しさん：2006/05/18(木) 02:25:09

>いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るか
ここがおかしいと思うんだが。

なぜ呼び元が後からになる？
使われる側の都合で使う側が変わるような設計してりゃ
(使う側からの視点における)テストが大幅に書き直しになるのはあたりまえだばw

760 ：デフォルトの名無しさん：2006/05/18(木) 04:15:42

＞使われる側の都合で使う側が変わる

は？呼ばれる側に変更が発生したときの影響の確認を言ってるんだが？
「仕様からして○○なはず」だけで全てがその通りなら、
それこそxUnitのリグレッションなんて要らないわけだが。

761 ：デフォルトの名無しさん：2006/05/18(木) 06:39:50

この議論面白いが、言葉の定義がされてないからなのか、混乱する。

単体テストとユニットテストって普通同じことだよね（訳しているだけだし）。
なんだかユニットテストがxUnit使った自動化のこと言ってる人もいそうな気がしたんだけど、
もしかしてそちらの方が常識なんでしょうか。

あと、変更影響の範囲の話だけど、単体テストがモックを使いまくって、
超純粋に１メソッド（１関数）のみをテストするものと定義されて、そのテストコードが
作られているという話ならば、実行しても確かに変更影響は分からん(failにならん）わな。
でも実際はそんな超純粋な状態を単体テストと言ってない場合が多いのではないかな。

というわけで、みんなの単体テストの定義が分からないという問題提起。

762 ：デフォルトの名無しさん：2006/05/18(木) 12:29:42

TDD
　実コードより先にxUnitのテストコードを書いてユニットテストで単体テストをする開発のやりかた方

単体テスト
　結合して全体を確認するのではなく、作成or修正した部分自体をテストすること

ユニットテスト
　xUnitを使ってOK/NGまで判定するテストコードを書いて単体テストを行うやり方

763 ：デフォルトの名無しさん：2006/05/18(木) 12:55:46

>>571
JUnit4がもう二ヶ月も前からリリースされていたのか。
なんだかワクワクしてきたぞ

アノテーションってか？

764 ：デフォルトの名無しさん：2006/05/18(木) 13:42:36

＞実際はそんな超純粋な状態

たしかに実際は完全に純粋なわけはないが、
実際のプログラムよりは、明らかに純粋になってるわけで、
ユニットテストで解る影響範囲は、本当の影響範囲の一部でしかない。

765 ：デフォルトの名無しさん：2006/05/18(木) 14:44:51

うちは、Facadeやコマンドレベルのクラスの単体テストは、
Mock使わずに実オブジェクトでやってるよ。実質、結合テストと呼ぶべきかも。
Mockは、設計レベルで導入するよう考慮しないと使えない。

ちなみに、xUnit使ってテストコード書く派。

766 ：737,738,745,752,753,755：2006/05/18(木) 18:05:39

もう誰が誰だか分からんな。
>>758
別にそっちのやり方を否定するつもりじゃないんだけど、
>いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るかソース読むだけ。面倒だがそんな大したことはない。
これって、呼んでる場所が多ければ多いほど読まなきゃいけない量が増えるんだよね。いいのかなあ。
それに、その呼び出しがコード上どこまで影響するかというのは、読むだけじゃわからんと思うけどなあ。
研究レベルではControl Flowを解析して影響範囲を表示してくれるツールがあるけど、758がそういうの使っているわけでもなさそうだし。

>関数ポインタだって代入箇所が掛かるだろ。
引数で渡したら名前のgrepじゃわかんないよ。あと関数テーブルとか。

>おいおい、話がズレてるぜ。１００の影響伝搬のうち、８０を分断してれば、
>予想内だろうが予想外だろうが関係なく、完璧に仕様を網羅したユニットテスト書いた場合ですら
>MAXでも２０しか影響が見つからんだろう。
これは何いってるのかわからん。
つうかな、プログラムってどんなに正しく書いたつもりでもやっぱりバグあるじゃん。
影響範囲の分析だって、ここ以外は影響ないと思っていても、やっぱり影響あったりする。
人間が頭で考えたのが必ず正しければいいんだけど、そうじゃないからテストがあるんだし。
まあ758の場合は想定外の影響があった場合は結合テストで見つかるからOKという立場なんだろうけど。

やっぱ「仕様変更が少ない（はじめに仕様が固まってくれる）」のと「レビューでバグが見つけられる（だけの優秀な人材を抱えている）」というのが大きいと思うよ。

767 ：デフォルトの名無しさん：2006/05/18(木) 22:34:19

おいおい、影響伝搬の検出力は、ユニットテストの有効性が決まる肝だぜ。
わからんの一言でスルーせんでくれよ。
実際のオブジェクトとのインタラクションがなくなれば、
そこの不整合が検出出来んだろう？

768 ：761：2006/05/19(金) 01:04:25

>>762
単体テストとユニットテストって違う意味だったのか～。
ｼﾗﾝｶｯﾀ(恥

769 ：デフォルトの名無しさん：2006/05/19(金) 01:19:31

>読むだけじゃわからんと思うけどなあ。
なんで？(呼び出す側を読んで)呼出し先の仕様が変わったらどうなるか解らんてことは、
プログラムが書けないって事だと思うが。

>引数で渡したら名前のgrepじゃわかんないよ。あと関数テーブルとか。
だから、最初に代入する部分があるでしょ？
DEPに引っ掛かるようなTEXT部に動的に関数を構成する様なのは無理だがうちはそんな高度な事してないから関係ないよ。
つか、うちはほとんどJavaだから、関数ポインタよりリフレクションだな。grepすれば済むけど。

レビューにスキルが必要ってのは、意識したことなかったわ。
もちろんスキルが高い方が良いレビューが出来るのは間違いないけど、
仕様を聞いて間違い探しするくらい曲がりなりにもPGなら誰でも出来るだろ？

仕様変更については、上にも書いた通りWFだから、アジャイルとかより変更が少ないのは間違いない。
アジャイルでもこのやり方がうまくいくとは思ってないよ。
でも、ほんとにみんなアジャイルやってんの？設計フェーズってもんがないの？

770 ：デフォルトの名無しさん：2006/05/19(金) 02:38:47

間違い探し位は誰でもできるだろうな。時間が無限にあれば。
レビューにもスキルは必要。

771 ：デフォルトの名無しさん：2006/05/19(金) 03:27:20

レビューはテストの代りにならないし、
テストはレビューの代りにならない。

レビューは、XPでもUnitテストと並ぶ超重要超効果的なプラクティスだ。
ただペアプロというあまりに極端なやり方を提示してしまったため、
Unitテストに比べて重視されていないのは不幸な事だ。

かといって、レビューをしているからテストが要らないというのは成り立たない。

772 ：デフォルトの名無しさん：2006/05/19(金) 05:25:28

>>767
だっておまえの文章、意味わからんもん。スルーされないようにわかりやすく書けよ。

773 ：デフォルトの名無しさん：2006/05/19(金) 08:16:12

>>769
>仕様を聞いて間違い探しするくらい曲がりなりにもPGなら誰でも出来るだろ？
仕様を聞いて理解できるだけでかなり上級。
普通は仕様書がない・間違ってる・いいかげん・宇宙語で書いてあるので、プログラマじゃ理解できない。

774 ：デフォルトの名無しさん：2006/05/19(金) 12:16:51

それじゃあ、保守はどうすんの？

775 ：デフォルトの名無しさん：2006/05/19(金) 12:47:59

エスパーに頼む＞保守

776 ：デフォルトの名無しさん：2006/05/19(金) 12:55:18

んなもんシステム納品したらはいサヨウナラのSIerには関係ないことだ

777 ：デフォルトの名無しさん：2006/05/19(金) 21:17:46

ならば、ユニットテストもいらんではないか。

778 ：686：2006/05/19(金) 22:04:47

>>777
納品できないだろ、テストしないと。

779 ：デフォルトの名無しさん：2006/05/19(金) 22:05:43

>>778
あれ、なんかハンドルに投稿者番号が残るな・・・
どっちでもいいけど、なんでだろ

780 ：デフォルトの名無しさん：2006/05/20(土) 01:15:05

一回こっきりの納品でおさらばできるならば、ユニットテストなんて形式的にしかやんない数字あわせの世界。
ましてやテストプログラムなんて作らん。

781 ：デフォルトの名無しさん：2006/05/20(土) 01:31:20

↑素人

782 ：デフォルトの名無しさん：2006/05/20(土) 11:03:06

素人のくせに SI を名乗る業者が大杉ってことで FA?

783 ：デフォルトの名無しさん：2006/05/20(土) 16:15:16

ユニットテストの話なんてSIじゃなく、ソフトハウスでしょう。

784 ：デフォルトの名無しさん：2006/05/20(土) 16:45:39

ユニットテーストユニットテスト♪
すべてのテストを自動で実行するんだぜ！って言うじゃな～い？

でもあんたのテスト、2個エラー発生してますから！
でもあんたのテスト、2個失敗してますから！

残念！
4個のテストで、エラー2個、失敗2個、斬り！

785 ：デフォルトの名無しさん：2006/05/20(土) 19:42:07

バグは現場で起きてるんじゃない、会議室で起きてるんだ！

・・・なんとなくこんなフレーズが浮かんだけど、
いくつかの致命的なバグの発生元って会議室だったりしない？

786 ：デフォルトの名無しさん：2006/05/20(土) 20:01:00

ユニットテストってXPとかTDDで使われるときと、それ以外で使われるときで
激しく役割が違うから誤解してるやつ多いね。
同じ名前で呼ぶのが間違ってたな。

787 ：デフォルトの名無しさん：2006/05/20(土) 22:46:33

>>785
つ ttp://pc8.2ch.net/test/read.cgi/prog/1148058311

788 ：デフォルトの名無しさん：2006/05/21(日) 09:37:30

>>786
ユニット＝単体と考えてるから、ってことはない？
単体と違って、ＸＰ・ＴＤＤのユニットテストはもっとアクティブに行うものだからさ。
だから齟齬が生じるんじゃないかなー。

789 ：デフォルトの名無しさん：2006/05/21(日) 13:41:27

ユニットテストがそういう意味というのは国内のみ？
それともUnit Testも同じ意味？

790 ：デフォルトの名無しさん：2006/05/21(日) 19:08:47

単体テスト＝上流・仕様作成側から見た「機能単位」ごとのテスト
ユニットテスト＝プログラマ側から見た、プログラムの構成要素単位（関数・クラス・モジュール）ごとのテスト

ユニット=Unit=単体という訳語を安易に当てはめるのが誤解のもとである。

791 ：デフォルトの名無しさん：2006/05/21(日) 19:13:16

じゃあ、単体テストは英語で何というの？

792 ：デフォルトの名無しさん：2006/05/21(日) 21:12:06

俺みたいに単体テスト=Unit Testと思っている人って結構いると思う。
単体テスト＋Unit Testingでググっっても結構そんな感じ。

だが、Wikipedia
http://en.wikipedia.org/wiki/Unit_test
を読むかぎり、たしかに>>788が言うとおり。

でも、さらにググると、IEEE Standard for Software Unit Testingとかもあって、それは
xUnit系の話ではない。
ユニットテストにも狭義と広義があるということが今俺の中での回答になった。
使うときに注意するってことだね。

793 ：デフォルトの名無しさん：2006/05/21(日) 22:21:18

狭義と広義があるというよりは、xUnit使ってる人達の一部が、意味を狭めているだけだと思う。
xUnitのテストケースを使ってすることが単体テストなのに、
テストケース自身を単体テストと呼んでいる気がする。
「シェルスクリプトを作る」を「シェルを作る」というのに近い。

794 ：デフォルトの名無しさん：2006/05/21(日) 22:26:34

>>793
シェルとシェルスクリプトは名詞だが、
テストは動詞でもあるな。

795 ：デフォルトの名無しさん：2006/05/21(日) 23:31:18

>>793
国語力なさそう…。

796 ：デフォルトの名無しさん：2006/05/22(月) 00:19:05

・・・なんか「ツールを使わなければそれはテストでは無い」と解釈しかねないレスが多いな
自分はテスト設計自体を単体テストと呼ぶような人間だよ

797 ：デフォルトの名無しさん：2006/05/22(月) 00:24:16

俺は実行しなければテストとは呼ばないなー。ツールの有無はともかく。

798 ：デフォルトの名無しさん：2006/05/22(月) 00:56:51

>>797
その有効性云々はともかくとして、俺は机上ステップ実行はテストの内に入れる。
>>797 的に、机上ステップ実行を実行と認めるかどうかは知らんが。

799 ：デフォルトの名無しさん：2006/05/22(月) 01:21:32

ここのレス見てると、やっぱり、混同されてると思わざるを得ない。
少なくとも、俺が思う問題と、みんなが思ってる問題がずれてる。

テストケース自体を呼ぶのか、テストする行為を言うのかというズレを
問題にしたいわけでもなく、機能単位とモジュール単位の違いがあるという
ことを問題にしたいわけでもない。
そんなの別にどうだっていい。

俺がここで言いたい問題と言うのは、普通「単体テスト」と言った場合、膨大な量
のテストケースを仕様確認のためにテストしていって、最終的にテストが全部通る
ようなアプリケーションを目指すときに使われるだろ。
TDDの時の単体テストもそういうものだと勘違いしてる奴が多すぎるってこと。
TDDの時は、そういうのとは単体テストの使われ方が全く違う。それを混同してる
奴がいる。このスレなんて多分そういう奴が多すぎる。

800 ：デフォルトの名無しさん：2006/05/22(月) 01:25:02

つまり、レッド→グリーン→レッドの短いサイクルを何度も繰り返してリファクタリングしていくって
いう過程が誤解されてる気がする。
そういう作業過程を知らないまま、「単体テストを使うんだ」という知識だけで全く別の工程を
想像して、そのまま話を進めてしまう。
単体テストという単語によって激しく誤解されてる気がする。

801 ：デフォルトの名無しさん：2006/05/22(月) 01:30:24

リファクタリングってテスト完了後にやるものだと思っていたよｗ

802 ：デフォルトの名無しさん：2006/05/22(月) 01:39:22

>>801
TDDの場合、

新しいテスト→レッドバーがﾞ出る→すぐにグリーンにする→
グリーンを保ちながらリファクタリング→新しいテスト

というパターンを繰り返すから、まあ、ある意味一つ一つのテスト完了後
にリファクタリングをしてるとも言えるかもしれないが、リファクタリングしてる
最中にもテストを何度も実行してグリーンかどうかを確認するわけだし、
同時進行ってのが一番しっくり来るかな。

そういうのを知らないまま、「最初にテストをたくさん作って、テストする時には
一気に全部テストして、パスする総数を少しずつ増やしていって」
みたいなことにxUnitを使うんだ、それがTDDなんだと勘違いしてるんじゃないかと思う。

ようするに、この2つは全然違うし、同時に行うことも可能。

803 ：デフォルトの名無しさん：2006/05/22(月) 02:40:19

つーことで、TDDはテスト駆動って言わなきゃいいのにね。

804 ：デフォルトの名無しさん：2006/05/22(月) 06:33:29

火の車開発とか自転車操業開発と言えば分かりやすくなるんじゃないだろうか？

805 ：デフォルトの名無しさん：2006/05/22(月) 08:34:36

突貫工事

806 ：デフォルトの名無しさん：2006/05/22(月) 08:38:01

ボトムアップ開発

807 ：デフォルトの名無しさん：2006/05/23(火) 04:26:17

>>804-805
それはXPにこそ、ふさわしい言葉だね

808 ：デフォルトの名無しさん：2006/05/23(火) 07:16:00

いやいや、ユーザーが火の車だろうと開発者は悠々と週40時間労働、
これこそが正しいXPだ。

809 ：デフォルトの名無しさん：2006/05/23(火) 07:39:07

Ｘ切り守らなくていいＰログラミング

それがＸＰ

810 ：デフォルトの名無しさん：2006/06/20(火) 11:41:06

DBUnitってあんま盛り上がってないの?

811 ：デフォルトの名無しさん：2006/06/20(火) 11:55:46

>>810
んなこたない。

まあ、ORM使ってたらDbUnitいらない場合も多いけどな。

812 ：デフォルトの名無しさん：2006/06/20(火) 13:01:42

>810
kwsk

813 ：デフォルトの名無しさん：2006/06/20(火) 23:04:47

DBUnitには俺も期待してたけど、なーんかバグ放置したまま
開発止まってるっぽいし。

814 ：デフォルトの名無しさん：2006/06/21(水) 00:01:08

うちじゃ使ってるが。CactusとDBUnit組み合わせて自動テストまでやってる。
今のバージョンはExcelでデータ作れるそうだけど、
1.5の頃からの資産が残ってるので、今だにXMLDataSet使ってるよ。

815 ：デフォルトの名無しさん：2006/06/21(水) 00:07:36

>>814
Excelは、Jakarta POIのバグ（仕様？）で使い物にならない。
http://www.jajakarta.org/kvasir/bbs/technical/267?expand=true

Excelのシート全体のフォントを変更したらOKだった、なんて
わけわからないことになっている。

816 ：デフォルトの名無しさん：2006/06/21(水) 00:14:57

うちでも、Cactus、DbUnitは使っている。
テストケースを作っておくとちょっと変更して動作確認、ってのが楽だな。
でも、Spring/Hibernate使うようになってからDbUnitは出番が減ったな・・・

識者の方にお聞きしたい。
Servletコンテナ上で動作することが前提のコンポーネントでデータベースアクセスのあるコードをテストしたい。
つまり、ServletTestCaseとDatabaseTestCaseの両機能を併せ持ったテストケースを作成したい。
このような場合どうしてますか？
具体的には、Spring/Hibernateを使ったWebアプリケーションです。
SpringでHibernate のSessionの管理をしています。
また、SpringではWebApplicationContextを利用しています。
HibernateDaoSupportを継承したDAOのテストってどうするのでしょうか？

817 ：デフォルトの名無しさん：2006/06/21(水) 00:49:55

Spring/Hibernateは使ったこと無いので役に立つかどうか分からないけど、
DBUnitの機能は、DatabaseTestCaseを継承しなくても使える。
こういうことをするようなユーティリティクラスを作っておけば
ttp://dbunit.sourceforge.net/howto.html#noextend
ServletTestcaseでもDBUnit使ってテストできるよ。

そういうことを聞きたかったのでなければスマソ。

ところで、こういった継承ベースのアプローチって、組み合わせるとき不便。
JUnitベースのツールがJUnit4対応になったら、この辺も便利になるんだろうか。

818 ：デフォルトの名無しさん：2006/06/21(水) 01:01:40

>>817
おおー、thxです。
これを参考にして、明日いろいろ試してみたいと思います

819 ：デフォルトの名無しさん：2006/06/23(金) 06:43:17

テストデータを手で作る分には問題ないのかな。
既存DBからデータを吐き出させようとすると、参照制約を考慮して
くれないとか、なぜか書き出されないレコードがあるとか、いろいろ
あったんで「こりゃ使えない」と思ったんだが。

820 ：デフォルトの名無しさん：2006/06/23(金) 10:40:08

NUnitFormってどうよ？説明見ると面度くさそうだけど、使ってる人いる？

それとNUnitで privateなメソッドのテストが出来ないけど、みなさんどうしてる？

821 ：デフォルトの名無しさん：2006/06/25(日) 15:21:25

> NUnitで privateなメソッドのテストが出来ない
もれだったらテストの際はpublicにするけど。
※そもそもそんなテストがなぜ必要？クラス化考え直した方がいいんじゃねの？

822 ：686：2006/06/26(月) 23:24:33

>>820
リフレクション使えば？
privateメソッドを呼び出すユーティリティを用意すればたいした手間でもないし。

publicなメソッドのテスト通せるんなら
privateのテストいらないって言う人もいるけど、
privateメソッドにちょっと複雑なロジックを切り出している場合はテストを書くかな。

823 ：デフォルトの名無しさん：2006/06/26(月) 23:25:35

↑う・・・なんかハンドルの履歴が消えん・・・

824 ：デフォルトの名無しさん：2006/06/26(月) 23:26:28

>>815
POIちょっとシートいじるとすぐ読めなくならない？
Excelの実装のせいなのかもしれないけど。
つまり仕様か。

825 ：デフォルトの名無しさん：2006/06/27(火) 01:22:02

>>822
お返事どもです。
あれから調べてリフレクションで呼ぶコードを書きましたが、いかんせんコードの可読性が悪くなりますね。

private メソッドを呼ぶユーティリティというのは、Assert.AreEqual のラッパーみたいなイメージですか？

826 ：822：2006/06/27(火) 21:55:08

>>825
Method.invokeのラッパ。
↓こんな感じのインターフェースかな？
中の実装はリフレクションでメソッド取得してinvokeしてるだけ。
後は普通に返り値なりのassertするだけでしょ。

ReflectionUtils.executeMethod(targetObj , clazz , methodName , args);

ちなみにAssert.AreEqualって？
ってNUnitって.netのか。
すまん、Javaの話じゃなかったのか。
まぁあんま変わらないと思うけど。

827 ：デフォルトの名無しさん：2006/06/28(水) 00:06:28

テスト駆動開発について教えてください。

まずはテストを書きます。
テストを失敗させます。
Fake it と呼ばれる手法？で、
とりあえずは一番楽な方法でテストを通します。

またテストを書きます。
テストを失敗させます。
Fake it で実装。

テストを書く。
テスト失敗。
Fake it。

テスト(ry

こんな感じで、
永遠に正しいコードが書けなくなる (テストに応じた if 文の連続になる) 気がするのですが、
どのタイミングで正しいコードを書いたらいいんでしょうか。
それともテストが悪いのでしょうか。

828 ：デフォルトの名無しさん：2006/06/28(水) 00:12:19

>>827
って釣りｗｗｗ

徐々に正しいコードを書いていくんねん
@ITの連載読めや。

829 ：デフォルトの名無しさん：2006/06/28(水) 00:12:40

>>827
テスト駆動開発は、
Red/Green/Refactor
の繰り返しです。
Refactorの所で正しいコードに置き換えます。
詳しくは書籍でどうぞ。

830 ：デフォルトの名無しさん：2006/06/28(水) 00:27:29

>>828-829
すみませんが、釣りじゃないです。
本気で悩んでました。

@IT 見てきます。

スレ汚しすいませんでした。

831 ：デフォルトの名無しさん：2006/06/28(水) 07:18:59

>>828
もしよかったら、URLを教えていただけますか？
それらしき連載は見つかりませんでした・・・
多分探し方が悪いのでしょうけど・・・

832 ：デフォルトの名無しさん：2006/06/28(水) 08:10:53

「atmarkit TDD」で検索
http://www.google.co.jp/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGGL:2006-18,GGGL:en&q=atmarkit+TDD

833 ：デフォルトの名無しさん：2006/06/28(水) 08:13:38

「テスト駆動開発三角測量」でググるのもいいんじゃまいか？

834 ：830：2006/06/28(水) 23:26:30

!831

何度もすみません。

@IT 見たのですがよく分かりません。
と言いますのも、
The Jakarta Project の Commons Lang、StringUtils#is* (例えば isBlank) をテスト駆動開発する場合、
どのようにコーディングしていくのか分かりません。

自分なりに下記のようにやってみました。

// Test Code
1:　public void testIsBlank() {
2:　　assertEquals(true, StringUtils.isBlank(null));
3:　　assertEquals(false, StringUtils.isBlank("foo"));
4:　　assertEquals(true, StringUtils.isBlank(""));
5:　}

// Domain Code
1:　public boolean isBlank(String str) {
2:　　return str == null || str == "";
3:　}

テストコードの 4 行目をテストにパスさせたところで行き詰まってしまいます。
この後はどのようにコーディングしていけばよいのでしょうか。

スレ違い、スレ汚しかとは思いますが、
よろしくお願いしますｴﾛｲ人。

835 ：デフォルトの名無しさん：2006/06/28(水) 23:42:55

>>834
えーと、それでそのメソッドは終わりだよ。
そこから何かをやらないといけないと思ってるのかな？
＠ITの記事は読んでないから、それを踏まえずに言うと、やっぱり本買ったほうがいいよ。
TDDのリズムがわかるから。

836 ：デフォルトの名無しさん：2006/06/28(水) 23:45:01

>>834
assertEquals(true, StringUtils.isBlank(new String("")));

837 ：836：2006/06/28(水) 23:45:37

まちがった。
assertEquals(false, StringUtils.isBlank(new String("")));

だった。

838 ：デフォルトの名無しさん：2006/06/28(水) 23:47:35

>>837
true で良いのでは？いや、仕様だったら知らんけど。

839 ：834：2006/06/29(木) 00:07:20

回答ありがとうございます。ｴﾛｲ皆様。

>>835
>えーと、それでそのメソッドは終わりだよ。
空白文字が連続する場合 (正しくは、渡された文字すべてに対し Charctor#isWhitespace が true を返す場合) にも、
isBlank は true を返します。

>>836
私が書いた isBlank メソッドで true が返りませんか？
Java に対する知識が足りないのでしょうか...。

840 ：デフォルトの名無しさん：2006/06/29(木) 00:22:07

>>839
> 私が書いた isBlank メソッドで true が返りませんか？
== は同じ参照かを判定するので false が返る。

841 ：デフォルトの名無しさん：2006/06/29(木) 00:40:51

>>839
ええっと、それは次になにやるべきなのか、わかってるということじゃないのか？

念のために言っておくと、（以下'_'はブランク）
assertEquals(true, StringUtils.isBlank("_"));
assertEquals(true, StringUtils.isBlank("__"));

というテストを追加して、それがGreenになるような簡単なコードを追加して、
isBlank内の文字列リテラル"_", "__"をなくすようリファクタリングする。
（ひょっとしたら""もなくなるかもしれない）

842 ：デフォルトの名無しさん：2006/06/29(木) 00:54:19

>>840
なるほど。
そう言われてみればそうです。
ありがとうございます。

>>841
なるほど！
リテラルがなくなるようにリファクタすればいいわけですね。
なんだかスッキリしました。
ありがとうございました。

843 ：デフォルトの名無しさん：2006/06/29(木) 01:00:49

Fake itする意味が分からない。
最初から答えを書いてリファクタリングするより、
当てずっぽうとリファクタリングの繰り返しの方がよいコードが書けるって事？

844 ：デフォルトの名無しさん：2006/06/29(木) 01:18:59

動かないコードより動くコードが、
XPのプラクティスじゃなかったっけ？

当てずっぽうで書いて、
リファクタリングするまで動かないのがダメってこと。

簡単なコード（例えばxとyを足すとか）は、
いきなり実装（明白実装）してもいいけど。

あんまり自身ない。

845 ：デフォルトの名無しさん：2006/06/29(木) 02:52:48

「当てずっぽう」って何？
って話はおいといて、Fake itする理由は、Redである期間を可能な限り
短くすることと（TDDのサイクルを早める）、段階的なリファクタリングの
準備をもっとも早くするため。（だと理解している）

846 ：デフォルトの名無しさん：2006/06/29(木) 11:55:11

TDDって、開発期間のほとんどをGreenですごすっていう目標がある。
そのほうが精神衛生上良いから。
従来どおりのコーディング方法だと、最後にやっとGreenになるので、
開発期間のほとんどをRedですごすことになる。

847 ：デフォルトの名無しさん：2006/06/29(木) 13:01:34

精神論なのかよ…orz
大体、割り込みとかなんかでFakeのまま放置されちまったらどうするんだよ。

848 ：デフォルトの名無しさん：2006/06/29(木) 13:39:33

精神衛生上良いというのと精神論は違うだろ。
精神論てのは、「バグがあるのはお前らの努力が足りないからだ」みたいな奴。

849 ：デフォルトの名無しさん：2006/06/29(木) 14:11:08

>>847
はっきり言って、次にどこから始めるか忘れるような奴はこの仕事に向いていない。

850 ：デフォルトの名無しさん：2006/06/29(木) 14:24:05

>>847
TDDは本来ポジティブなフィードバックを積み重ねていくというのがその基本精神だから。
そこに価値を見出せないなら、TDDやる意味ないよ。

851 ：デフォルトの名無しさん：2006/06/29(木) 15:26:08

>>847
Fakeのまま放置されるということは、
正しい実装がされない（バグ）ということ。
なので、Fakeのまま放置されるということはありえない。

バグのままリリースするなら話は別。

852 ：デフォルトの名無しさん：2006/06/29(木) 15:27:54

おっと。
さげ忘れた。

853 ：デフォルトの名無しさん：2006/06/29(木) 17:15:38

「Fakeのままほっとく奴はアホ」とか「ありえない」とかいうのって、
ちょっと楽観的すぎじゃない？
開発者にアホがいて、FakeのままのxUnitテストケースを
混入したままにしてたら、どうするのさ？

これだけだとアレなんで自分なりの解答を示しておくと、
そういうことが起きないように、
コードレビューなりペアプロなりで相互監視するのがよいと思うよ。
レビューかペアプロやってもFakeを見過ごすようなら…
そのときはプロジェクトに関わる以前に教育が必要だぁね。

854 ：デフォルトの名無しさん：2006/06/29(木) 17:22:07

>>853
あったりまえじゃん。
メンバーが「できました」って言ったら、できたって信じるの？

855 ：デフォルトの名無しさん：2006/06/29(木) 20:51:34

Fakeでオールグリーンになってしまうというのは明らかにテストコードが足りない気がする。

856 ：デフォルトの名無しさん：2006/06/29(木) 21:21:53

オールグリーンにならなかったらフェイクじゃないと思うけど。

857 ：デフォルトの名無しさん：2006/06/29(木) 22:07:42

Fakeでグリーンになるのはもちろんだけど、グリーンになったらさらにテストを追加するでしょ。
>>833で上がってる「三角測量」というやつ。

858 ：デフォルトの名無しさん：2006/06/29(木) 22:50:13

>>853
俺が言いたいのは、
Fakeのまま放置されたメソッドを呼び出すときに、
おかしいことが分かるんじゃねーの？ってこと。

でも、たしかにうちの会社はありえそうな気がする。

859 ：デフォルトの名無しさん：2006/06/29(木) 23:04:42

うちはあったぜ。
DB検索処理で、検索により生成されたオブジェクトの数だけassertEqualsして
オブジェクトの中身は全然みてないテストがあった。
単体テストはオールグリーンでカバレッジ90%強（catch節とかあるから100%は目指さない）なのに
後の工程でバグが見つかるという羽目に。

ええ、次からコードレビューするようにしました。

860 ：デフォルトの名無しさん：2006/06/29(木) 23:11:21

ありえNEEEEEEEEEEEEEEEEEE
お前らいったいどんな仕事のやり方してんだ。
レビューしなくてもコードを目で高速スキャンすりゃ、一発でわかるだろうが。
テストコードなら1K数分でスキャンできる。

861 ：デフォルトの名無しさん：2006/06/30(金) 09:20:39

高速スキャンとか言ってる奴って、脳みそ沸いてるのか？
まさかそれでスキルの自慢でもしてるつもり？

Fakeだって、初期ならともかく、それなりの段階に入れば
ぱっと見では、なんかちゃんとやってるように見えるだろ。

>>851
単に動かせば発見されるレベルのバグしか頭にないの？
Fakeだって初期のベタな大嘘実装とは限らん。
考慮すべき比較的レアな条件がまだ未実装という状態だってあるだろう。

862 ：デフォルトの名無しさん：2006/06/30(金) 09:27:28

>>861
よく読め、馬鹿。
高速スキャンするのは、テストされる側じゃなくて、テストする側のコードだ。

863 ：デフォルトの名無しさん：2006/06/30(金) 09:29:56

つうか、レビューもしないしメンバーが「できました」というのを無条件に信じる
なんてありえないから、せめてテストコードをざっと眺めるくらいはしろと
言ってるんだが。
そうすりゃ、どんなテストしてるか把握できるし、アドバイスも早い段階で
できるだろ。

864 ：859：2006/06/30(金) 09:39:19

>>860,863
全くおっしゃるとおり。

でもね…別件でプロジェクト離れてたんだよぅ…
部内の別プロジェクトに関わって6ヶ月、
余所の部署が火吹いてるってんで、強制的に手伝いに行かされて3ヶ月、
まさかその間に、こんなことになってるなんて思わなかったんだよぅ…
JUnit導入時に「テストはこう書きましょう」というガイドラインを作って
配ったのに、無視されてたのは悲しかった…

865 ：デフォルトの名無しさん：2006/06/30(金) 09:39:30

テストコードを見るのもいいが、１秒あたり６行のペースでは、
よくあるＴＤＤのサンプルみたいなシンプルな場合を除いて、
条件漏れが防げるとは思えんな。

それに、テストコードが十分であっても、
実際のコードの方は、Fakeばかりでごまかしてるかも知れん。

866 ：デフォルトの名無しさん：2006/06/30(金) 09:46:22

>>865
お前何が言いたいんだよ。
別に100%の条件漏れが防げるなんて言ってないだろ。

UnitTest完了の必要条件は、ピアレビューレベルのコードレビューが必要とでも
いいたいのか？お前のところはそうすりゃいいじゃん。

867 ：デフォルトの名無しさん：2006/06/30(金) 10:07:22

うちではtargetとなるメソッド名を必ずテストメソッド名に含めるようにさせていて、
メソッド内の実効行数と、そのメソッドが呼ぶ出すメソッドの数、テストメソッドの数、それぞれの
テストメソッド内のassertionの数を一覧表示するプログラムを作って、チェックするようにしてる。
これだけでもかなり違うよ。

868 ：デフォルトの名無しさん：2006/06/30(金) 10:28:45

>>867
それクレクレ

869 ：デフォルトの名無しさん：2006/06/30(金) 11:53:32

>>868
ごめん、無理。
就業時間中に書いちゃったから。

870 ：デフォルトの名無しさん：2006/06/30(金) 19:20:47

>>866
TDDがダメって言ってるんじゃないの？
始めからちゃんとしたテストコードとちゃんとした実コードを書けと。

871 ：デフォルトの名無しさん：2006/06/30(金) 23:16:44

>>870
たとえ不完全でも、やらないよりやったほうがよっぽどましなんだけどな。
6行/sとか言ってるのも意味不明だ。

872 ：デフォルトの名無しさん：2006/07/01(土) 00:22:17

下請けに出す場合みんなどうしてる？
うちの会社の場合元請の開発プロセスはなかなか変えられない立場なのでつらい。

873 ：デフォルトの名無しさん：2006/07/01(土) 03:15:49

>>872
派遣としてくる人以外なら、発注時の条件として開発プロセスの指定をしない限り、
法的に口出しすることが禁じられている。

874 ：デフォルトの名無しさん：2006/07/01(土) 10:42:57

　　　　　　　　　　　　, -'"´ ￣｀丶､_
　　　　　　　　　 ,.∩　　　　　　　　｀ヽ
　　　　　　　　　〃∪'´￣｀二二人＼　ヽ
　　　　　　　　　| ツ´￣￣￣￣´　ヾヽ.　',
　　　　　　　　　|ﾊ　,ニ、　　,. - ､　| | | ｌ |
　　　　　　　　　| ﾊｨハ　　 ,二ヽ. | | | | |　同じ板にコピペするとそのままだけど、
　　　　　　　　　| | |　じ'　　　|トJ〉　 /)} ｌ | 違う板にコピペすると鬼のような怖い顔
　　　　　　　　　|　ﾊ　､'＿,　￣,,　厶ｲ川|　に変わる摩訶不思議な佳子様コピペ。
　　　　　　　　　l　l /＼　　　 ..　イV＼川 |
　　　　　　　　 ,'　l l　,ｲ｀ｌ￣´ ／　　 /ヽl l
　　　　　　　　ｌ　| ｌハ　`メ､　　　〃　ヽヽ､__ノ
　　　　　　　　 l　 ∨ └‐ｲ「ト--ｧ'´　　　ﾊヽ__ノ
　　　　　　　　　ヽ/　　}　 l」」　/　　　　　/ }`ー
　　　　　　　　　〈_ｎ| 八　　　/ /　　　 /ノ
　　　　　　　　　〈二二人ｃ /＼/ /　, ｲ
　　　　　　　　　　/　 /厂／＼__>＜｛＿

875 ：デフォルトの名無しさん：2006/07/01(土) 23:53:41

>>871
やらないよりましなんて当たり前のことは否定してない。
いくらＴＤＤの中で相対的にましであっても、
絶対的にそんなレベルはまったく許されない開発もあるんだよ。
あと、６行/秒って、>>860が「1K数分でスキャン」って自分で言ったんだが。

876 ：デフォルトの名無しさん：2006/07/02(日) 00:09:08

>>865
だから何が言いたいワケ？はっきり言いなよ。
それから1K数分だったら平均5分と考えても3.3行/秒でしょ。
都合のいいように解釈するのは無しね。

877 ：デフォルトの名無しさん：2006/07/02(日) 00:22:33

簡単に「コードレビュー」とか言ってるやつ、ほんとに実務でやってんのかね？
ものの本によると、レビューの平均速度は50～100行/hだぞ。
あるプロジェクトで50Kのソースがあったら、レビューに500～1000時間かかるんだぞ。
しかも、これのべ工数じゃないからな。

俺は100%のコードレビューやるんだが、はっきりいって心身症や鬱病に
なりそうになるぞ。

878 ：877：2006/07/02(日) 00:27:58

一部の大規模プロジェクトで、きっちりとしたWFの中でコードレビューが
位置づけられているのでもなければ、最近のスピードが求められる開発では
とてもじゃないが、完全なコードレビューなんかやってられない。

俺がなんとかやれてるのは、xUnitによって、正しいかどうかはわからんが
全てのテストにpassしたコードという前提があるからレビューできる。

動かしたこともないコードのレビューなんか、考えただけでもぞっとする。

879 ：デフォルトの名無しさん：2006/07/02(日) 00:43:26

それってレビューのレベルが違うんじゃないの？
普通の業務プログラムで、50～100行/hってどんだけ丁寧に見てるんだ？
もちろんそれだけ丁寧に見る必要がある場合もあるが、
平均がその状態なんてことは普通はない（業務PGなら）。

880 ：デフォルトの名無しさん：2006/07/02(日) 00:53:36

50～100行/hって、ありえねぇだろ。
超絶技巧を凝らしたアセンブラならともかく。

881 ：877：2006/07/02(日) 00:58:16

>>879
「レビュー」と一口に言ってもいろんな手法があるからな。
50～100行/hは、ピアレビューの場合だったと思う。もちろん実効行数な。
レビュー準備も、レビュー後の資料作成も含めてだぞ。

俺の場合は、俺個人が前述のようなやり方で見るからもっと速い。

ちなみに俺の経験を語ると、ある「品質、品質」とうるさい所のプロジェクトでは、
およそ100行/hの速度で、参加者5～6人でレビューやってたよ。
つまり1KStepあたり、50～60人時。50Kだと2500～3000人時=14～17人月な。
狂ってる。

882 ：877：2006/07/02(日) 00:59:59

>>880
メンバー全員が信頼できるのなら、もっと早いだろうがな。

ちなみにピアレビューはCMMだかCMMIだかのレベルいくつかに入ってるらしいぞ。
よく知らんが。

883 ：デフォルトの名無しさん：2006/07/02(日) 01:02:13

コードレビューは重要。品質への効果は大きいよ。
だからこそ、ＸＰに至ってはペアプロなんて極端な形で重要視してる。
あと、双方への教育効果も見逃せない。

しかし、平均50～100行/hはよほどヤバいところでもない限りないな。

>>876
（FakeItを含む）TDDによって「まともな」品質が得られる
ってのは、大嘘だって事でしょ。「まとも」の度合いもあるだろうけど。
元々ろくにテストしてないような所では品質は上がるだろうけど。

884 ：877：2006/07/02(日) 01:05:03

まあ何が言いたかったのかというと、コードレビューで品質を担保しようとすると
莫大なコストがかかりかねないってこと。

だからこそ、他のやりかたで品質を担保すべきだと俺は考えていて、TDD、
というか、xUnitを開発プロセスに埋め込むのはとても良いことだと考えてるわけだ。

以上。

885 ：877：2006/07/02(日) 01:10:05

>>883
50～100行/hってのは、最初に書いたとおり「ものの本」によるものだ。
多分「ピアレビュー」って本。まあ、俺の記憶違いかもしれんが。

まあアンチTDDとは話し合っても無駄だから話さないけど。

886 ：デフォルトの名無しさん：2006/07/02(日) 01:12:04

TDDで本質を担保できてるって所って、
もともと別のやり方でもちゃんとできてたところじゃまいか？

887 ：デフォルトの名無しさん：2006/07/02(日) 01:12:39

本質を担保してどうすんだ

888 ：877：2006/07/02(日) 01:16:14

>>886
もちろん俺はTDDやxUnitだけで品質が担保できるなんて考えてないぞ。
コードレビューもやるし、いわゆる単体テスト以降のテストもちゃんとやる。
テストケースのレビューもやる。

ところで別のやり方ってどんなやり方？

889 ：877：2006/07/02(日) 01:23:17

あ、そうそういい忘れてたけど、コードレビューって一回で終わるものじゃないからな。
指摘事項があれば少なくとも２回、ひどいやつだと４回くらい同じとこやるはめになる。

で、いつも思うわけだ。
レビューする工数あるなら、俺様が書いたほうが早い、と。

890 ：デフォルトの名無しさん：2006/07/02(日) 01:30:42

いくら指摘しても教えても説明してもできないときはどうしたらいいんだろな。

結局その部分引き取ってやるしかなくなって、
でも自分でやるだけじゃ意味ないって評価されるんだよな…

891 ：デフォルトの名無しさん：2006/07/02(日) 01:34:00

>>883
>TDDによって「まともな」品質が得られるってのは、大嘘
ってことだけを言いたいんでしょ？
どんなにFUDかましても、実際にTDDでメリットを享受してる人たちがいることは
くつがえせないよ。

892 ：デフォルトの名無しさん：2006/07/02(日) 01:45:05

単にxUnit使うよりTDDがよいってのは、どういう理由？

＞実際にTDDでメリットを享受してる人たちがいる
そのメリットが品質、ということなら、
その大部分は今までろくに単体テストしてなかっただけだろ。

893 ：デフォルトの名無しさん：2006/07/02(日) 01:46:52

xUnitのおかげで、継続的インテグレーションや、頻繁なリグレッションテストが
実現できるというのに、品質向上に何も寄与しないと言う奴はどうしたものだろう。
アンチには何を言っても駄目なのか。

894 ：デフォルトの名無しさん：2006/07/02(日) 01:49:27

>>892
ということにしたい症候群。

終了。

895 ：デフォルトの名無しさん：2006/07/02(日) 01:53:38

>>892
xUnitとTDDを分けて議論したいの？

896 ：895：2006/07/02(日) 02:01:28

はっきり言って、どの開発プロセスが優れているかなんて議論は、それこそ
水掛け論になりがちだからね。多分その議論には何のメリットもないよ。お互いに。
いま終わったこのプロジェクトを、違ったプロセスでやったらどうだったろう、
なんてことは出来ないからね。
そういう意味では、デマルコの『デッドライン』は、読み物として面白かった。

それに、「品質」という言葉も曖昧だしね。お互い品質というものをどう捉えるかで
全く食い違った議論になりがち。
例えば俺は、TDDによる自然なリファクタリングによって、保守性が向上すると
考えてるわけだが、ただこれだけでも「そうは思わない」とばっさり切り捨てられる
可能性がある。「保守性って品質か？」などと言い出す奴もいるかもしれないしね。

897 ：デフォルトの名無しさん：2006/07/02(日) 02:05:02

>>895
そう。xUnitはツール、TDDは開発のやり方。
>>893は馬鹿。「何も」とか勝手に言ってもいない事言って逃げ道作ってるし。
>>894は今までろくに単体テストしてなかった奴。

898 ：895：2006/07/02(日) 02:08:23

>>897
なるほど、わかった。アンチTDDってことだね。
じゃ>>896の理由で、俺は開発プロセスの優劣の議論には意味がないと思ってるから
これで退散する。

899 ：895：2006/07/02(日) 02:14:16

一言付け加えておくと、「単体テスト」という言葉にも、個々人で意味あいが
違ったりするからね。Unit Testは単体テストに含まれないって考える人も
いたりするし。

このての議論は不毛になりがちなんだよなぁ。
お互い、言葉の定義を自分こそが正しいと信じてたりするから。

900 ：デフォルトの名無しさん：2006/07/02(日) 02:21:24

ただ単に
>絶対的にそんなレベルはまったく許されない開発もあるんだよ。
という自慢？がしたいだけ。相手にするだけ無駄

901 ：デフォルトの名無しさん：2006/07/02(日) 02:27:40

897のところは、ほぼコードと一対一な詳細設計書を書いて、フローチャートなんかも
書いちゃったりして、「iを0で初期化する」なんていう箱を一生懸命書いている、
と想像してみる。

902 ：デフォルトの名無しさん：2006/07/02(日) 10:15:59

877ってまた例のいつもの奴だろ。
まともに相手するなや

903 ：デフォルトの名無しさん：2006/07/02(日) 11:00:34

テスト自体もそうだけど、テスト項目の抽出ってみんなのとこの開発ではどうやってるの？
どんな設計書（詳細設計、プログラム設計）を作って、そこからどうやって抽出してるのか気になる。

904 ：デフォルトの名無しさん：2006/07/02(日) 11:33:45

>>902
いつもの奴って、どの「いつもの奴」？
まともなこと言ってると思うけど。

905 ：デフォルトの名無しさん：2006/07/02(日) 11:37:37

>>903
詳細設計書とプログラム設計書はどう違う？
ちなみにうちでは、「最終的には経験と勘」ということになっとります。
その「経験と勘」以外の部分は、常套手段がありますので、テスト関連書籍をどうぞ。

906 ：デフォルトの名無しさん：2006/07/02(日) 11:56:06

>>903
あー、世の中ってこんなレベルが普通なんだろうなあ

907 ：デフォルトの名無しさん：2006/07/02(日) 12:00:24

開発言語をJavaを例として説明すると、詳細設計は１つの機能のクラス構造とクラスのインタフェースを設計。
プログラム設計は各メソッドの実装ロジック（分岐だとか繰り返し）という感じ。

というツモリで書いたけど、やっぱ設計書の定義も会社やプロジェクトごとにまちまちなんだよね。

＞「最終的には経験と勘」
そう思うけど、多人数でやるとどうしても抽出する観点、抽出する判断基準がある程度
必要になるよね。
何年も一緒にやっている仲間同士なら別として、いろんな会社の人間が集まって開発を進める場合、
基準がないとテストのレベルもバラバラになってしまう。
あと、そういった基準がないとお客さんにテスト計画を説明するのも難しくなってしまう。
自分はまだ直接説明する立場じゃないけど、上の人間（請元）からはいつもしつこく言われる。

908 ：905：2006/07/02(日) 12:26:33

>>907
ひょっとしてttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?ST=itpro_print
のような情報を求めてるのかな？＠ITにも似たようなページがたくさんある。
「具体的なテストケース例」が知りたいなら、やはりテスト関連書籍をお勧めします。
とてもここでは書ききれない。（し、書くつもりも無い）

「最終的には経験と勘」というのは、全てのテストケース抽出を経験と勘でやるということ
ではなくて、上記のような基本的な部分を越えたところの話です。

909 ：905：2006/07/02(日) 12:32:24

ちなみにうちのやり方をざっと説明すると、V字モデルに沿ったような仕様書を作り、
時を同じくして対応するテスト設計書を書きます。うちでは、分岐や繰り返しレベル
まで記述した設計書は書きません。修正コストが膨大になるので。

どのようなテストをどのレベルまで、どのように行うかを、プロジェクトを超えて使える
ような「テスト観点書」というものにまとめていて、各プロジェクトではそれをカスタマイズ
するという感じでしょうか。
なんか、全然参考にならない気がしますが……。

910 ：デフォルトの名無しさん：2006/07/08(土) 21:34:38

ある関数の仕様変更でテストを全部書き直した。。めんどい・・・

911 ：686：2006/07/09(日) 19:01:29

>>910
なんだそりゃ・・・
よっぽどタコな設計してんだね。

912 ：デフォルトの名無しさん：2006/07/10(月) 01:50:31

>910
"ある関数"を呼び出すテストを書き直したって事？

それとも"ある関数"がテストに影響する何かなの？

913 ：デフォルトの名無しさん：2006/07/10(月) 01:58:31

>>912
あのさー、それ知ってどうしたいわけ？
ただの愚痴なんだろうから、スルーしろよ。

914 ：デフォルトの名無しさん：2006/07/10(月) 02:55:12

終了

915 ：きっず８：2006/07/16(日) 19:50:04

ですやーーーーーー

916 ：デフォルトの名無しさん：2006/07/17(月) 01:14:00

>>911
関数の仕様が変ってテストを書き直さずにすむ方法を問いたい。
ま、もともと仕様をきちんと網羅したテストを書いてなければ楽だろうけどねｗ

917 ：デフォルトの名無しさん：2006/07/17(月) 01:28:21

「テストを全部」ってところがタコなんだろ。

918 ：デフォルトの名無しさん：2006/07/19(水) 00:13:39

>>916
>>915の言うとおり・・・
全部ってのはまぁネタだろ？

まぁ俺の今いるところはあんたんとこより
はるかにやばい状態だが・・・
タコでもいいからまともにテスト仕様書書いてほしい。

919 ：デフォルトの名無しさん：2006/07/20(木) 02:28:51

> >>915の言うとおり・・・

・・・言うとおり、何？

920 ：デフォルトの名無しさん：2006/07/21(金) 00:06:27

>>919
すまん、アンカーが917だった。

単体テストぐらい書いてから画面動かさないと
どうにもならんですよって言ったら
そんな時間ないからやめてくれとか言われた。
クラサバ時代のファットクライアントをWEBアプリにそのまま移植とか
基地外みたいなことやってんのに。

921 ：デフォルトの名無しさん：2006/07/22(土) 13:34:56

単体の次テスト時のデバッグの時間が確実に存在する、かつ長期化する
ことによってどこかに金が流れる仕組みなんだろ？
(テスタを別途雇ってるとか)

922 ：デフォルトの名無しさん：2006/07/23(日) 01:01:51

日本語で頼む

923 ：デフォルトの名無しさん：2006/07/29(土) 00:49:44

.Net用のVirtual Mock Objects使えるテストツールってありますか？
EclipseのdjUnitプラグインみたいな。

924 ：デフォルトの名無しさん：2006/10/12(木) 23:50:48

　　　　　　　　　　　　　　　　　　　　　　　　　　　　やつを追う前に言っておくッ！
　　　　　　　　　　　　　　　　　　　　おれは今自分のコーディングをほんのちょっぴりだが体験した
　　　　　　　　　　　　　　　　　　い…いや…体験したというよりはまったく理解を超えていたのだが……
　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　　　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま今　起こった事を話すぜ！
　　　　　 |i i|　　 }!　}} /／|
　　　　　　 |l､{　　j}　/,,ｨ//｜　　　　　　『おれは某マイナー言語で手抜き用のライブラリを書こうと思ったら
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　いつのまにか別の言語のﾃｽﾃｨﾝｸﾞﾌﾚｰﾑﾜｰｸを移植していた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　　　／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも何をしているのかわからなかった…
　　　　,ﾞ　／ )ヽ iLﾚ　u' |　| ヾｌﾄﾊ〉
　　　 |／_／　ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼　　　　xUnitだとかTDDだとか
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　　　　ｲ　もっと恐ろしいテスト狂の片鱗を味わったぜ…

925 ：デフォルトの名無しさん：2006/10/13(金) 11:37:05

　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　　　 (.＿＿_,,,... -ｧァﾌ|　
　　　　　 |i i|　　 }!　}} /／|
　　　　　　 |l､{　　j}　/,,ｨ//｜　　
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　ありのまま　
　　　　　　　 |ﾘ⌒ }　 ,⌒　_,!V,ﾊ | 今起こった事を話す気なんて
　　　　／´f（●）ﾙ（ ●） , ﾀ人　　まったくないおｗｗｗｗｗ！
　　　　 /' 　ヾ|⌒ Lﾚ´⌒`/ |<ヽﾄiゝ　
　　　　,ﾞ　／ )ヽ（_人__） ' |　| ヾｌﾄﾊ〉
　　　 |／_／　ﾊﾉr┬ﾉ　'／:} 　V:::::ヽ
　　　 /／二二二7ー' .／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}

926 ：デフォルトの名無しさん：2006/10/28(土) 20:16:22

test

927 ：あま：2006/10/29(日) 11:27:30

初めてだけど荒らしまーす。

928 ：あま：2006/10/29(日) 11:30:33

初めてだけど荒らしまーす。

929 ：デフォルトの名無しさん：2006/10/30(月) 04:24:45

BDS2006のDUnitが使いにくいので、テストランナー自作しているのは俺だけ？

930 ：デフォルトの名無しさん：2006/11/20(月) 00:27:09

JUnit4.2ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!
http://sourceforge.net/project/showfiles.php?group_id=15278

931 ：デフォルトの名無しさん：2006/11/27(月) 17:04:01

>>925
お前がガルバルディβに見えたよ。

932 ：デフォルトの名無しさん：2006/11/30(木) 23:56:44

IBM コード品質を追求する: JUnit 4 対 TestNG - Japan
ttp://www-06.ibm.com/jp/developerworks/java/library/j-cq08296/index.shtml

933 ：デフォルトの名無しさん：2006/12/01(金) 22:09:49

>>932
> 失敗したテストを再実行できる機能は特に大規模なテスト・スイートで役立ちますが、
> これは TestNG にしかない機能です。

JUnitじゃなくてNUnitの話なんだけど、
この機能が無いのが不満で独自のテストフレームワーク作っちゃったよ。

934 ：デフォルトの名無しさん：2006/12/08(金) 14:50:38

コードに加えた修正が既存の機能を壊してないという保証が無い限り、失敗した
テストだけ再実行しても何の信頼性も無いよね？
コードを修正したらテスト全体を再実行すべきじゃないのかなぁ。

935 ：デフォルトの名無しさん：2006/12/08(金) 15:46:11

デバッグ作業中、ちょっと書き直すたびに全テスト再実行してたら鬱になるでしょ、規模にもよるけど。
一通りデバッグして、失敗したテストが全部通ってから、改めて全テスト再実行って手順で使うんだと思うけど。

936 ：デフォルトの名無しさん：2006/12/11(月) 13:31:28

.NETでテストをグループ化管理できるツールってないですかね?
VSTSのDevelopperについてたTestツール使ったけれど、クラス単位とかではグループ化とか出来るが、自分である機能がらみの物についてのテストとかを階層化してグルーピングするのはできないっぽい・・・(´・ω・｀)

937 ：デフォルトの名無しさん：2006/12/12(火) 14:17:03

>>935
それならもうちっとテストプロジェクトを分割すべき。
全テストと単機能テストの間に機能グループ毎のデグレードチェック用プロジェクト
を作らないと。

938 ：デフォルトの名無しさん：2007/02/14(水) 00:02:41

毎日自動でテストを実行して結果をグラフ化してくれるソフトってない？
名前をつけつとしたら「継続的テストツール」

939 ：デフォルトの名無しさん：2007/02/14(水) 00:09:19

>>938
1.Windowsのタスクで毎日自動でテストを実行させる。
2.結果をcsvで出力。
3.エクセルのマクロで自動グラフ化。

あるいは

1.Windowsのタスクで毎日自動でテストを実行させる。
2.結果をxmlで出力。
3.xsltで結果をグラフ表示。

好きな方を選べ。

940 ：デフォルトの名無しさん：2007/02/14(水) 00:12:54

なぜWindows限定？

941 ：デフォルトの名無しさん：2007/02/14(水) 00:21:18

Windowsしか使ってないヤツは沢山いても、
逆にWindowsだけは一切使ってないヤツなんて極少数派だから。

てか、エクセルはテストの強い味方だぞ。そのエクセルが優遇されている
Windows環境が前提の話をしても、ここはテストに関するスレなんだから
さして差し支えなかろ？

942 ：デフォルトの名無しさん：2007/02/14(水) 00:23:18

>>938
CruiseControlっつうのがあるらしい。Java版と、.Net版のCruiseControl.NETってのがある。使ったことはないけど。
うちはAnt使って、単体テストとカバレッジ測定、それとレポート作成まで自動でやってるよ。
build.xmlゴリゴリ書いたけど、一度書けば割と便利。

943 ：デフォルトの名無しさん：2007/02/14(水) 00:28:18

っちゅうか、>>939はWiondowsを使う方法しか知らないんだろ。

944 ：デフォルトの名無しさん：2007/02/14(水) 00:32:46

>>943
いや、俺はWiondowsすら知らない素人だよ。

945 ：デフォルトの名無しさん：2007/02/14(水) 00:34:26

>>938
テスト結果のグラフ化ってどこまでやりたいの？これくらいで十分なら
http://www.atmarkit.co.jp/farc/rensai/open04/open04c.html
http://hccweb1.bai.ne.jp/tsune-1/NUnitTestResult.html
単体テストツールのレポート機能だけでなんとかなるけど。
後はそれを定時に起動するだけだ。そこはWindowsのタスクなりLinuxのcronなりで好きにして。

946 ：938：2007/02/14(水) 21:26:48

みなさんありがとう。
でもLinuxでC++なんです。

> うちはAnt使って、単体テストとカバレッジ測定、それとレポート作成まで自動でやってるよ。

やりたいのはそういう事なんですがAntでC++のユニットテストはできるでしょうか？
あとCruiseControlも今調べています

947 ：デフォルトの名無しさん：2007/02/14(水) 22:02:08

テストの自動化の前に、することがいっぱいあるような気がする。
C++かー。CppUnitってのがあるみたいだけど、使ったことはない。

948 ：デフォルトの名無しさん：2007/02/20(火) 17:37:46

boost::testとか。

949 ：デフォルトの名無しさん：2007/07/21(土) 20:02:03

静的解析ツール（ソースコードを入力に）
って
やっぱりフロントエンドはコンパイラぽいことやってるのかな？

950 ：デフォルトの名無しさん：2007/07/21(土) 22:45:45

フロントエンドが何を指すのか、コンパイラっぽいっことことってなにを
言ってるのかよくわからんけど、構文解析あたりまではやらないと解析で
きないだろうし、PG-Relief あたりだと簡単なフロー解析ぐらいはやって
るんじゃないかな。

951 ：デフォルトの名無しさん：2007/07/21(土) 23:11:16

FindBugsとかその系統の話か？
大雑把に構文解析と同時に悪いイデオムとのマッチングをしているね
気になるならばソース読むのが一番だが

952 ：デフォルトの名無しさん：2007/08/06(月) 22:48:12

誰もいないｒｙ

privateのテストなんて
テストのプリプロセス時に
publicへしてしまえ。

953 ：デフォルトの名無しさん：2007/08/09(木) 03:28:37

privateのテストなんて
外部からテストする意味がわからんw

954 ：デフォルトの名無しさん：2007/08/09(木) 18:23:51

ファインド虫ズはバイトコード解析じゃね？

955 ：デフォルトの名無しさん：2007/08/22(水) 23:44:59

232

956 ：デフォルトの名無しさん：2007/12/11(火) 10:46:59

あのさ、テスト用のフレームワークは使わずに、
各クラスにテスト用の静的メンバ
static bool MyClass::Test(); を用意して、
とりあえず main 関数の先頭で assert(MyClass::Test());
ってチェックができるようにしてるんだけど、
たまに Test() の呼び出しを忘れるんだ。

プログラム中で使ってるクラスは50ほどあるんだけど、
なんとか忘れずにすべてのクラスの Test() を
呼び出すように強制する方法ってないかな？

957 ：デフォルトの名無しさん：2007/12/11(火) 11:56:29

>>956
それ、何時間かけて解決するつもり？

958 ：デフォルトの名無しさん：2007/12/11(火) 23:29:43

強制するうまい方法は思いつかないけど、すべて呼ばれているかどうかをチェックするだけなら簡単じゃないかな。

$ grep 'assert¥(.*Test¥); *.java | wc -l # 呼び出している行の数
$ grep 'static bool .*::Test¥(¥)' *.java | wc -l # 定義している行の数
これが等しいかどうかをチェックする。

959 ：：2008/01/10(木) 23:37:55

960 ：デフォルトの名無しさん：2008/01/11(金) 04:27:47

リフレクション使って、あるパッケージ内の全てのクラスについて
static bool Test() があればそれを呼ぶってコードを書けばいいんじゃない。

961 ：デフォルトの名無しさん：2008/01/11(金) 10:46:35

>>956
phpやrubyならglob使って特定のディレクトリにあってファイル名にTestがついてるの
全部requireとかでいける。
Cとかなら自分でスクリプト書いて、テストスィート自動生成。

962 ：デフォルトの名無しさん：2008/02/09(土) 10:36:48

TestDriven.NETをアップデート(ver.2.12)したら
ウンともスンともいわなくなっちゃいました。
(テスト時のビルドすら、し始めてくれない)

しょうがないので、今までのバージョンに戻してみると(2.7)
普通に動いてくれます。

ググってみても、同様現象に関しての記事はを見あたらないのですが
同じような方、または解決法などご存じの方がいらしたらお教えください。

ちなみに環境は Vista、VC#2005EE です。

963 ：デフォルトの名無しさん：2008/03/29(土) 03:13:51

>>962
テスト駆動開発なんて、アテにならないという証だなｗ

テスト駆動開発って、ホントに糞糞レベルの品質は避ける事が出来る、というだけで、
よい品質のソフトを作れる方法論じゃないよな。

まともな現場なら、モジュールとして動き始める頃には、
純粋なコーディングミスなんてほとんど出なくなって、
インタフェース誤解とか仕様自体のミスとかだけ。

テストコードなんて、現実には王道パターンひとつかふたつと、
「テストしやすい」妙なパターンいくつか、程度。まともな現場で起きる現実のバグは、
テスト対象オブジェクトが持つオブジェクトが持つオブジェクトが妙なパターンとか、
とてもテストコードなんて書いてらんないようなのが条件。

モジュールとして動き始めると純粋なコーディングミスがダバダバでるような、
「動きました出来ました」レベルの現場なら、品質は大きく向上するけど、それだけ。

964 ：デフォルトの名無しさん：2008/03/29(土) 03:58:52

レス乞食乙

965 ：デフォルトの名無しさん：2008/03/29(土) 06:07:13

業務システムなんて、ぶっちゃけバグの山だからな。
そのシステムで動いてる分には発生条件が起きないってだけの不発弾が大量に眠ってる。

稼働済みシステムのうちの、フレームワーク(として使える)部分を抜き出して、
他のシステムに適用したら、新たなバグが出るわ出るわ。元のシステムは安定してるのに。

出ないバグはバグじゃない。業務システムのソース品質なんて中品質でいいんだよ。

966 ：デフォルトの名無しさん：2008/03/29(土) 16:34:00

>>963
テスト駆動開発をまったく理解してないいい例。

> テストコードなんて、現実には王道パターンひとつかふたつと、
> 「テストしやすい」妙なパターンいくつか、程度。

単に、君の能力がそこまでと言うこと。(w

967 ：デフォルトの名無しさん：2008/04/09(水) 21:05:11

Nunitでテスト結果の詳細を出力する方法はないのでしょうか？
(成功・失敗にかかわらず、Assertごとにメッセージを出力など。)

そのまま単体テスト結果表にしたいので。。。

968 ：デフォルトの名無しさん：2008/04/10(木) 12:31:24

>>966
>>963がTDDの理解どう足りないのか、
どういうやり方なら>>963のいうﾚﾍﾞﾙ以上がTDDで実現出来るのか？
それがなければ、反論になってない。

969 ：デフォルトの名無しさん：2008/04/10(木) 13:06:08

>>968
で、君はTDDの本読んだことあんの？