1001コメント404KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001１

NGNG

プログラムにテストはつきもの
xUnitの効率的なテストコードの書き方や
その他テストツールについて語りましょう。

0002デフォルトの名無しさん

NGNG

　　　(V)∧_∧(V)
　　　　ヽ(･ω･)ノ　　ﾌｫｯﾌｫｯﾌｫｯ
.　　　　/　 /
　　　　ノ￣ゝ

.　　　　　　　　　 (V)∧_∧(V)
　　　　　　　　　　ヽ( 　　)ノ　　ﾌｫｯﾌｫｯﾌｫｯﾌｫｯ
.　　　　　　　　　　　/　 /
　　　　　　　.......... ノ￣ゝ

0003デフォルトの名無しさん

NGNG

デバックツールってあんのかなあ・・・

0004デフォルトの名無しさん

NGNG

そんなことよりDoxygenスレ作ってくれよ>>1

0005 ◆MAKNgZ1Q

NGNG

>>3
あるよ☆

$ruby -wc script.rb
Syntax OK

ほらね☆

0006デフォルトの名無しさん

NGNG

doxygenのスレあったけど落ちたな

0007デフォルトの名無しさん

NGNG

purifyとかboundary chekerとかメモリーリークをチェックする糞たけー
ソフトがあるが、どうよ？

0008デフォルトの名無しさん

NGNG

JUnitとか
http://member.nifty.ne.jp/masarl/article/junit.html
が詳しい。

0009デフォルトの名無しさん

NGNG

質問です。
テストツールって何ですか？

0010デフォルトの名無しさん

NGNG

>>9
2chにtestと書き込むソフトのことです。

0011デフォルトの名無しさん

NGNG

test

0012デフォルトの名無しさん

NGNG

IEもテストツールなんですね

0013デフォルトの名無しさん

NGNG

IEはtestツールではなくtextツールです。

0014デフォルトの名無しさん

NGNG

monazillaスレで書きこみテストしてる厨へのあてつけか？

0015デフォルトの名無しさん

NGNG

JMeterなどの負荷テストツールを使って
Yahooなどを相手に試したらダメですか？

0016デフォルトの名無しさん

NGNG

　　　|
　　　|_-)　ﾀﾞﾚﾓｲﾅｲ･･ﾋｷｺﾓﾙﾅﾗｲﾏﾉｳﾁ
　　　|⊂
　　　|

　　　|
　　　|
　　　|　　　　　 (-＿-)　…
　　　|　　　　　 (∩∩)

　　　|
　　　|
　　　|　　　　　 (-＿-)　…
　　　|　　　　　 (∩∩)

0017　

NGNG

>>15
やってみてください。

0018デフォルトの名無しさん

NGNG

自己責任でね
http://jove.prohosting.com/~f1pics/?ThroatCut
http://jove.prohosting.com/~f1pics/?VidCap017a

0019デフォルトの名無しさん

NGNG

おまいら、xUnit使ってますか？

0020デフォルトの名無しさん

NGNG

>>18
http://jove.prohosting.com/~f1pics/?ThroatCut →首切り動画(音声アリ)
http://jove.prohosting.com/~f1pics/?VidCap017a →首切り動画(音声アリ)

苦手なヤシは見るべからず。

0021デフォルトの名無しさん

NGNG

こっちじゃ駄目なの？
eXtreme Programming Part3
http://pc3.2ch.net/test/read.cgi/tech/1023709462/

･･･と思ったが微妙なｽﾚになっとる。
ここって主にxUnitとリファクタリングについて
語るｽﾚだったよなぁ･･･。

0022デフォルトの名無しさん

NGNG

HSP saiko-!

0023デフォルトの名無しさん

NGNG

>>15
プッ

0024デフォルトの名無しさん

NGNG

>>15
それがなにか?

0025デフォルトの名無しさん

NGNG

>>20
おい！見たいぞ気になるぞｺﾞﾙｧ

0026デフォルトの名無しさん

NGNG

0027デフォルトの名無しさん

NGNG

0028デフォルトの名無しさん

NGNG

0029デフォルトの名無しさん

NGNG

CppUnitとかつかってる人すくないのかなぁ？

0030IP記録実験

NGNG

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を提出することがある。

0031デフォルトの名無しさん

NGNG

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

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

0032デフォルトの名無しさん

NGNG

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

0033デフォルトの名無しさん

NGNG

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

0034デフォルトの名無しさん

NGNG

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

0035IP記録実験

NGNG

0036デフォルトの名無しさん

NGNG

速い

0037デフォルトの名無しさん

NGNG

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

0038デフォルトの名無しさん

NGNG

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

0039デフォルトの名無しさん

NGNG

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

0040デフォルトの名無しさん

NGNG

======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
────────────────────────────

0041デフォルトの名無しさん

NGNG

>713　ほう・・・

0042デフォルトの名無しさん

NGNG

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

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

0043デフォルトの名無しさん

NGNG

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

0044デフォルトの名無しさん

NGNG

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

0045デフォルトの名無しさん

NGNG

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

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

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

0046デフォルトの名無しさん

NGNG

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

　　　　　　　　　

0047デフォルトの名無しさん

NGNG

>>475　ﾜﾛﾀ

0048デフォルトの名無しさん

NGNG

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

0049デフォルトの名無しさん

NGNG

お疲れ様です

0050デフォルトの名無しさん

NGNG

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

0051デフォルトの名無しさん

NGNG

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

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

0052デフォルトの名無しさん

NGNG

マン喫からテスト

0053デフォルトの名無しさん

NGNG

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

0054デフォルトの名無しさん

NGNG

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

0055デフォルトの名無しさん

NGNG

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

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

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

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

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

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

んじゃ！

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

0056デフォルトの名無しさん

NGNG

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

0057デフォルトの名無しさん

NGNG

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

0058デフォルトの名無しさん

NGNG

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

0059デフォルトの名無しさん

NGNG

うざ

0060デフォルトの名無しさん

NGNG

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

0061デフォルトの名無しさん

NGNG

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

0062デフォルトの名無しさん

NGNG

トリップ公開時期

0063デフォルトの名無しさん

NGNG

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

0064デフォルトの名無しさん

NGNG

777

0065デフォルトの名無しさん

NGNG

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

0066デフォルトの名無しさん

NGNG

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

0067デフォルトの名無しさん

NGNG

エｽﾊﾟｰ伊東

0068デフォルトの名無しさん

NGNG

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

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

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

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

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

0069デフォルトの名無しさん

NGNG

引き続き　gamble 行きます。

0070山崎渉

NGNG

（＾＾）

0071デフォルトの名無しさん

NGNG

つまんね

0072山崎渉

NGNG

（＾＾）

0073山崎渉

NGNG

（＾＾）

0074デフォルトの名無しさん

NGNG

ぷららADSLテスト。

0075デフォルトの名無しさん

NGNG

age

0076デフォルトの名無しさん

NGNG

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

0077デフォルトの名無しさん

NGNG

CppUnit

0078デフォルトの名無しさん

NGNG

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

0079山崎渉

NGNG

（＾＾）

0080山崎渉

NGNG

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

0081デフォルトの名無しさん

NGNG

..\\\\\\\\\

0082デフォルトの名無しさん

NGNG

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

0083デフォルトの名無しさん

NGNG

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

0084山崎渉

NGNG

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

0085デフォルトの名無しさん

NGNG

>713 ほう・・・

0086デフォルトの名無しさん

NGNG

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

0087デフォルトの名無しさん

NGNG

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

0088山崎渉

NGNG

（＾＾）

0089山崎渉

NGNG

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

0090デフォルトの名無しさん

NGNG

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

0091デフォルトの名無しさん

NGNG

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

0092デフォルトの名無しさん

NGNG

0093デフォルトの名無しさん

NGNG

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

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

0094デフォルトの名無しさん

NGNG

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

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

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

0095デフォルトの名無しさん

NGNG

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

0096デフォルトの名無しさん

NGNG

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

0097デフォルトの名無しさん

NGNG

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

0098デフォルトの名無しさん

NGNG

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

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

0099デフォルトの名無しさん

NGNG

test

0100100

NGNG

100

0101(゜Jし゜)

NGNG

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

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

0102デフォルトの名無しさん

NGNG

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

0103デフォルトの名無しさん

NGNG

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

0104デフォルトの名無しさん

NGNG

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

ttp://www.opensourcetesting.org/

0105デフォルトの名無しさん

NGNG

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

0106デフォルトの名無しさん

NGNG

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

0107デフォルトの名無しさん

NGNG

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

0108デフォルトの名無しさん

NGNG

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

0109デフォルトの名無しさん

NGNG

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

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

0110デフォルトの名無しさん

NGNG

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

0111デフォルトの名無しさん

NGNG

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

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

0112デフォルトの名無しさん

NGNG

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

0113デフォルトの名無しさん

NGNG

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

0114デフォルトの名無しさん

NGNG

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

0115デフォルトの名無しさん

NGNG

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

0116デフォルトの名無しさん

NGNG

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

0117デフォルトの名無しさん

NGNG

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

0118デフォルトの名無しさん

NGNG

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

0119デフォルトの名無しさん

NGNG

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

これって妥当ですか？

0120デフォルトの名無しさん

NGNG

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

0121デフォルトの名無しさん

NGNG

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

0122デフォルトの名無しさん

NGNG

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

0123デフォルトの名無しさん

NGNG

↓通り一遍な回答

0124デフォルトの名無しさん

NGNG

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

0125デフォルトの名無しさん

NGNG

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

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

どうでしょうか？

0126デフォルトの名無しさん

NGNG

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

0127デフォルトの名無しさん

NGNG

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

0128デフォルトの名無しさん

NGNG

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

0129デフォルトの名無しさん

NGNG

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

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

0130デフォルトの名無しさん

NGNG

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

0131デフォルトの名無しさん

NGNG

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

0132デフォルトの名無しさん

NGNG

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

てまえら作れよ

0133マイク ◆yrBrqfF1Ew

NGNG

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

0134デフォルトの名無しさん

NGNG

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

0135デフォルトの名無しさん

NGNG

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

0136デフォルトの名無しさん

NGNG

あった

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

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

0137デフォルトの名無しさん

NGNG

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

0138デフォルトの名無しさん

NGNG

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

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

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

0139デフォルトの名無しさん

NGNG

それでいんでね？

0140デフォルトの名無しさん

NGNG

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

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

だな

0141デフォルトの名無しさん

NGNG

>>139　さん
>>140　さん

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

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

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

0142デフォルトの名無しさん

NGNG

>>141
DBはDBUnitで

0143デフォルトの名無しさん

NGNG

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

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

0144デフォルトの名無しさん

NGNG

jMock 使ってる人います？

0145デフォルトの名無しさん

NGNG

TestNGってどうなの？

0146デフォルトの名無しさん

NGNG

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 が作れないみたいなんですが、回避策どなたかわかりますか？

0147デフォルトの名無しさん

05/01/19 01:34:28

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

0148デフォルトの名無しさん

05/01/23 23:00:00

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

0149デフォルトの名無しさん

05/01/24 13:01:03

>>147
俺も興味ある。

0150デフォルトの名無しさん

05/01/25 09:37:54

あげてみるテスト

0151デフォルトの名無しさん

05/01/25 12:00:27

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

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

0152デフォルトの名無しさん

05/01/25 15:11:37

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

0153デフォルトの名無しさん

05/01/25 15:12:40

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

0154デフォルトの名無しさん

05/01/25 17:58:07

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

0155デフォルトの名無しさん

05/01/25 19:07:39

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

0156デフォルトの名無しさん

05/01/25 19:11:38

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

0157デフォルトの名無しさん

05/01/25 19:19:54

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

0158デフォルトの名無しさん

05/01/25 19:29:25

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

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

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

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

0159デフォルトの名無しさん

05/01/25 19:34:14

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

0160デフォルトの名無しさん

05/01/25 20:08:12

>>159
>>158

0161159

05/01/25 20:21:47

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

0162デフォルトの名無しさん

05/01/25 20:22:05

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

0163デフォルトの名無しさん

05/01/25 21:21:11

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

0164デフォルトの名無しさん

05/01/29 18:05:57

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

0165テストファーストしてますか？

05/02/14 23:19:31

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

0166デフォルトの名無しさん

05/02/15 00:58:18

>きちんと分析してから

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

0167デフォルトの名無しさん

05/02/15 01:24:34

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

0168デフォルトの名無しさん

05/02/22 15:24:58

struts test case for junit

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

0169デフォルトの名無しさん

05/02/25 22:21:48

これﾜﾗﾀ。

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

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

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

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

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

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

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

0170デフォルトの名無しさん

05/03/06 07:41:55

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

0171デフォルトの名無しさん

05/03/07 02:31:08

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

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

0172デフォルトの名無しさん

2005/03/22(火) 20:52:31

solexってどうですか？

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

0173デフォルトの名無しさん

2005/03/30(水) 18:59:47

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

0174デフォルトの名無しさん

2005/03/31(木) 02:57:59

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

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

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

0175デフォルトの名無しさん

2005/04/28(木) 21:09:39

>>8 で紹介されてる

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

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

0176メモ

2005/05/02(月) 23:23:16

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

0177デフォルトの名無しさん

2005/05/24(火) 21:57:12

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

0178デフォルトの名無しさん

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です。快適。

0179177

2005/05/25(水) 14:59:59

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

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

0180178

2005/05/25(水) 16:42:13

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

0181177

2005/05/25(水) 20:16:58

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

0182デフォルトの名無しさん

2005/05/27(金) 22:27:10

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

0183デフォルトの名無しさん

2005/05/28(土) 06:46:23

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

0184デフォルトの名無しさん

2005/05/28(土) 18:05:05

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

0185デフォルトの名無しさん

2005/05/28(土) 18:11:58

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

0186183

2005/05/28(土) 22:26:52

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

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

0187デフォルトの名無しさん

2005/05/29(日) 09:49:01

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

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

0188デフォルトの名無しさん

2005/06/10(金) 01:16:30

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

0189デフォルトの名無しさん

2005/06/10(金) 03:13:30

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

0190デフォルトの名無しさん

2005/06/10(金) 11:09:18

そうとは限らない。

0191デフォルトの名無しさん

2005/06/10(金) 13:30:14

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

0192デフォルトの名無しさん

2005/06/10(金) 21:10:01

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

0193デフォルトの名無しさん

2005/06/10(金) 23:13:52

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

0194デフォルトの名無しさん

2005/06/11(土) 01:17:00

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

0195デフォルトの名無しさん

2005/06/11(土) 02:09:50

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

0196デフォルトの名無しさん

2005/06/11(土) 02:39:13

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

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

0197デフォルトの名無しさん

2005/06/11(土) 04:41:18

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

0198197

2005/06/11(土) 04:50:27

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

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

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

0199デフォルトの名無しさん

2005/06/11(土) 11:33:36

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

0200197

2005/06/11(土) 14:14:05

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

0201デフォルトの名無しさん

2005/06/11(土) 18:11:03

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

0202デフォルトの名無しさん

2005/06/11(土) 21:44:17

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

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

0203デフォルトの名無しさん

2005/06/12(日) 01:39:07

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

0204デフォルトの名無しさん

2005/06/12(日) 04:04:44

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

0205デフォルトの名無しさん

2005/06/17(金) 13:17:15

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

0206デフォルトの名無しさん

2005/06/17(金) 22:48:16

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

0207デフォルトの名無しさん

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診断ソリューション
　　■短納期対応型のテストプロセス管理
　　　　現役マネージャが明かす“最速のテスト管理”手法

0208デフォルトの名無しさん

2005/07/03(日) 12:48:03

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

0209デフォルトの名無しさん

2005/07/03(日) 13:30:35

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

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

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

0210デフォルトの名無しさん

2005/07/18(月) 00:17:41

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

(Visual Studio Team Edition for Software Testers)

0211デフォルトの名無しさん

2005/07/18(月) 19:26:21

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

0212デフォルトの名無しさん

2005/07/18(月) 19:42:26

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

0213デフォルトの名無しさん

2005/07/18(月) 19:42:54

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

0214デフォルトの名無しさん

2005/07/18(月) 20:13:03

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

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

0215デフォルトの名無しさん

2005/07/18(月) 20:30:01

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

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

ﾌｼｷﾞ

0216デフォルトの名無しさん

2005/07/18(月) 20:51:51

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

0217デフォルトの名無しさん

2005/07/18(月) 21:00:21

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

0218デフォルトの名無しさん

2005/07/18(月) 21:13:47

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

0219デフォルトの名無しさん

2005/07/18(月) 21:42:55

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

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

0220デフォルトの名無しさん

2005/07/18(月) 21:47:50

人の手でやってますorz

0221デフォルトの名無しさん

2005/07/18(月) 22:50:37

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

0222デフォルトの名無しさん

2005/07/18(月) 23:03:59

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

まさにテスト駆動です

0223デフォルトの名無しさん

2005/07/18(月) 23:08:10

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

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

0224デフォルトの名無しさん

2005/07/18(月) 23:19:18

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

んなバカな

0225デフォルトの名無しさん

2005/07/18(月) 23:21:21

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

0226デフォルトの名無しさん

2005/07/18(月) 23:24:44

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

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

0227デフォルトの名無しさん

2005/07/18(月) 23:25:01

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

0228デフォルトの名無しさん

2005/07/18(月) 23:52:56

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

0229デフォルトの名無しさん

2005/07/19(火) 00:30:54

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

0230デフォルトの名無しさん

2005/07/19(火) 00:43:34

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

0231デフォルトの名無しさん

2005/07/19(火) 01:04:35

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

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

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

0232デフォルトの名無しさん

2005/07/19(火) 09:09:46

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

0233デフォルトの名無しさん

2005/07/19(火) 11:00:06

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

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

0234デフォルトの名無しさん

2005/07/19(火) 11:06:46

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

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

0235デフォルトの名無しさん

2005/07/19(火) 11:17:13

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

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

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

0236デフォルトの名無しさん

2005/07/19(火) 11:40:48

とりあえず、

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

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

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

0237デフォルトの名無しさん

2005/07/19(火) 11:45:45

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

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

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

0238223

2005/07/19(火) 12:24:18

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

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

0239デフォルトの名無しさん

2005/07/19(火) 12:41:28

あー。V字モデル

0240デフォルトの名無しさん

2005/07/19(火) 12:55:25

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

0241デフォルトの名無しさん

2005/07/19(火) 12:57:39

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

0242デフォルトの名無しさん

2005/07/19(火) 14:33:51

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

0243デフォルトの名無しさん

2005/07/19(火) 14:38:12

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

0244デフォルトの名無しさん

2005/07/19(火) 14:45:30

CUnit

0245デフォルトの名無しさん

2005/07/19(火) 14:49:27

NUnit
とtestdriven.net
これ最強

0246デフォルトの名無しさん

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よりもシンプルでプアな環境でも使用できる

0247デフォルトの名無しさん

2005/07/19(火) 20:04:04

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

0248デフォルトの名無しさん

2005/07/22(金) 16:31:35

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

0249デフォルトの名無しさん

2005/07/22(金) 23:49:15

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

0250デフォルトの名無しさん

2005/08/21(日) 12:47:50

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

0251デフォルトの名無しさん

2005/08/29(月) 10:15:50

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

0252デフォルトの名無しさん

2005/08/31(水) 09:52:13

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

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

0253デフォルトの名無しさん

2005/08/31(水) 10:28:46

ワレモノ

0254デフォルトの名無しさん

2005/08/31(水) 10:36:48

それはイカンね

0255デフォルトの名無しさん

2005/09/03(土) 13:09:26

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

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

public boolean testAuthPass(){

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

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

0256デフォルトの名無しさん

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

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

0257255

2005/09/03(土) 15:43:41

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

0258名無しさん＠そうだ選挙に行こう

2005/09/11(日) 12:36:43

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

0259名無しさん＠そうだ選挙に行こう

2005/09/11(日) 14:38:11

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

0260デフォルトの名無しさん

2005/09/12(月) 21:44:23

UWSC

0261デフォルトの名無しさん

2005/09/12(月) 23:11:37

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

0262デフォルトの名無しさん

2005/09/12(月) 23:13:07

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

0263デフォルトの名無しさん

2005/09/13(火) 21:34:29

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

0264デフォルトの名無しさん

2005/09/14(水) 00:26:55

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

0265デフォルトの名無しさん

2005/09/14(水) 03:07:27

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

0266デフォルトの名無しさん

2005/09/14(水) 19:50:04

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

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

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

0267デフォルトの名無しさん

2005/09/14(水) 21:36:40

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

0268デフォルトの名無しさん

2005/09/14(水) 21:46:46

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

0269デフォルトの名無しさん

2005/09/14(水) 21:56:10

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

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

0270デフォルトの名無しさん

2005/09/14(水) 22:44:13

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

>>268 ｶﾞｯ

0271デフォルトの名無しさん

2005/09/14(水) 23:45:26

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

0272デフォルトの名無しさん

2005/09/17(土) 11:52:05

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

0273デフォルトの名無しさん

2005/09/17(土) 15:55:09

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

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

0274デフォルトの名無しさん

2005/09/17(土) 16:06:01

>>266
ん。NUnitだと、

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

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

0275デフォルトの名無しさん

2005/09/17(土) 16:08:29

>>276
JUnit4からなら。

0276デフォルトの名無しさん

2005/09/17(土) 16:12:21

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

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

0277デフォルトの名無しさん

2005/09/17(土) 16:17:12

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

0278デフォルトの名無しさん

2005/09/17(土) 17:21:06

>>276

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

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

0279デフォルトの名無しさん

2005/09/17(土) 19:43:27

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

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

0280デフォルトの名無しさん

2005/09/18(日) 03:19:34

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

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

0281デフォルトの名無しさん

2005/09/18(日) 09:54:08

272の立場ねぇなぁ www

0282デフォルトの名無しさん

2005/09/18(日) 10:59:26

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

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

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

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

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

0283デフォルトの名無しさん

2005/09/18(日) 21:00:56

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

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

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

0284デフォルトの名無しさん

2005/09/18(日) 21:40:40

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

0285383

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

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

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

0286283

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は削除してから自動生成されたものだし、
一体何処に原因が・・・・？

0287283

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)のエラーはまだ消えず。

0288283

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だけで検査すればいいとはいえ。

0289デフォルトの名無しさん

2005/09/19(月) 08:56:35

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

0290デフォルトの名無しさん

2005/09/19(月) 14:55:19

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

0291283

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はすべて削除してから
実行しなおした。

みんなサンクス。

0292デフォルトの名無しさん

2005/09/19(月) 18:04:02

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

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

0293デフォルトの名無しさん

2005/09/30(金) 17:43:40

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

0294デフォルトの名無しさん

2005/10/01(土) 18:18:26

>293

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

0295デフォルトの名無しさん

2005/10/03(月) 21:46:07

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

0296デフォルトの名無しさん

2005/10/03(月) 22:23:50

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

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

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

0297デフォルトの名無しさん

2005/10/04(火) 09:44:23

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

0298デフォルトの名無しさん

2005/10/05(水) 20:18:17

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

0299デフォルトの名無しさん

2005/10/05(水) 20:28:03

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

0300デフォルトの名無しさん

2005/10/06(木) 10:56:05

300get

0301デフォルトの名無しさん

2005/10/06(木) 16:12:05

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

0302デフォルトの名無しさん

2005/10/06(木) 21:57:51

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

0303デフォルトの名無しさん

2005/10/06(木) 22:08:11

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

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

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

0304デフォルトの名無しさん

2005/10/06(木) 23:58:00

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

0305デフォルトの名無しさん

2005/10/07(金) 01:40:33

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

0306デフォルトの名無しさん

2005/10/07(金) 10:33:13

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

0307301

2005/10/07(金) 11:12:25

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

0308デフォルトの名無しさん

2005/10/07(金) 14:00:53

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

0309デフォルトの名無しさん

2005/10/11(火) 01:30:37

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

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

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

0310デフォルトの名無しさん

2005/10/13(木) 15:59:21

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

0311デフォルトの名無しさん

2005/11/03(木) 02:09:26

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

0312デフォルトの名無しさん

2005/11/03(木) 03:44:04

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

0313デフォルトの名無しさん

2005/11/03(木) 11:36:56

エロすぎ

0314デフォルトの名無しさん

2005/11/03(木) 13:59:23

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

0315デフォルトの名無しさん

2005/11/03(木) 14:25:59

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

0316デフォルトの名無しさん

2005/11/03(木) 21:14:36

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

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

0317デフォルトの名無しさん

2005/11/03(木) 21:46:15

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

0318デフォルトの名無しさん

2005/11/03(木) 22:35:52

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

0319デフォルトの名無しさん

2005/11/03(木) 22:43:31

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

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

0320デフォルトの名無しさん

2005/11/05(土) 03:27:15

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

0321デフォルトの名無しさん

2005/11/06(日) 21:56:07

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

0322デフォルトの名無しさん

2005/11/07(月) 13:00:07

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

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

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

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

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

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

0323デフォルトの名無しさん

2005/11/07(月) 13:29:43

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

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

0324デフォルトの名無しさん

2005/11/07(月) 14:17:54

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

0325322

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

0326デフォルトの名無しさん

2005/11/07(月) 17:09:07

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

これに尽きる。ｗ

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

0327デフォルトの名無しさん

2005/11/07(月) 18:34:54

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

0328デフォルトの名無しさん

2005/11/07(月) 19:00:20

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

0329デフォルトの名無しさん

2005/11/07(月) 19:03:31

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

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

0330322

2005/11/07(月) 19:50:59

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

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

0331デフォルトの名無しさん

2005/11/07(月) 19:57:53

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

0332デフォルトの名無しさん

2005/11/07(月) 20:26:11

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

0333デフォルトの名無しさん

2005/11/07(月) 20:28:49

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

0334322

2005/11/07(月) 23:03:01

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

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

0335デフォルトの名無しさん

2005/11/07(月) 23:29:18

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

0336デフォルトの名無しさん

2005/11/07(月) 23:43:57

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

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

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

0337322

2005/11/07(月) 23:54:54

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

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

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

0338デフォルトの名無しさん

2005/11/08(火) 00:08:28

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

0339322

2005/11/08(火) 00:17:55

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

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

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

0340322

2005/11/08(火) 00:47:06

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

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

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

0341デフォルトの名無しさん

2005/11/11(金) 14:54:25

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

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

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

0342デフォルトの名無しさん

2005/11/11(金) 18:39:59

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

0343デフォルトの名無しさん

2005/11/12(土) 11:52:29

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

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

0344デフォルトの名無しさん

2005/11/12(土) 14:35:29

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

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

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

0345デフォルトの名無しさん

2005/11/12(土) 21:33:05

>>344
つ分割統治

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

0346デフォルトの名無しさん

2005/11/13(日) 02:52:11

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

0347デフォルトの名無しさん

2005/11/13(日) 03:35:52

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

0348デフォルトの名無しさん

2005/11/13(日) 10:06:46

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

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

0349デフォルトの名無しさん

2005/11/13(日) 10:28:08

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

0350デフォルトの名無しさん

2005/11/16(水) 23:41:05

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

0351デフォルトの名無しさん

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には向かないようです。

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

0352デフォルトの名無しさん

2005/11/18(金) 19:46:59

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

0353351

2005/11/18(金) 22:27:50

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

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

0354デフォルトの名無しさん

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
ここを見たのですが、決して簡単にテストができるわけではないと感じました。
お使いになっている方はいらっしゃいますか？

0355デフォルトの名無しさん

2005/11/23(水) 11:59:02

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

0356354

2005/11/23(水) 15:27:26

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

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

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

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

0357デフォルトの名無しさん

2005/11/23(水) 17:08:04

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

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

0358デフォルトの名無しさん

2005/11/23(水) 18:23:51

激しく同意。

0359デフォルトの名無しさん

2005/11/23(水) 19:24:47

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

0360デフォルトの名無しさん

2005/11/23(水) 19:26:45

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

0361デフォルトの名無しさん

2005/11/23(水) 22:28:17

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

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

0362354

2005/11/23(水) 23:42:51

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

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

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

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

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

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

0363デフォルトの名無しさん

2005/11/23(水) 23:49:57

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

>>357 みたいなのが日本のエンジニア界現場をおかしくしてんの。

0364デフォルトの名無しさん

2005/11/23(水) 23:55:16

SQLの規格のpdfってどこかにない？

