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

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

JUnit使おうよ

1 :デフォルトの名無しさん:2006/03/17(金) 16:28:43
語ろうぜ。

2 :デフォルトの名無しさん:2006/03/17(金) 16:44:35
C の一花に使えばいいですか?

3 :デフォルトの名無しさん:2006/03/17(金) 19:18:09
一番簡単な入門ページ教えてください
そしたら使ってやります
周りにも布教してやります

4 :1:2006/03/17(金) 20:15:05
>>3
バカに教える価値は無い

5 :デフォルトの名無しさん:2006/03/17(金) 20:33:39
>>4
バカ!バカ!マンコ!

6 :デフォルトの名無しさん:2006/03/18(土) 14:55:26
>>4
http://www.junit.org/

7 :デフォルトの名無しさん:2006/03/18(土) 17:12:46
× >>4
>>5

8 :http://www.vector.co.jp/soft/win95/util/se072729.html:2006/03/18(土) 18:22:46

TextSS の64bit化キボンヌ

もしくは64bitにネイティブ対応した置換ソフトないですか?

9 :デフォルトの名無しさん:2006/03/20(月) 09:25:08
>>3
http://www.alles.or.jp/~torutk/oojava/maneuver/2000/6-3.html#SEC2
http://oss.timedia.co.jp/index.fcgi/kahua-web/show/XP%a4%c7%b3%da%a4%b7%a4%a4%bf%cd%c0%b8%a4%f2/XP%ca%aa%b8%ec/%bc%ea%ba%ee%b6%c8%a4%ce%a5%c6%a5%b9%a5%c8

10 :デフォルトの名無しさん:2006/03/22(水) 16:56:45
>>9
Thx!

11 :デフォルトの名無しさん:2006/03/24(金) 12:34:32
C使ってる人はどうすればいいの?

12 :デフォルトの名無しさん:2006/03/24(金) 15:50:35
>>11
きっとCUnitを使う。

13 :デフォルトの名無しさん:2006/03/24(金) 16:14:59

あんな面倒なの誰が使うかっつーの


14 :デフォルトの名無しさん:2006/03/24(金) 16:15:35
総本山の↓に、C用のがいくつかあるよ

ttp://www.xprogramming.com/software.htm

15 :デフォルトの名無しさん:2006/03/24(金) 16:17:21
うるせーぼけ

16 :デフォルトの名無しさん:2006/03/24(金) 16:19:35
なんで Visual Studio には
ユニットテストの便利ツールが組み込まれてないんだよ!

17 :デフォルトの名無しさん:2006/03/24(金) 16:20:30
だから MS 商品はバグだらけなんだな
ねーーーーーーーーーーーーーー!!!

18 :デフォルトの名無しさん:2006/03/24(金) 19:17:49
これは仕様です

19 :デフォルトの名無しさん:2006/03/24(金) 20:01:10
sage

20 :デフォルトの名無しさん:2006/04/22(土) 19:49:43
JUnitにあわせてコードを書くなど本末転倒

21 :デフォルトの名無しさん:2006/04/22(土) 20:04:14
>>20
おまえ、頭ガチガチだな。
一生テストしづらいコード書いて低品質でコスト高なシステム作ってろ

22 :デフォルトの名無しさん:2006/04/22(土) 23:15:17
>>21 いいから、まずは設計仕様書を書けって。
いきなりコードを書いて使い物になるのは達人だけだ。
オマイの糞コードを磨いていては100年経っても完成しないっつーの。

23 :デフォルトの名無しさん:2006/04/22(土) 23:26:09
テスト前提で設計をするんだよ。
カビの生えた脳みそさん♪

24 :デフォルトの名無しさん:2006/04/22(土) 23:50:18
ていうかさ、『ユニットテスト=いきなりコードを書く』とか思いこんでる時点で
全くわかってないじゃん、このオッサン。

25 :デフォルトの名無しさん:2006/04/23(日) 11:26:18
21=23=24

26 :デフォルトの名無しさん:2006/04/23(日) 12:55:47
突然JUnitで試験しろとか言うから
リフレクションで呼ぶのも面倒なので
メソットを全てpublicにした

EJBコンテナ上で動くクラスだけどCactus使うの面倒なんで
自分でInitialContextFactory作ってJNDI試験用実装
とJTAの試験実装書いて試験した

後悔はしていない

来月から違う現場だしw

始めから言えばTDDで作ってやったんだが・・・
あっ試験できないコードは糞ってのは同意

27 :デフォルトの名無しさん:2006/04/24(月) 17:16:51
DBアクセスしに行くようなメソッドとかってどうやってテストすればいいの?

28 :デフォルトの名無しさん:2006/04/24(月) 19:15:10
>>27
つ DbUnit

29 :デフォルトの名無しさん:2006/04/25(火) 13:07:08
デブユニット -
ダンスとダイエットとリバウンド(DDR)で活躍するデブ四人組娘ユニット。
日食の日にはデブエディットと名前を変えあなたの性欲晴らします。

30 :デフォルトの名無しさん:2006/04/25(火) 21:44:28
JUnitのJavadocの配色酷すぎないか?
緑バックに黒文字…加えてリンクが赤…。

多分Javadocのテストをしなかったのだろうな。

31 :デフォルトの名無しさん:2006/04/26(水) 00:31:35
>>26
>メソットを全てpublicにした
せめてパッケージ合わせて、デフォルトかprotectedにしろよ

32 :デフォルトの名無しさん:2006/04/26(水) 01:26:13
メソット

33 :デフォルトの名無しさん:2006/04/26(水) 21:37:18
ある時からテストに失敗して、原因が分からず思わず

メソットした。

34 :デフォルトの名無しさん:2006/04/27(木) 02:55:27
>>30
俺はいいと思うけど。
テスティングフレームワークらしい配色じゃん。

35 :デフォルトの名無しさん:2006/04/27(木) 07:58:19
いやあり得ない。
たぶんデザインした奴は色盲なんじゃないか?

36 :デフォルトの名無しさん:2006/04/27(木) 08:50:18
色盲なら緑地に赤はないな。

37 :デフォルトの名無しさん:2006/05/04(木) 08:40:10
外人と日本人って色の見え方や好みがかなり違うらしいよ。

38 :デフォルトの名無しさん:2006/05/22(月) 20:44:51
JUnitとかcactusって実務でよく使われてるんですか?
工数がかかりすぎるし、全てのテストができるわけでないし、
普通にテストした方が楽だと思うんですけど。

39 :デフォルトの名無しさん:2006/05/22(月) 20:52:49
>>38
自動車で言うと保険というよりシートベルトに近いです。



40 :デフォルトの名無しさん:2006/05/22(月) 21:27:16
>>39
どういうことですか?

41 :デフォルトの名無しさん:2006/05/22(月) 23:16:10
XPなんて流行ってないよ。

42 :デフォルトの名無しさん:2006/05/23(火) 02:18:31
他のスレで、unit test で品質が上がるってのは、
単にそれまでろくにテストやってなかっただけ、って結論が出てた。

43 :デフォルトの名無しさん:2006/05/23(火) 05:20:02
>>40
保険は事故った後。
シートベルトは事故の最中。

保守はコーディング後。
ユニットテストはコーディングの最中。

かな…?いい言葉見付からなくて、適当だけど。

44 :デフォルトの名無しさん:2006/05/23(火) 23:34:58
XPなんて、しょぼいシステムでしかやってられない。

45 :デフォルトの名無しさん:2006/05/24(水) 00:23:07
2000が最強だな

46 :デフォルトの名無しさん:2006/05/24(水) 01:47:49
( ´д)ヒソ(´д`)ヒソ(д` )

47 :デフォルトの名無しさん:2006/05/24(水) 03:12:36
俺はVistaに期待するぜ

48 :デフォルトの名無しさん:2006/05/24(水) 11:38:10
MEを選ばない理由がない

49 :デフォルトの名無しさん:2006/06/17(土) 00:29:52
デグレード試験にやたら時間を割く案件に放り込まれた。

junitつくっとけよ馬鹿、と思った。

50 :デフォルトの名無しさん:2006/06/17(土) 02:41:44
将来的に改修の予定が無い or 改修時に自分はいない、って案件だとテストケース書くのめんどい。
改修やリファクタリングする時は絶対合った方が安心感があっていいけど、短期的に捕らえるとしっかりしたテストケース書く分工数増えるしさ。

51 :デフォルトの名無しさん:2006/06/17(土) 05:42:02
で、テストケースをExcelかなんかで書いて、一個ずつシコシコやってくの?

52 :デフォルトの名無しさん:2006/06/17(土) 08:06:05
JUNITでGUIをテストするにはどうしたらよいですか?
if (お前は豚ですか)みたいな

53 :デフォルトの名無しさん:2006/06/17(土) 10:21:17
>>52
Swingなら つ JFCUnit
Webなら つ Cactus

54 :デフォルトの名無しさん:2006/06/17(土) 20:45:24
>>51
blancoJUnitとか

55 :デフォルトの名無しさん:2006/06/18(日) 01:51:05
>>51
一回だけやるテストならどう考えてもコード書くよりは早い&楽だろ。
繰り返しテストを行う予定がなければJUnitのテストケースなんて無駄。