0365デフォルトの名無しさん

2005/11/24(木) 00:03:10

>>356
実装の知識を全く使わないブラックボックステストを書く練習をすると良いかもね。
今までのレス読むと、何をテストすれば良いのかわからないって感じに見えたから。

0366デフォルトの名無しさん

2005/11/24(木) 09:15:25

>>363
おまえはクレクレ君に対して肯定的なんだな。

0367デフォルトの名無しさん

2005/11/24(木) 09:42:01

>>366
自分がクレクレ君だからだろ。

0368デフォルトの名無しさん

2005/11/24(木) 09:54:12

おまえらなんかけちくせーなー
>>362
最初は一回正面突破試みましたか？これやらないでいいアイデアは
でないよー

0369363

2005/11/24(木) 09:54:45

そうだな三十路ぐらいまで米国でPGやっていたせいか正当なるクレクレ君には肯定的だな。
ここまでやってみた、だけどココをどうすればいいのだろう、アイデア持ってる香具師おらんかね
というコミュニケーションがあたりまえの世界だったからな。
362のは無条件にオレだけに教えてクレクレ君じゃないとみるからな。

日本人は職人気質みたいにオレのワザ盗めとか自分で全部まかなえという空気が現場レベルでも往々にしてあるが
かえって全体品質を落としていることと国際的にみると日本人エンジニアのレベルをも落としていることに全く気づいてない罠。

たかだかテストケースの書き方、テクニックぐらいでなんだよ。企業秘密でも何でもあるまい。

＃しかし漏れはDBUnitとかはいじったことないからナニも答えられないんだよなｗｗｗ

0370デフォルトの名無しさん

2005/11/24(木) 10:17:54

まぁ、「テストツールについて語るスレ」だからな
ごちゃごちゃ言わずにテストツールについて語れよ

で、今年の9月にリリースされたDDStepsについてなにか情報持っている奴はいないか？
http://www.ddsteps.org/

ドキュメントのこの図を見ると結構期待できそうなんだが……。
http://www.ddsteps.org/images/ddsteps_overview.png

0371368

2005/11/24(木) 10:19:52

じゃーちょっとだけ書いてみます
DBUnit使ったことあります。354に挙げてあるxunitがそうであるかどうかは読んでないから分からん
DBUnitは便利だと思う。データを準備しなきゃならんのはめんどくさいかもしれんけど
それによってリグレッションテストができるメリットは大きい。（きっとそこは同意してもらえると思うけど）
おれは普通にいくつかのテストケースを用意してやってるけど
「テストが容易なSQLを作ること」と「テストを楽にする」のは異なることだし
> Java のコードは、テスト項目を洗い出すことが比較的容易です。分岐やルー
> プがあれば、大抵その条件をそのままテスト項目にできます。しかし SQL の
>場合、なかなかテスト項目を抽出しにくいと私は感じます。どのようなデータ
xunitの目指すとこではこの内部の分岐からケースを考えるってのがあんまり
適切な考え方じゃないような気がする。何をテストするかを考えるべきではないかと思ってる
> とテストを用意すれば必要十分なのか、分かりづらいのです。特に、リンク先
必要十分というのがどういうことなのか？というのを調べて確認してみるとか？
（すでに知ってるんだﾎﾞｹｪだったらごめん）よく、「XXX網羅」って言ってるはず
後最後に、ここ2chですから下手に出すぎると煽られますので、「やいてめーらおしえろよ」ぐらいでいいでしょう（実社会じゃやっちゃだめ）
ついでに上げ

0372デフォルトの名無しさん

2005/11/24(木) 11:22:58

まぁ煽ってんのは毎回同じ人物だったりするんだろうけどねｗ

0373デフォルトの名無しさん

2005/11/24(木) 11:47:03

>>369

> 日本人は職人気質みたいにオレのワザ盗めとか自分で全部まかなえという空気が現場レベルでも往々にしてあるが
> かえって全体品質を落としていることと国際的にみると日本人エンジニアのレベルをも落としていることに全く気づいてない罠。

おお、それ俺も前から思ってた。よく変な先輩や年長者に騙されて、車輪の再発明
にそっくりなことのためにかなり時間を無駄に過ごしてきた気がするよ。
年長者とはお互いに違うことをやれば生産性が上がるのに、年長者が、「俺とおなじことをしろ。
ただしやり方は教えない。さもないと教育によくなく学習しなくなるから。」とか言いだして。
車輪の再発明みたいな無駄なことのために一から作り直すのではなく既存のものを
改良できるような仕組みを用意した方が効率がよいのだが。
それをいうと連中は精神論を語り出して、若い奴はだらしないとかわけのわからないこと言って。
まったく、儒教精神とか武士道精神って奴は悪いことばかりでどうにかならないのかね。
「日本人は真似ばかりしてるから独創性が無い」とか言われてきたが
それを勘違いして曲解してる香具師が沢山いる。実際には真似しなければ応用なんてできないのにな。
まず真似、模倣することから初めて真似・模倣したものを応用することで
オリジナリティや新たな発明、発見ができるのにな。

バイト先でもさ、古い考え方、とくに未だにステップ数やウォータフォールにとらわれて
ソフトの品質をいっこうにあげられないってのも情けないね日本のＩＴ業界は。
常に「お客様は神様だ」と言い張ってどんなに効率の悪いことでも言われたとおりにやろうとする。
こちらから客に提案することも、客にとってプラスになることがあるのにそれができない馬鹿が実に多いことか。
テストの自動化も理解できていないし、時間が無いから単体テストはするなとか言いだすし。品質は下がるわけだ。
日本のIT企業の大半がCMMレベルが1や2程度のばかりだってことがよくわかるよ。

0374デフォルトの名無しさん

2005/11/24(木) 11:58:09

>>373
饒舌だねｗ。総論同意。だけど一つだけ。
CMM自体も単なる一つの側面にしか過ぎないという認識／意識がないと
>ステップ数やウォータフォールにとらわれて
という人達と同じになってしまうから気をつけた方が良いよ

0375デフォルトの名無しさん

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/ のサイトでは
これといって新しい動きと思われる情報が見あたらないな。

0376デフォルトの名無しさん

2005/11/24(木) 13:28:35

１から１０まで手取足取り教えなきゃ何もできねーような奴はいらねーな。
自分で動いた方が早い。

・・っておもっちゃうんだよなー。技術屋ってそういうところ無い？俺だけかな？

0377デフォルトの名無しさん

2005/11/24(木) 13:38:22

>>369
> たかだかテストケースの書き方、テクニックぐらいでなんだよ。
そう。「たかだか」テストケースの書き方なんだよ。
それぐらいは人様に教わらないでも出来ると思うんだよね。

0378デフォルトの名無しさん

2005/11/24(木) 14:01:42

>>376-377
>>369のいってること理解してねーな、おまえらみたいなのが（ｒｙ

もういいからテストツールについて語ってくれよ

0379デフォルトの名無しさん

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の使い方すらわからない馬鹿で困ったもんだ。

0380デフォルトの名無しさん

2005/11/24(木) 14:26:33

そりゃあんたがそういうバカがいるところに居るようなバカだからいけないんじゃないかね？

0381デフォルトの名無しさん

2005/11/24(木) 14:39:41

最近はツール自体は無料で、ノウハウやサポート等の提供で儲けるってのもあるしねぇ。

0382368

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のようなものが日本発で生まれたかもしれない、と思ったりして
日本人は品質を非常に重要視する、といわれているし←ソフトウェアの世界では全然成り立ってない
ような、というのはみんなの認めるとこだろうけど

またあげっちゃうんでおまいら語れよ

0383デフォルトの名無しさん

2005/11/24(木) 23:51:28

んじゃ、DbUnitネタをひとつ。

DbUnitのAntタスクのformat属性には、"flat"、"xml"、"dtd"が指定出来るとドキュメントには
書いてあるけど、ソースを見ると"csv"も指定できることがわかる。

まぁ、csvファイルはデフォルトエンコーディングで読み書きされることと、nullを指定できない欠点が
あるんで、ソースに手を入れてエンコーディングの指定とnullを指定する機能を付け加えて使ってる。

テストデータをcsv形式で作成出来るんで素のまま使うより多少便利ってとこかな。

>>382
まぁ、日本のソフトウェアの品質や新しいアイデア以前に>>354の件は
「マニュアル嫁」「サンプル動かせ」「疑問があったらまず自分から動け」と言いたくなるな。

0384379

2005/11/25(金) 00:00:38

>>380
おれは学生バイトだから関係ねえや。
そこの会社に就職するつもりはないがな。

0385デフォルトの名無しさん

2005/11/25(金) 22:48:12

>>384
その割にはなんか熱く語っていたようだが？ (w

て言うか、バイト代さえちゃんとくれるんならアフォ
な会社の方が楽できるから金儲けと割り切ればいいだ
けだろ。

0386デフォルトの名無しさん

2005/11/26(土) 08:52:16

>>383

DbUnitのcsvは一瞬便利かと思ったけど、意外と使えないという印象だな。

せっかくテストデータを作っても、制約を考慮してくれないからうまくいかない
ことがない？テーブルのimport順を指定できるか、あるいはファイル単位での
importができれば良かったんだが。
テーブルごとにディレクトリ作ってやればなんとかなるけど、それじゃあんまり
便利じゃないしなぁ。

0387デフォルトの名無しさん

2005/11/26(土) 23:51:09

すみません、それ以前に、DBUnit のデータ用XMLファイルってどうやって管理
したらいいですか？

プロジェクトのルートディレクトリにどんどんXMLファイルが溜まって困ってます。
できたら、テストクラスと同じパッケージのディレクトリに収めたいんだけど…。

0388デフォルトの名無しさん

2005/11/27(日) 01:20:58

>>387
俺は、DatabaseTestCaseを継承したクラスを作って、setUp()実行時に
テストクラスと同じディレクトリにあって同じ名前のXMLファイルを自動的に読み込むようにしてる。
テストクラスがfoo.bar.BuzTestなら、XMLファイルはfoo\bar\BuzTest.xmlね。
他のJUnit拡張フレームワーク（Cactusとか)と併用したいときは、そういうことをしてくれる
ユーティリティクラスを作った。

0389387

2005/11/27(日) 02:31:06

>>388
なるほど！私は Cactus と、あと JMock を使いたいから、それぞれの継承
クラスを作ってみることにします。ありがとう！

Seasar2 の S2Dao は、テストクラスと同じ場所にデータファイルを置くのが
標準みたいですね。いいなあ。
http://www.seasar.org/testtech.html#S2DaoTestCase

0390デフォルトの名無しさん

2005/11/27(日) 02:48:57

関係無いけど、Cactus ってすごく遅いのね。この前初めて Tomcat で使って
ビックリ。Jetty統合だともっと速いのかな？

『JUnit イン・アクション』で、テストディレクトリを Cactus とその他で
分けることをすすめている理由がつくづくよく分かった。

もちろん、コンテナオブジェクトのモックを使うこと自体のメリットも
あるんだろうけど。

モックとスタブの違い
http://d.hatena.ne.jp/devbankh/201002
（自分には難しくてよく分からない）

0391デフォルトの名無しさん

2005/11/27(日) 20:32:12

モックとスタブの違いを混同したところで、あんまり困るような状況にはならない気が。
長々説明しているけど、きっとささいな違いなんでしょ？

0392デフォルトの名無しさん

2005/11/27(日) 22:57:19

違いがあるということにしたいキチガイが騒いでるだけだよ
きっと流行語大賞でも狙ってるんだろ

0393デフォルトの名無しさん

2005/11/28(月) 12:48:02

ただのバズワードだとは思わないけどなあ。

今までマーチン・ファウラーの文章をいろいろ読んできたけれど、自分に理解
できた範囲では、彼はいつでも現場のプログラマのための、地に足の着いたこ
とを書いていた。内容の無い営業向けのことを書いていたことは一度もなかっ
た。だから自分は彼のことをすごく信頼している。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/

この文章は確かに分かりにくいけれど、きっと彼の考えがまだ簡潔に表現でき
るほどまとまっていないか、もしくは自分に理解力と経験が足りないのだろう
と思う。

0394デフォルトの名無しさん

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

の順でクエリーを投げて例外が発生したらテスト失敗、無事に正常終了したらテスト成功って仕組みみたいだ。

0395デフォルトの名無しさん

2005/11/29(火) 12:23:24

>>394
これ、.NET だし、MS-SQL-Server だし、全然仕事で関わりそうにないのが残念。
Java で他のDBに対応したものが欲しいよねえ。

0396デフォルトの名無しさん

2005/12/03(土) 19:01:33

チューリングテストに対応したツールでオススメのものはありますか？

0397デフォルトの名無しさん

2005/12/03(土) 19:03:48

C++の自動テストツールってない？
完璧なテストケースを書くのがめんどくさいから
自動で適当に８０％ぐらい網羅してくれる奴。

0398デフォルトの名無しさん

2005/12/03(土) 19:12:30

>>397
80%？残り20%はどうするんだ？100%自動化してくれない
テストツールの方が珍しいと思うけど？
C++のテストツールだったら、C++Unitがあるよ。
結合テストしてくれるテストツールは知らん。
他の言語って結合テストしてくれるツールってあるのか？

0399デフォルトの名無しさん

2005/12/03(土) 20:55:12

ほとんどのバグは残り20%のところに埋もれる

0400デフォルトの名無しさん

2005/12/03(土) 22:13:03

>>385
時給が糞安い社長を始めとする取締役や上司らの人格に
問題があって会社の空気を悪くしてるから言ってみただけだよ。
最近では上司らの腹黒さが解ったので
こちらもこちらでそれ相応のことしかしないようにしている。
自分を安売りするようなことは決してしないように。
他のバイトに今のところよりよさげなのがあるので
新しいバイト決まるまで今の糞会社に残る予定。

0401デフォルトの名無しさん

2005/12/03(土) 23:37:20

『JUnit インアクション』を読み、JUnit を導入してみて、なかなか勝手が
分からずに苦労してきたのだが、最近やっと慣れてきた。
と同時に、衝撃を受けた。この自動単体テストって、単なる開発のツールじゃ
なくて、プログラミングに対する考え方そのものを変えてしまうような、もの
すごく大きいものじゃないだろうか？

・JUnit はどんなコードでもテストできるわけではない。現実的にはとてもテ
　ストできないようなコードの方が多い。
・逆に言えば、JUnit で自動テストを行うためには、テストのしやすさを強く
　意識したコードを書かなければならない。
・JUnit でテストのしやすいコードとは「粒度が高い」「疎結合」という条件
　を満たすコードのことである。
・すなわち、オブジェクト指向的に良い設計と言われるコードのことである。
・つまり「良いオブジェクト指向設計」とは「テストしやすいコード」のこと
　なのである。
・既存のコードがテストが困難だったら、リファクタリングしてテストをしや
　すいコードに書き換えなければならない。むしろその書き換えをさせること
　が、モッ　クオブジェクトの大きな存在意義である。単に受身の存在ではない。
・リファクタリングの定義は、テストしやすいコードに書き換えることである。

まだまだ続くんだけど、全く同じことを言っている人を今日知ったんで、それ
を貼っておしまいにする。

オブジェクト指向の再定義
http://www.objectclub.jp/technicaldoc/object-orientation/OO_redefine/

0402デフォルトの名無しさん

2005/12/04(日) 00:18:17

あらためて感動するようなもんか？
まともなプログラマなら皆やってることなんだが

0403401

2005/12/04(日) 00:49:23

>>402
ならば俺は今までまともなプログラマでは無かった。
俺はユニットテストを組んだことが無かった。
今までユニットテストツールについては、将来手を出してみたい新技術の一つ
だとしか認識してなかった。

ユニットテストコードを組むようになって、今までに学んだ概念が全て、実は
テストの容易さを目的として作られていたものだと、初めて気がついた。テス
トは決して周辺技術じゃない。むしろ、他の多くの技術的概念の根幹を成すコ
アだ。しかしそれは、自分でテストを組んでみるまで分からなかった。

恐る恐る言うのだが、ユニットテストを組まないプログラマは、もはやまとも
なプログラマとは言えないのかもしれない。

だけど、逆に問いたい。XUnitって、日本で色物扱いされて、認知度は非常に
低いじゃないか。ユニットテストをこれほど重要だと認識しているプログラマ
は1割もいるまい。どうしてこんなに認知度が低いんだろう？

0404デフォルトの名無しさん

2005/12/04(日) 01:34:49

>>403
簡単なことです。
土方現場では、実装は土方作業に例えられ、納期さえ
守られていれば上司は満足という低レベルなプロジェクト
がほとんどだからです。

0405401

2005/12/04(日) 02:13:34

>>404
それはそうなんだろうけど、もうちょっと突っ込んだ視点はないだろうか？

例えば、デザパタのスレだったら、この板には過去にいくつも立っていた。ホ
ントの底辺プログラマは、デザパタなんて知らないし使わない。つまり、この
板には底辺プログラマばかりがいるわけではない。

それなのに、何でテストのスレはこんなに進みが遅いんだろう？

0406デフォルトの名無しさん

2005/12/04(日) 08:21:21

>>405
デザパタスレみたいに厨房が押し寄せて、隔離スレが出来るような展開がお望みですか？

0407デフォルトの名無しさん

2005/12/04(日) 15:51:33

>>403
今頃気付いたのか。おまえのような人間ばかりだから
デスマーチができあがる。

0408デフォルトの名無しさん

2005/12/04(日) 16:02:21