56 :デフォルトの名無しさん:2006/06/18(日) 02:10:05
>>51
>一回だけやるテスト

それってつまり

・機能バグ・詳細設計バグ・コーディングバグ0件
・リファクタリングの必要皆無=極限まで洗練されたソースコード(単体テスト終了時点)
・現在および将来に渡っての仕様変更0件

って事か。


あるわけねーだろ馬鹿

57 :56:2006/06/18(日) 02:11:28
訂正
>51→55

58 :デフォルトの名無しさん:2006/06/18(日) 02:48:42
すべてのクラスが、コード書いてテスト一発合格って凄いよな。
単体でも結合でも。
コードが書かれる以前に設計が完璧で変更無しか。
リファクタリングも無しか。
しかもそれらが完全保証。

確かにそれならJUnitいらないよな。


59 :デフォルトの名無しさん:2006/06/18(日) 02:56:21
>>56
君はJUnitを完全なものと捕らえすぎてる。
やらないよりやったほうが良いが、メソッドを一個一個確認せず全部まとめてドンと実行し
まぁOKとできるなら、そのほうが良い場合もある。
>>55 みたいなのもそのケース
何もこだわらずJUnitなんて無駄だ!とぬかすバカどもよりよほどマシだが
JUnitは万全で、すべての場合においてそれやればよいというものではない。





60 :デフォルトの名無しさん:2006/06/18(日) 03:10:18
xUnitのスレは、いつでも必要無いよ派を必要あるよ派が説得するという構図になる。
なぜ必要あるよ派は、無いよ派を説得しようとする、あるいはしたがるのだろうか。

ところで俺は必要あるよ派である。xUnitを手放せなくなった最大の理由があるのだが、
それはここでは書かない。説明しても必要ないよ派には絶対に理解できないからだ。
そう、それは実際にやらないとわからないことなのだ。

俺も以前は、こんな良い物を広めない手はないと、熱心なエバンジェリストと化した
こともあった。しかし今ではその情熱もさめた。

君もそうじゃないか?
なぜそうまでして説得するのだろう?
おそらく必要無いよ派は、死ぬまでxUnitを使わないのだろう。
それなのに君はなぜ説得しようと試みるのだ。

61 :デフォルトの名無しさん:2006/06/18(日) 03:20:04
xUnitのスレは、いつでも必要無いよ派が必要あるよ派を煽るという構図になる。

(以下略)

62 :デフォルトの名無しさん:2006/06/18(日) 06:21:36
XUnitは簡単なものでもいいから基本的に通るべきことを書いといて、
毎日暇な時間に動かして正常に動くことで変なことやってないってのを確かめるものでは?

63 :デフォルトの名無しさん:2006/06/18(日) 11:10:13
ユニットテストチェックリストをちゃんと埋めてるかを第三者に見せるためのものじゃないの?

64 :デフォルトの名無しさん:2006/06/18(日) 13:08:09
ユニットテストチェックリストってなに?

65 :デフォルトの名無しさん:2006/06/18(日) 13:24:12
テスト項目書

66 :デフォルトの名無しさん:2006/06/18(日) 13:35:58
テストスイートで何をやっているかを、第三者に見せる必要がある場合に作るのがテスト項目書であって、
テスト項目書を埋めるためにJUnitを使うってのは、本末転倒では。

67 :デフォルトの名無しさん:2006/06/18(日) 18:31:12
JUnitは上級者しか使いこなせない。
テストメソッドを一瞬で書くことが出来ず、何分もかかるようなレベルだと、テストメソッドを書くこと
自体がすぐに嫌になってメリットを享受するところまでいかない。

68 :デフォルトの名無しさん:2006/06/18(日) 18:33:55
>>66
JUnitでやるテストとテスト項目書のテストってどのくらい違うの?

69 :66:2006/06/18(日) 20:55:32
>>68
質問の意味が良く分かりません・・・

70 :デフォルトの名無しさん:2006/06/18(日) 21:01:34
なんでJUnitでテストするのが本末転倒なん?

71 :デフォルトの名無しさん:2006/06/18(日) 21:40:26
ユニットテストチェックリストをちゃんと埋めてるかを第三者に見せるための手段として
JUnitを使うのは本末転倒だということです。
テストスイートで何をやってるかをユニットテストチェックリストにおこすのなら話はわかります。

72 :デフォルトの名無しさん:2006/06/18(日) 21:49:11
ふーん
でもうちはユニットテストについては、ドキュメント化しないからなぁ

73 :デフォルトの名無しさん:2006/06/18(日) 22:36:41
うちはテストケースにもきちんとJavadocコメント書かせてJavadocでドキュメント化してる。

74 :デフォルトの名無しさん:2006/06/18(日) 22:40:49
無理に使わなくていいよ。 おれは使うけど。


75 :71:2006/06/18(日) 22:57:43
>>72
ご心配なく、うちもしませんので。
誰かがテストスイートの内容を示すドキュメント化をしろといわない限り。

>>73
変換後にきちんとしたドキュメントになるような内容を書け、というとアレルギーが発生するので、
うちでは適当でいいよ、と言っています。ただし、テストメソッド名で内容を語れ、とは言ってます。

76 :デフォルトの名無しさん:2006/06/19(月) 23:32:08
>>75
お前の下で働かせてくれ

77 :デフォルトの名無しさん:2006/06/19(月) 23:37:17
limitTestとやって下限オーバー、下限リミット、上限リミット、上限オーバーをそこでまとめて実行する。
こんな感じでドキュメント代わりに使う人は多いと思う。

78 :デフォルトの名無しさん:2006/06/20(火) 01:44:40
>>56
その1回のテストすらいらないな。

79 :デフォルトの名無しさん:2006/06/20(火) 02:28:38
UnitTestをドキュメントに数えてくれて、
標準のテスト項目が少なくなるならいいかも。

80 :デフォルトの名無しさん:2006/06/20(火) 03:54:03
ドキュメントにJUnitは使わないだろ。
あくまで、ソース修正の方向性を定めるためだけの
いい加減なテストケースであることがおおいし。

81 :デフォルトの名無しさん:2006/06/20(火) 06:58:41
じゃあ、パラメータとして、このクラスのこのフィールドにこれこれの値を設定して、
戻り値の内容がこれこれであること、っていう紙切れを別途用意すんの?


82 :デフォルトの名無しさん:2006/06/20(火) 08:33:43
そうじゃないの?
普通に関数の前のコメントとか、ドキュメント用のファイルとか、紙切れとかに書くだろ。
JUnitは関係ないだろ。

83 :デフォルトの名無しさん:2006/06/20(火) 17:33:50
話ぶった切る…というか若干関係することなんだけど、1つのテストメソッドにどこまで詰め込む?
例えばあるメソッドのテストをするとして、正常系・異常系とか、異常系でも引数のエラーとか
内部処理の例外とか。テストメソッド1つにテスト1つ?それともある程度まとめる?
前に出てたJavadocでのドキュメント化も、その範囲によって随分労力が変わると思うんだが。

84 :デフォルトの名無しさん:2006/06/20(火) 17:43:29
うちではメソッドの処理結果が分岐する数だけテストメソッドも書く。
正常1、正常2、異常1、異常2とあれば4つ。


85 :デフォルトの名無しさん:2006/06/20(火) 17:51:15
>>83-84
JUnitは本来TDDのためのもので、そのTDDに使うとしたら、
そんなに詳しいテストをきっちりとするわけがない。
JUnitの使い方が間違ってるとしか思えない。

86 :デフォルトの名無しさん:2006/06/20(火) 18:18:04
いやいや、TDDのほうが後出しですから。
それに、かっちりしないって、TDDじゃ少なくともC0カバレッジになるんですが。

87 :デフォルトの名無しさん:2006/06/20(火) 18:20:52
>>86
いや、後出しも何もJUnit作った本人(KentBeck)がTDDとワンセットで有名に
しただろ。
俺間違ってる?

88 :デフォルトの名無しさん:2006/06/20(火) 18:21:15
カバレッジってどこまで行けばいいの?
前やった業務プログラム、カバレッジ60%だった。
どんだけ例外で潰してんねんみたいなコードだった

89 :デフォルトの名無しさん:2006/06/20(火) 18:30:43
>>87
JUnitは、もともとはXPのtest firstのためのツールだったよね?
TDDは「Red/Green/Refactor」が合言葉の開発手法。このRefactorを重視してるところが、XPとは
異なるところ。

まぁそんなつまらん話はおいといて、>>86でいいたかったのは「>>84は間違ってるだろ」
って違うだろ、ってことなんだが。

90 :デフォルトの名無しさん:2006/06/20(火) 18:31:41
あと、必ずしもTDDがC0とは限らんよ。簡単すぎる関数にはテストメソッド作らない場合もあるし。

91 :デフォルトの名無しさん:2006/06/20(火) 18:33:04
>>88
業務ならよほどの場合を除いて100%がデフォ。
「よほどのこと」とは、エラー処理を書いたが、そんなエラー起こせません、ってなとき。

92 :デフォルトの名無しさん:2006/06/20(火) 18:34:47
>>90
じゃあその簡単すぎるメソッド以外では、C0カバレッジになる、には同意する?しない?