>>407
いや、それに今頃気づくお前のような人間ばかりだから・・・(ry

0409デフォルトの名無しさん

2005/12/04(日) 16:14:07

>>403
おまえ、5年は遅れているぞ。

0410デフォルトの名無しさん

2005/12/04(日) 18:48:34

いま気づいただけでもずいぶんマシだと思う。

0411デフォルトの名無しさん

2005/12/04(日) 20:25:31

406-411

0412デフォルトの名無しさん

2005/12/04(日) 21:33:59

ユニットテストなんて書けねー
とか言っている人間はそこらじゅうにいる。
そらお前がテスト書けるような実装をしないからだろ、と何回も言ってきた。
にもかかわらず結局そのまま走って穴だらけの手動テストで時間を浪費する。

そんなうちのプロジェクトメンバを見てる私からすると
>>403は素晴らしい部類に入ります。
是非その発想の転換が行なえたときの喜びや驚きを
多くの人に伝えてあげてください。
まだまだ知らない人は沢山います。

0413デフォルトの名無しさん

2005/12/04(日) 21:35:58

エクストリームをまともにやれるプロジェクトもほとんど無いしな。

0414デフォルトの名無しさん

2005/12/04(日) 22:15:01

ユニットテストの実践についてまとめた良書ってありますか？
まだ初心者なんで、
テストの粒度・密度とか、Privateメソッドはどうするかとか、
テストパターン-コード-ドキュメントの連携はどうするかとか、
そういうあたりでいつも迷ってよくわかんなくなります。

0415デフォルトの名無しさん

2005/12/04(日) 22:23:26

>>414
これっきゃない。英語だけど。
JUnit Recipes: Practical Methods for Programmer Testing
ttp://www.amazon.co.jp/exec/obidos/ASIN/1932394230/

かゆいところに手が届いている。

0416デフォルトの名無しさん

2005/12/04(日) 22:26:58

amazon.comのレビューのほうが参考になるので、こっちも見てくれ。
ttp://www.amazon.com/gp/product/1932394230/

ManningのWeb Page
ttp://www.manning.com/books/rainsberger

0417デフォルトの名無しさん

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

0418デフォルトの名無しさん

2005/12/04(日) 22:59:20

ユニットテストって粒度が問題にならね？
ＡＰＩ全てにユニットテスト通してたらプロジェクト御わっちまうよ

0419デフォルトの名無しさん

2005/12/05(月) 00:42:26

ユニットテストっていうぐらいだから1ソースファイルにテストは1つで十分

0420デフォルトの名無しさん

2005/12/05(月) 00:55:43

テストファーストは、プログラミングテクニックの一つぐらいに考えておいた方がいい。
実装とテストを分けて考えると>>418みたいなことを言い出す奴が出てくる。

0421デフォルトの名無しさん

2005/12/05(月) 05:42:44

やってあたりまえ

0422デフォルトの名無しさん

2005/12/05(月) 05:53:05

GUIのテストってどうやんの？

0423デフォルトの名無しさん

2005/12/05(月) 14:55:20

『JUnit インアクション』の訳は、自分には非常に読みづらい。
訳者がちゃんと分かってないからじゃないかと思う。

例えば７章の扉、
「成功の秘訣は誠実であることだ。軌道に乗ったら嘘をついてもよい」
これは後半が間違っていて、正しくは
「成功の秘訣は「誠実さ」である。それさえ装えれば、成功したも同然。」

要するにここは、ジャン・ジロドゥの名言を引用して、モックオブジェクトの
性質の説明をしているんだけど、書籍の訳では全然それが伝わらない。
この本に限らず、XP関連の書籍の訳は、大部分がかなりひどいと思う。

かと言って自分は英語ができないから、原書は少し読むだけで頭が混乱してくる。
『JUnit Recipes』読みたいのに。
英語がダメだとテストもできないのか。うう。

0424デフォルトの名無しさん

2005/12/05(月) 15:54:09

自動翻訳されたものを手直しした程度で出してるんじゃないのかな？

0425デフォルトの名無しさん

2005/12/05(月) 21:31:09

まあ昔に比べて、翻訳に時間をかけられないから、機械翻訳を下訳に使うのは
仕方がないだろう。だけど意味の通らない翻訳が多すぎるよ。
「JUnit イン・アクション」の翻訳の質の低さは、本邦におけるユニットテス
トの普及を少なからず妨げたと思う。

0426デフォルトの名無しさん

2005/12/06(火) 10:53:27

では 2ch 発で日本語による日本人のための JUnit テストツールの本を作りませんか？

0427デフォルトの名無しさん

2005/12/06(火) 11:00:37

>>426
電車男を見るにつけ、ひろゆきに搾取されて出した人間には一銭も入らない予感。

0428デフォルトの名無しさん

2005/12/06(火) 12:58:39

ゼロから本を書くんじゃなくて、例えばこのスレで『JUnit インアクション』
の分からないところを質問したり、良書を紹介したりして、情報共有する方が
効率的だと思うよ。

訳は悪くても『インアクション』は大変な名著だ。テストというものに対す
る見方ががラッと変わる。腰帯の「本書を読まずに、J2EEアプリケーションの
単体テストを行ってはいけない！」という、エリック・ガンマの言は伊達では
ないと思う。

0429デフォルトの名無しさん

2005/12/06(火) 13:43:32

>>426
つーか、原著読めば良くね？
英語読めない奴がどうなろうと、俺の知ったこっちゃない。

0430デフォルトの名無しさん

2005/12/06(火) 20:44:06

まあ、教えたい人は教えればいいし、教えたくない人は教えなければいい。

0431デフォルトの名無しさん

2005/12/07(水) 22:22:39

例えばGUIやディスクIOやDBアクセスがあるような「現実のプログラム」は、
どうしてもユニットテストでカバーできる部分とできない部分が出てきてしまう。
開発時テストにおいてユニットテストはあくまでも一手段であり、
すべてではないと思う。

カーニハンの著書「プログラミング作法」もテストについての章があって
参考になるよ。

0432名無しさん＠お腹いっぱい。

2005/12/08(木) 10:49:06

xUnitでのテストケースって、一個のテストメソッドに1個のassertXXXXX()とかfail()
を書くのが普通？

0433デフォルトの名無しさん

2005/12/08(木) 13:27:12

>>431
あ、その本持ってた。どんなこと書いてあったっけ。思い出せない。

0434デフォルトの名無しさん

2005/12/08(木) 23:37:36

>>432
別に普通じゃない。まずちゃんとした本を嫁。

0435デフォルトの名無しさん

2005/12/09(金) 01:21:09

JUnitインアクション隅から隅まで読んだわけじゃないが、
なんかやりすぎなような気がする手法もちらほらあるな。
モックのところとか初期化多すぎで何をテストしてるのかわからん。
テストファーストをテーマにした本なんだから、そこを強調
しているのはあたりまえだけど。
まあ参考程度に効果的に使わせてもらうよ。

0436デフォルトの名無しさん

2005/12/09(金) 02:20:13

機械翻訳といえば「テスト駆動開発」...ひどすぎw

0437デフォルトの名無しさん

2005/12/09(金) 11:39:28

>>435
いや、君は「単体テスト」というものの意味が分かっていない。
あるコードを単体テストするためには、他のコードに依存する部分を完全に切
り離さなければいけない。そうしないと、バグの原因を切り分けられないから。
それを達成するために、手間をかけてモックオブジェクトを用意する必要があ
るんだ。

0438デフォルトの名無しさん

2005/12/09(金) 13:02:09

webの機能テストツールって何がｵｽｽﾒですか？
とりあえずMaxQ、actiWATE、Seleniumあたりを試してみたいと思っていますが
これ使ってみれっていうのがあったら教えてやってください。

0439デフォルトの名無しさん

2005/12/10(土) 23:08:43

モックモックってお前らシブガキ隊を馬鹿にするな。

0440デフォルトの名無しさん

2005/12/10(土) 23:16:23

アフォスケジュールの時はテスト工藤開発などやってる暇が無い

0441デフォルトの名無しさん

2005/12/11(日) 08:40:07

とりあえず動くコード書くだけならテストツールに頼らなくても出来てしまうし
テストツールを使わなくても保守性の高いコードを書ける香具師は書ける

テストツールは素人に保守性の高いコードを書かせるための「あくまで補助的な」道具にすぎない

0442デフォルトの名無しさん

2005/12/11(日) 08:55:30

テストを書いてるとコメントを書くのがめんどくさくなってくる。

0443デフォルトの名無しさん

2005/12/11(日) 10:32:35

テスト書くのがめんどくさいんだけどテストツールなんて使えるの？
一回やってみたが書かなければいけないコードの量が3倍に増えて
品質が1/3になった。テストツール (ﾟ⊿ﾟ)ｲﾗﾈ
俺はC++だがJavaになるとまた違うのだろうか？

0444デフォルトの名無しさん

2005/12/11(日) 10:44:13

開発期間がある程度長くてビジネスロジックにのみテストケース書いている。
すべてのクラスに対してテストケース書いているわけじゃないよ。
あと、単体ケースの工数をテストケースを書く工数にあてている。
プロジェクトを効率よく管理できるｼﾞｬｰﾏﾈの下でないと難しいんじゃないかと思ったり。
一人か二人程度でやるプロジェクトならいらないような希ガス

0445デフォルトの名無しさん

2005/12/11(日) 13:07:41

>>443
元のコードの倍のテストを書いて品質が落ちるって、どんだけ下手なテストを
書いたのよ。どう考えてもネタかアホ。

0446デフォルトの名無しさん

2005/12/11(日) 14:36:20

人数増加＝設計期間短縮という単細胞の年寄り管理職やＰＭが
いなくならない限り、ソフトの品質は上がらない。

0447443

2005/12/11(日) 14:49:27

>>444
なるほど。無理してテストする必要もないのですね。
業務用とかの簡単なプログラムならともかく複雑なプログラムでは
テストケースを作れないケースも多いですからね。

>>445
テスト書くのに時間を取られてコードを書くのがおろそかになった。
コードを変えるとテストも書き直ししないといけないので、必然的に
これはまずいなーと思っていてもその場しのぎの誤魔化しが増えた。
ゆえにコードの品質が下がった。

0448デフォルトの名無しさん

2005/12/11(日) 15:28:34

オブジェクト指向やテストファーストの考え方をわかってない奴が
ユニットテストだけ取り入れようとするとこうなる。
という典型例だな。

0449デフォルトの名無しさん

2005/12/11(日) 15:33:43

と言い訳して煙に巻くパターン

0450デフォルトの名無しさん

2005/12/11(日) 15:36:08

>>448
上記の例ではどうすれば良かったのか、ぜひ講釈してくれ

0451デフォルトの名無しさん

2005/12/11(日) 15:53:21

テスト書けないような複雑なコード書いてる時点でアウトだと思う。

0452デフォルトの名無しさん

2005/12/11(日) 15:55:35

ここでオブジェクト指向のイロハからテストファーストの思想、
パターン別の設計のポイントまで解説しろってか？
さすが、物事や考え方をを把握することができない奴の言うことだ。
わかってないなら無理してやることないよ。何度やっても挫折と失敗を繰り返すだけだから。

0453443

2005/12/11(日) 15:56:48

俺はちゃんとオブジェクト指向している。
むしろオブジェクト指向だからこそ
入力ー関数ー出力
みたいな関係がないのでテストが難しい。
結局最後に人間が一気にテストするのが一番効率がいい。
>>451
それはお前さんが簡単なプログラムしか書いたことがないからだ。

0454デフォルトの名無しさん

2005/12/11(日) 16:08:01

>>452
おまえもしかして本に書いてある知識はあるが実践経験ないのか？ｗ

0455デフォルトの名無しさん

2005/12/11(日) 16:09:21

いっとくがここで言う実践経験ってのは、学生の宿題レベルや２～３人のプロジェクトじゃないからな

0456デフォルトの名無しさん

2005/12/11(日) 16:09:59

テストツールはあくまで道具であって、それを持っているだけで品質が良くなるような銀の弾丸じゃないんだけどな。

0457デフォルトの名無しさん

2005/12/11(日) 16:10:47

なんで実務経験って言わないんだろ

0458デフォルトの名無しさん

2005/12/11(日) 16:13:52

セミナーとか高い金出して出ても例題が実際のケースとはかけはなれ過ぎ。
やはりある程度は失敗をしながら経験値を上げるしかないと思われ。

0459デフォルトの名無しさん

2005/12/11(日) 16:23:09

>>453
複雑なプログラムを、テストが簡単になるようにリファクタリングしながら
テストしていくのがテスト工藤開発の勘所だよ。

難しいと感じた理由は、オブジェクトの責務の分担がうまくいってないからじゃない？

0460デフォルトの名無しさん

2005/12/11(日) 16:23:46

まあ、簡単なプログラムの簡単なテストが書けないPGとかが、結構ころがっているのが現実だし。

0461デフォルトの名無しさん

2005/12/11(日) 17:15:48

テストを前提にした設計ができてないんだろうね。
あとは、BBテストとWBテストの区別ができてないとか、
ユニットテストとデバッグの区別ができてないとか。

0462デフォルトの名無しさん

2005/12/11(日) 17:37:50

>>461
BBテストとWBテストって何？
とりあえず、ぐぐるさんは知らないって言ってるけど。

0463デフォルトの名無しさん

2005/12/11(日) 17:52:20

ブラックボックステストとホワイトボックステストなんじゃないか？

0464デフォルトの名無しさん

2005/12/11(日) 19:20:38

複雑なコード書かないでどうやって現実の複雑な問題に対処するんだ？ｗ

0465デフォルトの名無しさん

2005/12/11(日) 19:25:02

>>464
1つの複雑なコードを簡単な複数のコードに分割する。分割して統治せよ。

0466デフォルトの名無しさん

2005/12/11(日) 19:29:43

テストって面倒だよなー。でもテストケース書く時間とテストする人と時間も圧倒的に足りないんだよねぇ

法でなんとか整備してもらえぬものか。発注側や経営者がつけあがるだけな希ガス。

0467デフォルトの名無しさん

2005/12/11(日) 19:30:52

ユニットテストでテストする（べき）こととしない（べき）ことの区別もついてないのかもね。

0468デフォルトの名無しさん

2005/12/11(日) 19:33:01

>>464-465
単純なコード単位に落とし込むってのは良くわかるんだけど
それってテスト対象となる単位が増えるわけで、テストコード
も膨大にならないか？
バカでかいソフト作るときとか、どうやってんだろ。

0469デフォルトの名無しさん

2005/12/11(日) 19:35:19

法でって、どういう縛りでやんの
検査手順とかを法で定めても、その検査手順の裏かかれたら終わりだし

検査項目の数とかテストの行数でやっても無意味だろうし

0470デフォルトの名無しさん

2005/12/11(日) 19:37:33

ヒント：姉歯

0471デフォルトの名無しさん

2005/12/11(日) 19:38:26

>>465
複雑な分割になるのがオチだなｗ

0472デフォルトの名無しさん

2005/12/11(日) 19:41:12

>>464 の能力では、って事なら同意。

0473デフォルトの名無しさん

2005/12/11(日) 19:41:33

「複雑な分割」って何よ？

0474デフォルトの名無しさん

2005/12/11(日) 19:43:47

>>466
「テストする人と時間」という時点で、
ユニットテストの存在意義をはき違えてる希ガス。

0475デフォルトの名無しさん

2005/12/11(日) 19:44:32

え、だからさ、おれたちデジタル土方にとって都合のいい法をこしらえてくれそうな人を国会に送り込んで…（；´д｀）

0476デフォルトの名無しさん

2005/12/11(日) 19:56:18

実際人命に関わるソフトでも素人が開発してるからな

0477デフォルトの名無しさん

2005/12/11(日) 19:56:42

理不尽な値下げ要求禁止とかなら歓迎です。

0478デフォルトの名無しさん

2005/12/11(日) 23:24:11

ユニットテストって、メソッドのＩＦレベル（ブラックボックス）と、その中のロジックの分岐・繰り返しを
意識した（ホワイトボックス）だと思ってるんだけど、ち・・ちがうの？？
自信なくなってきた。

0479デフォルトの名無しさん

2005/12/11(日) 23:45:07

メソッドのIFレベルのブラックボックスだと思っていた方が安全だな。
ロジックのテストをするもんじゃない。
ましてやデバッグなぞ(ry

0480デフォルトの名無しさん

2005/12/12(月) 00:10:56

ロジックのテストってやったダメなのか・・。
自分はすっごい心配性だから何でも間でもテストしちゃう性分なんだけど。
その性で生産性はよくなく、他に迷惑かけることもあるけど・・。

0481デフォルトの名無しさん

2005/12/12(月) 01:17:56

「成功したテストとは、欠陥を検出したテストである」から、
なんでもかんでもテストした場合と、そうでない場合の欠陥検出率に
どれだけ違いがあるか比べてみたら？

0482デフォルトの名無しさん

2005/12/12(月) 01:21:37

欠陥検出率ってどう出すの？

例えば、１００個のテストパターンがパスしたがバグが見つかった。
１００個のテストパターンで５０個のバグが見つかった…

0483デフォルトの名無しさん

2005/12/12(月) 10:35:31

ユニットテスト(xUnit)って同じテストを繰り返し何度でもできることがメリットじゃないの？
なんか上の方で人がテストした方が早いって言ってるのがいるけど、
人間が同じテストを何十回、何百回もテストすることなんてできるん？しかもテストツール以上の早さで。
俺なら絶対できないな。
つーわけで俺はテストツールは非常に役に立ってますわ。

0484デフォルトの名無しさん

2005/12/12(月) 12:35:20

で、
>>483 はどんなテストツールつかってんの？

0485デフォルトの名無しさん

2005/12/12(月) 14:27:06

483 じゃないけど、普通にxUnit とかで 483 が言ってるレベルの効果は得られるんじゃないの。
逆にそれができないテストツールってどういうツールなのか想像できん。

0486デフォルトの名無しさん

2005/12/12(月) 21:28:57

テストの対象となるアプリの種類にもよるが、

人手：　テスト仕様書さえあれば比較的すぐにテストを開始できるが繰り返しに弱い

自動：　テスト仕様書とテストプログラムを準備するまでに相当時間がかかるが一度出来ると繰り返し最強

0487デフォルトの名無しさん

2005/12/12(月) 22:45:56

>テスト仕様書とテストプログラムを準備するまでに相当時間がかかるが

テストドリブンならそんなことはあり得ないんだが...
実コードができないはずda

0488デフォルトの名無しさん

2005/12/12(月) 22:57:22

つーか、大規模ソフト設計でテストドリブンで成功したプロジェクトってあるの？

0489デフォルトの名無しさん

2005/12/12(月) 23:32:58

３年ぐらい前から派遣で50人～100人ぐらいのプロジェクトをいくつか携わったが成功したのは見たこと無かったよ。
最後はみんなデスマ。でも漏れは途中で抜けて川口で性交。

0490デフォルトの名無しさん

2005/12/12(月) 23:41:53

テストドリブンは基本的には少数精鋭プロジェクトに向いていると思うな。
というのも、プロジェクト規模の問題ではなく、
テストを前提にした設計ができ、テストファーストプログラミングができる
PGをそうそう高いレベルで大量に集めるのは現実的に不可能に近いモノがあると思うから。
よくありがちな大規模プロジェクトでは、それだけのスキルを持った奴は
アーキテクト部隊など、ごく一部のみ。

0491デフォルトの名無しさん

2005/12/13(火) 02:51:40

ドリブンとか発してる奴、キモイ

0492デフォルトの名無しさん

2005/12/13(火) 02:57:55

XUnitで記述する手続きより、人間の手動操作の方が
簡単になるような単体テストってどんなもんになるのか
全く想像がつかないんだが。
XUnitにソースコード記述するのががもっともテスト準備
工数少ないんじゃないか？

上の人のいってるテストケースってどんなんだ？

0493デフォルトの名無しさん

2005/12/13(火) 07:13:25

そんなに素晴らしいツールなら東証に売り込みに逝けよ

0494デフォルトの名無しさん

2005/12/13(火) 08:04:23

ぶっちゃけスーパープログラマしか使いこなせない
プログラミング手法なんて何の役にも立たないわけですよ。
単体テストなんて馬鹿でも書けるんですよ。気持ちの問題
なわけですよ。テストファーストはデグレを発生させちゃうかもしれない
馬鹿のためにあるんですよ。なんか勘違いしてる人がいるみたいだけど。

0495デフォルトの名無しさん

2005/12/13(火) 08:14:53

>>492
GUI関連の操作とか・・・画像処理関連とか・・・

0496デフォルトの名無しさん

2005/12/13(火) 10:31:06

テストファーストは設計、製造、テストがある意味同時進行で
積み上げられていくものだと思うから
SE、PG（設計者、コーダー）って区分けされてるようなプロジェクトでは
実践不可能だろうし、自動テストを書いたとしても
コストの高い退行テストツールにしかならないのでは？

0497デフォルトの名無しさん

2005/12/13(火) 10:43:31

テストファーストは、テストと実装を分けて考えるのではなく
コーディングテクニックの一つぐらいに考えておくのが吉。
仕様をきちっと決めてからコードを書くから、「これでいいかな？」と
迷うこともなく、書いたコードに対して安心して「これで良し！」と思える。

0498デフォルトの名無しさん

2005/12/14(水) 03:31:53

ttp://www.amazon.co.jp/exec/obidos/ASIN/B00005UC51/249-2544756-7425905

0499デフォルトの名無しさん

2005/12/14(水) 12:37:55

>>498
ｷﾗｰﾚｽ乙

0500デフォルトの名無しさん

2005/12/14(水) 13:23:24

東証のシステム開発でテストツール使ってたとして、
1円株発行の特殊なケースでは取り消し出来ないのが仕様だとして、
テスト実行して「これで良し！」にしかならなかったと思う。

教訓：
仕様にバグがあるかどうかまではテストされない。

0501デフォルトの名無し

2005/12/14(水) 15:04:51

LMSアルゴリズムを使ってスピーカの特性を調べていますが
その評価方法がわかりません。
教えて下さい、

0502デフォルトの名無しさん

2005/12/14(水) 21:33:08

東証よりFUJITSUに売りに行け

0503デフォルトの名無しさん

2005/12/14(水) 21:37:50

>>500
そりゃそうだろｗ

0504デフォルトの名無しさん

2005/12/15(木) 06:05:30

>>500
与謝野金融相に仕様確認できねーしなｗ

0505デフォルトの名無しさん

2005/12/17(土) 19:35:08

テストツールって仕様変更に弱くね？
一度やったテストを何で２回やるの？馬鹿じゃね？
とか思う俺様でもテストツールの魅力がわかる本を教えてください。

0506デフォルトの名無しさん

2005/12/17(土) 19:41:46

仕様変更でまったく影響受けない部分についてはそのとおり、無駄。
でも、変更によって影響を受けるか受けないか微妙なラインの部分いついては有効。
ちょっと考えりゃ分かることだな。

0507デフォルトの名無しさん

2005/12/18(日) 01:55:52

影響あるかどうか人間が目視したり、仕様通りかどうか
再確認したりする手間を省けるから意味はあるよ。
ボタン1つで、前のコードのままで影響ないことが保証される。
もちろん単体レベルの話しだけどね。結合以降のテストは、また別な話。

0508デフォルトの名無しさん

2005/12/18(日) 03:42:29

GUIでも出来ますか？
ボタンの位置とかデザインが変わってしまっても大丈夫ですか？

0509デフォルトの名無しさん

2005/12/18(日) 03:56:39

単体テストで、
> ボタンの位置とかデザインが変わってしまっても大丈夫ですか？
に影響を及ぼすように書かれたプログラムってヤダなぁ。。。

0510デフォルトの名無しさん

2005/12/18(日) 06:58:04

メンドウでも回帰テストは重要だぞ。
影響部分を見抜けなかったら大変だ。検査制度の見直しが要る。

0511デフォルトの名無しさん

2005/12/18(日) 07:19:51

>>508
GUIでも、1ピクセル？単位で比較検証するツールを使えば良い。
GUIの挙動を検証したかったらマウスポインタの自動化ツールでテスト可能。
ま、まだGUI検証の分野は確立されていない部分だから、これを自動化する
手段や方法を決めて、それを実装したら、名が売れるよ。

0512デフォルトの名無しさん

2005/12/18(日) 09:21:08

だから正月に勉強するから入門書を教えてヽ( ﾟдﾟ)ﾉｸﾚﾖ

0513デフォルトの名無しさん

2005/12/19(月) 00:20:14

>>511
すべての画面遷移パターンの検証を自動化できたら神だろうけど・・・

検証ツールに比較させるためのパターンデータの作成と仕様変更時の改修に
かかるコストが大きすぎて無理っぽいな。微少なドットずれにはパターン認識で
対処させようにも、ウィンドウの表示内容に変化部分があると使えない方法だし。
ウィンドウ意匠と表示する文言が常に一定なメッセージボックスなら別だが・・・。

検証対象の画面数とパターンが少なければ人手による目視確認の方が迅速・確実だな。
それ以外でも人間の認識能力には勝てない。

0514デフォルトの名無しさん

2005/12/19(月) 00:40:09

>すべての画面遷移パターンの検証を自動化できたら神だろうけど・・・

>検証ツールに比較させるためのパターンデータの作成と仕様変更時の改修に
>かかるコストが大きすぎて無理っぽいな。

そのあたりの問題は、普通の単体テストでも変わらないぞ。
そのために様々なテスト最適化手法があるわけで。

0515デフォルトの名無しさん

2005/12/19(月) 00:56:59

>>512
「JUnit イン・アクション」なんてのはどうでしょうか？
テスト手法勉強したい方は普通には出来ると思っているので、
多少難ありとは思いますが、
読み進めることが出来ると思います。

いかかでしょうか。

0516デフォルトの名無しさん

2005/12/19(月) 02:42:07

>>513
そこは発想を変える必要があると思われる。
画面に表示されるものを「目視」するという先入観にとらわれすぎ。
固定概念とも言える。
画面とて、表示される前の「状態」がある。その状態と検証対象の状態を
比較できたら、パフォーマンスやコストの問題はなくなると考えられる。
うまく言えないが、どの時点で比較するかがキーとなるだろう。
目に見えるものが全てじゃないことは、俺らの方が良く知ってるはず。

0517デフォルトの名無しさん

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

0518デフォルトの名無しさん

2005/12/19(月) 17:37:33

.NETのテストツール関係（NUnit等）の書籍は今のところ洋書しかないですかね？

0519デフォルトの名無しさん

2005/12/19(月) 22:47:21

テストさえも本見ないと書けないお馬鹿ちゃんなのかい？

0520デフォルトの名無しさん

2005/12/19(月) 23:11:03

>>518
http://www.amazon.co.jp/exec/obidos/ASIN/4891004428/

0521デフォルトの名無しさん

2005/12/20(火) 11:37:41

このスレでは時々 >>519 みたいな発言が出るが、理解に苦しむ。
少なくとも『JUnit インアクション』『リファクタリング』ぐらいは隅々ま
で精読しないと、まともなテストが書けるとは思えない。

単体テストツールは、従来のテスト要員の作業を自動化したものじゃない。ま
たそれらを完全に置き換えることもできない。
むしろ、設計、コーディングのための新しいツールと見るべきもので、しかも
その適切な使い方を身につけるにはかなりの努力が必要だと思う。

0522デフォルトの名無しさん

2005/12/20(火) 11:57:00

>>520
ttp://www.amazon.com/gp/product/0735619484/qid=1135046881
の邦訳ですよね。評価が分かれてるみたいですけど良書なんでしょうか？
520さんは読みました？

0523デフォルトの名無しさん

2005/12/20(火) 14:36:39

ずれているかも知れないけど。
テストで一番大事なのはテストケースの設計なのではないのですか。
従来のテスト手法にしろテスト駆動にしろ、
ツール（とか環境）はツール（とか環境）に過ぎないのでは？
品質向上という錦の御旗は、テストをきちんとすることによって発生する効果だと考えていて正しいですか？

0524デフォルトの名無しさん

2005/12/20(火) 14:44:04

あと、テストしやすい設計な。

0525デフォルトの名無しさん

2005/12/20(火) 16:32:29

まあ、そのあたりを「承知の上」で、
どういうテストケースがあって、どのように役に立つかとか、
うまく使うためのノウハウなんかを話すのがこのスレの本来の目的では？

0526デフォルトの名無しさん

2005/12/20(火) 16:41:06

おいらはそういう話が目的でROMってたんだが、
どうもテストをすること自体の是非(極端に言えばTDDの是非)の話が多いよねぇ。
テストツールを使うべきなのか(TDDに切り替えていいのか)悩んでいる人が多いっつー事の現れとも言えなくないだろうけど。。

0527デフォルトの名無しさん

2005/12/20(火) 21:19:11

テストって言うからいけないんだ、あれは動かせる仕様書なんだ、と言う意見を以前どっかの日記で見た。俺も同意する。

0528デフォルトの名無しさん

2005/12/20(火) 23:37:58

>>524
設計者が昔気質な組織でドキュメント無しだと最悪だ。
モノじゃなくて組織や設計者の批判になってテストにならない。

0529デフォルトの名無しさん

2005/12/21(水) 00:09:43

某本からの受け売りなんだが、

ＴＤＤが少人数設計に向くのは確か
大人数設計になればなるほどＴＤＤの経験者でかつしっかり理解しているプロジェクトリーダーが必須（これはＴＤＤエンジニアがまだ少ないため）
やるからには徹底的にＴＤＤしないと駄目
（中途半端な導入だと結局失敗し、およそＴＤＤではないのにＴＤＤで失敗したかのように取られ、それみろやっぱりＴＤＤは駄目という誤った先入観を生んでしまう）

上記の説明は、ＴＤＤをＸＰに置き換えてもＯＫ

0530デフォルトの名無しさん

2005/12/21(水) 00:15:12

オフサイドトラップの理解できないDFを入れてそれを仕掛けてはならないってことだね

0531デフォルトの名無しさん

2005/12/21(水) 11:54:00

>>530
なるほど～。

0532デフォルトの名無しさん

2005/12/26(月) 01:02:02

趣味のプログラミングにはＴＤＤがいいよ。
一人で開発するのにドキュメント整備なんかしないし、
とりあえず思いつきで作った部分でも後からの変更に耐えられるようになるし。
まさに動く仕様書。

0533デフォルトの名無しさん

2005/12/29(木) 15:12:39

>>532
一人で開発するにしても忘れるから
ドキュメントは必要。きっちりしたものを作る必要はない。

一人で開発って、まさかサンプルプログラムの
ことじゃないよね？300Lineくらいの。

0534デフォルトの名無しさん

2005/12/29(木) 17:34:03

TDDてﾅﾆよ？

0535デフォルトの名無しさん

2005/12/29(木) 17:36:07

>>534
http://e-words.jp/w/TDD.html

0536デフォルトの名無しさん

2005/12/29(木) 17:39:58

このスレで TDD ったらテスト駆動開発（test driven development）の事なんでは？

去年ぐらいからテスト駆動開発のテストは、従来のテストとは違うってんで
behaviour driven development とか呼ぼうとか言われてるらしいけど。

0537デフォルトの名無しさん

2005/12/29(木) 17:50:26

テスト==作ったものに対する検査
という思いこみタップリな、
頭ガチガチの奴がいると（特にマネージャや客先）
テスト駆動型開発はうまくいかない。

0538デフォルトの名無しさん

2005/12/31(土) 17:46:34

テストツールって戻り値しかテストできないんでしょ？
どうせデバッガーが必要になるからテストツールいらね。

0539デフォルトの名無しさん

2005/12/31(土) 18:19:40

　　　　　　∩ 　_,　,_ 　　
　　　　　 ⊂⌒（ﾟдﾟ）　／)　　　　
　　∩　_,　,_ ｀ヽ_つ ⊂ノ　(　⌒ヽつ　　
⊂⌒ （ﾟдﾟ）　　　　　 ⊂（ﾟдﾟ）つ. ∩　_,　,_　　
　｀ヽ._つ⊂ノ　　　　　　　　　　　　 ⊂⌒（ﾟдﾟ ´）　
　　　／) 　　　　　　　　　　　　　　／)゛｀ヽ.つ⊂ノ
　　(　⌒ヽつ　　　 ∩　_,　,_　　(　⌒ヽつ
⊂（ﾟдﾟ）つ. ⊂⌒（　ﾟдﾟ）⊂（ﾟдﾟ）つ
　　　　　　　　　｀ヽ._つ⊂ノ　

0540デフォルトの名無しさん

2006/01/01(日) 00:06:20

TDDにおけるテストとは実装に対する契約書なんだけどな。

ドキュメントは詳細になればなるほどソースコードの変化についていけなくなる。
そこで、ドキュメントファーストという考え方を徹底させ、全員がこれを守るとする。
すると、この問題は解決する。
ハイ！では、同じコンテキストでテストファーストについても考えてみよう。
まぁ、そういうこと。

0541デフォルトの名無しさん

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― 人＿　　　〉
　　　　　　　　　|　ヽ∠＿,止ｧ´_ﾐ/＿＼厂
　　　　　　　　　|　ｰ<　　　　￣｀　　/ヾ
　　　　　　　　　＼　　｀＞.､　　　 /　"ヽ
　　　　　　　　　　｀爪｀ｰ-｀＞ー'´　　仏
　　　　　　　　　　　/　　　　　　＿　- ￣　ヽ

0542デフォルトの名無しさん

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― 人＿　　　〉
　　　　　　　　　|　ヽ∠＿,止ｧ´_ﾐ/＿＼厂
　　　　　　　　　|　ｰ<　　　　￣｀　　/ヾ
　　　　　　　　　＼　　｀＞.､　　　 /　"ヽ
　　　　　　　　　　｀爪｀ｰ-｀＞ー'´　　仏
　　　　　　　　　　　/　　　　　　＿　- ￣　ヽ

0543デフォルトの名無しさん

2006/01/03(火) 11:24:13

TDDにおけるテストとは実装に対する契約書なんだけどな。

何を実装すれば良いのか、先に取り決めするだろ？
(どうやるかは実装する側が後で考える)

まぁ、そういうこと。

0544デフォルトの名無しさん

2006/01/03(火) 13:00:24

どうせ
とちゅうで
仕様が
コロコロかわるんだろ

というのが現場の大方の意見ですたが、何か

0545デフォルトの名無しさん

2006/01/03(火) 13:11:16

仕様が変わることと何か関係があるのですか？

仕様が変わればその仕様に合ったテストケースを作って、そして実装するのがテストファースト。
たとえ仕様が変わっても、コーディングする時点では何を書くか決めなければならないでしょ？

0546デフォルトの名無しさん

2006/01/04(水) 11:38:19

DejaGNUってどうよ？　他に似たようなのある？

0547デフォルトの名無しさん

2006/01/04(水) 20:37:47

同じコンテキストでテストファーストについても考えてみた。

テストは詳細になればなるほどソースコードの変化についていけなくなる。
そこで、テストファーストという考え方を徹底させると、全員がこれを守らなくなる。
すると、このテストファーストは自壊する。
まぁ、そういうこと。

テストファーストって正常系のテストだけでいいの？

0548デフォルトの名無しさん

2006/01/04(水) 21:37:12

なかなかいい質問だね（ﾟ∀´）bｸﾞｯ
それはTDDを初めて知った人が一番最初に気になることなんだっ
そのためにほとんどの解説ページや書籍ではそれを一番最初に説明しているんだっ
レッツ!!エンジェイ!テストファースト・ライフ!!

0549デフォルトの名無しさん

2006/01/04(水) 21:47:56

>>547
結局テスト書くの人間だから
無計画なTDDは破綻以外ない

0550デフォルトの名無しさん

2006/01/04(水) 22:22:28

> テストファーストって正常系のテストだけでいいの？

はぁ？
例えば無効なパラメータを与えたときにあぼーんしない、とかはテストしないって事？
ばかじゃねーの？

0551デフォルトの名無しさん

2006/01/04(水) 22:24:41

無効なパラーメタか渡されるかどうかなんて実際わからないじゃん。
ばかじゃねーの？

0552デフォルトの名無しさん

2006/01/04(水) 22:34:12

ヴァカは >>551だ。
呼ばれる側の都合を考えてはいけないのが原則。

0553デフォルトの名無しさん

2006/01/04(水) 22:34:24

> 無効なパラーメタか渡されるかどうか

想定の範囲外のパラメータ、って意味？
確かにそれがわかるわきゃねー

ま、とりあえず想定の範囲内でテストしとけ > ばかども

0554デフォルトの名無しさん

2006/01/04(水) 22:35:06

そんなこともわからないなんて、
ばかじゃねーの？

0555デフォルトの名無しさん

2006/01/04(水) 22:35:46

ばかじゃん

0556デフォルトの名無しさん

2006/01/04(水) 22:41:15

そもそもテストファーストなんて御伽噺ありえないんだよ
ばかじゃねーの？

0557デフォルトの名無しさん

2006/01/04(水) 22:42:40

お兄ちゃんのばかーーーーっっっ！！！！

0558デフォルトの名無しさん

2006/01/04(水) 22:49:27

お兄ちゃんがばかなことと何か関係があるのですか？

0559デフォルトの名無しさん

2006/01/05(木) 01:10:13

ないのですか？

0560デフォルトの名無しさん

2006/01/05(木) 01:13:32

無効なパラメータを渡された場合の仕様を明確にしてあればテストするし
してなければテストしない。

0561デフォルトの名無しさん

2006/01/05(木) 19:18:11

なるほど。「仕様通りにテストする」というわけですな
どんなことになっても仕様書に責任を押し付けられるから安心なわけだ
・・・それで本当にいいの？

0562デフォルトの名無しさん

2006/01/05(木) 19:27:40

Winrunnerの値段てどれくらいですか？

0563デフォルトの名無しさん

2006/01/06(金) 00:39:08

>>561
仕様書に責任を押し付けるんではなく、仕様書を契約書として責任の
切り分けをはっきりつける目的でやってる。
いままでIFの仕様があいまいで想定外の作業をやらされてきたことが
たくさんあったからその自衛策のつもり。
（まぁ自分が決めた仕様があいまいだったのが悪いわけだけど・・）

0564デフォルトの名無しさん

2006/01/06(金) 00:53:18

>どんなことになっても仕様書に責任を押し付けられるから安心なわけ
はぁ？

「無効なパラメータ」ってのがあらかじめ分かるならな
仕様として
・無視する(何もリアクションしない)
・何かリアクションする(例外、エラーコードetc.)
以外にありえないだろ

このやろー

0565デフォルトの名無しさん

2006/01/08(日) 15:58:15

テストツールって何使ってる？
C++で教えて

0566デフォルトの名無しさん

2006/01/08(日) 16:03:47

>>565
http://www.opensourcetesting.org/unit_c.php

0567デフォルトの名無しさん

2006/01/11(水) 11:57:15

Canoo WebTest 試してみてるんだけど、verifytext で日本語がマッチしない
のよね。UTF-8 でも Shift_JIS でもダメポ。

誰かできたってひといないかしら?

0568デフォルトの名無しさん

2006/01/13(金) 02:57:17

>>565
cppunit+河童

0569567

2006/01/24(火) 19:00:37

Canoo WebTest 1.6 ならそのままで verifytext での日本語も動作した。

1.6 で HttpUnit ベースだったのが、1.7 になって HtmlUnit ベースに
変更されたのだが、そのときに動かなくなったようだ。仕方ないのでソ
ース持ってきて適当に直したところ、動くようにはなった。

以上、チラシの裏でした...使ってる人いないのだろうか...。

0570デフォルトの名無しさん

2006/02/17(金) 12:58:28

JUnit4.0 リリースage
junit.orgにはまだ書いてないけどsf.netにはあがってる。

Eclipseに入るのはいつかなぁ

0571デフォルトの名無しさん

2006/02/18(土) 10:11:15

>>570
JUnit4のパッケージがorg.junit.*で、
昔のパッケージjunit.framework.*になってるから、
わかりやすいと言えばやすいけど、なんか美しくないなぁ
新パッケージ側が旧パッケージ側にいろいろ依存してるし

Eclipse入りはv3.2の予定だそうな

0572デフォルトの名無しさん

2006/02/19(日) 20:51:44

テストツールをおべんきょしたいんだけど、
いい本ないですか？
一応C++がメイン、それ以外の言語も必要あれば使うって感じです。

0573デフォルトの名無しさん

2006/02/20(月) 23:35:13

なんかあってから対応すりゃいいじゃん。テスト代浮くし

0574デフォルトの名無しさん

2006/02/21(火) 00:22:17

事故に遭ってから保険かけりゃいいじゃん。保険料浮くし。

0575デフォルトの名無しさん

2006/02/21(火) 00:22:32

>>573
なんかあってからだと対応できないって。
普段から学習しとかないと。
特に泥縄は通用しない分野だなあ、と周りの人間見てて思う。

0576572

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.を買うことにするですです

0577デフォルトの名無しさん

2006/02/21(火) 10:17:24

>>576
その本を買った人間としてお薦めできません。内容が薄すぎます。
ツールの紹介でしかなく、テストの技法についてはほとんど触れていません。
多分半月で不要になるでしょう。

私の場合、先にJavaとJUnitの理解が多少あった状態で読んだのと、
RubyやC++などの言語の記事は流し読みしていたので
そう感じたのかもしれませんが。

CppUnitについてはWeb上に結構役立ちそうなページが見つかるので、
書籍ではなくそちらを見た方がいいような気がします。

0578デフォルトの名無しさん

2006/02/21(火) 10:36:49

>>574
保険を引き合いに出すのはどうかと。保険は何かあったとき
金と言う形で保障してくれるが、山ほどテストやっても
後から出た不具合はフォローしてくれないよ。

>>575
そういう分野でやってる人は尊敬する。飛行機の自動運行とか
原子力発電所の制御とか、お疲れ様

0579デフォルトの名無しさん

2006/02/22(水) 00:06:55

>>578
自動車にかけてる保険は、自宅の火事をカバーしてくれませんがなにか？

0580デフォルトの名無しさん

2006/02/22(水) 10:08:07

火災保険もかければ？
ついでに地震保険や盗難保険、ガン保険にも入っとくといい。
保険は無敵

0581デフォルトの名無しさん

2006/02/22(水) 14:18:05

超外出臭いけど、ユニットテストって、
コピペしまくりになりがちなんだけどどうしてる？

そんで、ちょっとの仕様変更やバグで、
コピペ箇所みんな直さなくちゃいけなくなる。

0582デフォルトの名無しさん

2006/02/22(水) 16:50:15

>>581
テスト対象を抽象化するレイヤーを一枚はさむ。　仕様変更はその
レイヤーで吸収。　

0583デフォルトの名無しさん

2006/02/22(水) 19:55:40

テストしたいのなんて、マルチスレッド時の挙動がほとんどだ。
マルチスレッドのテストできるツールが欲しい。
リソースの保護し忘れとか、
デッドロックの可能性とか自動的に検出してくれるやつ。

0584デフォルトの名無しさん

2006/02/22(水) 19:55:58

厨小化キター━(ﾟ∀ﾟ)━!!

0585デフォルトの名無しさん

2006/02/22(水) 20:02:54

>>583
VTuneやスレッドアナライザーは？

0586581

2006/02/22(水) 22:16:52

>>582
テスト対象を抽象化するレイヤー？
仕様書としてのメリットを損なうように聞こえるけど、
もっとkwsk

0587582

2006/02/22(水) 22:48:39

>>586
通信機器の開発やっててテストは使う立場で自分で書いているのではないが、
うちの品質管理の連中はobjective TCLでテストを書いている。　機器の設定、
状態などを様々なTCL objectとして表し、それを操作、検査することでテストを
書いている。

実際にそれぞれのobjectがどうやってそれらを機器に反映させたり状態を引っ張って
来るかはそれぞれのobjectの実装だからそれらの仕様が変わってもトップレベルの
テストのスクリプトは大抵変える必要ない。

0588581

2006/02/23(木) 00:12:59

なるほどMockの話か。しかし、
Mockは地面から離陸することは出来ても、コピペ地獄にはどういう風に役に立つ？
というか、仕様変更って地面の方が変わるんじゃなくて、
自分自身以上のレベルの変更の事なんだけど。

0589デフォルトの名無しさん

2006/02/23(木) 01:32:17

テストケースもリファクタリング汁！
重複は悪

0590デフォルトの名無しさん

2006/02/23(木) 12:53:42

そのリファクタリングの勘処が分かんないんだよ
普通にやったら仕様書として訳分からなくなるし、
処理じゃなくて特定のメソッドを使うのが目的だから
普通にやってそのメソッドを使わなくなっちゃしょうがない。

0591デフォルトの名無しさん

2006/02/23(木) 13:37:04

Boost.Jamは結構簡単に使えた
こりゃ便利

0592デフォルトの名無しさん

2006/02/28(火) 04:31:19

VSのwebの自動テストは便利そうだけど

0593デフォルトの名無しさん

2006/03/12(日) 23:32:57

JUnit4ってEclipse3.1.xで使用する事はできますか？
その際何か特別な設定など必要でしょうか？

0594デフォルトの名無しさん

2006/03/13(月) 02:56:20

>>593
http://jroller.com/page/eu?entry=running_junit_4_test_cases

0595デフォルトの名無しさん

2006/03/13(月) 21:06:24

cgiのテストツールで
HTTPポストを簡単に送信できるのないかな？
データと項目名だけ設定して実行できる

0596デフォルトの名無しさん

2006/03/13(月) 21:12:15

>>595
HttpUnit

0597http://www.vector.co.jp/soft/win95/util/se072729.html

2006/03/18(土) 21:02:37

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

0598デフォルトの名無しさん

2006/03/18(土) 22:42:46

>>597
マルチ + スレ違い乙

0599デフォルトの名無しさん

2006/04/07(金) 19:05:09

Pythonにはdoctestって標準でよさげなのがあるんですが、
Javaでもjavadocにテスト書けるようなのってありませんか？

0600ハーピィ

2006/04/10(月) 22:33:46

E・∇・ﾖﾉｼ　＜600ｹﾞｯﾄ♫

0601デフォルトの名無しさん

2006/04/12(水) 00:35:13

↑うぜぇ

0602デフォルトの名無しさん

2006/04/28(金) 19:37:21

CppUnitは環境整えるのに面倒臭いんで、boost::testにしますた。
ヘッダファイルだけインクルードすりゃ使えるし、(L)GPL汚染もないし。

0603デフォルトの名無しさん

2006/05/06(土) 12:23:18

JUnit 4.1 release age

0604デフォルトの名無しさん

2006/05/09(火) 15:47:32

TDDは
Test Driven Developmentっていうより
Test Driven Designにした方が
誤解が少なくなるように思う。スレ違いだけど

0605デフォルトの名無しさん

2006/05/10(水) 02:04:17

別にデザインが目的じゃないからなぁ

BDD（Behavior Driven Development) の方がまだましじゃ

0606デフォルトの名無しさん

2006/05/11(木) 13:54:14

TDDとかBDDとか、ホントにやってる奴っているの？
無駄に工数３倍以上掛かると思うんだけど。

　・　メソッドレベルの詳細仕様なんてぐるぐる変わる
　→　その度に大量のテストコードから直すので、工数数倍

　・　そもそも、レビューちゃんとやってるから、
　　　単体テストなんて、いちいちドライバなんて作らずデバッガでさっさがやっちまう。
　→単体レベルのコーディングバグなんてほとんど無い。
　　　実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
　　　結合以後に現れる。

0607デフォルトの名無しさん

2006/05/11(木) 23:36:51

＞レビューちゃんとやってるから

＞単体レベルのコーディングバグなんてほとんど無い

なんだかよくわからないがすごい自信だ

0608デフォルトの名無しさん

2006/05/12(金) 02:27:02

>>606
>・　そもそも、レビューちゃんとやってるから、
>単体テストなんて、いちいちドライバなんて作らずデバッガでさっさがやっちまう。
なんかすげー珍妙な理屈だな。
～からの前後がまったく繋がってないように見えるんだが。
それとどれだけすげーレビューやってんだ？

>　→単体レベルのコーディングバグなんてほとんど無い。
単体のコーディングやテストの効率とか無視かい？
一度書いたらもうテスト全部パスできる自信あるのかい？違うだろ？

>　　　実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
>　　　結合以後に現れる。
単体レベルで検証しっかりしておけば
結合でしょうもないのが出るのを減らせるんじゃないの？

0609デフォルトの名無しさん

2006/05/12(金) 02:44:41

>　メソッドレベルの詳細仕様なんてぐるぐる変わる
抽象に依存汁！

>　そもそも、レビューちゃんとやってるから
完璧な設計が間違っている場合がある

0610デフォルトの名無しさん

2006/05/12(金) 02:49:03

>>608
レビューはセルフレビューと、話聞きながら勝手にソース読んで突っ込むだけ。いたって普通かと。

＞単体のコーディングやテストの効率とか無視かい？
自動で全仕様を満たすケースを実行できるようなの書くより、
デバッガで値いじったりしてやった方が圧倒的に早い。

＞一度書いたらもうテスト全部パスできる自信あるのかい
だから、レビューもするし単体テストもしないとは言ってない。
自動で全仕様を満たすケースを実行できるようなユニットテストプログラムを書かないと言ってるだけ。

＞単体レベルで検証しっかりしておけば
だから、現実のバグは単体レベルの仕様自体に既に問題があるのがほとんどなんだから、
問題がある仕様にあってることを検証しても防げない。

0611デフォルトの名無しさん

2006/05/12(金) 02:49:50

>>609
言ってる意味が全く分からない。

0612デフォルトの名無しさん

2006/05/12(金) 03:12:08

ツールを使えば手間じゃないと思うんだが。

0613デフォルトの名無しさん

2006/05/12(金) 03:18:10

実際のバグのうち、純粋なコーディングのミスなんて１割以下だろ。
他の部分と仕様の認識にズレがあるとか、
存在すら認識されていなかったパターンがあって仕様が対応していなかったとか、
なんらかの環境に関する問題とか、そんなんが残りの９割。

単体テストじゃこの９割は防げない。

すごく難しいアルゴリズムの塊みたいなプログラムなら違うのかも知れないけど、
普通の業務プログラムなんてこんなところだろ？

0614デフォルトの名無しさん

2006/05/12(金) 03:23:01

>>612
なんのツールを使うと、なにが自動化されて、なんの手間が減るの？

0615デフォルトの名無しさん

2006/05/12(金) 03:46:19

>>614
ちょっとは自分で調べてから質問しろよ

0616デフォルトの名無しさん

2006/05/12(金) 07:44:16

デバッグとテストを混同するな

0617デフォルトの名無しさん

2006/05/12(金) 09:25:32

TDDやBDDなんか実際にやってる所なんてないだろ
XPと同様、空想上のお話だよ

0618デフォルトの名無しさん

2006/05/12(金) 09:29:43

>>616
言ってる意味が不明

0619デフォルトの名無しさん

2006/05/12(金) 10:48:19

>>608
＞自動で全仕様を満たすケースを実行できるようなの書くより、
＞デバッガで値いじったりしてやった方が圧倒的に早い。
コードを修正する度に、毎回デバッガで値を弄ってテストするなんて、嫌過ぎ。
基本的に同じ作業を3回以上繰り返す事が判っている場合は、自動化を検討するのが賢い働き方だと思うが。

0620デフォルトの名無しさん

2006/05/12(金) 11:18:08

大半の箇所は3回も繰り返さないし、
3回位ならテストケースをゴリゴリ書くよりデバッガでチョコチョコやった方がはやい。

0621デフォルトの名無しさん

2006/05/12(金) 11:35:24

なんつーか、単体テストの自動化の是非なんて今さらじゃん

今じゃどこの現場でもJUnitかそれに準じるテストツールを使ってるよ

0622デフォルトの名無しさん

2006/05/12(金) 11:46:03

オレはTDDは有用だと思うからオレはやってるけど、別にこれをしないからってダメなわけじゃないよ。
TDDはあくまでも手段だから使わなくても品質のいいものが作れるならそれでいいわけだし。

だからそんなに必死になって自分を正当化しなくてもいいよ。TDDにメリットを感じなければ使わなければいいだけの話。
ここの住人も含めて誰も責めないと思うよ。

なんか見ててかわいそうになってきた。
もっとも、デバッガでちょこちょこやった程度で「テストしました。」なんてうちの部下が言ってきたらやり直しさせるけどね。
>>616ってこと。

0623デフォルトの名無しさん

2006/05/12(金) 12:40:48

>>621
単体テストをしない・するな、なんて言ってないよ。
詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
本当に生産的かどうかを言ってるんだよ。

本当に生産的であるという結論が出てるなら、悪いけどポイントしてくれないか？

>>622
感じるじゃなくて事実を問うているんだよ。
デバッガを使ったらデバッグなのかい？>>616の意味が分からないんだが。
で、やり直しさせる理由は？（まあ、そいつが嘘つきの場合は証拠がなくて困るけど、それは論外だろう）

0624デフォルトの名無しさん

2006/05/12(金) 23:22:08

>>623
デバッガでちょこっとやったとして
その場でバグとかおかしいところを見つけられるかもしれんが、
それ再現するの大変だろ？
仕様の変更があって修正とか入ってもテスト流せば
どこに影響があるとかすぐにわかるし、
客観的に検証できるじゃん。
それとも全部デバッガで手動で見るのかい？
とても繰り返しに耐えられると思えんが。

「デバッガで確認したのでバグはないです」なんて言う奴がいたら
俺なら絶対に吊るし上げする。
あんたの職場がどんなとこか知らんが、
俺はそんなところ恐くて働きたくないね。

0625デフォルトの名無しさん

2006/05/13(土) 01:29:10

デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
それに、仕様の変更があったら、テストケースも直さなきゃあかんだろ。影響なんてわからないじゃん。
しかも折角書いたテストケースがゴミになってまた書き直し。
そもそも、ユニットテストをかっちり書いてたら、モックとか使うから、ほかのクラスへの影響なんてわからないだろ。
（本来の意味の、仕様を変えない）リファクタリングでは確かに、自動で確認できるのはありがたいが、
実際は､レビューでそれなりのレベルになってるから現実に後になってリファクタリングなんてほとんどない。
後からの修正だって、テストなんて気休めでしかないよ。単体テストで引っかかるようなデグレをこく奴は論外だろ。
後からの修正は、熟考とレビューで少なくともコーディングレベルのデグレは殲滅させるのが普通。

で、吊るし上げる理由は？
理由も無く上司の好き嫌いで吊るし上げられるところは怖くて働きたくないなぁ。

って、別に煽るのが目的じゃなくて。
詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
本当に生産的であるっていう、根拠を教えてよ。

0626デフォルトの名無しさん

2006/05/13(土) 02:04:03

＞デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
それだと、誰でもいつでも同じ結果を出せるテストを実施することは難しいだろうな
xUnitを使うメリットとかその辺を知りたければ、こんなところでグズグズ言ってないで適当にググれば？

0627デフォルトの名無しさん

2006/05/13(土) 02:26:01

修正っていうけど
　仕様追加と仕様変更
ぢゃねの？
それ変えたくないところが確かに変わっていないことをテストなしでどうやって保証するのか知りたいな

0628デフォルトの名無しさん

2006/05/13(土) 03:30:56

>>627
毎回すべての項目をデバッガ使って手動テスト&目視確認なんだろ。
または、ちゃんとレビューしているという妙な自信から、思いつく部分以外は
確認しないとか。

＞デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
>>626に同意だわ。再現性の違いがわかってない奴が手動テスト&目視確認。
あーこわ。

0629デフォルトの名無しさん

2006/05/13(土) 11:27:00

>>625
> デバッガでやるか、テストケースをプログラムで書くかで、なんで再現性に違いが出るんだ？
手動で値を入力してデバッガで一々見ながら目視でチェックするのと
テストケース一発流すのとどっちが楽でかつ確実なんだ？
ちょっと考えればわかるだろう？
デバッガを否定しているわけじゃないぜ？
当然俺も使っているし。

> それに、仕様の変更があったら、テストケースも直さなきゃあかんだろ。影響なんてわからないじゃん。
> しかも折角書いたテストケースがゴミになってまた書き直し。
> そもそも、ユニットテストをかっちり書いてたら、モックとか使うから、ほかのクラスへの影響なんてわからないだろ。
> （本来の意味の、仕様を変えない）リファクタリングでは確かに、自動で確認できるのはありがたいが、
> 実際は､レビューでそれなりのレベルになってるから現実に後になってリファクタリングなんてほとんどない。
> 後からの修正だって、テストなんて気休めでしかないよ。単体テストで引っかかるようなデグレをこく奴は論外だろ。
> 後からの修正は、熟考とレビューで少なくともコーディングレベルのデグレは殲滅させるのが普通。
仕様が変わっていない部分にも影響が出てないか検証が必要だろ？
全部デバッガでがっさり確認するのか？
おんなじこと何度も書かせるなよ。
まぁレビューで検証してるからとか言って何もテストしてなさそうだな、
その書き込みを見ていると。

> で、吊るし上げる理由は？
> 理由も無く上司の好き嫌いで吊るし上げられるところは怖くて働きたくないなぁ。
お前さん個人が「デバッガで確認したのでバグはありません」
なんて言っても何の客観性も無いからって書いただろ？
ふざけるなの一言だな。

0630デフォルトの名無しさん

2006/05/13(土) 14:52:25

昔、オールドタイプと同じような言い争いになったな。そいつはクビになったけどｗｗｗ

0631デフォルトの名無しさん

2006/05/13(土) 15:51:46

すみませんが、使える派遣の見抜くためのテストツールって
どこでダウンロードできるのでしょうか？

0632デフォルトの名無しさん

2006/05/13(土) 15:55:53

そーすふぉーぢで探してみればどうですか

0633デフォルトの名無しさん

2006/05/13(土) 17:49:41

おまえら、そんないうほどちゃんとユニットテストやってんのか？
ちなみに俺は、メソッドが１パターン動かす位しかやってねぇ

0634609

2006/05/13(土) 18:04:16

>>611
・メソッドレベルの詳細仕様を変更すると大量のテストコードから修正が必要になるのは
呼び出す側が呼ばれる側の実装に依存しているからである
→呼び出す側は呼ばれる側の変更に影響されないように作るのが常識
　＝抽象(インタフェース)に依存させる、など

・
>実際のバグは、そもそもの部分仕様の前提になんらかのミスがあるってのがほとんどで、
とあるように、単体レベルのレビューをちゃんとやってコーディングバグが0だとしても問題が発生する
　＝完璧な(単体レベルではバグがない)設計が間違っている場合をレビューでは救えない
→早い段階から設計の問題を発見するのが常識
　＝動作するテストを用いて実際に動作させながら設計を行うのがTDD(とかBDD)

結論)も前は非常識

0635デフォルトの名無しさん

2006/05/13(土) 20:15:04

>>634
おまえホントにTDDしてるの？あきれた。空想で語るなよ。

0636デフォルトの名無しさん

2006/05/13(土) 20:16:39

Ｃ++のテストツールって何使ってる？
Windows限定でお願いします

0637デフォルトの名無しさん

2006/05/13(土) 23:44:54

この議論、なんやかんや言って、意外に本質的なところを議論している気がする。
>>623に同意しているわけではないが、テスト対象によっては>>623の言うことが正しい場合があると思う。
なので、「何も考えずに」JUnitでテストコードを全部書くのはたぶんうまくない。

ここでの議論のようなことが、すべてのプロジェクトの内部で行われた結果、
どっちにするか決めているのであれば、それがどっちの答えになろうとも、結構正解
を選んでるんではないか。
まぁ、それをテスト戦略と呼ぶのだろうが。

0638デフォルトの名無しさん

2006/05/14(日) 00:23:15

経験年数を重ねてもどうしても目視で間違いを見落とす人がいるので、
時間は掛かるけど、全体で一定の品質を保つために実践してるよ。
それで、現状の課題は２つ。

　・テストコードのかきっぷり
　　複雑すぎてしまうととホントにテストできているのか確認が難しい。
　　もっとテストしやすい設計を精進すればコレはある程度解決できるかも
　　と感じてる。

　・テストに掛かる工数
　　テストコードを書いておくことによって回帰テストを行う事になった場合に
　　非常に威力を発揮するが、やはり初期工数がより多く掛かってしまう（1.5～2倍)。
　　頻繁に変わる可能性の高いものはxUnitでテスト、それ以外はデバッガとかで
　　確認とか出来れば少しはマシになるかなと思うんだけど、その基準をどうすべきか
　　悩んでる。

0639デフォルトの名無しさん

2006/05/14(日) 00:36:17

うちではユニットテストと搦め手、コードが動作しているか同化も検証している
網羅率って香具師

0640デフォルトの名無しさん

2006/05/14(日) 01:16:06

>>638
>・テストコードのかきっぷり
>　複雑すぎてしまうととホントにテストできているのか確認が難しい。
それがコードもしくは設計を見直すよいトリガになる。

>・テストに掛かる工数
その基準の悩みこそ、テスト改善のミソ。悩むべきところで悩んでいると思う。
それをしないで、どっちの方法がよい！などと断言するのは意味もないと思う。

0641デフォルトの名無しさん

2006/05/14(日) 02:49:45

>>638
その後、実装が頻繁に変わらないぐらいに安定したクラスに対してxUnitをつかってる。
むしろイテレーションの初期は、インテグレーションテストを自動化することに注力したほうが効率的な気がする。

0642デフォルトの名無しさん

2006/05/14(日) 03:08:35

なんか日本語が変だったので書き直し。

むしろ実装が頻繁に変わらないぐらいに安定したクラスに対してxUnitをつかってる。
イテレーションの初期は、インテグレーションテストを自動化することに注力したほうが効率的な気がする。

0643デフォルトの名無しさん

2006/05/14(日) 03:09:57

テストを書くことで人は成長するんだよ。

0644デフォルトの名無しさん

2006/05/14(日) 06:54:02

設計もシンプルになるしね

0645デフォルトの名無しさん

2006/05/14(日) 11:01:21

xUnitの怖いところは、
回帰テストが簡単にできるからと、後からの変更に妙な安心感が出来てしまうこと。
テストは、バグの存在は証明できても、バグの不在は証明できない。
テストケースの網羅性が全然低かったり、モックの動作が実際のオブジェクトとズレが出てても、
妙な安心感のため、慎重さ（ちゃんとした調査・検討）やレビューがおざなりになって、
「オールグリーン確認。問題なし！」とかなりがち。

0646ほそく

2006/05/14(日) 11:05:44

＞「オールグリーン確認。問題なし！」

数百、数千項目がグリーンだとなんとなく強気になるかも知れないけど、
その９割以上はもとから変更箇所と何らの絡みもない全く関係しようがないところなのにね。

0647デフォルトの名無しさん

2006/05/14(日) 11:09:20

シンプルって言葉も、なにかと語弊を生むよね。
粗結合・高凝集な設計を志すと個々の実装はちょっと複雑になりがちだけど
そこがシンプルっていう語感と相容れないからかな。
シンプルな設計と称して、手続き型のプログラムを書いてしまう。
そういうのが一番テストケース書きにくいプログラムなのに。

0648デフォルトの名無しさん

2006/05/14(日) 11:19:05

>>645
＞テストケースの網羅性が全然低かったり

そこでカバレッジ測定ツールですよ。
うちではEmma使って毎日カバレッジ測ってる。
カバレッジ低いコード書くヤツには個別指導…と、行きたいが、そんなに時間がとれないんだよね。

0649デフォルトの名無しさん

2006/05/14(日) 11:21:30

Javaのカバレッジはcloverで測定してるけど、実はデバッグツールとして重宝してたり。
ある経路を想定した回数通過してないのを発見したり。

0650デフォルトの名無しさん

2006/05/14(日) 11:41:04

カバレッジ測定ツールで測れるのは、コード行の網羅性だろ？
=と==のミスとか変数の取り違えとかそんなレベルはそれでOKだけど、
正しいと言えるには、仕様条件が網羅されないと。

0651デフォルトの名無しさん

2006/05/14(日) 12:18:30

ユニットテストでは、ひとつのオブジェクトに閉じて「正しさ」をテストできる。
だが、実際のプログラムでは、
オブジェクトは他の複数のオブジェクトを正しく使わねばならない。

ユニットテストでは、依存先のオブジェクトの使い方が正しいかどうかはあまりテストできない。
これがテストできなければ、そのオブジェクトの「正しさ」をちゃんとテストできてるとは言えない。

0652デフォルトの名無しさん

2006/05/14(日) 16:35:43

払うべきコストの妥当性は「テスト不足で発生するリスクの金額（期待値）」
事象ごとに想定損失額と確率を掛けたものを合計する。

システムの性格により、想定損失額が変わればテストの価格も変化する、
と考えるのは自然なこと。

0653デフォルトの名無しさん

2006/05/14(日) 19:47:03

なかなか難しそうな気が・・・

0654デフォルトの名無しさん

2006/05/14(日) 21:00:26

>>651
Mockじゃだめ？

0655デフォルトの名無しさん

2006/05/14(日) 21:48:34

>>650
コードが仕様を満たしているかどうかは、Fitとかの受け入れテストツールが向いてる。適材適所だ。

>>654
Mockを使う場合、DIできるように設計しとかないといけないからなぁ。
そういう風に設計しておけばいいんだけど。
それでもjMockとか面倒だった。

0656デフォルトの名無しさん

2006/05/14(日) 22:11:37

injectionのためにsetterを用意すると、
情報隠蔽が崩れ、さらに、
コンストラクトされても使えないオブジェクト状態が生まれる諸刃の剣。

そもそも、Mockが実際のオブジェクトと全く同じ振る舞いである保証は？

0657デフォルトの名無しさん

2006/05/14(日) 22:24:09

インターフェース一緒ぢゃん

0658デフォルトの名無しさん

2006/05/14(日) 22:27:36

>>657 ← こういう人ってどうしよう…。

0659デフォルトの名無しさん

2006/05/14(日) 22:53:43

>>656
S2のセッタインジェクションは
implの方にだけsetterを定義しておけば
自動でバインディングしてくれるので、
別に使う側から見て情報隠蔽が崩れてないんちゃう？

Springとか使ったことないのでこのへんどうか知らんけど・・・

0660658

2006/05/14(日) 22:54:45

>>659
なんかいまいちな説明だった。
要するに使う側から見てインターフェースは変わってないってことで。

0661デフォルトの名無しさん

2006/05/14(日) 23:02:31

>>652
自然なことなのにそんなこと考えてないプロジェクトの多いこと。
言うは簡単。

0662デフォルトの名無しさん

2006/05/14(日) 23:11:21

>>656
まさにその「コンストラクトされても使えないオブジェクト」を回避するために
コンストラクタインジェクションってのがある。

0663デフォルトの名無しさん

2006/05/15(月) 00:28:37

>>655
FITって使える？
自分は統合テストも結局JUnitで書いてしまっているんだけど、
FITはテストケースをプログラマ以外の人が作れるだけの
ユニットテストツールにしか思えないんだが。

0664デフォルトの名無しさん

2006/05/15(月) 10:25:51

>>655
単体仕様の確認は？

0665デフォルトの名無しさん

2006/05/15(月) 10:53:39

もう、TDD=悪と決めつけてるから何言っても無駄だな。
だいたいそんなにいやなら使わなければいいのに何でそんなにこだわってるんだ？
誰かになんか言われて悔しい思いでもしたのか？