93 :デフォルトの名無しさん:2006/06/20(火) 18:39:17
>>89
Test first=TDDじゃん。
まあ、厳密に言えばTDDの方が詳しい概念かも知らんが、
少なくともTDD提唱者とJUnit作者は同じであり、JUnitが現在TDDのためのツールであることは
間違いないよ。
>>84はTDDじゃないとおもうが。

>>92
どうだろうね。そういうのまでC0カバレッジになるって
言っちゃっていいのかなw
あと、もちろん他人の書いたソースコードに対しては
テストなんかしないだろうし。

94 :デフォルトの名無しさん:2006/06/20(火) 18:47:02
XP提唱者も同じだよなw

95 :デフォルトの名無しさん:2006/06/20(火) 18:47:50
何を持ってしてのTDDなの?>>84がそうじゃなくて
>>93が言わんとしてるTDDこそ正答だってのはどんな流れ?

96 :デフォルトの名無しさん:2006/06/20(火) 18:49:21
>>95
君は>>89
>TDDは「Red/Green/Refactor」が合言葉の開発手法。このRefactorを重視してる

これが大体当たってるよ。「XPのtestfirstと違う」ってのは間違ってると思うが。
ほぼ同じだと思うから。

97 :デフォルトの名無しさん:2006/06/20(火) 18:53:40
だから、TestFirstにrefactoringを重視したのがTDDってことでしょ。
同じものが進化したともいえるけどね。


98 :デフォルトの名無しさん:2006/06/20(火) 18:56:53
>>97
まあ、そうかもしれんが、いずれにせよ、きっちりと体系的に
テストを用意してドキュメント代わりに使ったりするような
もんではないな。

99 :デフォルトの名無しさん:2006/06/20(火) 19:02:59
まぁいいや。めんどくさいので「JUnitは本来TDDのためのものだった」ってとこには同意しとこう。
同意しないといつまでも暴れそうだから。

>>84を「そんなに詳しいテスト」と表現しちゃうような人とは話しても無駄なんで、
俺は退散するよ。俺の意見は>>91

C0カバレッジすらめざさない奴といっしょに仕事したくないな。

100 :デフォルトの名無しさん:2006/06/20(火) 19:06:15
ちなみにKent Beckは「TDDはtest firstじゃなくてもいいよ」って言ってるからね。

101 :デフォルトの名無しさん:2006/06/20(火) 19:10:12
>>99
俺は別に暴れてるわけじゃないよ。厳密に言えばJUnitは本来TDDのためのものじゃなくて
Test Firstのためのものだったかもしれないということには同意しているし。
ただ、そんなことは重要なことではない。
言葉のあやで、「本来=意図した」という意味で言ってたわけで、
現在JUnitがTDDを意図したツールであることは間違いないし、そこが重要だからね。

で、あくまでJUnitを使ったTDDのためのテストではそんなに詳しいテストをしないというだけ。
必ずしもC0すら目指さないよ。TDDの本読めばわかるし、提唱者本人が本にそうかいてるしね。

しかし、それとは別に、業務では詳しいテストを実施するだろうね。
そこでC0を目指したらいい。これはJUnitを使ったテストとはまったく別。
少なくともJUnitの意図された使い方とは別。


102 :デフォルトの名無しさん:2006/06/20(火) 19:11:09
>>85
じゃ、ファイルを処理する正常系のコードとテストを書いて、Greenになったあとで、
ファイルがオープンできなかったときのコードを追加したとき「これは簡単だから
てすとしなくていいや」ということ?

103 :デフォルトの名無しさん:2006/06/20(火) 19:11:57
>>100
確かにそういってたかもなあ。忘れたけど。
KentBeckのTDDの本は持ってるし読んだから。
厳密に言えばTestFirstはTDDとは違うんだろうね。
そんなことはどうでもいいけど。

104 :デフォルトの名無しさん:2006/06/20(火) 19:13:31
>>102
そういうこともありえるだろうね。
TDDってそんなもんだよ。

105 :デフォルトの名無しさん:2006/06/20(火) 19:15:23
>>101
退散するとか言いながら、また出てきたりする。

あー、最近暴れてる奴と勘違いしちゃった。ごめん。
俺もあなたとほぼ同じ認識だよ。(JUnitとTDDの関係)

でもね、Kent Beckが出した本では、何をテストすべきかでちゃんと分岐も繰り返しもあげてるよ。
しつこいようだけど、>>84のJUnitの使い方が誤りってばっさりやるのが納得できないだけ。

まぁ、個々人でテストをどうとらえるかによるところでもあるから、あまり話しても利益がないかもね。
ということで、本当にこの話題からは手を引く。

106 :デフォルトの名無しさん:2006/06/20(火) 19:19:04
>>105
確かに分岐や繰り返しなんかは格好のテスト分割対象かもしれないけど、
>>84みたいに必ずしも結果が分岐するからそれにあわせて
テストを作る必要はないってこと。
ようは、「簡単すぎるからテストなんかいいや」、ってこともある。
もちろん程度の問題だが。

107 :デフォルトの名無しさん:2006/06/20(火) 19:19:42
誰もKent Beckなんて知らないんだよ
徳光和夫のホントの涙を見た人がいないように

108 :デフォルトの名無しさん:2006/06/20(火) 19:30:55
>>106
Kent Beckは言ったでしょ?「大切なのは目的」「不安がなくなるまでテストやれ」って。
どうやるのが正解で、どうやるのが誤りなんて、君が決めることじゃないよ

109 :デフォルトの名無しさん:2006/06/20(火) 19:39:08
Kent Beck信者ウザいよ

110 :デフォルトの名無しさん:2006/06/20(火) 20:03:23
>>108
だからさ、「不安がなくなるまでテストする」でいいじゃん。
分岐のたびにきっちりテストするとか、そういうきっちりとした規則とか作らないし、
そんな細かくメソッド分けないし。

111 :デフォルトの名無しさん:2006/06/20(火) 20:08:12
>>109
JUnitのスレなんだから作者の発言が出てくるのは
仕方ないだろ・・・

112 :デフォルトの名無しさん:2006/06/20(火) 20:28:52
>>84
だからさ、君がテストのやり方きめなくていいじゃん。
君の不安と他人の不安っていっしょなの?

113 :デフォルトの名無しさん:2006/06/20(火) 20:29:46
>>110のまちがい

114 :デフォルトの名無しさん:2006/06/20(火) 20:31:55
>>110
それに君TDDの精神まったくわかってないから。
ほんとに本読んだの?

115 :デフォルトの名無しさん:2006/06/20(火) 20:49:31
>>112
まあ、どれだけテストするかは、ある程度は個人の自由かもわからんが、
どうみても、>>84は不安とかを基準にしてないでしょ。
機械的にきっちりとルールを決めすぎ。
それと、処理結果ごとにメソッドを書くなんて言ってるところは
おそらくメソッド書きすぎ。
1つのメソッドのテストに1つのテストメソッド程度が普通かな。

>>114
悪いけど読んだよ。読んだ上に、実際コードを全部打ち込んで
シミュレートまでしたよw
で、異常な場合までテストしてなかったよw

116 :デフォルトの名無しさん:2006/06/20(火) 21:14:18
>>115
それは君が書くコードを基準にものを考えてるだけなんだよ。
そりゃ君はそれで十分なんだろうけど。その基準を他人に押し付ける権利はないよ。

読んだんならわかるだろ。TDDは開発手法であってテスト手法じゃないことが。

KentはTDDの為にJUnitを作った。正しい。
TDDではJUnitを使う。正しい。
JUnitをTDD以外で使うのは正しくない。誤り。
JUnitを使う人はみんなTDDで開発している。誤り。

まぁ君は優秀なプログラマなんだろうけど、視野が狭いね。

117 :デフォルトの名無しさん:2006/06/20(火) 21:33:25
>>115
2章のxUnitの例をきっちり読んでれば
>処理結果ごとにメソッドを書くなんて言ってるところは
>おそらくメソッド書きすぎ
なんてアホなこと言わないはずだけど。

118 :デフォルトの名無しさん:2006/06/20(火) 22:29:23
>>82
なんか勘違いしてるな。
関数の仕様のドキュメントじゃないよ。
テストケースのドキュメントの話だよ。


119 :デフォルトの名無しさん:2006/06/20(火) 22:41:08
>>117
処理結果ごとにassertを実行するというのならまだわかるけど、
メソッド書くなんてのは明らかに違うだろ

120 :デフォルトの名無しさん:2006/06/20(火) 22:43:39
>>84の書き込みを見て「こうしてるに違いない」と決めつけ&思いこみの激しい方が
いらっしゃいますな。
この書き込みだけで「機械的きっちりと決めすぎたルール」だと思ってしまうなんて。
どれだけの脳内補完が働いていることやら。
「処理分岐」としか書いていないのに、どれだけの粒度・詳細度で考えているのかまで
読み取れるのか。すごいな。

恐らく、経験3年前後の若くて優秀なエンジニアと想像してみる。
新しいことを覚えるのに夢中で、自分のスキルに自信があり、
こだわりと明確なポリシーを持って仕事をしている。