0666デフォルトの名無しさん

2006/05/15(月) 12:29:05

なんでそうなるんだ？
メリットを聞いてるだけなのに。
メリット云々じゃなくて信仰って事？

0667デフォルトの名無しさん

2006/05/15(月) 23:52:26

TDD=悪と決め付けてる発言がどれか分からん。
そんなこと言った香具師いたの？

0668デフォルトの名無しさん

2006/05/15(月) 23:59:07

>>666
メリットを説明しても理解できない、お脳がスローリィな奴は黙ってろ。

0669デフォルトの名無しさん

2006/05/16(火) 00:03:00

そもそも、Mockが実際のオブジェクトと全く同じ振る舞いである保証は？

0670デフォルトの名無しさん

2006/05/16(火) 00:08:02

TDDの主たるメリットはソースコードのテスタビリティの向上。
テスタビリティの向上はリグレッションテストのカバレッジを高くする。
リグレッションテストのカバレッジが高くなるとエンバグしにくくなるし
リファクタリングがしやすくなる。
リファクタリングがしやすくなるとコードの寿命が延びる。それとコードの
改造にかかるコスト自体が安くなる。

0671デフォルトの名無しさん

2006/05/16(火) 00:13:01

>>669
Mockは「使われ方」をテストするためのもの
Mockの動きが実際のオブジェクトと全く同じ振る舞いである必要はない。

0672デフォルトの名無しさん

2006/05/16(火) 00:16:26

>>606についてはどうなんだ？それにそのメリットが投資を上回るという根拠は？
さらに、カバレッジつっても、コード行のカバー率だろ。詳細仕様のカバー率が必要だろ。

0673デフォルトの名無しさん

2006/05/16(火) 00:19:18

>>671
> Mockは「使われ方」をテストするためのもの
よくわからん。
例えば、あるメソッドが普段は０、特定条件では１を返すオブジェクトを、
常に０を返すモックに変えてテストしたら、特定条件の場合バグってても話下欄だろ。

0674デフォルトの名無しさん

2006/05/16(火) 00:23:04

>>606については散々既出だと思うが。
一人のPGが手作業＆目視で俺様流のテストをして
「大丈夫です」と言い張るのを信用できるかって話しだ。

0675デフォルトの名無しさん

2006/05/16(火) 00:31:23

ということは、TDDが有効なのは、
みんな嘘つきでサボる事しか考えてないやる気のない職場ということだな。

目視つうけど、ユニットテストに誤り無いなんて保証あるのか？
オマエの理屈だと、ユニットテストにもユニットテストが必要だな。
もちろんユニットテストのユニットテストにも、ユニ（以下ry

0676デフォルトの名無しさん

2006/05/16(火) 00:32:00

>それにそのメリットが投資を上回るという根拠は？
常に投資がメリットを上回るということではない。
自動リグレッションテストやリファクタリングが一般的になる以前は
一旦作成されたコードについてテスト工数の関係で仕様変更箇所以外の箇所に
ついてみだりに変更することが困難だった。
そういう制約の中で何度も差分開発を繰り替えすと単位機能あたりのソースコード
の修正コストはどんどん高くなっていってしまう。
それに対し今は「一定のコストを払うことでソースコードの修正コストを引き下げる
ことができる」という選択子が単純に増えたということになる。
イテレーションを何度も回さない開発の場合はテストコードを書く必要はない。

0677デフォルトの名無しさん

2006/05/16(火) 00:36:22

>>673
その普段は０、特定条件では１っていうのが
試験条件なんだから試験項目バグってこと。
インテグレーションテストだろうが、単体試験だろうが
試験項目がバグってたらどうにもならない。

0678デフォルトの名無しさん

2006/05/16(火) 00:38:25

>>675
手作業で再現性のない物と自動化された物を同一視している奴にはそのメリットは理解できんよ。
おまえにとってTDDはメリットは無い。やらなくていいよ。やるだけムダだ。工数かかるし。

0679デフォルトの名無しさん

2006/05/16(火) 00:43:52

>>676
それは単体テストじゃなくて機能テストが必要なのでは？
単体がみんなテストOKでも、>>373とか、>>645-646とか。

>>677
どうにもならないんじゃTDDダメじゃん。

>>678
全然回答にも否定にもなってないね。

0680訂正

2006/05/16(火) 00:44:43

>>676
それは単体テストじゃなくて機能テストが必要なのでは？
単体がみんなテストOKでも、>>673とか、>>645-646とか。

0681デフォルトの名無しさん

2006/05/16(火) 00:45:23

>>673
モックを正しく使っているかのテストであって、
モック自体をテストしているのではないですよ。

モックが０を返す限り、テスト対象のオブジェクトは
その情報に基づいて振舞うのがそのオブジェクトの役割であって、
特定条件でも正しく振舞うかテストするには、
１を返すモックで別のテストをすればいいだけかと。

0682デフォルトの名無しさん

2006/05/16(火) 00:47:41

>>681
そうじゃなくて、モックを作る奴が、１を返す事があると
気が付かないでやっちゃう場合の事を言ってるんだけど。

0683デフォルトの名無しさん

2006/05/16(火) 00:51:52

>>679
単体テストが機能テストでもどっちでもいいよ。
要は、手作業で試験するよりプログラムで試験するほうがトータルのコストが安くなる
ケースがあるってこと。

0684デフォルトの名無しさん

2006/05/16(火) 00:53:54

>>683
それは同意。でもTDDじゃないな。

0685デフォルトの名無しさん

2006/05/16(火) 00:57:24

>>682
Mockが返す値は、試験項目なんだって。
すなわちMockが返す値は試験内容によって決まる。
Mockは「正しく呼ばれたか」をテストするもの。

Mockが返す値が間違っているってのは、試験項目
誤りかまたは試験手順ミスなのだがそれは手作業で
試験をしても発生しうるよね？

0686658

2006/05/16(火) 01:01:24

>>682
そいつはテスト漏れちゃうの？
それともお前さんの大好きな手動テストなら
確実に0と1両方確認できるってのかい？

0687デフォルトの名無しさん

2006/05/16(火) 01:01:29

>>684
>>670でも書いたけど、TDDはコードのテスタビリティを向上させる
働きがある。
はじめからテストしやすいコードを書くのは実は非常に難しくて、
なんの制約もなくコードを書いた（書かせた）後、そのコードにテスト
コードを書くのはかなり骨が折れる。テストしやすいようにコードを
書き直したくなる。

であれば、逆にテストコードを先に書くことによって本編のコードを
テストしやすい形態に強制するのが効果的ってわけ。

0688686

2006/05/16(火) 01:02:32

>>686
あり、なんか投稿者名が・・・
すいません、自分658氏ではないです。どっちでもいいすけど。

0689デフォルトの名無しさん

2006/05/16(火) 01:03:03

>>685
なるほど。でも、実際のオブジェクトを使ってたら、
１の場合を見逃さずに済んだ可能性が高いじゃん？

0690デフォルトの名無しさん

2006/05/16(火) 01:05:23

>>685-686
しかも、手作業だとテストする人によってとかテストする度に漏れが発生したりしなかったりするしね。

0691デフォルトの名無しさん

2006/05/16(火) 01:06:44

無料でカバレッジ分析まで可能なやつってありますか？
C++　Windowsでお願いします

0692デフォルトの名無しさん

2006/05/16(火) 01:09:15

>>686
もちろん100%ではないが、１になる問題の条件が広い（＝起きやすい）ほど100%に近付く。
それに比べてモックを間違ってれば0%だろ？

>>687
それは単体テストの話ではないの？TDD的には。機能テストではなくて。
単体テストの手スタビリティと機能テストのそれは、類似性もあるがやっぱり別物。

0693デフォルトの名無しさん

2006/05/16(火) 01:13:38

>>690
エクセルに条件表作って、みんなちゃんとやってる。すくなくともうちは。
ユニットテストをコードで書いたら、条件が自動的に網羅されるのかい？
ユニットテストコードで、条件が網羅されてる事が保証されてるのかい？

0694デフォルトの名無しさん

2006/05/16(火) 01:16:48

エクセルに条件表かけるなら
ユニットテストのコードに反映できるだろ？
おまけに実施ミスもなし

0695デフォルトの名無しさん

2006/05/16(火) 01:17:43

>>692
あるメソッドが返しうる値の範囲が明確になっていないとすれば、
そのメソッドを使うクラスが正しく実装されている可能性もすごく低いんじゃないか？
結局メソッドの受け取るパラメータの範囲・クラスの取りうるステータス・メソッドの戻す値を
明確化しておくのは何をするのにも前提になる気がするが。

0696デフォルトの名無しさん

2006/05/16(火) 01:17:57

やれば出来るけど工数が勿体ない。

0697デフォルトの名無しさん

2006/05/16(火) 01:19:02

>>692
単体テストでもTDDでもどっちでもよいが、
それではTDDのどういうプラクティスの何が問題?

0698デフォルトの名無しさん

2006/05/16(火) 01:21:26

>>696
俺は694じゃないが、たぶん条件表をかかなきゃいけないほど
複雑なテストならテストコード書いたほうが早くできるケースのほうが多いよ。
慣れの問題もあるけど、イニシャルコストを払う価値はあると思う。

0699デフォルトの名無しさん

2006/05/16(火) 01:21:31

>>695
そのはずなのにミスってる所がバグで、そのためのテストだろうが。
テストの話をしてるのに、テストの意味がない問題ない所の話をしてどうする。

0700686

2006/05/16(火) 01:22:42

>>693
なんかループしてるね、この人・・・
エクセル書いたってミスする奴はミスするよ。人間だし。

>ユニットテストをコードで書いたら、条件が自動的に網羅されるのかい？
>ユニットテストコードで、条件が網羅されてる事が保証されてるのかい？
これそのまま自分たちに当てはまらないか？
俺はエクセルで全部手動の方が信頼できない。

TDDとかテストファーストとかは色々意見があるとは思うけど
ユニットテスト否定するのは久しぶりに見た。
この業界はまだまだ未知の世界があるのぅ！

0701デフォルトの名無しさん

2006/05/16(火) 01:25:54

>>694
落ち着いてよく読み返そうよ。
Mock側のコードがバグってても、Mockはそのバグを検出しないんだって。

0702デフォルトの名無しさん

2006/05/16(火) 01:28:25

>>697
>>606

>>698
そうか？？？
コードだけじゃ、都合良く条件設定しづらいし（テスタビリティとかいってMock使うと
上に書いたとおりだし、Mockかくのも大変だし）、それに、
一発で完璧なテストコード掛ければよいが、実際はつまらんミスやなんやでやり直しが出るし、
テストコードだってバグがある可能性高いし。

0703デフォルトの名無しさん

2006/05/16(火) 01:28:26

ごめんレスアンカー間違えた。
誤>>694
正>>699
落ち着いてないのは俺かｗ

0704デフォルトの名無しさん

2006/05/16(火) 01:32:48

>>702
> Mockかくのも大変だし
EasyMockとかjMock使えばいいんでない？

0705デフォルトの名無しさん

2006/05/16(火) 01:35:34

>>703
>>701がアンカを訂正されても意味が分からん…。

>>704
馬鹿にされるのを覚悟で聞くけど、そういうのって、
ストリームとかスゲー典型的な奴だけじゃないの？
ビジネスロジック内のアプリ固有のオブジェクトとかのモックを秒築できるの？

0706デフォルトの名無しさん

2006/05/16(火) 01:39:19

>>702
ちょっと今までの話とは変わるが、テストコードとテストコードを前提としたコードの記述には
まあなんていうかコツみたいなものは確かに存在して、それを
つかむまで生産性が向上したようには感じられないのは確かだと思う。
俺もそうだったし。

0707デフォルトの名無しさん

2006/05/16(火) 01:46:00

>>699
たぶんだけど、戻り値を返すためのコードじゃなくって
なんらかの処理の「結果として」戻り値を返すような、
設計になってるから戻り値が明確になってないんじゃない？

0708705

2006/05/16(火) 01:48:21

>>704
ちょっと調べてきた。俺のMock理解は相当時代遅れだったようだな。
だが逆に、こんなテストを、しかもテストコードで書いてたら、変更コスト高すぎだろ。

>>706
そうなのか…？それでもデバッガより早くなるとは思いがたいが…。

0709デフォルトの名無しさん

2006/05/16(火) 01:48:49

>>705
ビジネスロジック固有のオブジェクトだろうがなんだろうが
よばれた順番に決められた値を帰すのが典型的なMockだから、
そんなに実装に手間取るはずがない。
スタブと違ってインテリジェントに振舞う必要性があまりない。

0710デフォルトの名無しさん

2006/05/16(火) 01:51:20

>>707
上の返値の話は、わかりやすい例を書いただけで、
普段から何が帰ってくるか解らんようなコードを書いてる訳じゃないって。

0711デフォルトの名無しさん

2006/05/16(火) 01:53:05

>>708
同じようなテストコードを使いまわせるところ以外なら
１回だけならデバッガのがさすがに早いって。
テストコードとは棲み分けが違うよ。

0712デフォルトの名無しさん

2006/05/16(火) 01:55:10

>>709
俺はモックとスタブを区別できていないようだ。
ちょっと調べてくるがしかし、モックに対する見解は>>708。

0713デフォルトの名無しさん

2006/05/16(火) 01:59:03

俺さコードのテストツールより人間のテストツール欲しい
誰か作ってくれないかなぁ。デスマ何時間とか
ファビョ率とかさなんかそっちのほうが重要な気がしてならない

0714712

2006/05/16(火) 02:15:21

調べてきたがやっぱりモックスタイルに対する見解>>708は変わらんし、
実際にテスト書くにはスタブも結局は必要だし、それに対しては上で言ったとおりだなぁ。

>>711
だろ？
で、実際にデグレがない事は単体テストじゃなくて機能テストが必要。
オブジェクト同士の依存を廃してバラバラにテストするのがよい単体テストなら、なおさら。
単体テストを何回もやるって、実際の所、オブジェクトが、そしてテスト自体が独立してたら
あまり意味はないと思われ。そのために工数を割くのはどうかなぁ。
中身が複雑なFacadeとかにはイイかもしれんけど。

0715デフォルトの名無しさん

2006/05/16(火) 02:30:00

>>714
ちなみにあなたの機能テストの定義ってどんなんなの？
ちょっとそこらへんがずれてる気がするんで。
（いや俺だけかもしれないので。煽りじゃなく。）

いくつかオブジェクトを組み合わせて動かしてって意味で言ってるなら
それって機能テストというか
結合テストって言った方がいいんちゃうかなと思うけど。

0716デフォルトの名無しさん

2006/05/16(火) 03:06:44

>>714
いやいやテストコード書くことに意味がないなんて言ってねーよ。

・あまりイテレーションが多く回らない。
・オブジェクト指向でプログラム組まない。
ただ、上のどちらかならxUnitのテストにメリットがない可能性はあるかもしらんが。

0717デフォルトの名無しさん

2006/05/16(火) 07:14:36

理屈こねるより、実際やってみてどういう場合に有用か無用かを知るのが一番いいと思うのだが、
試験的にUnitTestを導入する手頃な案件がないのよね。

0718デフォルトの名無しさん

2006/05/16(火) 07:24:22

>>717がいま、TDDが成り立たないことを実証しました。
所詮、テストまわりから始めるなんてことはできないのです。

0719デフォルトの名無しさん

2006/05/16(火) 07:34:37

>>718
意味が分からないんだけど。馬鹿？

0720デフォルトの名無しさん

2006/05/16(火) 07:37:00

>>718
どうしてそういう結論になるのかまったく理解できない。

この書き込みを「実証」と呼べるような人間には
「テスト」そのものに対する理解も難しいとは思うけどね。

0721デフォルトの名無しさん

2006/05/16(火) 07:38:42

>>719-720
ﾈﾀにﾏｼﾞ(rya

0722デフォルトの名無しさん

2006/05/16(火) 23:30:57

つーか実際、ホントにTDD(テストファースト)なんて、おまえらやってないだろ。

0723デフォルトの名無しさん

2006/05/17(水) 00:27:19

単体テストでも機能テストするっつーの。
ま、>>715の言うとおり、単なる言葉使いの間違いかもしれんが。

0724デフォルトの名無しさん

2006/05/17(水) 00:34:23

>>606がTDDとかって問題にあげてるけれど、TDD関係なく
単なるユニットテストのことを問題にあげてるんだよね？

0725デフォルトの名無しさん

2006/05/17(水) 00:39:16

あぁ、おれもそう思った。
いわゆる「インクリメンタルテストよりもビッグバンテストの方がええわい」
という先カンブリア時代のような話をしているのではないか。

0726725

2006/05/17(水) 00:44:46

と、自分で書いてて思ったけど、
ビッグバンテストが完全に悪いと言えないケースも存在するのかもな。
ほとんどないと思うけど。

0727デフォルトの名無しさん

2006/05/17(水) 00:55:33

だって、どうせユニットテスト書いたって、
そのテスト対象を変更する事なんてあんまないし、
変更する場合はほとんどテストごと書き直しだし。
リファクタリング？完成前にレビューでほぼ完成形になっちゃうからユニットテストの意味なし。

0728デフォルトの名無しさん

2006/05/17(水) 00:58:31

>>606
つーかメソッドレベルの詳細仕様書ってそんなに変わるのかね？
変更がちょっと入るたびに大量のテストコードやり直しで手間が掛かるだけとか
そのへんからなんかおかしい気がするんだけど。

0729デフォルトの名無しさん

2006/05/17(水) 01:00:40

>>727
>リファクタリング？完成前にレビューでほぼ完成形になっちゃうからユニットテストの意味なし。
なぁ、これまじで言ってるの・・・？
レビューってソースコードレビュー？

0730デフォルトの名無しさん

2006/05/17(水) 01:13:02

>>728
詳細仕様「書」っちゅうか詳細仕様は、何度も修正入るだろ。
まずレビューでクラス設計にあとからケチ^H^H改善提案が付くし、
単体テスト終って結合で問題が出たら、クラスがいびつになるとか言ってまた直すし。

>>729
その後のリファクタリングの必要が減るレビューって、ソースレビュー以外に何があるんだ？

0731デフォルトの名無しさん

2006/05/17(水) 01:17:26

POJOとJUnitで書いたテストコードこそが最大の資産である

0732デフォルトの名無しさん

2006/05/17(水) 01:23:16

Seasar信者はｶｴﾚ

0733デフォルトの名無しさん

2006/05/17(水) 01:37:55

ユースケースと要求仕様の違いって何でしょうか？

0734デフォルトの名無しさん

2006/05/17(水) 02:09:38

>730
でもテストが作り直しになるような変更はそう何度もないぞ？
作り方（設計）がおかＰ
んじゃねの

0735デフォルトの名無しさん

2006/05/17(水) 03:10:54

>>730
なんか手戻りが多すぎね？

0736デフォルトの名無しさん

2006/05/17(水) 06:30:38

とりあえずコード書き始めちゃうんだろうな。
で、変更のたびに毎回レビューしてるっぽい。
このレビューだが、テストケースを書くよりも工数少ないの？

0737デフォルトの名無しさん

2006/05/17(水) 08:19:43

なかなか面白い議論してるな。
>>675
>目視つうけど、ユニットテストに誤り無いなんて保証あるのか？

そうなんだよな。>>674で
>一人のPGが手作業＆目視で俺様流のテストをして「大丈夫です」と言い張るのを信用できるかって話しだ。
といってるけど、これって「俺流のユニットテストを流して「大丈夫です」と言い張るのを信用できるか」と言い換えられる。

>>676
>イテレーションを何度も回さない開発の場合はテストコードを書く必要はない。

おれもそう思う。おれは頻繁にコードを修正するからxUnitを使って回帰テストしやすいようにしてるけど、
プロジェクトによってはいったんコードフリーズしたらそのあとは滅多に変更しないという戦略をとってるところもある。
その戦略自体どうよとも思うが、それはおいといて、そういうプロジェクトならユニットテストはあんまりそぐわないし、
デバッガで変数を書き換えてテストする方法でも十分いいと思うよ。

0738デフォルトの名無しさん

2006/05/17(水) 08:27:43

>>625
>詳細仕様を網羅するテストケースプログラムをわざわざ書く事が、
>本当に生産的であるっていう、根拠を教えてよ。

ほんとうに仕様を網羅するテストケースは、実際に作るとコストがすごくかかるし、仕様変更にも弱いから、ふつうはしないんじゃないかな。
おれは、正しい入力ひとつと、あとはエラーチェックにかかる入力をいくつか与えるくらいのテストしかしてない。可能性のある入力をすべて網羅なんて無理。
それでもxUnitによる恩恵は感じる。結局はxUnitだって道具でしかないんだし、使い方だよ。

ユニットテストはプログラム全体に渡ってバグがないことを保証するためのものじゃない。テストしたパターンではバグがないことを保証するだけ。
すべてのパターンを網羅できればそりゃ理想だけど、それは困難だし、そこまでしなくても
典型的なパターンをテストするだけでもバグはぐっと減らせる。
だから>>625が「仕様を網羅するテストケースを用意しなきゃいけない」と考えてるなら、それは行き過ぎのような気がする。
そこまでしなくてもユニットテストは効果あるし、効果ある使い方だけをすればいい。

それにしてもユニットテスト信者うぜーな。昔のEJB信者とおなじぐらいうざい。

0739デフォルトの名無しさん

2006/05/17(水) 09:48:58

>>736
テストケースのコードによって、
「俺流のユニットテスト」が何をするものなのか、
そしてそのテストは本当に行われたのかが
確認できる。
手作業&目視だと、出来の悪い嘘つきが、やってもいないテストを「やった」と言い張れて、
その嘘は結合テスト実行まで露見しないが、
テストケースを作る規則にしてあれば単体テストのフェーズで見つかる。

そこで次に問題になるのは、テストケースの品質だね。
極端な話、assertしないテストケースを書けばオールグリーンになるが、品質はまるで当てにならない。
テストケースの品質を保証するのは、コードレビューでもいいし、ペアプロでもいい。
うちはカバレッジ測定でやってる。
もちろんカバレッジ測定で100%保証できる訳じゃないけど、このあたりで妥協して落とし所としている。
その先の品質保証は、やっぱり結合テスト、総合テストでするよ。
ユニットテストで100%の品質保証なんてできると思ってない。
もちろん、ここにいる、「ユニットテストをコードで書く」派も、そう思ってる奴はいないんじゃないかな。

ちなみに、うちじゃコードレビューはやってないけど、コードレビュー自体は否定しないよ。
やっぱ、コード読んでると、つっこみたくなるところが出てくるしさぁ。
そういうのを言い合える機会はあるといいね。
うちでもやってみたいけど、時間がかかりそうなのでやってない。
メンバーでスケジュール調整するのも面倒だし。

0740デフォルトの名無しさん

2006/05/17(水) 10:51:31

>>734
TDD（テストファースト）だったらありまくりだろ。
レビューより先にテスト書いたって、どうせクラス設計は変わるし、
それにほかのオブジェクトも動くちょっと実践に近いテストでNGが出たら、
大抵、クラス設計のミスが含まれてる（誤魔化せる場合も多いが）から、また変わる。

クラス設計が変れば、ユニットテストは当然書き直しだろ。

0741デフォルトの名無しさん

2006/05/17(水) 11:47:04

まだやってるのかよ。もうほっとけばいいのに。

0742デフォルトの名無しさん

2006/05/17(水) 12:18:42

>>736
単発はともかく、なんどもテストケースを修正するよりは、レビューの方が工数は少ないだろう。
レビューは、仕様を踏まえていろんな条件を考慮して行う。さらにバグだけでなく改善も提案される。
>>738のいうように典型的なパターンのみの確認ならば、効果はとても比べられるモノじゃないだろ。

>>739
つまり、上の方にあった、「嘘つき手抜き」ばかりの現場では、デバッガじゃだめってことね。

煽る訳じゃないが、
しかし、レビュー無し・コード行カバー率利用って、
うちは、レビューで設計改善と全仕様考慮が当たり前だし、
デバッガで実オブジェクトを使ってのコード＋分岐で１００％がデフォなんだが、
うちの感覚からすると、正直な感想は、「みんなエライ適当にやってるんだな」と感じてしまう。

まとめるとこんなところか？

アジャイル………スパイラル………ｳｫｰﾀｰﾌｫｰﾙ　
←xUnitが効果的　　　　　　　　　xUnitは非効率→

クラス設計軽視（レビュー軽視）……クラス設計重視（レビュー重視）
←TDDコスト安い　　　　　　　　　　　　　　　　　　　　TDDコスト高い→

0743デフォルトの名無しさん

2006/05/17(水) 12:18:51

>>734
うそーん　テストが作り直しになる変更なんてしょっちゅうだよ
でもテストの作り直しはそんなに手間と思ったことはないな。
おれにとっちゃ、テストもコードの一部。仕様が変更されたら仕様書もupdateするのと同じように、
コード変更したらテストもupdateする。それだけ。
テストデータが書きやすいように工夫してるからかな。テストデータを直すのは大変だとは思わない。

これがJavaやCそのものでテストプログラム書かなきゃいけないのなら大変なんだろうけどな。
本体がCやJavaでもテストプログラムはスクリプト言語でやってるから、すげー楽。

0744デフォルトの名無しさん

2006/05/17(水) 12:30:16

>>743
それユニットテストじゃないんじゃないの？

0745デフォルトの名無しさん

2006/05/17(水) 12:34:07

>>742
ちょっと聞きたいのだが、742のことじゃレビューが終わると仕様もコードも変更されることはないの？
おれんとこじゃ、レビューするしないに関係なく、仕様変更や利ファクタリングをよくやるから、テストが自動化されてないと、とてもじゃないが品質が維持できない。

742をみると、レビューするしないとか、アジャイルかウォーターフォールかはあんまり関係なく、
仕様変更や機能拡張がどれだけ行われるかどうかが重要なんじゃね？
仕様変更や機能拡張があんまりないんなら、デバッガによるテストを一回やってOKならそれでいいけどさ、
おれんとこは仕様変更も機能拡張も結構な頻度でやってるから、そのたびに毎回デバッガ使ってなんてやってられない。

ユニットテストってそのためのもんじゃね？最初から仕様なんて決まるわけがない、仕様は作りながら徐々に固めていくものだ、
その前提で品質を保証するにはテストの工数を下げる必要がある、だから自動化しようねというのが、そもそもテストを自動化する理由だったはず。
742みてると、最初から仕様がかっちり決まってるように見えるんだよね。そんなのおれたちとは前提が全然ちがうからさ、話かみわないよ。

具体的に742のやってる開発って何よ？最初っから仕様がかっちり決められる開発なんて滅多にないと思うけど。
古いCOBOLのシステムをJavaでリプレースするときでさえ、仕様変更も機能拡張もがんがんあったぞ。

0746デフォルトの名無しさん

2006/05/17(水) 12:53:13

>>745
>742のことじゃレビューが終わると仕様もコードも変更されることはないの？
結合してバグが出たら当然直すよ。

>レビューするしないとか、アジャイルかウォーターフォールかはあんまり関係なく
>毎回デバッガ使ってなんてやってられない。
察しの通りうちは基本的にｳｫｰﾀｰﾌｫｰﾙ。
だが、後工程での部分仕様変更はあるし、完了後も機能拡張開発はある。
それで、デバッガで関係ないクラスまで全クラステストなんてやらないし、意味がないだろ。
修正したらどこまで影響が及ぶかを調査してその範囲をテストする。
既存で修正無しの部分は単体テストじゃなくて結合・機能テストだが。

>具体的に742のやってる開発って何よ？
フィールド案件で使い回せる共通機能ライブラリっつうかフレームワークっつうかパッケージっつうかそんな感じのモノ。

0747デフォルトの名無しさん

2006/05/17(水) 12:55:35

>>742
はい、適当にやってます。全コードレビューなんてやってるところに行ったら、尊敬してしまう。

ただ、これも煽る訳じゃないけど、
「そんなに手作業を信じられるの」と、逆に疑問に思ってしまう。
デバッガで実オブジェクト使ってのテストなんて、手順間違えたら終わりだし、
分岐網羅するテスト仕様を自分で考えてテストなんて、仕様の列挙間違ってたら100%にならないし。

その代わりに、
xUnitテストケース書いてテストの手順を自動化すれば、
誰でもいつでも同じ手順でテストが出来る。
カバレッジ測定すれば、テスト仕様が十分かどうかわかる。

別に、チームに嘘つきや低能がいる場合を想定している訳じゃないよ。
人間誰だってミスするし。だから人間の手作業が信じられない。自分も含めて。

さらに言うなら、結合テストは手作業でやってるけど、ここもできるなら自動化したい。
そんで、テストの正しさを測りたい。
だれか、俺たちのテストが正しいことを証明してくれ。

0748デフォルトの名無しさん

2006/05/17(水) 13:14:07

>>747
＞カバレッジ測定すれば、テスト仕様が十分かどうかわかる。
http://www-06.ibm.com/jp/developerworks/java/060217/j_j-cq01316.shtml

＞人間誰だってミスするし。だから人間の手作業が信じられない。
ユニットテストは、人間が手作業で書くんじゃないのか？

＞さらに言うなら、結合テストは手作業でやってるけど、ここもできるなら自動化したい。
同意というか、単体テストなんかより、結合テストこそ、できるだけ自動化してるよ。
だって、修正のホントの影響が解るのってここだから、これこそ繰り返しやる必要がある。

他意無く、正直な感想を言わせて貰うと、
「TDD・ユニットテストは、いままでろくにレビューや単体テストをしてなくて、
　ただガリガリコード書いてくっつけて確認みたいな開発をしてきた現場では、
　品質向上に役に立つ。
　それは、テスト・レビューしてなかったのをテストするようになったんだから、品質が上がるのは当たり前」
という感じ。どこか間違ってる？

0749デフォルトの名無しさん

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が最適な解と言ってる訳じゃないので。

0750デフォルトの名無しさん

2006/05/17(水) 13:59:33

＞正直言って、TDDが必要なほど複雑なロジック、今までお目にかかったことはないんだが。

激しく同意。
一応お目に掛かったことぐらいはあるが、普通はあんまりない。

0751デフォルトの名無しさん

2006/05/17(水) 14:08:23

＞＞ユニットテストは、人間が手作業で書くんじゃないのか？
＞そう、だからテストの品質をカバレッジで測定し、保証する。
だから、カバレッジは、単にそのステップが動いたというだけで、テストされた事の証明じゃねぇっつの。
例えば、assetがヌルかったりとか、スタブがバグってたりとか。
つ　jester (使ったこと無いけど)

＞HttpUnitとか試してみたいな。
seleniumお勧め。
ただし、条件分岐がないので素人にはお勧めできなくもなくもない。

＞そういう奴でも、「値段が10000円の時は、売値は10500円」
＞「値段が99999円の時は、売値は104998円」
＞「値段が100000円の時は、売値は115000円」
それは、超重要で、要するにテストの仕様網羅性をあげているわけだ。カバレッジツールじゃ測れない。
そして、ユニットテスト書いてる大抵の奴はこんなにちゃんと書いてないんじゃないか？
ちなみに、うちらは、デバッガ単体テストで境界値テストはデフォ。

0752デフォルトの名無しさん

2006/05/17(水) 15:08:43

>>746
>だが、後工程での部分仕様変更はあるし、完了後も機能拡張開発はある。
いやだから、その頻度が問題なのよ。仕様変更あっても十分少なければ同じじゃんん。
頻繁に起こるなら、746とは違うやり方が必要なわけ。

>それで、デバッガで関係ないクラスまで全クラステストなんてやらないし、意味がないだろ。
これは違うと思うぞ。関係ないと思ってもどこでどう関係しているかわからないのがソフトウェア。
だからテストを自動化しておいて、一カ所変更されただけでも全体をテストし直し、
関係ないと思われたクラスも本当に関係ないことを確かめるんだ。手作業じゃそれがつらいだろ。
やっぱり746の場合は変更が少ないことが前提になってると思うな。別にいやみとかじゃなくて、おれたちとはえらい違いだってこと。

>修正したらどこまで影響が及ぶかを調査してその範囲をテストする。
>既存で修正無しの部分は単体テストじゃなくて結合・機能テストだが。
広範囲に関わるような基本クラスやライブラリを変更したときはどうするんだ？それも手作業でテストするのか？この場合はテストが自動化されていた方がいいと思うのだが。
というか、そういう変更自体が発生しないようなプロジェクトなんだろうな。ある意味、正しいよ。あるべき姿かもしれん。

0753デフォルトの名無しさん

2006/05/17(水) 15:18:10

>>748
それはいえるかもな。今までテストはコストがかかるからおざなりにされてきた。
そこに、（習熟コストは別として）コストがあまりかかんなくてもテストできるツールが広まった。
だから、そういうツールとは別に品質を保持できる仕組みがある組織では、あんまり必要ないといえそう。

ただな、レビューってのはかなり高度な技術が必要だよ。だれもができることではない。それだけはいっておく。
それにくらべると、ユニットテストはわりとレベルが低くても実践できる。

>>751
>それは、超重要で、要するにテストの仕様網羅性をあげているわけだ。カバレッジツールじゃ測れない。
>そして、ユニットテスト書いてる大抵の奴はこんなにちゃんと書いてないんじゃないか？
これもそのとおりなんだよな。ユニットテスト書けばOKっていう風潮はおかしくて、ちゃんとしたテスト書くのってすごい難しいことなんだよな。
そして、そのへんのことは本や雑誌にも載ってない。xUnitの使い方とかばっかし。
ただまあ、テストが重要っていうふうに流れを変えてくれたのはxUnitとかアジャイル派のおかげ。それはありがたかった。
746みたいにレビューをちゃんとやらせてもらえる（そのための期間やコストを考えている）プロジェクトなんて、ごくごく少数だぜよ。世の中のバカマネージャってそんなもの。

0754デフォルトの名無しさん

2006/05/17(水) 15:25:47

＞関係ないと思ってもどこでどう関係しているかわからないのがソフトウェア。
「関係ないと思って」ってところがやっぱり、考え方の違いなのかな。
「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。

もちろんとても追い切れない場合もある。
それは、結合テスト・機能テストでその追い切れない影響を確認する。
だから、結合テスト・機能テストは出来るだけ自動化してる。

大体、ユニットテストは、クラス毎にバラバラにテストするのが基本だろ？
モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
それで、予想外の影響伝搬を確認するっておかしくないか？
第一、典型パターンのみの、仕様が網羅されてないテストがOKという程度じゃ、
とても恐ろしくて「影響なし」なんて判断できないよ。

余所は知らんが、ｳｫｰﾀｰﾌｫｰﾙだから、それ以外に比べたら変更自体は少ないだろうな。
だから、いちいち「関係ないことを確認して」なんて事が出来るのかも知れない。
俺以外の所は、XPみたいな週単位で仕様を追加作っていくような開発してるの？

0755デフォルトの名無しさん

2006/05/17(水) 18:22:56

>>754
>「関係ないと思って」ってところがやっぱり、考え方の違いなのかな。
>「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。
これ、どうなん？こんな方法でうまくいくものなのか。それってけっこう実力が高くないと難しくないか？
まず、その確認とやらがgrepぐらいで本当にできるのかという疑問。関数へのポインタとか使ってると、関数名をgrepしただけじゃ影響範囲は判定できないと思うけど。
それから、これもやっぱり変更があるたびにやるんだよな。そのコストがどうなの？という疑問。これも仕様変更やコード修正が少ないことを前提としてるとしか思えん。

>もちろんとても追い切れない場合もある。
>それは、結合テスト・機能テストでその追い切れない影響を確認する。
>だから、結合テスト・機能テストは出来るだけ自動化してる。
そうだな、単体テストを自動化してそこで見つけるか、結合テストを自動化して見つけるかの違いなんだろうか。
ただ、テスト対象が広くなるほど、不具合があった場合（テストが失敗した場合）の原因特定が難しくなるから、
おれとしては結合テストより単体テストで見つけたいところだなー。

>大体、ユニットテストは、クラス毎にバラバラにテストするのが基本だろ？
>モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
>それで、予想外の影響伝搬を確認するっておかしくないか？
予想できないから予想外なんだよ。粗結合になるように設計していても、ある箇所の変更が思わぬところに影響を与えたりする。まるで「蝶の羽ばたきがハリケーンになる」とかまさにそんな感じ。
それから、影響範囲をgrepで見つけるのもいいけど、単にユニットテスト全体をやり直してfailしたのがあればそこが影響範囲だと判断して修正している。おれんとこでは。
どっちのやり方が正しいのかわからんけど、影響範囲を調べる方法としてはgrepよりはいいんじゃないかなと思うんだけど。

0756デフォルトの名無しさん

2006/05/17(水) 18:23:29

つづき。

>第一、典型パターンのみの、仕様が網羅されてないテストがOKという程度じゃ、
>とても恐ろしくて「影響なし」なんて判断できないよ。
まあ、単体テストがどのくらい信用できるかについては、そのとおりだ。そもそも仕様がうまく明文化できないのが問題で、仕方ないからテスト書いてるようなものか。

>余所は知らんが、ｳｫｰﾀｰﾌｫｰﾙだから、それ以外に比べたら変更自体は少ないだろうな。
>だから、いちいち「関係ないことを確認して」なんて事が出来るのかも知れない。
たぶんそう。こっちのほうで単体テストが終わって仕様が固まってリファクタリングも済んで完成したと思ってるレベルが、そっちでのレビュー対象となるんだと思うよ。

>俺以外の所は、XPみたいな週単位で仕様を追加作っていくような開発してるの？
週単位というか、営業が客とあう単位？仕様変更じゃなくても、リファクタリングはしょっちゅうだから、やっぱりxUnitなしじゃまともな開発できねー。

0757デフォルトの名無しさん

2006/05/17(水) 18:28:31

つうかさ、xUnit使ったテストの自動化って、客のわがままや無能なSEのせいで仕様変更ばっかり起こって困ってるプログラマーの、
自衛のための手段なんだと思う。
世の中が仕様をきちんと決められて凍結できるようなプロジェクトばかりだったらテストの自動化は必要なかったろう。
でも実際はそんなプロジェクト滅多にないから、そういう仕様変更から自分の身を守るための手段がxUnitなんじゃなかろうか。
テストこそが仕様だというやつもいるけど、まあそのアイデア自体は悪くないと思うけど、今はまだツールがそこまで進化できていないから。

0758デフォルトの名無しさん

2006/05/18(木) 01:02:08

＞>「関係ないことを確認して」だよ。昔ならgrep、今ならeclipseの参照検索。
＞それってけっこう実力が高くないと難しくないか？

いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るかソース読むだけ。面倒だがそんな大したことはない。

＞関数へのポインタとか使ってると、関数名をgrepしただけじゃ影響範囲は判定できないと思うけど。

関数ポインタだって代入箇所が掛かるだろ。

＞>モック入れたりドライバ入れたりして、わざわざ影響伝搬を分断するような事してるんだから、
＞>それで、予想外の影響伝搬を確認するっておかしくないか？
＞予想できないから予想外なんだよ。粗結合になるように設計していても、

おいおい、話がズレてるぜ。１００の影響伝搬のうち、８０を分断してれば、
予想内だろうが予想外だろうが関係なく、完璧に仕様を網羅したユニットテスト書いた場合ですら
MAXでも２０しか影響が見つからんだろう。
だから、

＞単にユニットテスト全体をやり直してfailしたのがあればそこが影響範囲だと判断

は、正しくはないだろ。ただ、現実の妥協点としてはありかもしれんが。

＞そういう仕様変更から自分の身を守るための手段がxUnitなんじゃなかろうか。

変更が頻繁にある場合は、テストの自動化は重要性が増すな。
だがその最適な単位がユニットテストというのは、納得に値する理由は見つからないな。
影響伝搬の分断によって検出力不足だし、書き直しが頻繁に発生しすぎ（クラス設計に拘れば）。

0759デフォルトの名無しさん

2006/05/18(木) 02:25:09

>いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るか
ここがおかしいと思うんだが。

なぜ呼び元が後からになる？
使われる側の都合で使う側が変わるような設計してりゃ
(使う側からの視点における)テストが大幅に書き直しになるのはあたりまえだばw

0760デフォルトの名無しさん

2006/05/18(木) 04:15:42

＞使われる側の都合で使う側が変わる

は？呼ばれる側に変更が発生したときの影響の確認を言ってるんだが？
「仕様からして○○なはず」だけで全てがその通りなら、
それこそxUnitのリグレッションなんて要らないわけだが。

0761デフォルトの名無しさん

2006/05/18(木) 06:39:50

この議論面白いが、言葉の定義がされてないからなのか、混乱する。

単体テストとユニットテストって普通同じことだよね（訳しているだけだし）。
なんだかユニットテストがxUnit使った自動化のこと言ってる人もいそうな気がしたんだけど、
もしかしてそちらの方が常識なんでしょうか。

あと、変更影響の範囲の話だけど、単体テストがモックを使いまくって、
超純粋に１メソッド（１関数）のみをテストするものと定義されて、そのテストコードが
作られているという話ならば、実行しても確かに変更影響は分からん(failにならん）わな。
でも実際はそんな超純粋な状態を単体テストと言ってない場合が多いのではないかな。

というわけで、みんなの単体テストの定義が分からないという問題提起。

0762デフォルトの名無しさん

2006/05/18(木) 12:29:42

TDD
　実コードより先にxUnitのテストコードを書いてユニットテストで単体テストをする開発のやりかた方

単体テスト
　結合して全体を確認するのではなく、作成or修正した部分自体をテストすること

ユニットテスト
　xUnitを使ってOK/NGまで判定するテストコードを書いて単体テストを行うやり方

0763デフォルトの名無しさん

2006/05/18(木) 12:55:46

>>571
JUnit4がもう二ヶ月も前からリリースされていたのか。
なんだかワクワクしてきたぞ

アノテーションってか？

0764デフォルトの名無しさん

2006/05/18(木) 13:42:36

＞実際はそんな超純粋な状態

たしかに実際は完全に純粋なわけはないが、
実際のプログラムよりは、明らかに純粋になってるわけで、
ユニットテストで解る影響範囲は、本当の影響範囲の一部でしかない。

0765デフォルトの名無しさん

2006/05/18(木) 14:44:51

うちは、Facadeやコマンドレベルのクラスの単体テストは、
Mock使わずに実オブジェクトでやってるよ。実質、結合テストと呼ぶべきかも。
Mockは、設計レベルで導入するよう考慮しないと使えない。

ちなみに、xUnit使ってテストコード書く派。

0766737,738,745,752,753,755

2006/05/18(木) 18:05:39

もう誰が誰だか分からんな。
>>758
別にそっちのやり方を否定するつもりじゃないんだけど、
>いじったメソッドの仕様の変更で、呼んでるところの仕様がどう変るかソース読むだけ。面倒だがそんな大したことはない。
これって、呼んでる場所が多ければ多いほど読まなきゃいけない量が増えるんだよね。いいのかなあ。
それに、その呼び出しがコード上どこまで影響するかというのは、読むだけじゃわからんと思うけどなあ。
研究レベルではControl Flowを解析して影響範囲を表示してくれるツールがあるけど、758がそういうの使っているわけでもなさそうだし。

>関数ポインタだって代入箇所が掛かるだろ。
引数で渡したら名前のgrepじゃわかんないよ。あと関数テーブルとか。

>おいおい、話がズレてるぜ。１００の影響伝搬のうち、８０を分断してれば、
>予想内だろうが予想外だろうが関係なく、完璧に仕様を網羅したユニットテスト書いた場合ですら
>MAXでも２０しか影響が見つからんだろう。
これは何いってるのかわからん。
つうかな、プログラムってどんなに正しく書いたつもりでもやっぱりバグあるじゃん。
影響範囲の分析だって、ここ以外は影響ないと思っていても、やっぱり影響あったりする。
人間が頭で考えたのが必ず正しければいいんだけど、そうじゃないからテストがあるんだし。
まあ758の場合は想定外の影響があった場合は結合テストで見つかるからOKという立場なんだろうけど。

やっぱ「仕様変更が少ない（はじめに仕様が固まってくれる）」のと「レビューでバグが見つけられる（だけの優秀な人材を抱えている）」というのが大きいと思うよ。

0767デフォルトの名無しさん

2006/05/18(木) 22:34:19

おいおい、影響伝搬の検出力は、ユニットテストの有効性が決まる肝だぜ。
わからんの一言でスルーせんでくれよ。
実際のオブジェクトとのインタラクションがなくなれば、
そこの不整合が検出出来んだろう？

0768761

2006/05/19(金) 01:04:25

>>762
単体テストとユニットテストって違う意味だったのか～。
ｼﾗﾝｶｯﾀ(恥

0769デフォルトの名無しさん

2006/05/19(金) 01:19:31

>読むだけじゃわからんと思うけどなあ。
なんで？(呼び出す側を読んで)呼出し先の仕様が変わったらどうなるか解らんてことは、
プログラムが書けないって事だと思うが。

>引数で渡したら名前のgrepじゃわかんないよ。あと関数テーブルとか。
だから、最初に代入する部分があるでしょ？
DEPに引っ掛かるようなTEXT部に動的に関数を構成する様なのは無理だがうちはそんな高度な事してないから関係ないよ。
つか、うちはほとんどJavaだから、関数ポインタよりリフレクションだな。grepすれば済むけど。

レビューにスキルが必要ってのは、意識したことなかったわ。
もちろんスキルが高い方が良いレビューが出来るのは間違いないけど、
仕様を聞いて間違い探しするくらい曲がりなりにもPGなら誰でも出来るだろ？

仕様変更については、上にも書いた通りWFだから、アジャイルとかより変更が少ないのは間違いない。
アジャイルでもこのやり方がうまくいくとは思ってないよ。
でも、ほんとにみんなアジャイルやってんの？設計フェーズってもんがないの？

0770デフォルトの名無しさん

2006/05/19(金) 02:38:47

間違い探し位は誰でもできるだろうな。時間が無限にあれば。
レビューにもスキルは必要。

0771デフォルトの名無しさん

2006/05/19(金) 03:27:20

レビューはテストの代りにならないし、
テストはレビューの代りにならない。

レビューは、XPでもUnitテストと並ぶ超重要超効果的なプラクティスだ。
ただペアプロというあまりに極端なやり方を提示してしまったため、
Unitテストに比べて重視されていないのは不幸な事だ。

かといって、レビューをしているからテストが要らないというのは成り立たない。

0772デフォルトの名無しさん

2006/05/19(金) 05:25:28

>>767
だっておまえの文章、意味わからんもん。スルーされないようにわかりやすく書けよ。

0773デフォルトの名無しさん

2006/05/19(金) 08:16:12

>>769
>仕様を聞いて間違い探しするくらい曲がりなりにもPGなら誰でも出来るだろ？
仕様を聞いて理解できるだけでかなり上級。
普通は仕様書がない・間違ってる・いいかげん・宇宙語で書いてあるので、プログラマじゃ理解できない。

0774デフォルトの名無しさん

2006/05/19(金) 12:16:51

それじゃあ、保守はどうすんの？

0775デフォルトの名無しさん

2006/05/19(金) 12:47:59

エスパーに頼む＞保守

0776デフォルトの名無しさん

2006/05/19(金) 12:55:18

んなもんシステム納品したらはいサヨウナラのSIerには関係ないことだ

0777デフォルトの名無しさん

2006/05/19(金) 21:17:46

ならば、ユニットテストもいらんではないか。

0778686

2006/05/19(金) 22:04:47

>>777
納品できないだろ、テストしないと。

0779デフォルトの名無しさん

2006/05/19(金) 22:05:43

>>778
あれ、なんかハンドルに投稿者番号が残るな・・・
どっちでもいいけど、なんでだろ

0780デフォルトの名無しさん

2006/05/20(土) 01:15:05

一回こっきりの納品でおさらばできるならば、ユニットテストなんて形式的にしかやんない数字あわせの世界。
ましてやテストプログラムなんて作らん。

0781デフォルトの名無しさん

2006/05/20(土) 01:31:20

↑素人

0782デフォルトの名無しさん

2006/05/20(土) 11:03:06

素人のくせに SI を名乗る業者が大杉ってことで FA?

0783デフォルトの名無しさん

2006/05/20(土) 16:15:16

ユニットテストの話なんてSIじゃなく、ソフトハウスでしょう。

0784デフォルトの名無しさん

2006/05/20(土) 16:45:39

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

でもあんたのテスト、2個エラー発生してますから！
でもあんたのテスト、2個失敗してますから！

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

0785デフォルトの名無しさん

2006/05/20(土) 19:42:07

バグは現場で起きてるんじゃない、会議室で起きてるんだ！

・・・なんとなくこんなフレーズが浮かんだけど、
いくつかの致命的なバグの発生元って会議室だったりしない？

0786デフォルトの名無しさん

2006/05/20(土) 20:01:00

ユニットテストってXPとかTDDで使われるときと、それ以外で使われるときで
激しく役割が違うから誤解してるやつ多いね。
同じ名前で呼ぶのが間違ってたな。

0787デフォルトの名無しさん

2006/05/20(土) 22:46:33

>>785
つ ttp://pc8.2ch.net/test/read.cgi/prog/1148058311

0788デフォルトの名無しさん

2006/05/21(日) 09:37:30

>>786
ユニット＝単体と考えてるから、ってことはない？
単体と違って、ＸＰ・ＴＤＤのユニットテストはもっとアクティブに行うものだからさ。
だから齟齬が生じるんじゃないかなー。

0789デフォルトの名無しさん

2006/05/21(日) 13:41:27

ユニットテストがそういう意味というのは国内のみ？
それともUnit Testも同じ意味？

0790デフォルトの名無しさん

2006/05/21(日) 19:08:47

単体テスト＝上流・仕様作成側から見た「機能単位」ごとのテスト
ユニットテスト＝プログラマ側から見た、プログラムの構成要素単位（関数・クラス・モジュール）ごとのテスト

ユニット=Unit=単体という訳語を安易に当てはめるのが誤解のもとである。

0791デフォルトの名無しさん

2006/05/21(日) 19:13:16

じゃあ、単体テストは英語で何というの？

0792デフォルトの名無しさん

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系の話ではない。
ユニットテストにも狭義と広義があるということが今俺の中での回答になった。
使うときに注意するってことだね。

0793デフォルトの名無しさん

2006/05/21(日) 22:21:18

狭義と広義があるというよりは、xUnit使ってる人達の一部が、意味を狭めているだけだと思う。
xUnitのテストケースを使ってすることが単体テストなのに、
テストケース自身を単体テストと呼んでいる気がする。
「シェルスクリプトを作る」を「シェルを作る」というのに近い。

0794デフォルトの名無しさん

2006/05/21(日) 22:26:34

>>793
シェルとシェルスクリプトは名詞だが、
テストは動詞でもあるな。

0795デフォルトの名無しさん

2006/05/21(日) 23:31:18

>>793
国語力なさそう…。

0796デフォルトの名無しさん

2006/05/22(月) 00:19:05

・・・なんか「ツールを使わなければそれはテストでは無い」と解釈しかねないレスが多いな
自分はテスト設計自体を単体テストと呼ぶような人間だよ

0797デフォルトの名無しさん

2006/05/22(月) 00:24:16

俺は実行しなければテストとは呼ばないなー。ツールの有無はともかく。

0798デフォルトの名無しさん

2006/05/22(月) 00:56:51

>>797
その有効性云々はともかくとして、俺は机上ステップ実行はテストの内に入れる。
>>797 的に、机上ステップ実行を実行と認めるかどうかは知らんが。

0799デフォルトの名無しさん

2006/05/22(月) 01:21:32

ここのレス見てると、やっぱり、混同されてると思わざるを得ない。
少なくとも、俺が思う問題と、みんなが思ってる問題がずれてる。

テストケース自体を呼ぶのか、テストする行為を言うのかというズレを
問題にしたいわけでもなく、機能単位とモジュール単位の違いがあるという
ことを問題にしたいわけでもない。
そんなの別にどうだっていい。

俺がここで言いたい問題と言うのは、普通「単体テスト」と言った場合、膨大な量
のテストケースを仕様確認のためにテストしていって、最終的にテストが全部通る
ようなアプリケーションを目指すときに使われるだろ。
TDDの時の単体テストもそういうものだと勘違いしてる奴が多すぎるってこと。
TDDの時は、そういうのとは単体テストの使われ方が全く違う。それを混同してる
奴がいる。このスレなんて多分そういう奴が多すぎる。

0800デフォルトの名無しさん

2006/05/22(月) 01:25:02

つまり、レッド→グリーン→レッドの短いサイクルを何度も繰り返してリファクタリングしていくって
いう過程が誤解されてる気がする。
そういう作業過程を知らないまま、「単体テストを使うんだ」という知識だけで全く別の工程を
想像して、そのまま話を進めてしまう。
単体テストという単語によって激しく誤解されてる気がする。

0801デフォルトの名無しさん

2006/05/22(月) 01:30:24

リファクタリングってテスト完了後にやるものだと思っていたよｗ

0802デフォルトの名無しさん

2006/05/22(月) 01:39:22

>>801
TDDの場合、

新しいテスト→レッドバーがﾞ出る→すぐにグリーンにする→
グリーンを保ちながらリファクタリング→新しいテスト

というパターンを繰り返すから、まあ、ある意味一つ一つのテスト完了後
にリファクタリングをしてるとも言えるかもしれないが、リファクタリングしてる
最中にもテストを何度も実行してグリーンかどうかを確認するわけだし、
同時進行ってのが一番しっくり来るかな。

そういうのを知らないまま、「最初にテストをたくさん作って、テストする時には
一気に全部テストして、パスする総数を少しずつ増やしていって」
みたいなことにxUnitを使うんだ、それがTDDなんだと勘違いしてるんじゃないかと思う。

ようするに、この2つは全然違うし、同時に行うことも可能。

0803デフォルトの名無しさん

2006/05/22(月) 02:40:19

つーことで、TDDはテスト駆動って言わなきゃいいのにね。

0804デフォルトの名無しさん

2006/05/22(月) 06:33:29

火の車開発とか自転車操業開発と言えば分かりやすくなるんじゃないだろうか？

0805デフォルトの名無しさん

2006/05/22(月) 08:34:36

突貫工事

0806デフォルトの名無しさん

2006/05/22(月) 08:38:01

ボトムアップ開発

0807デフォルトの名無しさん

2006/05/23(火) 04:26:17

>>804-805
それはXPにこそ、ふさわしい言葉だね

0808デフォルトの名無しさん

2006/05/23(火) 07:16:00

いやいや、ユーザーが火の車だろうと開発者は悠々と週40時間労働、
これこそが正しいXPだ。

0809デフォルトの名無しさん

2006/05/23(火) 07:39:07

Ｘ切り守らなくていいＰログラミング

それがＸＰ

0810デフォルトの名無しさん

2006/06/20(火) 11:41:06

DBUnitってあんま盛り上がってないの?

0811デフォルトの名無しさん

2006/06/20(火) 11:55:46

>>810
んなこたない。

まあ、ORM使ってたらDbUnitいらない場合も多いけどな。

0812デフォルトの名無しさん

2006/06/20(火) 13:01:42

>810
kwsk

0813デフォルトの名無しさん

2006/06/20(火) 23:04:47

DBUnitには俺も期待してたけど、なーんかバグ放置したまま
開発止まってるっぽいし。

0814デフォルトの名無しさん

2006/06/21(水) 00:01:08

うちじゃ使ってるが。CactusとDBUnit組み合わせて自動テストまでやってる。
今のバージョンはExcelでデータ作れるそうだけど、
1.5の頃からの資産が残ってるので、今だにXMLDataSet使ってるよ。

0815デフォルトの名無しさん

2006/06/21(水) 00:07:36

>>814
Excelは、Jakarta POIのバグ（仕様？）で使い物にならない。
http://www.jajakarta.org/kvasir/bbs/technical/267?expand=true

Excelのシート全体のフォントを変更したらOKだった、なんて
わけわからないことになっている。

0816デフォルトの名無しさん

2006/06/21(水) 00:14:57

うちでも、Cactus、DbUnitは使っている。
テストケースを作っておくとちょっと変更して動作確認、ってのが楽だな。
でも、Spring/Hibernate使うようになってからDbUnitは出番が減ったな・・・

識者の方にお聞きしたい。
Servletコンテナ上で動作することが前提のコンポーネントでデータベースアクセスのあるコードをテストしたい。
つまり、ServletTestCaseとDatabaseTestCaseの両機能を併せ持ったテストケースを作成したい。
このような場合どうしてますか？
具体的には、Spring/Hibernateを使ったWebアプリケーションです。
SpringでHibernate のSessionの管理をしています。
また、SpringではWebApplicationContextを利用しています。
HibernateDaoSupportを継承したDAOのテストってどうするのでしょうか？

0817デフォルトの名無しさん

2006/06/21(水) 00:49:55

Spring/Hibernateは使ったこと無いので役に立つかどうか分からないけど、
DBUnitの機能は、DatabaseTestCaseを継承しなくても使える。
こういうことをするようなユーティリティクラスを作っておけば
ttp://dbunit.sourceforge.net/howto.html#noextend
ServletTestcaseでもDBUnit使ってテストできるよ。

そういうことを聞きたかったのでなければスマソ。

ところで、こういった継承ベースのアプローチって、組み合わせるとき不便。
JUnitベースのツールがJUnit4対応になったら、この辺も便利になるんだろうか。

0818デフォルトの名無しさん

2006/06/21(水) 01:01:40

>>817
おおー、thxです。
これを参考にして、明日いろいろ試してみたいと思います

0819デフォルトの名無しさん

2006/06/23(金) 06:43:17

テストデータを手で作る分には問題ないのかな。
既存DBからデータを吐き出させようとすると、参照制約を考慮して
くれないとか、なぜか書き出されないレコードがあるとか、いろいろ
あったんで「こりゃ使えない」と思ったんだが。

0820デフォルトの名無しさん

2006/06/23(金) 10:40:08

NUnitFormってどうよ？説明見ると面度くさそうだけど、使ってる人いる？

それとNUnitで privateなメソッドのテストが出来ないけど、みなさんどうしてる？

0821デフォルトの名無しさん

2006/06/25(日) 15:21:25

> NUnitで privateなメソッドのテストが出来ない
もれだったらテストの際はpublicにするけど。
※そもそもそんなテストがなぜ必要？クラス化考え直した方がいいんじゃねの？

0822686

2006/06/26(月) 23:24:33

>>820
リフレクション使えば？
privateメソッドを呼び出すユーティリティを用意すればたいした手間でもないし。

publicなメソッドのテスト通せるんなら
privateのテストいらないって言う人もいるけど、
privateメソッドにちょっと複雑なロジックを切り出している場合はテストを書くかな。

0823デフォルトの名無しさん

2006/06/26(月) 23:25:35

↑う・・・なんかハンドルの履歴が消えん・・・

0824デフォルトの名無しさん

2006/06/26(月) 23:26:28

>>815
POIちょっとシートいじるとすぐ読めなくならない？
Excelの実装のせいなのかもしれないけど。
つまり仕様か。

0825デフォルトの名無しさん

2006/06/27(火) 01:22:02

>>822
お返事どもです。
あれから調べてリフレクションで呼ぶコードを書きましたが、いかんせんコードの可読性が悪くなりますね。

private メソッドを呼ぶユーティリティというのは、Assert.AreEqual のラッパーみたいなイメージですか？

0826822

2006/06/27(火) 21:55:08

>>825
Method.invokeのラッパ。
↓こんな感じのインターフェースかな？
中の実装はリフレクションでメソッド取得してinvokeしてるだけ。
後は普通に返り値なりのassertするだけでしょ。

ReflectionUtils.executeMethod(targetObj , clazz , methodName , args);

ちなみにAssert.AreEqualって？
ってNUnitって.netのか。
すまん、Javaの話じゃなかったのか。
まぁあんま変わらないと思うけど。

0827デフォルトの名無しさん

2006/06/28(水) 00:06:28

テスト駆動開発について教えてください。

まずはテストを書きます。
テストを失敗させます。
Fake it と呼ばれる手法？で、
とりあえずは一番楽な方法でテストを通します。

またテストを書きます。
テストを失敗させます。
Fake it で実装。

テストを書く。
テスト失敗。
Fake it。

テスト(ry

こんな感じで、
永遠に正しいコードが書けなくなる (テストに応じた if 文の連続になる) 気がするのですが、
どのタイミングで正しいコードを書いたらいいんでしょうか。
それともテストが悪いのでしょうか。

0828デフォルトの名無しさん

2006/06/28(水) 00:12:19

>>827
って釣りｗｗｗ

徐々に正しいコードを書いていくんねん
@ITの連載読めや。

0829デフォルトの名無しさん

2006/06/28(水) 00:12:40

>>827
テスト駆動開発は、
Red/Green/Refactor
の繰り返しです。
Refactorの所で正しいコードに置き換えます。
詳しくは書籍でどうぞ。

0830デフォルトの名無しさん

2006/06/28(水) 00:27:29

>>828-829
すみませんが、釣りじゃないです。
本気で悩んでました。

@IT 見てきます。

スレ汚しすいませんでした。

0831デフォルトの名無しさん

2006/06/28(水) 07:18:59

>>828
もしよかったら、URLを教えていただけますか？
それらしき連載は見つかりませんでした・・・
多分探し方が悪いのでしょうけど・・・

0832デフォルトの名無しさん

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

0833デフォルトの名無しさん

2006/06/28(水) 08:13:38

「テスト駆動開発三角測量」でググるのもいいんじゃまいか？

0834830

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 行目をテストにパスさせたところで行き詰まってしまいます。
この後はどのようにコーディングしていけばよいのでしょうか。

スレ違い、スレ汚しかとは思いますが、
よろしくお願いしますｴﾛｲ人。

0835デフォルトの名無しさん

2006/06/28(水) 23:42:55

>>834
えーと、それでそのメソッドは終わりだよ。
そこから何かをやらないといけないと思ってるのかな？
＠ITの記事は読んでないから、それを踏まえずに言うと、やっぱり本買ったほうがいいよ。
TDDのリズムがわかるから。

0836デフォルトの名無しさん

2006/06/28(水) 23:45:01

>>834
assertEquals(true, StringUtils.isBlank(new String("")));

0837836

2006/06/28(水) 23:45:37

まちがった。
assertEquals(false, StringUtils.isBlank(new String("")));

だった。

0838デフォルトの名無しさん

2006/06/28(水) 23:47:35

>>837
true で良いのでは？いや、仕様だったら知らんけど。

0839834

2006/06/29(木) 00:07:20

回答ありがとうございます。ｴﾛｲ皆様。

>>835
>えーと、それでそのメソッドは終わりだよ。
空白文字が連続する場合 (正しくは、渡された文字すべてに対し Charctor#isWhitespace が true を返す場合) にも、
isBlank は true を返します。

>>836
私が書いた isBlank メソッドで true が返りませんか？
Java に対する知識が足りないのでしょうか...。

0840デフォルトの名無しさん

2006/06/29(木) 00:22:07

>>839
> 私が書いた isBlank メソッドで true が返りませんか？
== は同じ参照かを判定するので false が返る。

0841デフォルトの名無しさん

2006/06/29(木) 00:40:51

>>839
ええっと、それは次になにやるべきなのか、わかってるということじゃないのか？

念のために言っておくと、（以下'_'はブランク）
assertEquals(true, StringUtils.isBlank("_"));
assertEquals(true, StringUtils.isBlank("__"));

というテストを追加して、それがGreenになるような簡単なコードを追加して、
isBlank内の文字列リテラル"_", "__"をなくすようリファクタリングする。
（ひょっとしたら""もなくなるかもしれない）

0842デフォルトの名無しさん

2006/06/29(木) 00:54:19

>>840
なるほど。
そう言われてみればそうです。
ありがとうございます。

>>841
なるほど！
リテラルがなくなるようにリファクタすればいいわけですね。
なんだかスッキリしました。
ありがとうございました。

0843デフォルトの名無しさん

2006/06/29(木) 01:00:49

Fake itする意味が分からない。
最初から答えを書いてリファクタリングするより、
当てずっぽうとリファクタリングの繰り返しの方がよいコードが書けるって事？

0844デフォルトの名無しさん

2006/06/29(木) 01:18:59

動かないコードより動くコードが、
XPのプラクティスじゃなかったっけ？

当てずっぽうで書いて、
リファクタリングするまで動かないのがダメってこと。

簡単なコード（例えばxとyを足すとか）は、
いきなり実装（明白実装）してもいいけど。

あんまり自身ない。

0845デフォルトの名無しさん

2006/06/29(木) 02:52:48

「当てずっぽう」って何？
って話はおいといて、Fake itする理由は、Redである期間を可能な限り
短くすることと（TDDのサイクルを早める）、段階的なリファクタリングの
準備をもっとも早くするため。（だと理解している）

0846デフォルトの名無しさん

2006/06/29(木) 11:55:11

TDDって、開発期間のほとんどをGreenですごすっていう目標がある。
そのほうが精神衛生上良いから。
従来どおりのコーディング方法だと、最後にやっとGreenになるので、
開発期間のほとんどをRedですごすことになる。

0847デフォルトの名無しさん

2006/06/29(木) 13:01:34

精神論なのかよ…orz
大体、割り込みとかなんかでFakeのまま放置されちまったらどうするんだよ。

0848デフォルトの名無しさん

2006/06/29(木) 13:39:33

精神衛生上良いというのと精神論は違うだろ。
精神論てのは、「バグがあるのはお前らの努力が足りないからだ」みたいな奴。

0849デフォルトの名無しさん

2006/06/29(木) 14:11:08

>>847
はっきり言って、次にどこから始めるか忘れるような奴はこの仕事に向いていない。

0850デフォルトの名無しさん

2006/06/29(木) 14:24:05

>>847
TDDは本来ポジティブなフィードバックを積み重ねていくというのがその基本精神だから。
そこに価値を見出せないなら、TDDやる意味ないよ。

0851デフォルトの名無しさん

2006/06/29(木) 15:26:08

>>847
Fakeのまま放置されるということは、
正しい実装がされない（バグ）ということ。
なので、Fakeのまま放置されるということはありえない。

バグのままリリースするなら話は別。

0852デフォルトの名無しさん

2006/06/29(木) 15:27:54

おっと。
さげ忘れた。

0853デフォルトの名無しさん

2006/06/29(木) 17:15:38

「Fakeのままほっとく奴はアホ」とか「ありえない」とかいうのって、
ちょっと楽観的すぎじゃない？
開発者にアホがいて、FakeのままのxUnitテストケースを
混入したままにしてたら、どうするのさ？

これだけだとアレなんで自分なりの解答を示しておくと、
そういうことが起きないように、
コードレビューなりペアプロなりで相互監視するのがよいと思うよ。
レビューかペアプロやってもFakeを見過ごすようなら…
そのときはプロジェクトに関わる以前に教育が必要だぁね。

0854デフォルトの名無しさん

2006/06/29(木) 17:22:07

>>853
あったりまえじゃん。
メンバーが「できました」って言ったら、できたって信じるの？

0855デフォルトの名無しさん

2006/06/29(木) 20:51:34

Fakeでオールグリーンになってしまうというのは明らかにテストコードが足りない気がする。

0856デフォルトの名無しさん

2006/06/29(木) 21:21:53

オールグリーンにならなかったらフェイクじゃないと思うけど。

0857デフォルトの名無しさん

2006/06/29(木) 22:07:42

Fakeでグリーンになるのはもちろんだけど、グリーンになったらさらにテストを追加するでしょ。
>>833で上がってる「三角測量」というやつ。

0858デフォルトの名無しさん

2006/06/29(木) 22:50:13

>>853
俺が言いたいのは、
Fakeのまま放置されたメソッドを呼び出すときに、
おかしいことが分かるんじゃねーの？ってこと。

でも、たしかにうちの会社はありえそうな気がする。

0859デフォルトの名無しさん

2006/06/29(木) 23:04:42

うちはあったぜ。
DB検索処理で、検索により生成されたオブジェクトの数だけassertEqualsして
オブジェクトの中身は全然みてないテストがあった。
単体テストはオールグリーンでカバレッジ90%強（catch節とかあるから100%は目指さない）なのに
後の工程でバグが見つかるという羽目に。

ええ、次からコードレビューするようにしました。

0860デフォルトの名無しさん

2006/06/29(木) 23:11:21

ありえNEEEEEEEEEEEEEEEEEE
お前らいったいどんな仕事のやり方してんだ。
レビューしなくてもコードを目で高速スキャンすりゃ、一発でわかるだろうが。
テストコードなら1K数分でスキャンできる。

0861デフォルトの名無しさん

2006/06/30(金) 09:20:39

高速スキャンとか言ってる奴って、脳みそ沸いてるのか？
まさかそれでスキルの自慢でもしてるつもり？

Fakeだって、初期ならともかく、それなりの段階に入れば
ぱっと見では、なんかちゃんとやってるように見えるだろ。

>>851
単に動かせば発見されるレベルのバグしか頭にないの？
Fakeだって初期のベタな大嘘実装とは限らん。
考慮すべき比較的レアな条件がまだ未実装という状態だってあるだろう。

0862デフォルトの名無しさん

2006/06/30(金) 09:27:28

>>861
よく読め、馬鹿。
高速スキャンするのは、テストされる側じゃなくて、テストする側のコードだ。

0863デフォルトの名無しさん

2006/06/30(金) 09:29:56

つうか、レビューもしないしメンバーが「できました」というのを無条件に信じる
なんてありえないから、せめてテストコードをざっと眺めるくらいはしろと
言ってるんだが。
そうすりゃ、どんなテストしてるか把握できるし、アドバイスも早い段階で
できるだろ。

0864859

2006/06/30(金) 09:39:19

>>860,863
全くおっしゃるとおり。

でもね…別件でプロジェクト離れてたんだよぅ…
部内の別プロジェクトに関わって6ヶ月、
余所の部署が火吹いてるってんで、強制的に手伝いに行かされて3ヶ月、
まさかその間に、こんなことになってるなんて思わなかったんだよぅ…
JUnit導入時に「テストはこう書きましょう」というガイドラインを作って
配ったのに、無視されてたのは悲しかった…

0865デフォルトの名無しさん

2006/06/30(金) 09:39:30

テストコードを見るのもいいが、１秒あたり６行のペースでは、
よくあるＴＤＤのサンプルみたいなシンプルな場合を除いて、
条件漏れが防げるとは思えんな。

それに、テストコードが十分であっても、
実際のコードの方は、Fakeばかりでごまかしてるかも知れん。

0866デフォルトの名無しさん

2006/06/30(金) 09:46:22

>>865
お前何が言いたいんだよ。
別に100%の条件漏れが防げるなんて言ってないだろ。

UnitTest完了の必要条件は、ピアレビューレベルのコードレビューが必要とでも
いいたいのか？お前のところはそうすりゃいいじゃん。

0867デフォルトの名無しさん

2006/06/30(金) 10:07:22

うちではtargetとなるメソッド名を必ずテストメソッド名に含めるようにさせていて、
メソッド内の実効行数と、そのメソッドが呼ぶ出すメソッドの数、テストメソッドの数、それぞれの
テストメソッド内のassertionの数を一覧表示するプログラムを作って、チェックするようにしてる。
これだけでもかなり違うよ。

0868デフォルトの名無しさん

2006/06/30(金) 10:28:45

>>867
それクレクレ

0869デフォルトの名無しさん

2006/06/30(金) 11:53:32

>>868
ごめん、無理。
就業時間中に書いちゃったから。

0870デフォルトの名無しさん

2006/06/30(金) 19:20:47

>>866
TDDがダメって言ってるんじゃないの？
始めからちゃんとしたテストコードとちゃんとした実コードを書けと。

0871デフォルトの名無しさん

2006/06/30(金) 23:16:44

>>870
たとえ不完全でも、やらないよりやったほうがよっぽどましなんだけどな。
6行/sとか言ってるのも意味不明だ。

0872デフォルトの名無しさん

2006/07/01(土) 00:22:17

下請けに出す場合みんなどうしてる？
うちの会社の場合元請の開発プロセスはなかなか変えられない立場なのでつらい。

0873デフォルトの名無しさん

2006/07/01(土) 03:15:49

>>872
派遣としてくる人以外なら、発注時の条件として開発プロセスの指定をしない限り、
法的に口出しすることが禁じられている。

0874デフォルトの名無しさん

2006/07/01(土) 10:42:57

　　　　　　　　　　　　, -'"´ ￣｀丶､_
　　　　　　　　　 ,.∩　　　　　　　　｀ヽ
　　　　　　　　　〃∪'´￣｀二二人＼　ヽ
　　　　　　　　　| ツ´￣￣￣￣´　ヾヽ.　',
　　　　　　　　　|ﾊ　,ニ、　　,. - ､　| | | ｌ |
　　　　　　　　　| ﾊｨハ　　 ,二ヽ. | | | | |　同じ板にコピペするとそのままだけど、
　　　　　　　　　| | |　じ'　　　|トJ〉　 /)} ｌ | 違う板にコピペすると鬼のような怖い顔
　　　　　　　　　|　ﾊ　､'＿,　￣,,　厶ｲ川|　に変わる摩訶不思議な佳子様コピペ。
　　　　　　　　　l　l /＼　　　 ..　イV＼川 |
　　　　　　　　 ,'　l l　,ｲ｀ｌ￣´ ／　　 /ヽl l
　　　　　　　　ｌ　| ｌハ　`メ､　　　〃　ヽヽ､__ノ
　　　　　　　　 l　 ∨ └‐ｲ「ト--ｧ'´　　　ﾊヽ__ノ
　　　　　　　　　ヽ/　　}　 l」」　/　　　　　/ }`ー
　　　　　　　　　〈_ｎ| 八　　　/ /　　　 /ノ
　　　　　　　　　〈二二人ｃ /＼/ /　, ｲ
　　　　　　　　　　/　 /厂／＼__>＜｛＿

0875デフォルトの名無しさん

2006/07/01(土) 23:53:41

>>871
やらないよりましなんて当たり前のことは否定してない。
いくらＴＤＤの中で相対的にましであっても、
絶対的にそんなレベルはまったく許されない開発もあるんだよ。
あと、６行/秒って、>>860が「1K数分でスキャン」って自分で言ったんだが。

0876デフォルトの名無しさん

2006/07/02(日) 00:09:08

>>865
だから何が言いたいワケ？はっきり言いなよ。
それから1K数分だったら平均5分と考えても3.3行/秒でしょ。
都合のいいように解釈するのは無しね。

0877デフォルトの名無しさん

2006/07/02(日) 00:22:33

簡単に「コードレビュー」とか言ってるやつ、ほんとに実務でやってんのかね？
ものの本によると、レビューの平均速度は50～100行/hだぞ。
あるプロジェクトで50Kのソースがあったら、レビューに500～1000時間かかるんだぞ。
しかも、これのべ工数じゃないからな。

俺は100%のコードレビューやるんだが、はっきりいって心身症や鬱病に
なりそうになるぞ。

0878877

2006/07/02(日) 00:27:58

一部の大規模プロジェクトで、きっちりとしたWFの中でコードレビューが
位置づけられているのでもなければ、最近のスピードが求められる開発では
とてもじゃないが、完全なコードレビューなんかやってられない。

俺がなんとかやれてるのは、xUnitによって、正しいかどうかはわからんが
全てのテストにpassしたコードという前提があるからレビューできる。

動かしたこともないコードのレビューなんか、考えただけでもぞっとする。

0879デフォルトの名無しさん

2006/07/02(日) 00:43:26

それってレビューのレベルが違うんじゃないの？
普通の業務プログラムで、50～100行/hってどんだけ丁寧に見てるんだ？
もちろんそれだけ丁寧に見る必要がある場合もあるが、
平均がその状態なんてことは普通はない（業務PGなら）。

0880デフォルトの名無しさん

2006/07/02(日) 00:53:36

50～100行/hって、ありえねぇだろ。
超絶技巧を凝らしたアセンブラならともかく。

0881877

2006/07/02(日) 00:58:16

>>879
「レビュー」と一口に言ってもいろんな手法があるからな。
50～100行/hは、ピアレビューの場合だったと思う。もちろん実効行数な。
レビュー準備も、レビュー後の資料作成も含めてだぞ。

俺の場合は、俺個人が前述のようなやり方で見るからもっと速い。

ちなみに俺の経験を語ると、ある「品質、品質」とうるさい所のプロジェクトでは、
およそ100行/hの速度で、参加者5～6人でレビューやってたよ。
つまり1KStepあたり、50～60人時。50Kだと2500～3000人時=14～17人月な。
狂ってる。

0882877

2006/07/02(日) 00:59:59

>>880
メンバー全員が信頼できるのなら、もっと早いだろうがな。

ちなみにピアレビューはCMMだかCMMIだかのレベルいくつかに入ってるらしいぞ。
よく知らんが。

0883デフォルトの名無しさん

2006/07/02(日) 01:02:13

コードレビューは重要。品質への効果は大きいよ。
だからこそ、ＸＰに至ってはペアプロなんて極端な形で重要視してる。
あと、双方への教育効果も見逃せない。

しかし、平均50～100行/hはよほどヤバいところでもない限りないな。

>>876
（FakeItを含む）TDDによって「まともな」品質が得られる
ってのは、大嘘だって事でしょ。「まとも」の度合いもあるだろうけど。
元々ろくにテストしてないような所では品質は上がるだろうけど。

0884877

2006/07/02(日) 01:05:03

まあ何が言いたかったのかというと、コードレビューで品質を担保しようとすると
莫大なコストがかかりかねないってこと。

だからこそ、他のやりかたで品質を担保すべきだと俺は考えていて、TDD、
というか、xUnitを開発プロセスに埋め込むのはとても良いことだと考えてるわけだ。

以上。

0885877

2006/07/02(日) 01:10:05

>>883
50～100行/hってのは、最初に書いたとおり「ものの本」によるものだ。
多分「ピアレビュー」って本。まあ、俺の記憶違いかもしれんが。

まあアンチTDDとは話し合っても無駄だから話さないけど。

0886デフォルトの名無しさん

2006/07/02(日) 01:12:04

TDDで本質を担保できてるって所って、
もともと別のやり方でもちゃんとできてたところじゃまいか？

0887デフォルトの名無しさん

2006/07/02(日) 01:12:39

本質を担保してどうすんだ

0888877

2006/07/02(日) 01:16:14

>>886
もちろん俺はTDDやxUnitだけで品質が担保できるなんて考えてないぞ。
コードレビューもやるし、いわゆる単体テスト以降のテストもちゃんとやる。
テストケースのレビューもやる。

ところで別のやり方ってどんなやり方？

0889877

2006/07/02(日) 01:23:17

あ、そうそういい忘れてたけど、コードレビューって一回で終わるものじゃないからな。
指摘事項があれば少なくとも２回、ひどいやつだと４回くらい同じとこやるはめになる。

で、いつも思うわけだ。
レビューする工数あるなら、俺様が書いたほうが早い、と。

0890デフォルトの名無しさん

2006/07/02(日) 01:30:42

いくら指摘しても教えても説明してもできないときはどうしたらいいんだろな。

結局その部分引き取ってやるしかなくなって、
でも自分でやるだけじゃ意味ないって評価されるんだよな…

0891デフォルトの名無しさん

2006/07/02(日) 01:34:00

>>883
>TDDによって「まともな」品質が得られるってのは、大嘘
ってことだけを言いたいんでしょ？
どんなにFUDかましても、実際にTDDでメリットを享受してる人たちがいることは
くつがえせないよ。

0892デフォルトの名無しさん

2006/07/02(日) 01:45:05

単にxUnit使うよりTDDがよいってのは、どういう理由？

＞実際にTDDでメリットを享受してる人たちがいる
そのメリットが品質、ということなら、
その大部分は今までろくに単体テストしてなかっただけだろ。

0893デフォルトの名無しさん

2006/07/02(日) 01:46:52

xUnitのおかげで、継続的インテグレーションや、頻繁なリグレッションテストが
実現できるというのに、品質向上に何も寄与しないと言う奴はどうしたものだろう。
アンチには何を言っても駄目なのか。

0894デフォルトの名無しさん

2006/07/02(日) 01:49:27

>>892
ということにしたい症候群。

終了。

0895デフォルトの名無しさん

2006/07/02(日) 01:53:38

>>892
xUnitとTDDを分けて議論したいの？

0896895

2006/07/02(日) 02:01:28

はっきり言って、どの開発プロセスが優れているかなんて議論は、それこそ
水掛け論になりがちだからね。多分その議論には何のメリットもないよ。お互いに。
いま終わったこのプロジェクトを、違ったプロセスでやったらどうだったろう、
なんてことは出来ないからね。
そういう意味では、デマルコの『デッドライン』は、読み物として面白かった。

それに、「品質」という言葉も曖昧だしね。お互い品質というものをどう捉えるかで
全く食い違った議論になりがち。
例えば俺は、TDDによる自然なリファクタリングによって、保守性が向上すると
考えてるわけだが、ただこれだけでも「そうは思わない」とばっさり切り捨てられる
可能性がある。「保守性って品質か？」などと言い出す奴もいるかもしれないしね。

0897デフォルトの名無しさん

2006/07/02(日) 02:05:02

>>895
そう。xUnitはツール、TDDは開発のやり方。
>>893は馬鹿。「何も」とか勝手に言ってもいない事言って逃げ道作ってるし。
>>894は今までろくに単体テストしてなかった奴。

0898895

2006/07/02(日) 02:08:23

>>897
なるほど、わかった。アンチTDDってことだね。
じゃ>>896の理由で、俺は開発プロセスの優劣の議論には意味がないと思ってるから
これで退散する。

0899895

2006/07/02(日) 02:14:16

一言付け加えておくと、「単体テスト」という言葉にも、個々人で意味あいが
違ったりするからね。Unit Testは単体テストに含まれないって考える人も
いたりするし。

このての議論は不毛になりがちなんだよなぁ。
お互い、言葉の定義を自分こそが正しいと信じてたりするから。

0900デフォルトの名無しさん

2006/07/02(日) 02:21:24

ただ単に
>絶対的にそんなレベルはまったく許されない開発もあるんだよ。
という自慢？がしたいだけ。相手にするだけ無駄

0901デフォルトの名無しさん

2006/07/02(日) 02:27:40

897のところは、ほぼコードと一対一な詳細設計書を書いて、フローチャートなんかも
書いちゃったりして、「iを0で初期化する」なんていう箱を一生懸命書いている、
と想像してみる。

0902デフォルトの名無しさん

2006/07/02(日) 10:15:59

877ってまた例のいつもの奴だろ。
まともに相手するなや

0903デフォルトの名無しさん

2006/07/02(日) 11:00:34

テスト自体もそうだけど、テスト項目の抽出ってみんなのとこの開発ではどうやってるの？
どんな設計書（詳細設計、プログラム設計）を作って、そこからどうやって抽出してるのか気になる。

0904デフォルトの名無しさん

2006/07/02(日) 11:33:45

>>902
いつもの奴って、どの「いつもの奴」？
まともなこと言ってると思うけど。

0905デフォルトの名無しさん

2006/07/02(日) 11:37:37

>>903
詳細設計書とプログラム設計書はどう違う？
ちなみにうちでは、「最終的には経験と勘」ということになっとります。
その「経験と勘」以外の部分は、常套手段がありますので、テスト関連書籍をどうぞ。

0906デフォルトの名無しさん

2006/07/02(日) 11:56:06

>>903
あー、世の中ってこんなレベルが普通なんだろうなあ

0907デフォルトの名無しさん

2006/07/02(日) 12:00:24

開発言語をJavaを例として説明すると、詳細設計は１つの機能のクラス構造とクラスのインタフェースを設計。
プログラム設計は各メソッドの実装ロジック（分岐だとか繰り返し）という感じ。

というツモリで書いたけど、やっぱ設計書の定義も会社やプロジェクトごとにまちまちなんだよね。

＞「最終的には経験と勘」
そう思うけど、多人数でやるとどうしても抽出する観点、抽出する判断基準がある程度
必要になるよね。
何年も一緒にやっている仲間同士なら別として、いろんな会社の人間が集まって開発を進める場合、
基準がないとテストのレベルもバラバラになってしまう。
あと、そういった基準がないとお客さんにテスト計画を説明するのも難しくなってしまう。
自分はまだ直接説明する立場じゃないけど、上の人間（請元）からはいつもしつこく言われる。

0908905

2006/07/02(日) 12:26:33

>>907
ひょっとしてttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?ST=itpro_print
のような情報を求めてるのかな？＠ITにも似たようなページがたくさんある。
「具体的なテストケース例」が知りたいなら、やはりテスト関連書籍をお勧めします。
とてもここでは書ききれない。（し、書くつもりも無い）

「最終的には経験と勘」というのは、全てのテストケース抽出を経験と勘でやるということ
ではなくて、上記のような基本的な部分を越えたところの話です。

0909905

2006/07/02(日) 12:32:24

ちなみにうちのやり方をざっと説明すると、V字モデルに沿ったような仕様書を作り、
時を同じくして対応するテスト設計書を書きます。うちでは、分岐や繰り返しレベル
まで記述した設計書は書きません。修正コストが膨大になるので。

どのようなテストをどのレベルまで、どのように行うかを、プロジェクトを超えて使える
ような「テスト観点書」というものにまとめていて、各プロジェクトではそれをカスタマイズ
するという感じでしょうか。
なんか、全然参考にならない気がしますが……。

0910デフォルトの名無しさん

2006/07/08(土) 21:34:38

ある関数の仕様変更でテストを全部書き直した。。めんどい・・・

0911686

2006/07/09(日) 19:01:29

>>910
なんだそりゃ・・・
よっぽどタコな設計してんだね。

0912デフォルトの名無しさん

2006/07/10(月) 01:50:31

>910
"ある関数"を呼び出すテストを書き直したって事？

それとも"ある関数"がテストに影響する何かなの？

0913デフォルトの名無しさん

2006/07/10(月) 01:58:31

>>912
あのさー、それ知ってどうしたいわけ？
ただの愚痴なんだろうから、スルーしろよ。

0914デフォルトの名無しさん

2006/07/10(月) 02:55:12

終了

0915きっず８

2006/07/16(日) 19:50:04

ですやーーーーーー

0916デフォルトの名無しさん

2006/07/17(月) 01:14:00

>>911
関数の仕様が変ってテストを書き直さずにすむ方法を問いたい。
ま、もともと仕様をきちんと網羅したテストを書いてなければ楽だろうけどねｗ

0917デフォルトの名無しさん

2006/07/17(月) 01:28:21

「テストを全部」ってところがタコなんだろ。

0918デフォルトの名無しさん

2006/07/19(水) 00:13:39

>>916
>>915の言うとおり・・・
全部ってのはまぁネタだろ？

まぁ俺の今いるところはあんたんとこより
はるかにやばい状態だが・・・
タコでもいいからまともにテスト仕様書書いてほしい。

0919デフォルトの名無しさん

2006/07/20(木) 02:28:51

> >>915の言うとおり・・・

・・・言うとおり、何？

0920デフォルトの名無しさん

2006/07/21(金) 00:06:27

>>919
すまん、アンカーが917だった。

単体テストぐらい書いてから画面動かさないと
どうにもならんですよって言ったら
そんな時間ないからやめてくれとか言われた。
クラサバ時代のファットクライアントをWEBアプリにそのまま移植とか
基地外みたいなことやってんのに。

0921デフォルトの名無しさん

2006/07/22(土) 13:34:56

単体の次テスト時のデバッグの時間が確実に存在する、かつ長期化する
ことによってどこかに金が流れる仕組みなんだろ？
(テスタを別途雇ってるとか)

0922デフォルトの名無しさん

2006/07/23(日) 01:01:51

日本語で頼む

0923デフォルトの名無しさん

2006/07/29(土) 00:49:44

.Net用のVirtual Mock Objects使えるテストツールってありますか？
EclipseのdjUnitプラグインみたいな。

0924デフォルトの名無しさん

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だとか
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　　　　ｲ　もっと恐ろしいテスト狂の片鱗を味わったぜ…

0925デフォルトの名無しさん

2006/10/13(金) 11:37:05

　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　　　 (.＿＿_,,,... -ｧァﾌ|　
　　　　　 |i i|　　 }!　}} /／|
　　　　　　 |l､{　　j}　/,,ｨ//｜　　
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　ありのまま　
　　　　　　　 |ﾘ⌒ }　 ,⌒　_,!V,ﾊ | 今起こった事を話す気なんて
　　　　／´f（●）ﾙ（ ●） , ﾀ人　　まったくないおｗｗｗｗｗ！
　　　　 /' 　ヾ|⌒ Lﾚ´⌒`/ |<ヽﾄiゝ　
　　　　,ﾞ　／ )ヽ（_人__） ' |　| ヾｌﾄﾊ〉
　　　 |／_／　ﾊﾉr┬ﾉ　'／:} 　V:::::ヽ
　　　 /／二二二7ー' .／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}

0926デフォルトの名無しさん

2006/10/28(土) 20:16:22

test

0927あま

2006/10/29(日) 11:27:30

初めてだけど荒らしまーす。

0928あま

2006/10/29(日) 11:30:33

初めてだけど荒らしまーす。

0929デフォルトの名無しさん

2006/10/30(月) 04:24:45

BDS2006のDUnitが使いにくいので、テストランナー自作しているのは俺だけ？

0930デフォルトの名無しさん

2006/11/20(月) 00:27:09

JUnit4.2ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!
http://sourceforge.net/project/showfiles.php?group_id=15278

0931デフォルトの名無しさん

2006/11/27(月) 17:04:01

>>925
お前がガルバルディβに見えたよ。

0932デフォルトの名無しさん

2006/11/30(木) 23:56:44

IBM コード品質を追求する: JUnit 4 対 TestNG - Japan
ttp://www-06.ibm.com/jp/developerworks/java/library/j-cq08296/index.shtml

0933デフォルトの名無しさん

2006/12/01(金) 22:09:49

>>932
> 失敗したテストを再実行できる機能は特に大規模なテスト・スイートで役立ちますが、
> これは TestNG にしかない機能です。

JUnitじゃなくてNUnitの話なんだけど、
この機能が無いのが不満で独自のテストフレームワーク作っちゃったよ。

0934デフォルトの名無しさん

2006/12/08(金) 14:50:38

コードに加えた修正が既存の機能を壊してないという保証が無い限り、失敗した
テストだけ再実行しても何の信頼性も無いよね？
コードを修正したらテスト全体を再実行すべきじゃないのかなぁ。

0935デフォルトの名無しさん

2006/12/08(金) 15:46:11

デバッグ作業中、ちょっと書き直すたびに全テスト再実行してたら鬱になるでしょ、規模にもよるけど。
一通りデバッグして、失敗したテストが全部通ってから、改めて全テスト再実行って手順で使うんだと思うけど。

0936デフォルトの名無しさん

2006/12/11(月) 13:31:28

.NETでテストをグループ化管理できるツールってないですかね?
VSTSのDevelopperについてたTestツール使ったけれど、クラス単位とかではグループ化とか出来るが、自分である機能がらみの物についてのテストとかを階層化してグルーピングするのはできないっぽい・・・(´・ω・｀)

0937デフォルトの名無しさん

2006/12/12(火) 14:17:03

>>935
それならもうちっとテストプロジェクトを分割すべき。
全テストと単機能テストの間に機能グループ毎のデグレードチェック用プロジェクト
を作らないと。

0938デフォルトの名無しさん

2007/02/14(水) 00:02:41

毎日自動でテストを実行して結果をグラフ化してくれるソフトってない？
名前をつけつとしたら「継続的テストツール」

0939デフォルトの名無しさん

2007/02/14(水) 00:09:19

>>938
1.Windowsのタスクで毎日自動でテストを実行させる。
2.結果をcsvで出力。
3.エクセルのマクロで自動グラフ化。

あるいは

1.Windowsのタスクで毎日自動でテストを実行させる。
2.結果をxmlで出力。
3.xsltで結果をグラフ表示。

好きな方を選べ。

0940デフォルトの名無しさん

2007/02/14(水) 00:12:54

なぜWindows限定？

0941デフォルトの名無しさん

2007/02/14(水) 00:21:18

Windowsしか使ってないヤツは沢山いても、
逆にWindowsだけは一切使ってないヤツなんて極少数派だから。

てか、エクセルはテストの強い味方だぞ。そのエクセルが優遇されている
Windows環境が前提の話をしても、ここはテストに関するスレなんだから
さして差し支えなかろ？

0942デフォルトの名無しさん

2007/02/14(水) 00:23:18

>>938
CruiseControlっつうのがあるらしい。Java版と、.Net版のCruiseControl.NETってのがある。使ったことはないけど。
うちはAnt使って、単体テストとカバレッジ測定、それとレポート作成まで自動でやってるよ。
build.xmlゴリゴリ書いたけど、一度書けば割と便利。

0943デフォルトの名無しさん

2007/02/14(水) 00:28:18

っちゅうか、>>939はWiondowsを使う方法しか知らないんだろ。

0944デフォルトの名無しさん

2007/02/14(水) 00:32:46

>>943
いや、俺はWiondowsすら知らない素人だよ。

0945デフォルトの名無しさん

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なりで好きにして。

0946938

2007/02/14(水) 21:26:48

みなさんありがとう。
でもLinuxでC++なんです。

> うちはAnt使って、単体テストとカバレッジ測定、それとレポート作成まで自動でやってるよ。

やりたいのはそういう事なんですがAntでC++のユニットテストはできるでしょうか？
あとCruiseControlも今調べています

0947デフォルトの名無しさん

2007/02/14(水) 22:02:08

テストの自動化の前に、することがいっぱいあるような気がする。
C++かー。CppUnitってのがあるみたいだけど、使ったことはない。

0948デフォルトの名無しさん

2007/02/20(火) 17:37:46

boost::testとか。

0949デフォルトの名無しさん

2007/07/21(土) 20:02:03

静的解析ツール（ソースコードを入力に）
って
やっぱりフロントエンドはコンパイラぽいことやってるのかな？

0950デフォルトの名無しさん

2007/07/21(土) 22:45:45

フロントエンドが何を指すのか、コンパイラっぽいっことことってなにを
言ってるのかよくわからんけど、構文解析あたりまではやらないと解析で
きないだろうし、PG-Relief あたりだと簡単なフロー解析ぐらいはやって
るんじゃないかな。

0951デフォルトの名無しさん

2007/07/21(土) 23:11:16

FindBugsとかその系統の話か？
大雑把に構文解析と同時に悪いイデオムとのマッチングをしているね
気になるならばソース読むのが一番だが

0952デフォルトの名無しさん

2007/08/06(月) 22:48:12

誰もいないｒｙ

privateのテストなんて
テストのプリプロセス時に
publicへしてしまえ。

0953デフォルトの名無しさん

2007/08/09(木) 03:28:37

privateのテストなんて
外部からテストする意味がわからんw

0954デフォルトの名無しさん

2007/08/09(木) 18:23:51

ファインド虫ズはバイトコード解析じゃね？

0955デフォルトの名無しさん

2007/08/22(水) 23:44:59

232

0956デフォルトの名無しさん

2007/12/11(火) 10:46:59

あのさ、テスト用のフレームワークは使わずに、
各クラスにテスト用の静的メンバ
static bool MyClass::Test(); を用意して、
とりあえず main 関数の先頭で assert(MyClass::Test());
ってチェックができるようにしてるんだけど、
たまに Test() の呼び出しを忘れるんだ。

プログラム中で使ってるクラスは50ほどあるんだけど、
なんとか忘れずにすべてのクラスの Test() を
呼び出すように強制する方法ってないかな？

0957デフォルトの名無しさん

2007/12/11(火) 11:56:29

>>956
それ、何時間かけて解決するつもり？

0958デフォルトの名無しさん

2007/12/11(火) 23:29:43

強制するうまい方法は思いつかないけど、すべて呼ばれているかどうかをチェックするだけなら簡単じゃないかな。

$ grep 'assert¥(.*Test¥); *.java | wc -l # 呼び出している行の数
$ grep 'static bool .*::Test¥(¥)' *.java | wc -l # 定義している行の数
これが等しいかどうかをチェックする。

0959

2008/01/10(木) 23:37:55

0960デフォルトの名無しさん

2008/01/11(金) 04:27:47

リフレクション使って、あるパッケージ内の全てのクラスについて
static bool Test() があればそれを呼ぶってコードを書けばいいんじゃない。

0961デフォルトの名無しさん

2008/01/11(金) 10:46:35

>>956
phpやrubyならglob使って特定のディレクトリにあってファイル名にTestがついてるの
全部requireとかでいける。
Cとかなら自分でスクリプト書いて、テストスィート自動生成。

0962デフォルトの名無しさん

2008/02/09(土) 10:36:48

TestDriven.NETをアップデート(ver.2.12)したら
ウンともスンともいわなくなっちゃいました。
(テスト時のビルドすら、し始めてくれない)

しょうがないので、今までのバージョンに戻してみると(2.7)
普通に動いてくれます。

ググってみても、同様現象に関しての記事はを見あたらないのですが
同じような方、または解決法などご存じの方がいらしたらお教えください。

ちなみに環境は Vista、VC#2005EE です。

0963デフォルトの名無しさん

2008/03/29(土) 03:13:51

>>962
テスト駆動開発なんて、アテにならないという証だなｗ

テスト駆動開発って、ホントに糞糞レベルの品質は避ける事が出来る、というだけで、
よい品質のソフトを作れる方法論じゃないよな。

まともな現場なら、モジュールとして動き始める頃には、
純粋なコーディングミスなんてほとんど出なくなって、
インタフェース誤解とか仕様自体のミスとかだけ。

テストコードなんて、現実には王道パターンひとつかふたつと、
「テストしやすい」妙なパターンいくつか、程度。まともな現場で起きる現実のバグは、
テスト対象オブジェクトが持つオブジェクトが持つオブジェクトが妙なパターンとか、
とてもテストコードなんて書いてらんないようなのが条件。

モジュールとして動き始めると純粋なコーディングミスがダバダバでるような、
「動きました出来ました」レベルの現場なら、品質は大きく向上するけど、それだけ。

0964デフォルトの名無しさん

2008/03/29(土) 03:58:52

レス乞食乙

0965デフォルトの名無しさん

2008/03/29(土) 06:07:13

業務システムなんて、ぶっちゃけバグの山だからな。
そのシステムで動いてる分には発生条件が起きないってだけの不発弾が大量に眠ってる。

稼働済みシステムのうちの、フレームワーク(として使える)部分を抜き出して、
他のシステムに適用したら、新たなバグが出るわ出るわ。元のシステムは安定してるのに。

出ないバグはバグじゃない。業務システムのソース品質なんて中品質でいいんだよ。

0966デフォルトの名無しさん

2008/03/29(土) 16:34:00

>>963
テスト駆動開発をまったく理解してないいい例。

> テストコードなんて、現実には王道パターンひとつかふたつと、
> 「テストしやすい」妙なパターンいくつか、程度。

単に、君の能力がそこまでと言うこと。(w

0967デフォルトの名無しさん

2008/04/09(水) 21:05:11

Nunitでテスト結果の詳細を出力する方法はないのでしょうか？
(成功・失敗にかかわらず、Assertごとにメッセージを出力など。)

そのまま単体テスト結果表にしたいので。。。

0968デフォルトの名無しさん

2008/04/10(木) 12:31:24

>>966
>>963がTDDの理解どう足りないのか、
どういうやり方なら>>963のいうﾚﾍﾞﾙ以上がTDDで実現出来るのか？
それがなければ、反論になってない。

0969デフォルトの名無しさん

2008/04/10(木) 13:06:08

>>968
で、君はTDDの本読んだことあんの？

0970デフォルトの名無しさん

2008/04/12(土) 09:04:58

>>969
「TDDの本」なんて曖昧に言われても Kent Beck の本しか思いつかない。
あれ以外に参考になる良書はあるのか？

Kent Beck の本だけ読んだ感想では、あれ一冊では仕事で使えるレベルの理解には
到底達しないように思う。あの本はコーディングの視点からの解説しかしていないので。
「ベースとなるコードがテストケースと共に揃っている望ましい状態」から
小さなリファクタリングや機能拡張を TDD で進めるのは簡単だが
実際のプロジェクトを TDD で進めるためには、
「TDD を可能にするための上流工程」という暗黙の前提条件が存在していて
それについて Kent Beck の本では何も触れられていない。

0971デフォルトの名無しさん

2008/04/12(土) 11:03:20

>>968
> テストコードなんて、現実には王道パターンひとつかふたつと、
> 「テストしやすい」妙なパターンいくつか、程度。

単体テストもろくろくできてないとしか思えない。

バカにどんな良い方法論を与えても無駄。

0972デフォルトの名無しさん

2008/04/12(土) 11:31:48

971のようなレスを見ると
「バカにインターネットを与えても無駄」とも思えてくる。

何か自分の意見を主張するでもなく単に他人を叩くだけ。
叩くにしても何がいけないのかも示さない。本当にただ叩くだけ。

せっかくの双方向メディアもバカが刃物を振り回すだけの場になり
S/N比は下がる一方。

0973デフォルトの名無しさん

2008/04/12(土) 13:37:57

> 単体テストもろくろくできてないとしか思えない。

⇒ まずは、単体テストをちゃんとやれ。TDD はその後だ。

---

バカには何を言っても無駄な例でした。(w

0974>970

2008/04/12(土) 14:40:47

>上流工程
が要件定義などを指しているのであればTDDとは無関係では？
ウィキペディアのVモデルあたりを参照して
機能設計後の詳細設計（＝クラスの抽出？）あたりから結合テスト前ぐらいまでの工程がTDD

あとTDDのテストは、検証のテストとは違うと何度言ったら(ry

0975デフォルトの名無しさん

2008/04/12(土) 14:51:55

信者キモいな。現実を無視した脳内厨臭い。
じゃあ信者は実際の業務で１メソッド当たりいくつのテストを書いてるんだ。

0976デフォルトの名無しさん

2008/04/12(土) 15:03:18

そのメソッドの仕様の数だろ。

0977デフォルトの名無しさん

2008/04/12(土) 15:19:01

なんだ、ただのアンチか。
TDDの本読んで、何も得るところがないなら採用しなけりゃいいだけの話でしょ。

0978デフォルトの名無しさん

2008/04/12(土) 15:35:50

>>963
もともとそんな「まともな現場」にいるのなら、xUnitもTDD必要ないね。今のやり方でやっとけばいい。

>テストコードなんて、現実には王道パターンひとつかふたつと、
>「テストしやすい」妙なパターンいくつか、程度。

今現実に存在するコードに、後付けでテストコードを書くって考えるとそう思うかもしれないけど、
それはxUnitもTDDも使ったことのない人の発想。

xUnitやTDDを使えば、Testabilityのプライオリティが上がっていき、それが結果的にコードの
品質の向上につながっていく。高い凝集度と低い結合度という結果で。

xUnitやTDDを使うメリットはそれだけじゃないけど、まずはこんなとこで納得してくれる？

0979デフォルトの名無しさん

2008/04/12(土) 15:37:10

>１メソッド当たりいくつのテスト
メソッドが何をするかによるんじゃねの？

入力パラメータの内容とか出力のパターン数とか
それともどんなメソッドでも一つあたりいくつ、とか固定で決めてるの？バカじゃんw

0980デフォルトの名無しさん

2008/04/12(土) 15:37:48

>>970
XP関連の本も併せて読むと、彼ら一派が要件定義をどのように考えているかがわかると思うよ。

0981デフォルトの名無しさん

2008/04/12(土) 16:18:22

おれんところでも、TDD を使い始めていて効果があると思っているが、

「Testability のプライオリティが上がる」

とか言うわけわからんこと言う奴が TDD の普及を妨げる一因だと思う。

よくわかってないなら、無理に難しい言葉使わなければ良いのにね。

0982デフォルトの名無しさん

2008/04/12(土) 16:33:22

>>981
Testabilityは、日本語で言えば「試験性」で、もっとかみ砕いて言えば「テストのし易さ」。
コーディングに関する一連の作業（内部設計以降）の中で、xUnitやTDDを使うと、この
Testabilityを考えざるを得なくなり、自然とそのプライオリティが上がるって意味。

0983デフォルトの名無しさん

2008/04/12(土) 16:37:32

あ、ごめん。「テスト容易性」の方が日本語では一般的みたい。ググったら、こっちの方が多かった。

0984デフォルトの名無しさん

2008/04/12(土) 17:01:40

つーか、TDDってモジュールとして動き出す前の話だから、根本から誤解してるな

0985デフォルトの名無しさん

2008/04/12(土) 17:57:00

>>982
だから、普通に「テストのし易さに配慮するようになる」と書けばいいのに、
なんで「Testability のプライオリティが上がる」なんて書くんだ？

もしかしてそれがかっこいいとでも思ってるの？

0986デフォルトの名無しさん

2008/04/12(土) 18:08:08

いや、目の前に実例があるだろ
>>982-983にあるような日本語訳の対応問題が根底にあるから testability という原語で表現してる

煙に巻くために横文字多用するアホもいるがそんな例持ち出しても意味はないな

0987デフォルトの名無しさん

2008/04/12(土) 19:33:06

だったら、全部原語で書けば？

0988デフォルトの名無しさん

2008/04/12(土) 19:54:20

そんな事より俺とNUnitしようぜ

0989デフォルトの名無しさん

2008/04/12(土) 21:19:25

＞どんなメソッドでも一つあたりいくつ、とか固定で決めてるの？バカじゃんw
相手が言っても居ない事をあげつらって、何を言ってるんだろう。

結局、どの程度テストを書いてるかは秘密なんだな。
>>963のより少ないとか言うオチだったり。

>>978
テストを先に書いてもそういう風になるだろう。
仕様の普通の所ばかりテスト書いたってしょうがない。
あと、まともにクラス設計が出来ない奴がＴＤＤしてまともになるとは考えにくいがな。
っつーか、1を期待するテストを書いてreturn 1;ってメソッドを書く意味がどこにあるよ。

0990デフォルトの名無しさん

2008/04/12(土) 22:02:47

> どんなメソッドでも一つあたりいくつ、とか固定で決めてるの？バカじゃんw
> 相手が言っても居ない事をあげつらって、何を言ってるんだろう。

固定で決めてないなら、「１メソッド当たりいくつのテストを書いてるんだ」
などと言う馬鹿な質問はしないと思うぞ。

> 結局、どの程度テストを書いてるかは秘密なんだな。

>>976, >>979 に書いてあるんだが。

> 仕様の普通の所ばかりテスト書いたってしょうがない。

仕様が 100% 実現できれば十分。
ユーザーが入力ミスした時とか繋がってるハードが変な値を入れてきた時の動作
なんかも仕様に書いてあるはずだが、当然だよな？

> あと、まともにクラス設計が出来ない奴がＴＤＤしてまともになるとは考えに
> くいがな。

まともにならないかも知れないけど、テストがパスしないから最終的にそう言う
奴を排除できる。君は、排除される側かもしれないけど。(w

> っつーか、1を期待するテストを書いてreturn 1;ってメソッドを書く意味が
> どこにあるよ。

意味わからん。
仕様に 1 を返すと書いてあれば、return 1; ってメソッドに書くのが一番手っ
取り早いと思うが、もっといい方法があるのか？

0991デフォルトの名無しさん

2008/04/12(土) 22:41:51

>>> １メソッド当たりいくつのテストを書いてるんだ。
>> どんなメソッドでも一つあたりいくつ、とか固定で決めてるの？バカじゃんw
> 相手が言っても居ない事をあげつらって、何を言ってるんだろう。

それって、自分が何を質問しているのか分かりません＞＜
ってこと？
「１メソッド当たりいくつ」なんてそのメソッド次第ですが、って回答だよ？

>結局、どの程度テストを書いてるかは秘密
むしろも前の文章読解力の方が言迷w

0992デフォルトの名無しさん

2008/04/12(土) 22:57:04

>>990
俺は>>989じゃないが、それは多分Kent BeckのTDDの本に書いてあるとおりのことを
そのまま言ってるんだと思う。
本が手元にないので正確じゃないが、例えば税計算で「○○の条件の時は1%」という仕様に沿って
public void testHoge_Return1(){
　Foo foo = new Foo();
　assertEquals(1, foo.tax(100));
}
というテストメソッドを作ってから
public int tax(int price){
　return 1;
}
みたいな実装して、テスト実行→グリーン！とやっていたはず。
実際にはこれ以外にも仕様があり、後段ではそのほかの仕様も加えたテストメソッドを
作りながらTDDを進め、仕様上あるべき実装を生み出していく、という流れになってる。
が、このreturn 1の部分だけ抜き出せば、確かに冗長で無駄に感じる。俺もこんなこたぁヤラネ。

が、俺はこれを説明のための方便だと解釈している。
俺の方針はこう。
「実装が自明でないところからTDDを始めよ」
つまりこうだ。
もし、入力の100から1を求める実装が自明でないなら、暫定的にリテラル1を書けばいい。
この段階では実装は不明だが、TDDでやってけばそのうち分かるはずだ（というのがKent Beckの主張、だと俺解釈）。
でなくて、入力の100から1を求める実装が自明なら、その部分はすぐに入力を100で割るコードを書いてしまえばいい。

ただ、自明かどうかの判断が実装者任せなので、危険といえば危険。
仕様を網羅しない不完全な実装になることもありえる（特にこの税計算の例では丸め計算が危険）。
それでも、仕様が適切に定義してあれば発見できるだろうし、
そうでなきゃいけないのは、TDDしてもしなくても一緒。

0993970

2008/04/12(土) 23:14:07

>>974
自分はそこが無関係だと思っていない。
現実に「仕事」で関わる多くのシステムではコーディング担当者と
顧客との間に何重もの中間層が挟まっていることがままあって、
そういう顧客との距離の遠いシステムではコーディング担当者は
信頼できる仕様を掴むこと自体が難しい。

結局のところ TDD は「信頼できるテストを書ける」ことが
暗黙の前提になっているというのが俺の認識。
レッド、グリーン、ちょっと待てそのグリーンはグリーンなのか？

こういうプロジェクトが「そもそも望ましくない」ことはわかっているが
実際そういうプロジェクトが多いのも現実。
現実に多く遭遇するそんなプロジェクトで TDD は
「信頼できないテストコードをメンテナンスするコスト」が
開発者に圧し掛かるだけだと。

0994>993

2008/04/12(土) 23:22:37

いや、だから「信頼できないテストコードをメンテナンスするコストが」って事がおかしいでしょ
そもそも求められている仕様が変更されて、それにあっていないものをそのままにしておいていいわけがないんだが...

0995デフォルトの名無しさん

2008/04/12(土) 23:50:21

>>993
ウォータフォール前提で語るけど、
設計者が作った仕様をコーディング担当者に渡して、そいつがコード書いてテストしたら、
書いたコードを設計者に渡して、設計者は次のフェーズのテスト
（用語はなんでもいいや、会社によって違うし）をしてると思う。

ここで仕様を受け取ってから、仕様設計者にコードを渡すまでは、
どうやろうが一緒じゃね？
テストが信用できないというのなら、TDDでない方法で行ったテストも同様な訳だし。

ただ、TDDならではの利点として、プログラマが行ったテストが再現可能である、
ってことがある。「もう一回テストして」が気軽に言えるよ。
それから、やる気のないプログラマがこんなテストド書いて「できました」と言った時に
より強く「バカヤロウ！」と言える証拠になる。
public class GreenTest{
　@Test public void testGreen(){
　}
}
すぐに見つかるかというと、コードレビューが必要なんでそうも行かないかもしれないが。
この辺、メトリクスとかうまくいかないもんかね。カバレッジも万能じゃないし。

ところで、そろそろ1000が近いけど。

0996デフォルトの名無しさん

2008/04/12(土) 23:58:28

>>995
>ただ、TDDならではの利点として、プログラマが行ったテストが再現可能である、
TDDでなくてもテストは書くだろ

0997デフォルトの名無しさん

2008/04/13(日) 00:06:51

先にテストを書くってのが教条的でイマイチやりにくい。普通に
ちょっと実装→すぐテスト→ちょっと拡張→またすぐテスト
で何で駄目なん？

0998デフォルトの名無しさん

2008/04/13(日) 00:12:14

普通にデバッガの付いてるIDE使ってりゃスタブコードだけ作っといて
デバッガで動作確認しながらってスタイルの方が軽いし。
レグレッションテスト用の資産蓄積って目的なら
テストが先か実装が先かってどっちでもいいはず

0999デフォルトの名無しさん

2008/04/13(日) 00:23:12

次スレ

テストツールについて語るスレ 2
http://pc11.2ch.net/test/read.cgi/tech/1208013693/

1000デフォルトの名無しさん

2008/04/13(日) 02:12:30

１０００げち

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。