121 :デフォルトの名無しさん:2006/06/20(火) 22:48:39
>>119
例えば、メソッドの戻り値がboolean型で、
特定の状況でHogeExceptionをthrowするという
仕様だったとしたら、メソッド3つとかそんなもん。
trueを返すパターンとfalseを返すパターンと
例外が投げられるパターン。
これでも書きすぎ?

StrutsやTomcatのソースコード見てると
そんな書き方をしてるけど・・・
CraigやRemmyに「明らかに違うだろ」って言ってよ。
HustedやMartinはわかってないって言いたい?


122 :デフォルトの名無しさん:2006/06/20(火) 22:58:52
>>121
時と場合による。booleanとかその程度しかなく、それぞれの場合が何の関連性も持たずに
独立しているならそれでいいけど、いつの場合も機械的に分けるのは明らかに間違い。

123 :デフォルトの名無しさん:2006/06/20(火) 23:00:11
>>120
随分と決め付けが激しいなw

124 :デフォルトの名無しさん:2006/06/20(火) 23:05:18
『メソッド書くのは明らかに違う』から『時と場合による』に方針変更ですか。

125 :デフォルトの名無しさん:2006/06/20(火) 23:06:35
>>123
後半部分は単なる想像です。「明らかに」なんて言ってません。

126 :デフォルトの名無しさん:2006/06/20(火) 23:06:53
>>124
方針変換などしてないよ。はじめからそのつもり。
文脈見ればわかるだろ。
機械的に決めるのが間違いだと言ってるわけで、
時と場合によってOKになるのは当たり前。

127 :デフォルトの名無しさん:2006/06/20(火) 23:07:26
不安を基準にしていたら、テストするパターンはむしろ増える一方じゃないのか?

128 :デフォルトの名無しさん:2006/06/20(火) 23:08:45
>>125
前半部分は決めつけだろw

129 :デフォルトの名無しさん:2006/06/20(火) 23:10:03
>>127
これも場合によるんじゃないかな。
耐用年数が多い堅牢なシステムを作る必要があるなら、多くなるかもしれないし、
そうじゃになら少なくなるんじゃないかな。

130 :デフォルトの名無しさん:2006/06/20(火) 23:10:42

なんだか、自分の基準でものを考える人ですね。

131 :デフォルトの名無しさん:2006/06/20(火) 23:11:49
>>128
決めつけの根拠の詳細を希望。


132 :デフォルトの名無しさん:2006/06/20(火) 23:12:28
>>130-131
そろそろ冷静になれよ。くだらないことにむきになるなよw

133 :デフォルトの名無しさん:2006/06/20(火) 23:29:09
ってことは、
・メソッドを分けるか、同一メソッド内で複数のアサーションを行うかは時と場合による。
・でも、>>84 は明らかに間違い。
・ASFのコードは「時と場合による」の範疇。
ってことでFA?


134 :デフォルトの名無しさん:2006/06/20(火) 23:36:01
>>133
3つ目は見ないとなんとも言えないが上から二つはその通り。

135 :デフォルトの名無しさん:2006/06/20(火) 23:41:25
>>84のこの書き込みだけで明らかな間違いだと断言・断定できるってすごいな
俺は>>84のコードを見ないとなんとも言えない。
>>133の一つめだけだな。同意できるのは。

136 :デフォルトの名無しさん:2006/06/20(火) 23:56:01
>>84は普通に読めば、「処理結果が分岐すると無条件にメソッドをわける。」という意味だと読める。
もしそうであるならば、こんなもんは間違いにきまってる。
まあ確かに、そういう意味だとするのは決め付けだ、そういう意味ではないと強弁すれば、
言い逃れることもできるがなw

137 :デフォルトの名無しさん:2006/06/21(水) 00:58:24
>>136
「もしそうであるならば」って・・・
明らかだったんじゃないのか?

138 :デフォルトの名無しさん:2006/06/21(水) 01:36:37
俺、上に言われて>>84にたいな事やらされた事ある。
メソッドの仕様も判らず、ソースコードを見て想定される結果をひたすらテストコードに記述。
品質保証の武器になったらしいが、まじで無駄な仕事だった。

上のレスでもあったが、JUnitはTDDが理想。
それが不可能でも、少なくともブラックボックステストであるべきだ。
ホワイトボックステストではない。



139 :デフォルトの名無しさん:2006/06/21(水) 01:49:13
将来のためのコードは書かないことを原則とすると、
TDDの場合はある意味ホワイトボックステストに近いテストケースになるはず。

140 :デフォルトの名無しさん:2006/06/21(水) 02:08:26
みんな遅くまで起きているなぁ。

自分はJUnitではなくてCUnitなんだけど、ホワイトボックスでないと駄目なケースが多いよ。
ブラックボックスにする時は相当優秀なスタブ作った時ぐらい。
C0検査とかはxUnitではなくて、商用のツールにお任せしている。

インフラが整った環境だと、xUnitでテストできる分野って狭いんだよね。
単体テストの3割ぐらいを占めるぐらい。
それでもテストコードを書きやすいって事は、品質が高い事につながる場合が多い。
つまり、ガンガレおまえら。

141 :デフォルトの名無しさん:2006/06/21(水) 02:11:44
つーか、JUnitって自作自演感が強くて、少し恥ずかしくなるときあるよね。
あとで、それが役に立つって分かってても、
「ここでこうなる!…あ、なったなった、Greenバーオメデトウ」

って、馬鹿馬鹿しい気がしてくる。

142 :デフォルトの名無しさん:2006/06/21(水) 02:13:52
>ブラックボックスにする時は相当優秀なスタブ作った時ぐらい。
それわかる。
最近はもう、XUnit利用はDI前提だと思ってる。

143 :デフォルトの名無しさん:2006/06/21(水) 02:24:56
>>119
じゃぁKent Beckが間違えているということですね。

144 :デフォルトの名無しさん:2006/06/21(水) 02:28:32
そもそもある程度規模以上のところでTDDやってるとこなんてあんのかよ?
あっても片手で数えられるくらいだろ。
しかしJUnitを使ってるところは多い。

あとはわかるな?

145 :デフォルトの名無しさん:2006/06/21(水) 02:32:30
>>84が異様に叩かれてるが、ありゃテストの基本だろうが。
んで、TDD以外ではJUnitなんか使わないはずだから、JUnitであんなことすんのは馬鹿、って
アホが叩いてる、と。

社会に出ろ、自分の目で見ろ、絶望しろ。
世界はお前らが思ってるほど、綺麗ごとでは動いてないし、整然ともしてない。
周りは馬鹿だらけだ。
お前の世界で正しいことが、世の中でも正しいだなんて思うな。

146 :デフォルトの名無しさん:2006/06/21(水) 02:36:17
ビッグバン方式のテストで逐次的にテスト項目をこなしていく場合の最大の問題点が
「途中のバグを修正しても、過去に行ったテストはなかなか実行しない」だ。
それをxUnitは克服させてくれる。テストの自動化っつーやつでな。
Regression testにも有効なんだよ、Unit Testing Frameworkは。
Acceptance testで使ってるところもあるくらいだ。

147 :デフォルトの名無しさん:2006/06/21(水) 10:49:14
仕様のポイントが4つあるんなら4つテストするの当たり前じゃん。
おまえら正常ひとつだけテストして品質がどうとか語ってんの?
それでリグレッションやってるつもりなの?

148 :デフォルトの名無しさん:2006/06/21(水) 11:21:16
>>147
どうやらそういうことらしい。
そういう方針は明らかに間違いなんだそうだ。

149 :デフォルトの名無しさん:2006/06/21(水) 12:00:52
うえの方にもあったけど、
xUnitで品質上がったとか言ってる奴の9割が、
単にいままで全結合するまでほとんどテストをしてなかったってだけ。
ソースレビューすらしてないとか平気な人達。

150 :デフォルトの名無しさん:2006/06/21(水) 12:31:26
>>138
ブラックボックスだけというような制約はTDDにもないよ。

>>140 >>142
君が言うように普通のテストにJUnitなんか使ったって、しょうがないんだよ。
もともとTDDしか念頭においてないんだし。

>>143
間違ってないよ。84は間違えてるけど。

>>145
結局その社会とやらの方が馬鹿なのかよw
その通りだよw

>>147-148
だから、JUnitでやるのは、TDDであって、普通のテストじゃないって
何回言えばわかるんだ。
TDD以外でJUnit使うのは、JUnitの使い方を間違えてる。

151 :デフォルトの名無しさん:2006/06/21(水) 12:34:21
>>149
だから、xUnitのTDDと普通のテストを混同するなよ。
全結合テストをやっているいないにかかわらず、TDDは有効だし、
それ以外にxUnit使うのは、使い方の間違い。

152 :デフォルトの名無しさん:2006/06/21(水) 12:43:13
ふーん、よく知らないけど、
4つある仕様のうち、ひとつさえ動作が確認できたらできあがりなのか。
リファクタリングしても、4つある仕様のうち、ひとつさえ動作できたらデグレ無しなのか。
TDDって夢のような開発手法だね。

153 :デフォルトの名無しさん:2006/06/21(水) 12:44:32
そうじゃないよ。
ただ、簡単なエラーになった場合とかテストを省くことは多いね。
まあTDDの本でも読みなよ。

154 :デフォルトの名無しさん:2006/06/21(水) 12:45:07
>>84>>147-148がTDDじゃないって激しく思いこんでるんですね

155 :デフォルトの名無しさん:2006/06/21(水) 12:52:42
あと、TDDにおけるテストと普通のテストは別ものだから。
片方しかやっちゃいけないということはないよ。

156 :デフォルトの名無しさん:2006/06/21(水) 12:54:45
>>154
まあ、TDDだとすると、間違ったテスト方針だねw


157 :デフォルトの名無しさん:2006/06/21(水) 12:55:56
思いこみの激しい奴は、本を読んでも自己流解釈してる可能性大。

158 :デフォルトの名無しさん:2006/06/21(水) 12:56:50
とりえあず正常パターンのみ動けばOKってレベルの品質要求の安価案件むけの手法だな。
あと極小規模じゃないとね。
クラス(Interface)すらリファクタリングで初めて設計されるんじゃ普通の開発では使えた代物じゃない。

159 :デフォルトの名無しさん:2006/06/21(水) 12:59:50
>>158
それはTDD自体の良し悪しだな。
そして、JUnitはそのTDD向けのもんだ。
確かに、TDDが嫌ならJUnitなんか使わなければいい。

160 :デフォルトの名無しさん:2006/06/21(水) 13:02:08
で、TDD以外でJUnitを使っちゃいけない理由は?

161 :デフォルトの名無しさん:2006/06/21(水) 13:03:56
>>156
つまり、TDDではメソッドの仕様にそったテストケースを作成しないってことだねw

162 :デフォルトの名無しさん:2006/06/21(水) 13:05:48
>>160
普通のテストならもっといいツールがあるから。

>>161
考え方が両極端だな。作成するけども無条件に作成するわけではない。

163 :デフォルトの名無しさん:2006/06/21(水) 13:13:07
つまり、>>162>>84
「うちでは(すべてのメソッドに対して)メソッドの処理結果が分岐する数だけ(無条件に機械的に)テストメソッドも書く(というルールを決めて厳格厳密に運用している)。」
と解釈したわけだ。しかも、その粒度・詳細度も読み取れたわけだ。



164 :デフォルトの名無しさん:2006/06/21(水) 13:15:57
>>163
まあ、正確には
「うちでは(ほぼすべてのメソッドに対して)メソッドの処理結果が
分岐する数だけ(無条件に機械的に)テストメソッドも書く(という
ルールを決めて、ほぼこのルールに従って運用している)。」
程度だがなw
あと、粒度・詳細度は正確にはよみとれてないよ。booleanだったら、falseとtrueで
わけるんだろ程度のことはわかるがな。

165 :デフォルトの名無しさん:2006/06/21(水) 13:26:25
>>162
もっといい単体テストツールがあるなら紹介してくれ

166 :デフォルトの名無しさん:2006/06/21(水) 13:27:45

あきれた

167 :デフォルトの名無しさん:2006/06/21(水) 13:39:47
なんだやっぱり他スレで暴れてるしったかチャンだったんじゃないか。
真面目に相手してそんしたよ。

168 :デフォルトの名無しさん:2006/06/21(水) 13:46:55
>>150
>>>143
>間違ってないよ。84は間違えてるけど。

runメソッドに複数のテストケースがある。状態によって複数の結果になるときには複数の
テストを行う。あたりまえじゃん。
読んでないの?Pythonだから読み飛ばしちゃった?

169 :デフォルトの名無しさん:2006/06/21(水) 13:58:57
>>150
>だから、JUnitでやるのは、TDDであって、普通のテストじゃないって
>何回言えばわかるんだ。

この辺に思い込みの強さが現れてますなぁ。
Kentは確かにTDDのためにJUnitを書いたのかもしれん。
だがなぁ、いいものは得てして作成者の思惑を超えて広く使われるものなんだよ。

TDDには確かにxUnitが必要。でもxUnitをTDD以外で使ってはいけないという法はない。
簡単な論理でしょう?

170 :デフォルトの名無しさん:2006/06/21(水) 14:10:34
>>155
君が言う「普通のテスト」ってどんなもので、どうやって実行するの?
あぁ、説明する際に適切な語彙を使わないと、お里が知れちゃうから気をつけてね。

171 :デフォルトの名無しさん:2006/06/21(水) 14:14:25
>>167
乙。

172 :デフォルトの名無しさん:2006/06/21(水) 14:55:29
TDD礼賛な奴がいるけど、似たようなことは熟練プログラマなら昔から普通にやってたことだから。
ちょっと書いて動かして確認、ちょっと書いて動かして確認。
最近の、何百行もコンパイルすらせずにコード書いて、コンパイルエラーでまくりで困惑
してる奴を見ると眩暈がする。

Javaじゃないが、viが使えないという理由で何百行もコードを秀丸で書いて、書き終わったら
ftp送信する奴などは、俺からすれば神だな。そんなこと俺にはとても出来ない。

173 :デフォルトの名無しさん:2006/06/21(水) 15:04:23
>>165
実は俺も手書きでしか書いたことがないからわからないんだ。
商用の糞高いツールはあるらしいが、勘弁してくれw
でもそういうツールはテストを自動生成してくれるし、JUnitよりは間違いなく便利だわな。
TDDに使わないJUnitなんか何が便利なのかわからん。
あえて言えば、IDEと親和性が高く、操作方法が慣れてるとかその辺か。
まあ全く意味がないわけじゃないな。

>>167
166は別人だw

>>169
それはわかるぞ。実際JUnitをそれ以外のことに使う事だって出来なくは
ないかも知れん。
だがJUnitはTDD用なので、もっと便利なツールを作るのは簡単だ。
目的以外のことに使うとなると、多くの機能が不足してるのは容易にわかるだろう。
その辺を補ってJUnitを使うならまだわかるがな。

だが、少なくともTDD以外でJUnit使っておいて、機能が足りない、使えないとか言ってるのは
お門違いなんだよ。使えないのは当たり前なんだから。そういうのは使い方の間違い。

>>170
いい加減、人にボロを出させて貶すためだけの質問をやめてくれないか?
説明もめんどくさいし、俺のお里がしれようとなんだろうと、関係ないんだよ。
大事なのはお前の主張の正しさはだろ。直接内容に言及しろよ。

まあ、俺が言ってる普通のテストってのは単体テスト→結合テストとやってC0〜C2
満たしたりする昔ながらの開発スタイルだな。

174 :デフォルトの名無しさん:2006/06/21(水) 15:09:01
>>172
TDD礼さんな主張をしてるやつはいないよ。
むしろ、

>似たようなことは熟練プログラマなら昔から普通にやってたことだから

こんなこと言ってる君がTDD礼賛っぽいなw
まあ俺も同意見だったりするが。TDD礼賛のレスをしたのはこれがはじめてかなw

175 :デフォルトの名無しさん:2006/06/21(水) 15:14:44
>>173
>実は俺も手書きでしか書いたことがないからわからないんだ。
なんでそこでJUnit使わないの?

>TDDに使わないJUnitなんか何が便利なのかわからん。
わからないのに、わかった奴に難癖付けてるんだ。

>だがJUnitはTDD用なので、もっと便利なツールを作るのは簡単だ。
簡単なのに、xUnit登場以前はそのようなツールが出回らなかったのは何故なんでしょう?

>だが、少なくともTDD以外でJUnit使っておいて、機能が足りない、使えないとか言ってるのは
>お門違いなんだよ。
誰もそんなこと主張してませんよ。TDD以外でJUnitを使うと便利だから使うって奴は多いけど。

>いい加減、人にボロを出させて貶すためだけの質問をやめてくれないか?
理由もなしに他人を貶めてるのは君の方なんだけどなぁ。

>単体テスト
だから、単体テストってどうやってやるのか教えてよ。それがわからないとJUnitを
単体テストでつかっちゃいかんという理由がわからないんだよ。

176 :デフォルトの名無しさん:2006/06/21(水) 15:32:52
>>174
JUnit登場から日本でのTDD本発売までには数年のラグがあるけど、その間に日本でJUnitを
使ってた奴はみんな馬鹿なんだね。
(一部の間では有名な)「テスト熱中症」の記事に感激した奴も馬鹿なんだ。これもTDD本のかなり前。
誰もがKent Beckの真意なんか汲み取れたわけではなかったと思うよ。その当時はね。

君は君の考えで、TDD以外でJUnitを使わなけりゃいいだけじゃないの?
何で他人を批判するのかねぇ。

177 :デフォルトの名無しさん:2006/06/21(水) 15:53:40
ああ、みごとに俺の書いた>>146が無視されとる orz
自説を展開するのに都合がわるかったんだろうか。

178 :デフォルトの名無しさん:2006/06/21(水) 16:01:04
JUnitを強制することのメリットには、テストの自動化以外にも、プログラマをTestabilityに目を
向けさせるということもある。
自分の書いたコードを直接テストできるようにと考えながらコードを書くと、自然と結合度が
低く、凝集度が高いモジュールになっていく。駄目な奴は何をどうやらせても駄目だが。
コードレベルと同等の詳細設計をやらせるところでは無意味だが。

179 :デフォルトの名無しさん:2006/06/21(水) 16:10:13
テストスィートが存在するメリットの一つは、保守性の向上だ。

Unixでtar ballからソフトウェアをインストールしたことある人ならわかるだろうが、
多くのソフトには数百ものテストが添付されていたりする。
これは、自分のマシンで正しく動くことを確認するためだけではなく、改造したときに
他に影響を与えていないかどうかの確認にとても役立つ。

翻って自分が関係するプロジェクトに目を向けると、同じような構図であることが
すぐにわかるはずだ。メンテナンスするものにとって、テストスィートの存在ほど
心強いものはない。譬えそれが不完全なものであったとしても。

180 :デフォルトの名無しさん:2006/06/21(水) 16:14:20
注意して欲しいのは、そのテストスィートがTDDの成果物でなくてもかまわないということだ。

いわゆる「単体テスト」フェーズで、後付でJUnitのテストを書いても全くかまわない。
出来上がったテストスィートの効果には、なんの影響も及ぼさない。

181 :デフォルトの名無しさん:2006/06/21(水) 16:17:12
宗教論争があるようだが、漏れは気にせず使ってるよ。いいツールだ。
漏れが使ってるのはJUnit(Java)とTUT(C++)だ。

XPの教科書どおりテスト先に書き始めることもあるけど、
テストが後追いになることもある。
デバグ作業中に漏れに気づいてテストを追加することもあるし、
テストを追加するうちに内容が複雑になりすぎて
テスト自体をリファクタリング(メソッドやクラスの分割)するようなこともある。
一応基本は単体テストだがトップレベルに近いクラスは純粋な単体動作は書きにくいから
(ダミーの動作が複雑になりすぎる場合とかね。)
結合テスト寄りな内容になることも当然ある。

どんな手法も万能ではないから杓子定規にする意味はないわな。
大事なのは教義に忠実かどうかではなく
メリット・デメリットのバランスが重要。
教義はメリット・デメリットの着眼点として役立つが、
教義では想定してないメリット・デメリットが後から見つかるのもよくある話。

182 :デフォルトの名無しさん:2006/06/21(水) 16:19:10
はっ、しまった。俺の立場は>>60なのに。また熱くなってしまった。
このスレを読むからいかんのだ。馬鹿だなぁ、俺って orz

183 :デフォルトの名無しさん:2006/06/21(水) 16:22:22
ServletTestRunner/Cactus-Reportなんかもその流れだな

184 :182:2006/06/21(水) 16:22:49
いちおう・・・>>177->>180が俺の発言だから。

185 :デフォルトの名無しさん:2006/06/21(水) 16:33:31
っていうか、>>84が間違いって主張してる人は、個人でやってるか趣味でプログラムしてる人でしょ。

186 :デフォルトの名無しさん:2006/06/21(水) 16:37:14
っていうか、「あー、なんでみんな分んないんだ、俺が正しいのに。馬鹿ばっかり」っていう場合は、
大抵自分が間違ってたりするんだよね。
まあ、2ちゃんでは逆の場合もあるけどね。しったか君が粘着した場合とか。

187 :デフォルトの名無しさん:2006/06/21(水) 16:46:23
うちの会社は20人くらいの小さな会社なんだけど、
A「コーディング終わりました」
リダ「じゃテストやっといて」
・・・
リダ「テスト終わった?」
A「はい終わりました」
リダ「バグ全部取れた?」
A「はい取れました」
リダ「じゃインストーラくっつけてサーバ置いといて」

てな感じのDQN会社ですから orz
俺はxUnit使ってるけど orz

188 :デフォルトの名無しさん:2006/06/21(水) 16:55:35
>>187
いや、ある意味それで会社が廻ってるんだからすごいとも言えるぞ。
実は高スキルな連中ばかりいるんじゃね?

189 :デフォルトの名無しさん:2006/06/21(水) 16:58:38
>>186
間違っちゃいないんだろうけど、自己主張・こだわりが強く、視野と許容性が狭い人間。
優秀な若いエンジニアにはありがちなケース。


190 :デフォルトの名無しさん:2006/06/21(水) 17:02:12
相手を説き伏せようとする熱意と時間を別のことにつかえばいいのになぁと思った。双方とも。

191 :デフォルトの名無しさん:2006/06/21(水) 17:12:11
>>85
JUnitの使い方もわからない馬鹿どもはほおっておけって。ここで数人にわからせてやったって
世の中には馬鹿がくさるほどいるからな。時間の無駄だ。

>>対85
視野の狭い原理主義者なんかほおっておけって。奴を説得しても君にはなんのメリットもないぞ。
使う時間の無駄だ。

192 :デフォルトの名無しさん:2006/06/21(水) 17:15:50
まぁいずれにせよ「JUnitはTDD以外で使うのは誤り」という視点は目新しかったので勉強にはなった。

193 :デフォルトの名無しさん:2006/06/21(水) 17:24:28
うちは研究所。開発に関わる人員は2〜4人。
私が入る前まで開発されてた版は殆ど1人で3年掛けてコツコツ書いてたらしい。
がC++/Rubyが入り混じる10万行規模(後に機能が整理されて6万行規模に)の
C言語サブセット処理系で単体テストなし。
いきなり結合テストとしてCソースを喰わせていて、
後から参加してデバッグ手伝わされたり移植させられたりでエラい目にあった。
正直絶対メンテできないコードだと思った。

ので既存のコンパイラ・フレームワークを使って
後継新版を開発する話を提案してついでに言語環境もJavaに移し、JUnitも導入してもらった。

まぁ、スケジュールは多少遅れ気味だけどプログラミング的には
去年よりは幸せになったと思う。多分。

194 :デフォルトの名無しさん:2006/06/21(水) 17:33:38
メソッドの仕様にそったテストケースを作る
ってのがTDDではないってのも目新しい。


195 :デフォルトの名無しさん:2006/06/21(水) 17:56:47
件の彼の主張は
・JUnitはKent Beckが作った
・Kent BeckはTDDをやる目的でJUnitを作った
・だからTDD以外でJUnitを使うのはあやまり
というもの以上でも以下でもないから。

コーディングという文脈ではなくテストと言う文脈でJUnitを使うところも結構あると思うが(>>84も多分そうだろう)、
件の彼は以上の理由でもってただ切り捨ててるだけ。死語の感はあるが、馬鹿の壁というやつだろう。

「何故TDD以外でJUnitを使ってはいけないのか」に明確な理由を示さないのがその証拠。
しかも件の彼の会社なりチームで、どのような単体テストをどのように実行しているのかを説明できないのもその証拠。

196 :デフォルトの名無しさん:2006/06/21(水) 18:03:55
「JUnitって使えないね、テストコード書くのめんどくさいし」という意見に対して彼は言うだろう。
「TDDでやらないからだ。TDDでやればJUnitは有用なのだ」
一理ある。
しかしこれはいただけない。
「JUnitって便利だからTDD以外でも使ってるよ」
「それはJUnitの正しい使い方じゃない。TDD以外でJUnitを使うのはあやまり」

197 :デフォルトの名無しさん:2006/06/21(水) 18:07:54
マルチ・スレッドのテストってどうしてる?

例えば相互に干渉しうる優先順位つきの要求を
複数のスレッドから受け取って順に処理するスケジューラのクラスを作るのだが、
テスト、どうやって書く?
典型的なシナリオを幾つか準備するくらいしか手はないかな?

198 :デフォルトの名無しさん:2006/06/21(水) 18:09:05
なんか包丁は料理に使うものだから、それ以外は変だって叫んでるみたい。
不穏なところで人も殺せるし、無難なところでペーパナイフの代わりになるんだよ。
便利だったらそれでいいじゃん。由来は関係ない。

199 :デフォルトの名無しさん:2006/06/21(水) 18:20:34
>>197
具体的な内容がわからないので的外れかもしれないけど、そのスケジューラに登録するオブジェクトなり
スレッドなりをテストコード側で用意して情報を取得しassetする。Mock ObjectとかStubとか。
あるいは、「スレッド」などのテストしづらい部分を分割して、個別にテストするとか。

200 :デフォルトの名無しさん:2006/06/21(水) 18:27:09
ん、なんかわかりづらかった。
「スレッドから要求を受け取ってスケジューリングする」機能を、
「スレッドから要求を受け取る」「スケジューリングする」に分割してテストするってことです。

201 :デフォルトの名無しさん:2006/06/21(水) 18:53:34
この間NT○が発注した2000人月超(正確には知らん)のプロジェクトに参加したんだよ。受けたのはNT○-D○TA。
で、その中の何割か(正確にはしらん)がJavaで書かれてたんだけど、その単体テストはJUnit使えという指示
だったんだよね。もちろんプロジェクト全体は、がちがちのWF。
NT○-D○TAがいつからJUnit使うようになったかしらんけどさ、JUnitって何?な世界に、JUnitで行きましょうって
提言した猛者がいるはずなんだよな。俺尊敬するよ。その人。

202 :デフォルトの名無しさん:2006/06/21(水) 18:57:40
採用したところで火事るんだけどね
面子のレベルが一番の問題ってことさ

203 :デフォルトの名無しさん:2006/06/21(水) 19:02:28
>>202
ちっちっちっ。
注目して欲しいところはそこじゃなくて「採用した」ってところ。今までJUnitのテストコード自身がevidenceに
なることなんてなかったからね。

204 :デフォルトの名無しさん:2006/06/21(水) 19:07:49
みかかデータがJUnitって何?な世界なのか?
あれだけの規模の企業だから部署によってまちまちだけど、
業界・オープンソースコミュニティでは有名な
Javaエンジニアを何名も擁する部署だってある。

205 :デフォルトの名無しさん:2006/06/21(水) 19:15:18
NTT-DATAってそんなに尖ったところなの?全然知らなかった。
日立やNECの子会社と同じような感じかと・・・

206 :デフォルトの名無しさん:2006/06/21(水) 19:20:26
そういやEclipseプラグインで頑張ってる日本人がいるらしいけど
Java関係で有名な人って他に誰か居ないの?

207 :デフォルトの名無しさん:2006/06/21(水) 19:21:15
>>205
書籍や雑誌やWEBでちゃんと情報収集してるか?
イベントやカンファレンスに行ってるか?
みかかデータの一部は業界の急先鋒だぞ。

208 :デフォルトの名無しさん:2006/06/21(水) 20:10:01
そしてその他大部分は進捗管理しかできないITゼネコン

209 :デフォルトの名無しさん:2006/06/21(水) 20:16:24
>>207
俺は各社用サーバが用意されてる環境で、bashとvim入れていいかってみかかデータに聞いたら、
フリーソフトは駄目と言われて、それいらい、そういう会社なんだと思ってる。
え、もちろん入れたよ。だって効率わるいじゃん。

210 :デフォルトの名無しさん:2006/06/21(水) 20:21:19
EclipseもJUnitもフリーソフトじゃん。それがホントの話なら矛盾してる。

211 :デフォルトの名無しさん:2006/06/21(水) 20:21:35
なんか>>84の逆鱗に触れちゃったみたいだなw
突っ込むのも馬鹿らしくなってきた。

212 :デフォルトの名無しさん:2006/06/21(水) 20:28:34
ま、便利なら使えば?もうあきらめたよw
少なくとも俺は84みたいな用途にJUnitを使いたくないがな。
たかがtrueとfalseのためにいつもテストメソッドを
分割するなんてやってられんよ。
ツール使って自動生成するならともかく。


213 :デフォルトの名無しさん:2006/06/21(水) 20:30:41
終わった話を蒸し返すのは本人さん?根暗は消えてね。

214 :デフォルトの名無しさん:2006/06/21(水) 20:44:38
悔しかったんだねw

215 :デフォルトの名無しさん:2006/06/21(水) 20:47:19
しかも連投ってとこが傑作だね

216 :デフォルトの名無しさん:2006/06/21(水) 20:47:39
>>212
>たかがtrueとfalseのためにいつもテストメソッドを
>分割する
なんて誰も言ってないが。
最後まで勘違いレスごくろうさん。

217 :209:2006/06/21(水) 20:49:02
>>210
本当だよ。cvsも初めは却下された。粘り強い説得の結果、やっと入れていいことになった。

218 :209:2006/06/21(水) 20:51:02
しまった、これ書くと一部の人に俺が誰か特定されそうな気がする

219 :デフォルトの名無しさん:2006/06/21(水) 20:52:15
ソース管理するなとは基地○の世界だな…

220 :デフォルトの名無しさん:2006/06/21(水) 20:53:04
>>218
まあ気にするなよ工藤さん

221 :デフォルトの名無しさん:2006/06/21(水) 20:53:32
俺分割派。何が通ってるか、一目瞭然でいいんよね。

これは、テストメソッドに日本語書くかどうかと近い問題だと思うよ。

test閾値は100〜200までならおk()
test閾値が100〜200をはみ出したら例外飛ぶわな()

みたいなテストメソッドをガンガン書いてる。
少し前の俺なら卒倒もののコードだが、
最近これでグリーンバー伸びてくのを確認する方が
外人がxUnit使うときの感覚に近いんじゃないかと思ってる。

222 :デフォルトの名無しさん:2006/06/21(水) 20:54:22
つか、>>85ってテストメソッドはそれぞれ独立してて、異なるインスタンスに対してテストが出来ることを
理解してないんじゃなかろうか。

223 :デフォルトの名無しさん:2006/06/21(水) 20:56:16
30ページの一番上、92ページの一番下

224 :デフォルトの名無しさん:2006/06/21(水) 20:57:11
>>219
サーバで動くものをサーバで開発してるのに、バージョン管理したいなら手元のWindows PCでやればー?
(口調は脚色)とか言われたしw

225 :デフォルトの名無しさん:2006/06/21(水) 20:57:27
フリーソフトは入れちゃ駄目ってeclipseスレでも言ってるやついたよ。
そういうところは多いかもしれないな。

226 :デフォルトの名無しさん:2006/06/21(水) 20:58:36
>>223
まだ粘着するか。true/falseなんか誰も問題にしてないというのに。

227 :デフォルトの名無しさん:2006/06/21(水) 20:59:59
お前もまだ、抵抗するのかよw

228 :デフォルトの名無しさん:2006/06/21(水) 21:01:07
根暗に釣られるお前らも根暗…
HOTOHOTO呆れたYO

229 :デフォルトの名無しさん:2006/06/21(水) 21:01:52
2.0は変数じゃない、double型じゃないって言い張ってた奴とかぶるのは俺だけか

230 :デフォルトの名無しさん:2006/06/21(水) 21:01:57
とりあえずJava野郎の有意義な議論つぶせたらなんでもいいんだよ!
ばーかwwww

231 :デフォルトの名無しさん:2006/06/21(水) 21:02:05
eclipseもフリーソフトなのになあw
JUnitやcvsが標準でついててよかったよw

232 :デフォルトの名無しさん:2006/06/21(水) 21:13:35
>>230
ゲイツと寝てろ。

233 :デフォルトの名無しさん:2006/06/21(水) 21:25:50
寝てたらこんな惨めな思いでこの板荒らしてねぇよ、豚

234 :デフォルトの名無しさん:2006/06/21(水) 21:59:54
>>222
うわ、ホントだ。こんなんじゃsetUp()、tearDown()は使えないな。

235 :デフォルトの名無しさん:2006/06/21(水) 22:01:33
>>209,210
JUnitやCVSを却下した部署と
某Oかもと氏がいる部署とは違うんでしょ。きっと。


236 :デフォルトの名無しさん:2006/06/23(金) 01:10:39
つかNTTデータって自分でコーディングやら単体テストまでは実際しないだろ…。
NTTや役所系から仕事とってきてNECや富士通や日立、IBMに投げるだけ。

237 :デフォルトの名無しさん:2006/06/23(金) 01:16:30
>>236
これだけの大企業、いろんな形態の仕事がある。
「NTTデータって」と一括りにするのは間違いのもと。

>NECや富士通や日立、IBMに投げるだけ。
分野によっては(というか、そのほうが多いと推測するが)、
NEC、富士通、日立、IBMはむしろライバル企業。


238 :デフォルトの名無しさん:2006/06/23(金) 01:48:59
あー数年前だけど、なんかNECと競合してたの聞いたことがある。
官庁のネットワークのインフラかなんかの話だったけど。

239 :デフォルトの名無しさん:2006/06/23(金) 15:37:50
>>199-200
受け取った要求が正しい順番でキューに入ってるかどうかと
順番通りにいれたキューの処理が正しく行われてるかを調べるってこと?

240 :デフォルトの名無しさん:2006/06/26(月) 23:51:24
>>239
観点がずれちゃわないかそれでは
複数スレッドの取り合いでスレッド相互の行き過ぎのバリエーションを見たいんだろ
>>197の試験は必須だよ
キー入力待ち埋め込んで状態作ったことあったかな

241 :デフォルトの名無しさん:2006/06/26(月) 23:56:39
>>197読み直したら違うな
逆かw読み飛ばしてw
ごめん

242 :デフォルトの名無しさん:2006/06/27(火) 00:13:32
JUnitってスレッドで例外発生しても死なないの?
CppUnitでは苦労したが・・・

243 :デフォルトの名無しさん:2006/06/27(火) 14:37:36
>>242
Test()アノテーションで捕捉してる例外や
自分でcatchしてる以外の例外はエラーとして中断するよ。

244 :デフォルトの名無しさん:2006/07/07(金) 14:44:14
.Net用のNUnitはどう?
自分はJavaだからJUnit重宝してるもんで、
C#で書くことになったバイトにもテケトーに薦めてしまったが。

245 :デフォルトの名無しさん:2006/07/07(金) 20:41:51
まず最初にC#Unitがあるかどうかチェックしたはずだ

246 :244:2006/07/11(火) 13:54:16
C# ユニット テスト でググッたような気がする。

247 :デフォルトの名無しさん:2006/07/11(火) 15:28:11
まずは
ttp://www.xprogramming.com/
からだな。

248 :デフォルトの名無しさん:2006/07/11(火) 17:34:27
>>247
それはそれで結構だが、諸般の事情でXPを徹底できないときでも
Unitテストのフレームワークは有効だと思うが。

249 :247:2006/07/11(火) 17:42:30
>>248
ちゃうちゃう、特定言語用Unit Testing Frameworkを探すなら、
まずはそこからっつー意味。

250 :デフォルトの名無しさん:2006/07/12(水) 13:47:48
一応そこの
http://www.xprogramming.com/software.htmからから辿って見つけた。

NUnit .Net unit testing framework
http://sourceforge.net/projects/nunit/

AutoTest for .Net
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=997126bc-c924-4e53-b061-c877794d99ba

dotunit
http://dotunit.sourceforge.net/

csUnit
http://www.csunit.org/

メジャーなのはNUNITとcsUnitか。

251 :デフォルトの名無しさん:2006/08/04(金) 15:24:48
テストのためageます。

252 :デフォルトの名無しさん:2006/08/23(水) 00:03:55
再テスト

253 :デフォルトの名無しさん:2006/09/12(火) 02:54:18
うにっとテスト。

254 :デフォルトの名無しさん:2006/10/11(水) 14:34:21
NUnitって更新停滞中か…。csUnitに乗り換えたほうがいいのかね…。

255 :デフォルトの名無しさん:2006/10/11(水) 20:44:57
Tiger対応したJUnitの新しい版に対応したEclipse向けプラグインはまだかのう?
移行措置でアダプタとsuitメソッド使ってるけど
個別テストの実行ができなくて面倒。

256 :デフォルトの名無しさん:2006/10/12(木) 04:05:19
csUnit・・・テストがassertionで失敗すると
テストランナー自身がException捕まえず
丸投げで外に投げてテストランナーごと死ぬって仕様は如何なものか?

またそのテストランナーを内部からツールメニューで立ち上げてると
問答無用で一緒に死ぬVisualStudio2005のガラスのような頑健性も如何なものか?

最初テスト走らせるたびに落ちて何事かと思ったぞ…。
外部で立ち上げて走らせなおしてようやく原因が分かったよ。

257 :デフォルトの名無しさん:2006/10/12(木) 04:12:19
ちなみにcsUnit 2.1.1 BETAとVisualStudio2005 Professionalの取り合わせ。

258 :デフォルトの名無しさん:2006/10/12(木) 04:57:16
厨沸いてるみたいだけど
どこら辺から読み始めるとお得?

259 :デフォルトの名無しさん:2006/10/12(木) 05:14:19
ケチケチすんない。全部読めやい。

260 :デフォルトの名無しさん:2006/10/12(木) 05:17:48
>>259
ケチw途中でウザくなったけどCSUnitとか気になる
まだ自宅でしか使わないけど(´・ω・`)

261 :256:2006/10/12(木) 08:13:07
…さすがに全部見逃す仕様って訳じゃないようだな。
Assertionの失敗の例外を時々見逃してしまうらしい。バグか…。

262 :デフォルトの名無しさん:2006/10/13(金) 21:28:44
全部読んできた・・・
学生とみかかについてかよw何のスレだよwww

263 :デフォルトの名無しさん:2006/10/13(金) 23:26:07
俺たちの戦いはこれからだ!



                     <完>

ご愛読ありがとうございました。
次レスからはunitテストについての新スレが始まります。ご期待ください。

264 :デフォルトの名無しさん:2006/10/14(土) 01:52:09
協力会社、元請、ひいてはIT業界がキャッチできずに
つぶれるぐらいの例外…



…そう、 Throwableをはるかに跳躍した例外をthrowしたい。
finallyをさせる暇さえ与えさせない

265 :デフォルトの名無しさん:2006/10/14(土) 12:32:24
証券会社のシステムのCPUが何故か外れちゃうとかそんな感じかしら。

例外っつーか想定外っつーか。

266 :デフォルトの名無しさん:2006/10/14(土) 22:20:20
>>264
電気渡さなければいいんじゃないか?
ここまで書けば何をすればいいかわかるよな?w

267 :デフォルトの名無しさん:2006/10/15(日) 08:37:01
>>266
まあそれと大手町爆破すればOKっぽい

268 :デフォルトの名無しさん:2006/10/16(月) 13:02:31
ゴルゴに依頼しとけばなお安心

269 :デフォルトの名無しさん:2006/10/17(火) 15:54:19
そんな金があればそもそも>>264みたいなことは考えないだろう。

270 :デフォルトの名無しさん:2006/11/13(月) 12:48:50
長いXMLファイルの出力がうまくいってるかどうかってどうやってチェックしてる?
自分は正解を手で書いといてそいつと出力結果を1行づつ読み込んで比較する
assertion用メソッドを書いている。

ただ問題があって仕様が変わるたびにXMLファイルを書き直すのが面倒で、
つい比較用に出力したXMLファイルを目で眺めて参照用ファイルとしてリネームして流用しちまうこと…。
この場合、目で見るときに間違いを見落とすことがあり、それでもテストは通るからチェックにかからない。

271 :デフォルトの名無しさん:2006/11/13(月) 23:21:25
>>270
正直言ってる意味がよくわからない

272 :デフォルトの名無しさん:2006/11/13(月) 23:50:45
XML読むライブラリ使おうよ。

XPathとかで、必要とされる要素が必要とされる階層にあると確認できれば
それで良しとしてくれなきゃ、きりがない。

273 :デフォルトの名無しさん:2006/11/14(火) 12:41:43
>>272
読み込み側のプログラムではXMLパーサとか使ってるけど
対象プログラムは出力専用で、テストでしか読まないからなぁ。

274 :デフォルトの名無しさん:2006/11/14(火) 21:56:22
>>270
jaxbでいいんじゃね?
型チェックも出来るし、Objectからデータとってチェックすればいいし。

まぁテストだけのために使うか?wwwって話だが・・・

275 :272:2006/11/15(水) 00:27:12
>>273
俺が言ってるのは、以下のような感じで構造を確認すれば?って事なんだが。

String str = "<foo><bar id=\"10\">hoge</bar><bar id=\"11\">mage</bar></foo>";
InputSource source = new InputSource(new StringReader(str));
XPath xpath = XPathFactory.newInstance().newXPath();
String result = xpath.evaluate("/foo/bar[@id=11]", source);
assertEqual("mage",result);

多分これぐらいだったら
assertXml(XPath,ドキュメント,期待値);
っていうメソッド作れば、楽にならんか?

見当違いの事言ってたらすまんね。

276 :デフォルトの名無しさん:2006/11/15(水) 08:08:26
>>275
そういうのならXMLUnitってのがあるよ。

277 :デフォルトの名無しさん:2006/11/15(水) 16:36:59
>>276
↓これすか?
配布元
 http://xmlunit.sourceforge.net/
日本語解説
 http://634.ayumu-baby.com/xmlunit/index.html

278 :デフォルトの名無しさん:2006/11/15(水) 16:42:09
…最終更新が2003年4月か、ウチは今JUnit 4.0使ってるんだが対応してるかな。
配布元サイトで対応するJUnitの版に関して書いてある部分を見つけられないが…。

279 :デフォルトの名無しさん:2006/11/15(水) 21:31:33
>>278
きっとJUnit4には未対応だろうね。でも、javadoc見ると
org.junit.Assertに対応するorg.custommonkey.xmlunit.XMLAssertというクラスがあるので、
これをimport staticすれば、JUnit4のテストケースでも使えるんじゃないかと思う。

280 :デフォルトの名無しさん:2006/11/16(木) 11:08:22
ぬぬむ。今回のプロジェクトではもう今更テスト書き直すのが面倒だけど、
次は使ってみるか…。

281 :デフォルトの名無しさん:2006/11/16(木) 23:00:00
>>280
「単純クラスで試してみればいい」に100ペカリ

282 :sage:2006/11/17(金) 16:10:57
Excel VBAのxUnitを探してたら、souceforge.jpにVBAUnitってのがあったんだけど、
これどうやって使うんでしょう?アドイン形式なので他のやつよりよさげなんだけど・・・。

283 :デフォルトの名無しさん:2006/11/20(月) 00:26:35
JUnit4.2キタ━━━━━━(゚∀゚)━━━━━━ !!
http://sourceforge.net/project/showfiles.php?group_id=15278

284 :デフォルトの名無しさん:2006/11/20(月) 00:43:57
>>283
マルチウザい。
具体的にどういうところが変わったのよ?
人柱レポートよろ。

285 :デフォルトの名無しさん:2007/01/05(金) 15:55:40
>>284
話が進まないので、もう言いだしっぺのキミが人柱でヨロ。

286 :デフォルトの名無しさん:2007/02/15(木) 20:13:20
JUnit Converterって今誰かメンテしてるの?
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/junit/string-converter.html

作者の石井勝さんは、JR福知山線脱線事故でお亡くなりになられたそうです。ご冥福をお祈りします。


287 :デフォルトの名無しさん:2007/02/15(木) 20:24:46
してないんじゃないかな。
Quick Junitはsf.jpにプロジェクトがあるけど。

288 :286:2007/02/16(金) 10:11:58
>>287
うーん、残念です。非常に便利なモノなのですがね……。

289 :デフォルトの名無しさん:2007/02/16(金) 11:58:01
Commons LangのToStringBuilderがいい線までいってるけど、
JUnit Converterと比べるとイマイチ。

290 :デフォルトの名無しさん:2007/02/17(土) 21:42:33
ううむ、こんないいのあったの知らなかった。
自分で似たようなの作った後にCommons LangのReflectionToStringBuilder見つけてへこんでたのに、
さらに便利なのがあったとは。

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)