JUnit使おうよ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/03/17(金) 16:28:430002デフォルトの名無しさん
2006/03/17(金) 16:44:350003デフォルトの名無しさん
2006/03/17(金) 19:18:09そしたら使ってやります
周りにも布教してやります
00041
2006/03/17(金) 20:15:05バカに教える価値は無い
0005デフォルトの名無しさん
2006/03/17(金) 20:33:39バカ！バカ！マンコ！
0006デフォルトの名無しさん
2006/03/18(土) 14:55:26http://www.junit.org/
0007デフォルトの名無しさん
2006/03/18(土) 17:12:46○ >>5
0008http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 18:22:46TextSS の64bit化キボンヌ
もしくは64bitにネイティブ対応した置換ソフトないですか？
0009デフォルトの名無しさん
2006/03/20(月) 09:25:08http://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
0010デフォルトの名無しさん
2006/03/22(水) 16:56:45Thx！
0011デフォルトの名無しさん
2006/03/24(金) 12:34:320012デフォルトの名無しさん
2006/03/24(金) 15:50:35きっとCUnitを使う。
0013デフォルトの名無しさん
2006/03/24(金) 16:14:59あんな面倒なの誰が使うかっつーの
0014デフォルトの名無しさん
2006/03/24(金) 16:15:35ttp://www.xprogramming.com/software.htm
0015デフォルトの名無しさん
2006/03/24(金) 16:17:210016デフォルトの名無しさん
2006/03/24(金) 16:19:35ユニットテストの便利ツールが組み込まれてないんだよ！
0017デフォルトの名無しさん
2006/03/24(金) 16:20:30ねーーーーーーーーーーーーーー!!!
0018デフォルトの名無しさん
2006/03/24(金) 19:17:490019デフォルトの名無しさん
2006/03/24(金) 20:01:100020デフォルトの名無しさん
2006/04/22(土) 19:49:430021デフォルトの名無しさん
2006/04/22(土) 20:04:14おまえ、頭ガチガチだな。
一生テストしづらいコード書いて低品質でコスト高なシステム作ってろ
0022デフォルトの名無しさん
2006/04/22(土) 23:15:17いきなりコードを書いて使い物になるのは達人だけだ。
オマイの糞コードを磨いていては１００年経っても完成しないっつーの。
0023デフォルトの名無しさん
2006/04/22(土) 23:26:09カビの生えた脳みそさん♪
0024デフォルトの名無しさん
2006/04/22(土) 23:50:18全くわかってないじゃん、このオッサン。
0025デフォルトの名無しさん
2006/04/23(日) 11:26:180026デフォルトの名無しさん
2006/04/23(日) 12:55:47リフレクションで呼ぶのも面倒なので
メソットを全てpublicにした
EJBコンテナ上で動くクラスだけどCactus使うの面倒なんで
自分でInitialContextFactory作ってJNDI試験用実装
とJTAの試験実装書いて試験した
後悔はしていない
来月から違う現場だしｗ
始めから言えばTDDで作ってやったんだが・・・
あっ試験できないコードは糞ってのは同意
0027デフォルトの名無しさん
2006/04/24(月) 17:16:510028デフォルトの名無しさん
2006/04/24(月) 19:15:10つ DbUnit
0029デフォルトの名無しさん
2006/04/25(火) 13:07:08ダンスとダイエットとリバウンド（DDR）で活躍するデブ四人組娘ユニット。
日食の日にはデブエディットと名前を変えあなたの性欲晴らします。
0030デフォルトの名無しさん
2006/04/25(火) 21:44:28緑バックに黒文字…加えてリンクが赤…。
多分Javadocのテストをしなかったのだろうな。
0031デフォルトの名無しさん
2006/04/26(水) 00:31:35＞メソットを全てpublicにした
せめてパッケージ合わせて、デフォルトかprotectedにしろよ
0032デフォルトの名無しさん
2006/04/26(水) 01:26:130033デフォルトの名無しさん
2006/04/26(水) 21:37:18メソットした。
0034デフォルトの名無しさん
2006/04/27(木) 02:55:27俺はいいと思うけど。
テスティングフレームワークらしい配色じゃん。
0035デフォルトの名無しさん
2006/04/27(木) 07:58:19たぶんデザインした奴は色盲なんじゃないか？
0036デフォルトの名無しさん
2006/04/27(木) 08:50:180037デフォルトの名無しさん
2006/05/04(木) 08:40:100038デフォルトの名無しさん
2006/05/22(月) 20:44:51工数がかかりすぎるし、全てのテストができるわけでないし、
普通にテストした方が楽だと思うんですけど。
0039デフォルトの名無しさん
2006/05/22(月) 20:52:49自動車で言うと保険というよりシートベルトに近いです。
0040デフォルトの名無しさん
2006/05/22(月) 21:27:16どういうことですか？
0041デフォルトの名無しさん
2006/05/22(月) 23:16:100042デフォルトの名無しさん
2006/05/23(火) 02:18:31単にそれまでろくにテストやってなかっただけ、って結論が出てた。
0043デフォルトの名無しさん
2006/05/23(火) 05:20:02保険は事故った後。
シートベルトは事故の最中。
保守はコーディング後。
ユニットテストはコーディングの最中。
かな…？いい言葉見付からなくて、適当だけど。
0044デフォルトの名無しさん
2006/05/23(火) 23:34:580045デフォルトの名無しさん
2006/05/24(水) 00:23:070046デフォルトの名無しさん
2006/05/24(水) 01:47:490047デフォルトの名無しさん
2006/05/24(水) 03:12:360048デフォルトの名無しさん
2006/05/24(水) 11:38:100049デフォルトの名無しさん
2006/06/17(土) 00:29:52junitつくっとけよ馬鹿、と思った。
0050デフォルトの名無しさん
2006/06/17(土) 02:41:44改修やリファクタリングする時は絶対合った方が安心感があっていいけど、短期的に捕らえるとしっかりしたテストケース書く分工数増えるしさ。
0051デフォルトの名無しさん
2006/06/17(土) 05:42:020052デフォルトの名無しさん
2006/06/17(土) 08:06:05if (お前は豚ですか）みたいな
0053デフォルトの名無しさん
2006/06/17(土) 10:21:17Swingなら つ JFCUnit
Webなら つ Cactus
0054デフォルトの名無しさん
2006/06/17(土) 20:45:24blancoJUnitとか
0055デフォルトの名無しさん
2006/06/18(日) 01:51:05一回だけやるテストならどう考えてもコード書くよりは早い&楽だろ。
繰り返しテストを行う予定がなければJUnitのテストケースなんて無駄。
0056デフォルトの名無しさん
2006/06/18(日) 02:10:05>一回だけやるテスト
それってつまり
・機能バグ・詳細設計バグ・コーディングバグ0件
・リファクタリングの必要皆無=極限まで洗練されたソースコード（単体テスト終了時点）
・現在および将来に渡っての仕様変更0件
って事か。
あるわけねーだろ馬鹿
005756
2006/06/18(日) 02:11:28>51→55
0058デフォルトの名無しさん
2006/06/18(日) 02:48:42単体でも結合でも。
コードが書かれる以前に設計が完璧で変更無しか。
リファクタリングも無しか。
しかもそれらが完全保証。
確かにそれならJUnitいらないよな。
0059デフォルトの名無しさん
2006/06/18(日) 02:56:21君はJUnitを完全なものと捕らえすぎてる。
やらないよりやったほうが良いが、メソッドを一個一個確認せず全部まとめてドンと実行し
まぁOKとできるなら、そのほうが良い場合もある。
>>55 みたいなのもそのケース
何もこだわらずJUnitなんて無駄だ!とぬかすバカどもよりよほどマシだが
JUnitは万全で、すべての場合においてそれやればよいというものではない。
0060デフォルトの名無しさん
2006/06/18(日) 03:10:18なぜ必要あるよ派は、無いよ派を説得しようとする、あるいはしたがるのだろうか。
ところで俺は必要あるよ派である。xUnitを手放せなくなった最大の理由があるのだが、
それはここでは書かない。説明しても必要ないよ派には絶対に理解できないからだ。
そう、それは実際にやらないとわからないことなのだ。
俺も以前は、こんな良い物を広めない手はないと、熱心なエバンジェリストと化した
こともあった。しかし今ではその情熱もさめた。
君もそうじゃないか？
なぜそうまでして説得するのだろう？
おそらく必要無いよ派は、死ぬまでxUnitを使わないのだろう。
それなのに君はなぜ説得しようと試みるのだ。
0061デフォルトの名無しさん
2006/06/18(日) 03:20:04（以下略）
0062デフォルトの名無しさん
2006/06/18(日) 06:21:36毎日暇な時間に動かして正常に動くことで変なことやってないってのを確かめるものでは？
0063デフォルトの名無しさん
2006/06/18(日) 11:10:130064デフォルトの名無しさん
2006/06/18(日) 13:08:090065デフォルトの名無しさん
2006/06/18(日) 13:24:120066デフォルトの名無しさん
2006/06/18(日) 13:35:58テスト項目書を埋めるためにJUnitを使うってのは、本末転倒では。
0067デフォルトの名無しさん
2006/06/18(日) 18:31:12テストメソッドを一瞬で書くことが出来ず、何分もかかるようなレベルだと、テストメソッドを書くこと
自体がすぐに嫌になってメリットを享受するところまでいかない。
0068デフォルトの名無しさん
2006/06/18(日) 18:33:55JUnitでやるテストとテスト項目書のテストってどのくらい違うの？
0070デフォルトの名無しさん
2006/06/18(日) 21:01:340071デフォルトの名無しさん
2006/06/18(日) 21:40:26JUnitを使うのは本末転倒だということです。
テストスイートで何をやってるかをユニットテストチェックリストにおこすのなら話はわかります。
0072デフォルトの名無しさん
2006/06/18(日) 21:49:11でもうちはユニットテストについては、ドキュメント化しないからなぁ
0073デフォルトの名無しさん
2006/06/18(日) 22:36:410074デフォルトの名無しさん
2006/06/18(日) 22:40:49007571
2006/06/18(日) 22:57:43ご心配なく、うちもしませんので。
誰かがテストスイートの内容を示すドキュメント化をしろといわない限り。
>>73
変換後にきちんとしたドキュメントになるような内容を書け、というとアレルギーが発生するので、
うちでは適当でいいよ、と言っています。ただし、テストメソッド名で内容を語れ、とは言ってます。
0076デフォルトの名無しさん
2006/06/19(月) 23:32:08お前の下で働かせてくれ
0077デフォルトの名無しさん
2006/06/19(月) 23:37:17こんな感じでドキュメント代わりに使う人は多いと思う。
0078デフォルトの名無しさん
2006/06/20(火) 01:44:40その1回のテストすらいらないな。
0079デフォルトの名無しさん
2006/06/20(火) 02:28:38標準のテスト項目が少なくなるならいいかも。
0080デフォルトの名無しさん
2006/06/20(火) 03:54:03あくまで、ソース修正の方向性を定めるためだけの
いい加減なテストケースであることがおおいし。
0081デフォルトの名無しさん
2006/06/20(火) 06:58:41戻り値の内容がこれこれであること、っていう紙切れを別途用意すんの？
0082デフォルトの名無しさん
2006/06/20(火) 08:33:43普通に関数の前のコメントとか、ドキュメント用のファイルとか、紙切れとかに書くだろ。
JUnitは関係ないだろ。
0083デフォルトの名無しさん
2006/06/20(火) 17:33:50例えばあるメソッドのテストをするとして、正常系・異常系とか、異常系でも引数のエラーとか
内部処理の例外とか。テストメソッド1つにテスト1つ？それともある程度まとめる？
前に出てたJavadocでのドキュメント化も、その範囲によって随分労力が変わると思うんだが。
0084デフォルトの名無しさん
2006/06/20(火) 17:43:29正常1、正常2、異常1、異常2とあれば4つ。
0085デフォルトの名無しさん
2006/06/20(火) 17:51:15JUnitは本来TDDのためのもので、そのTDDに使うとしたら、
そんなに詳しいテストをきっちりとするわけがない。
JUnitの使い方が間違ってるとしか思えない。
0086デフォルトの名無しさん
2006/06/20(火) 18:18:04それに、かっちりしないって、TDDじゃ少なくともC0カバレッジになるんですが。
0087デフォルトの名無しさん
2006/06/20(火) 18:20:52いや、後出しも何もJUnit作った本人（KentBeck）がTDDとワンセットで有名に
しただろ。
俺間違ってる？
0088デフォルトの名無しさん
2006/06/20(火) 18:21:15前やった業務プログラム、カバレッジ60%だった。
どんだけ例外で潰してんねんみたいなコードだった
0089デフォルトの名無しさん
2006/06/20(火) 18:30:43JUnitは、もともとはXPのtest firstのためのツールだったよね？
TDDは「Red/Green/Refactor」が合言葉の開発手法。このRefactorを重視してるところが、XPとは
異なるところ。
まぁそんなつまらん話はおいといて、>>86でいいたかったのは「>>84は間違ってるだろ」
って違うだろ、ってことなんだが。
0090デフォルトの名無しさん
2006/06/20(火) 18:31:410091デフォルトの名無しさん
2006/06/20(火) 18:33:04業務ならよほどの場合を除いて100%がデフォ。
「よほどのこと」とは、エラー処理を書いたが、そんなエラー起こせません、ってなとき。
0092デフォルトの名無しさん
2006/06/20(火) 18:34:47じゃあその簡単すぎるメソッド以外では、C0カバレッジになる、には同意する？しない？
0093デフォルトの名無しさん
2006/06/20(火) 18:39:17Test first＝TDDじゃん。
まあ、厳密に言えばTDDの方が詳しい概念かも知らんが、
少なくともTDD提唱者とJUnit作者は同じであり、JUnitが現在TDDのためのツールであることは
間違いないよ。
>>84はTDDじゃないとおもうが。
>>92
どうだろうね。そういうのまでC0カバレッジになるって
言っちゃっていいのかなｗ
あと、もちろん他人の書いたソースコードに対しては
テストなんかしないだろうし。
0094デフォルトの名無しさん
2006/06/20(火) 18:47:020095デフォルトの名無しさん
2006/06/20(火) 18:47:50>>93が言わんとしてるTDDこそ正答だってのはどんな流れ？
0096デフォルトの名無しさん
2006/06/20(火) 18:49:21君は>>89？
>TDDは「Red/Green/Refactor」が合言葉の開発手法。このRefactorを重視してる
これが大体当たってるよ。「XPのtestfirstと違う」ってのは間違ってると思うが。
ほぼ同じだと思うから。
0097デフォルトの名無しさん
2006/06/20(火) 18:53:40同じものが進化したともいえるけどね。
0098デフォルトの名無しさん
2006/06/20(火) 18:56:53まあ、そうかもしれんが、いずれにせよ、きっちりと体系的に
テストを用意してドキュメント代わりに使ったりするような
もんではないな。
0099デフォルトの名無しさん
2006/06/20(火) 19:02:59同意しないといつまでも暴れそうだから。
>>84を「そんなに詳しいテスト」と表現しちゃうような人とは話しても無駄なんで、
俺は退散するよ。俺の意見は>>91。
C0カバレッジすらめざさない奴といっしょに仕事したくないな。
0100デフォルトの名無しさん
2006/06/20(火) 19:06:150101デフォルトの名無しさん
2006/06/20(火) 19:10:12俺は別に暴れてるわけじゃないよ。厳密に言えばJUnitは本来TDDのためのものじゃなくて
Test Firstのためのものだったかもしれないということには同意しているし。
ただ、そんなことは重要なことではない。
言葉のあやで、「本来＝意図した」という意味で言ってたわけで、
現在JUnitがTDDを意図したツールであることは間違いないし、そこが重要だからね。
で、あくまでJUnitを使ったTDDのためのテストではそんなに詳しいテストをしないというだけ。
必ずしもC０すら目指さないよ。TDDの本読めばわかるし、提唱者本人が本にそうかいてるしね。
しかし、それとは別に、業務では詳しいテストを実施するだろうね。
そこでC０を目指したらいい。これはJUnitを使ったテストとはまったく別。
少なくともJUnitの意図された使い方とは別。
0102デフォルトの名無しさん
2006/06/20(火) 19:11:09じゃ、ファイルを処理する正常系のコードとテストを書いて、Greenになったあとで、
ファイルがオープンできなかったときのコードを追加したとき「これは簡単だから
てすとしなくていいや」ということ？
0103デフォルトの名無しさん
2006/06/20(火) 19:11:57確かにそういってたかもなあ。忘れたけど。
KentBeckのTDDの本は持ってるし読んだから。
厳密に言えばTestFirstはTDDとは違うんだろうね。
そんなことはどうでもいいけど。
0104デフォルトの名無しさん
2006/06/20(火) 19:13:31そういうこともありえるだろうね。
TDDってそんなもんだよ。
0105デフォルトの名無しさん
2006/06/20(火) 19:15:23退散するとか言いながら、また出てきたりする。
あー、最近暴れてる奴と勘違いしちゃった。ごめん。
俺もあなたとほぼ同じ認識だよ。（JUnitとTDDの関係）
でもね、Kent Beckが出した本では、何をテストすべきかでちゃんと分岐も繰り返しもあげてるよ。
しつこいようだけど、>>84のJUnitの使い方が誤りってばっさりやるのが納得できないだけ。
まぁ、個々人でテストをどうとらえるかによるところでもあるから、あまり話しても利益がないかもね。
ということで、本当にこの話題からは手を引く。
0106デフォルトの名無しさん
2006/06/20(火) 19:19:04確かに分岐や繰り返しなんかは格好のテスト分割対象かもしれないけど、
>>84みたいに必ずしも結果が分岐するからそれにあわせて
テストを作る必要はないってこと。
ようは、「簡単すぎるからテストなんかいいや」、ってこともある。
もちろん程度の問題だが。
0107デフォルトの名無しさん
2006/06/20(火) 19:19:42徳光和夫のホントの涙を見た人がいないように
0108デフォルトの名無しさん
2006/06/20(火) 19:30:55Kent Beckは言ったでしょ？「大切なのは目的」「不安がなくなるまでテストやれ」って。
どうやるのが正解で、どうやるのが誤りなんて、君が決めることじゃないよ
0109デフォルトの名無しさん
2006/06/20(火) 19:39:080110デフォルトの名無しさん
2006/06/20(火) 20:03:23だからさ、「不安がなくなるまでテストする」でいいじゃん。
分岐のたびにきっちりテストするとか、そういうきっちりとした規則とか作らないし、
そんな細かくメソッド分けないし。
0111デフォルトの名無しさん
2006/06/20(火) 20:08:12JUnitのスレなんだから作者の発言が出てくるのは
仕方ないだろ・・・
0112デフォルトの名無しさん
2006/06/20(火) 20:28:52だからさ、君がテストのやり方きめなくていいじゃん。
君の不安と他人の不安っていっしょなの？
0113デフォルトの名無しさん
2006/06/20(火) 20:29:460114デフォルトの名無しさん
2006/06/20(火) 20:31:55それに君TDDの精神まったくわかってないから。
ほんとに本読んだの？
0115デフォルトの名無しさん
2006/06/20(火) 20:49:31まあ、どれだけテストするかは、ある程度は個人の自由かもわからんが、
どうみても、>>84は不安とかを基準にしてないでしょ。
機械的にきっちりとルールを決めすぎ。
それと、処理結果ごとにメソッドを書くなんて言ってるところは
おそらくメソッド書きすぎ。
1つのメソッドのテストに1つのテストメソッド程度が普通かな。
>>114
悪いけど読んだよ。読んだ上に、実際コードを全部打ち込んで
シミュレートまでしたよｗ
で、異常な場合までテストしてなかったよｗ
0116デフォルトの名無しさん
2006/06/20(火) 21:14:18それは君が書くコードを基準にものを考えてるだけなんだよ。
そりゃ君はそれで十分なんだろうけど。その基準を他人に押し付ける権利はないよ。
読んだんならわかるだろ。TDDは開発手法であってテスト手法じゃないことが。
KentはTDDの為にJUnitを作った。正しい。
TDDではJUnitを使う。正しい。
JUnitをTDD以外で使うのは正しくない。誤り。
JUnitを使う人はみんなTDDで開発している。誤り。
まぁ君は優秀なプログラマなんだろうけど、視野が狭いね。
0117デフォルトの名無しさん
2006/06/20(火) 21:33:252章のxUnitの例をきっちり読んでれば
>処理結果ごとにメソッドを書くなんて言ってるところは
>おそらくメソッド書きすぎ
なんてアホなこと言わないはずだけど。
0118デフォルトの名無しさん
2006/06/20(火) 22:29:23なんか勘違いしてるな。
関数の仕様のドキュメントじゃないよ。
テストケースのドキュメントの話だよ。
0119デフォルトの名無しさん
2006/06/20(火) 22:41:08処理結果ごとにassertを実行するというのならまだわかるけど、
メソッド書くなんてのは明らかに違うだろ
0120デフォルトの名無しさん
2006/06/20(火) 22:43:39いらっしゃいますな。
この書き込みだけで「機械的きっちりと決めすぎたルール」だと思ってしまうなんて。
どれだけの脳内補完が働いていることやら。
「処理分岐」としか書いていないのに、どれだけの粒度・詳細度で考えているのかまで
読み取れるのか。すごいな。
恐らく、経験3年前後の若くて優秀なエンジニアと想像してみる。
新しいことを覚えるのに夢中で、自分のスキルに自信があり、
こだわりと明確なポリシーを持って仕事をしている。
0121デフォルトの名無しさん
2006/06/20(火) 22:48:39例えば、メソッドの戻り値がboolean型で、
特定の状況でHogeExceptionをthrowするという
仕様だったとしたら、メソッド3つとかそんなもん。
trueを返すパターンとfalseを返すパターンと
例外が投げられるパターン。
これでも書きすぎ？
StrutsやTomcatのソースコード見てると
そんな書き方をしてるけど・・・
CraigやRemmyに「明らかに違うだろ」って言ってよ。
HustedやMartinはわかってないって言いたい？
0122デフォルトの名無しさん
2006/06/20(火) 22:58:52時と場合による。booleanとかその程度しかなく、それぞれの場合が何の関連性も持たずに
独立しているならそれでいいけど、いつの場合も機械的に分けるのは明らかに間違い。
0123デフォルトの名無しさん
2006/06/20(火) 23:00:11随分と決め付けが激しいなｗ
0124デフォルトの名無しさん
2006/06/20(火) 23:05:180125デフォルトの名無しさん
2006/06/20(火) 23:06:35後半部分は単なる想像です。「明らかに」なんて言ってません。
0126デフォルトの名無しさん
2006/06/20(火) 23:06:53方針変換などしてないよ。はじめからそのつもり。
文脈見ればわかるだろ。
機械的に決めるのが間違いだと言ってるわけで、
時と場合によってOKになるのは当たり前。
0127デフォルトの名無しさん
2006/06/20(火) 23:07:260128デフォルトの名無しさん
2006/06/20(火) 23:08:45前半部分は決めつけだろｗ
0129デフォルトの名無しさん
2006/06/20(火) 23:10:03これも場合によるんじゃないかな。
耐用年数が多い堅牢なシステムを作る必要があるなら、多くなるかもしれないし、
そうじゃになら少なくなるんじゃないかな。
0130デフォルトの名無しさん
2006/06/20(火) 23:10:42なんだか、自分の基準でものを考える人ですね。
0131デフォルトの名無しさん
2006/06/20(火) 23:11:49決めつけの根拠の詳細を希望。
0132デフォルトの名無しさん
2006/06/20(火) 23:12:28そろそろ冷静になれよ。くだらないことにむきになるなよｗ
0133デフォルトの名無しさん
2006/06/20(火) 23:29:09・メソッドを分けるか、同一メソッド内で複数のアサーションを行うかは時と場合による。
・でも、>>84 は明らかに間違い。
・ASFのコードは「時と場合による」の範疇。
ってことでFA?
0134デフォルトの名無しさん
2006/06/20(火) 23:36:013つ目は見ないとなんとも言えないが上から二つはその通り。
0135デフォルトの名無しさん
2006/06/20(火) 23:41:25俺は>>84のコードを見ないとなんとも言えない。
>>133の一つめだけだな。同意できるのは。
0136デフォルトの名無しさん
2006/06/20(火) 23:56:01もしそうであるならば、こんなもんは間違いにきまってる。
まあ確かに、そういう意味だとするのは決め付けだ、そういう意味ではないと強弁すれば、
言い逃れることもできるがなｗ
0137デフォルトの名無しさん
2006/06/21(水) 00:58:24｢もしそうであるならば｣って・・・
明らかだったんじゃないのか？
0138デフォルトの名無しさん
2006/06/21(水) 01:36:37メソッドの仕様も判らず、ソースコードを見て想定される結果をひたすらテストコードに記述。
品質保証の武器になったらしいが、まじで無駄な仕事だった。
上のレスでもあったが、JUnitはTDDが理想。
それが不可能でも、少なくともブラックボックステストであるべきだ。
ホワイトボックステストではない。
0139デフォルトの名無しさん
2006/06/21(水) 01:49:13TDDの場合はある意味ホワイトボックステストに近いテストケースになるはず。
0140デフォルトの名無しさん
2006/06/21(水) 02:08:26自分はJUnitではなくてCUnitなんだけど、ホワイトボックスでないと駄目なケースが多いよ。
ブラックボックスにする時は相当優秀なスタブ作った時ぐらい。
C0検査とかはxUnitではなくて、商用のツールにお任せしている。
インフラが整った環境だと、xUnitでテストできる分野って狭いんだよね。
単体テストの３割ぐらいを占めるぐらい。
それでもテストコードを書きやすいって事は、品質が高い事につながる場合が多い。
つまり、ガンガレおまえら。
0141デフォルトの名無しさん
2006/06/21(水) 02:11:44あとで、それが役に立つって分かってても、
「ここでこうなる！…あ、なったなった、Greenバーオメデトウ」
って、馬鹿馬鹿しい気がしてくる。
0142デフォルトの名無しさん
2006/06/21(水) 02:13:52それわかる。
最近はもう、XUnit利用はDI前提だと思ってる。
0143デフォルトの名無しさん
2006/06/21(水) 02:24:56じゃぁKent Beckが間違えているということですね。
0144デフォルトの名無しさん
2006/06/21(水) 02:28:32あっても片手で数えられるくらいだろ。
しかしJUnitを使ってるところは多い。
あとはわかるな？
0145デフォルトの名無しさん
2006/06/21(水) 02:32:30んで、TDD以外ではJUnitなんか使わないはずだから、JUnitであんなことすんのは馬鹿、って
アホが叩いてる、と。
社会に出ろ、自分の目で見ろ、絶望しろ。
世界はお前らが思ってるほど、綺麗ごとでは動いてないし、整然ともしてない。
周りは馬鹿だらけだ。
お前の世界で正しいことが、世の中でも正しいだなんて思うな。
0146デフォルトの名無しさん
2006/06/21(水) 02:36:17「途中のバグを修正しても、過去に行ったテストはなかなか実行しない」だ。
それをxUnitは克服させてくれる。テストの自動化っつーやつでな。
Regression testにも有効なんだよ、Unit Testing Frameworkは。
Acceptance testで使ってるところもあるくらいだ。
0147デフォルトの名無しさん
2006/06/21(水) 10:49:14おまえら正常ひとつだけテストして品質がどうとか語ってんの？
それでリグレッションやってるつもりなの？
0148デフォルトの名無しさん
2006/06/21(水) 11:21:16どうやらそういうことらしい。
そういう方針は明らかに間違いなんだそうだ。
0149デフォルトの名無しさん
2006/06/21(水) 12:00:52xUnitで品質上がったとか言ってる奴の9割が、
単にいままで全結合するまでほとんどテストをしてなかったってだけ。
ソースレビューすらしてないとか平気な人達。
0150デフォルトの名無しさん
2006/06/21(水) 12:31:26ブラックボックスだけというような制約はTDDにもないよ。
>>140 >>142
君が言うように普通のテストにJUnitなんか使ったって、しょうがないんだよ。
もともとTDDしか念頭においてないんだし。
>>143
間違ってないよ。84は間違えてるけど。
>>145
結局その社会とやらの方が馬鹿なのかよｗ
その通りだよｗ
>>147-148
だから、JUnitでやるのは、TDDであって、普通のテストじゃないって
何回言えばわかるんだ。
TDD以外でJUnit使うのは、JUnitの使い方を間違えてる。
0151デフォルトの名無しさん
2006/06/21(水) 12:34:21だから、xUnitのTDDと普通のテストを混同するなよ。
全結合テストをやっているいないにかかわらず、TDDは有効だし、
それ以外にxUnit使うのは、使い方の間違い。
0152デフォルトの名無しさん
2006/06/21(水) 12:43:13４つある仕様のうち、ひとつさえ動作が確認できたらできあがりなのか。
リファクタリングしても、４つある仕様のうち、ひとつさえ動作できたらデグレ無しなのか。
ＴＤＤって夢のような開発手法だね。
0153デフォルトの名無しさん
2006/06/21(水) 12:44:32ただ、簡単なエラーになった場合とかテストを省くことは多いね。
まあTDDの本でも読みなよ。
0154デフォルトの名無しさん
2006/06/21(水) 12:45:070155デフォルトの名無しさん
2006/06/21(水) 12:52:42片方しかやっちゃいけないということはないよ。
0156デフォルトの名無しさん
2006/06/21(水) 12:54:45まあ、TDDだとすると、間違ったテスト方針だねｗ
0157デフォルトの名無しさん
2006/06/21(水) 12:55:560158デフォルトの名無しさん
2006/06/21(水) 12:56:50あと極小規模じゃないとね。
クラス（Ｉｎｔｅｒｆａｃｅ）すらリファクタリングで初めて設計されるんじゃ普通の開発では使えた代物じゃない。
0159デフォルトの名無しさん
2006/06/21(水) 12:59:50それはTDD自体の良し悪しだな。
そして、JUnitはそのTDD向けのもんだ。
確かに、TDDが嫌ならJUnitなんか使わなければいい。
0160デフォルトの名無しさん
2006/06/21(水) 13:02:080161デフォルトの名無しさん
2006/06/21(水) 13:03:56つまり、TDDではメソッドの仕様にそったテストケースを作成しないってことだねｗ
0162デフォルトの名無しさん
2006/06/21(水) 13:05:48普通のテストならもっといいツールがあるから。
>>161
考え方が両極端だな。作成するけども無条件に作成するわけではない。
0163デフォルトの名無しさん
2006/06/21(水) 13:13:07「うちでは（すべてのメソッドに対して）メソッドの処理結果が分岐する数だけ（無条件に機械的に）テストメソッドも書く（というルールを決めて厳格厳密に運用している）。」
と解釈したわけだ。しかも、その粒度・詳細度も読み取れたわけだ。
0164デフォルトの名無しさん
2006/06/21(水) 13:15:57まあ、正確には
「うちでは（ほぼすべてのメソッドに対して）メソッドの処理結果が
分岐する数だけ（無条件に機械的に）テストメソッドも書く（という
ルールを決めて、ほぼこのルールに従って運用している）。」
程度だがなｗ
あと、粒度・詳細度は正確にはよみとれてないよ。booleanだったら、falseとtrueで
わけるんだろ程度のことはわかるがな。
0165デフォルトの名無しさん
2006/06/21(水) 13:26:25もっといい単体テストツールがあるなら紹介してくれ
0166デフォルトの名無しさん
2006/06/21(水) 13:27:45あきれた
0167デフォルトの名無しさん
2006/06/21(水) 13:39:47真面目に相手してそんしたよ。
0168デフォルトの名無しさん
2006/06/21(水) 13:46:55>>>143
>間違ってないよ。84は間違えてるけど。
runメソッドに複数のテストケースがある。状態によって複数の結果になるときには複数の
テストを行う。あたりまえじゃん。
読んでないの？Pythonだから読み飛ばしちゃった？
0169デフォルトの名無しさん
2006/06/21(水) 13:58:57>だから、JUnitでやるのは、TDDであって、普通のテストじゃないって
>何回言えばわかるんだ。
この辺に思い込みの強さが現れてますなぁ。
Kentは確かにTDDのためにJUnitを書いたのかもしれん。
だがなぁ、いいものは得てして作成者の思惑を超えて広く使われるものなんだよ。
TDDには確かにxUnitが必要。でもxUnitをTDD以外で使ってはいけないという法はない。
簡単な論理でしょう？
0170デフォルトの名無しさん
2006/06/21(水) 14:10:34君が言う「普通のテスト」ってどんなもので、どうやって実行するの？
あぁ、説明する際に適切な語彙を使わないと、お里が知れちゃうから気をつけてね。
0171デフォルトの名無しさん
2006/06/21(水) 14:14:25乙。
0172デフォルトの名無しさん
2006/06/21(水) 14:55:29ちょっと書いて動かして確認、ちょっと書いて動かして確認。
最近の、何百行もコンパイルすらせずにコード書いて、コンパイルエラーでまくりで困惑
してる奴を見ると眩暈がする。
Javaじゃないが、viが使えないという理由で何百行もコードを秀丸で書いて、書き終わったら
ftp送信する奴などは、俺からすれば神だな。そんなこと俺にはとても出来ない。
0173デフォルトの名無しさん
2006/06/21(水) 15:04:23実は俺も手書きでしか書いたことがないからわからないんだ。
商用の糞高いツールはあるらしいが、勘弁してくれｗ
でもそういうツールはテストを自動生成してくれるし、JUnitよりは間違いなく便利だわな。
TDDに使わないJUnitなんか何が便利なのかわからん。
あえて言えば、IDEと親和性が高く、操作方法が慣れてるとかその辺か。
まあ全く意味がないわけじゃないな。
>>167
166は別人だｗ
>>169
それはわかるぞ。実際JUnitをそれ以外のことに使う事だって出来なくは
ないかも知れん。
だがJUnitはTDD用なので、もっと便利なツールを作るのは簡単だ。
目的以外のことに使うとなると、多くの機能が不足してるのは容易にわかるだろう。
その辺を補ってJUnitを使うならまだわかるがな。
だが、少なくともTDD以外でJUnit使っておいて、機能が足りない、使えないとか言ってるのは
お門違いなんだよ。使えないのは当たり前なんだから。そういうのは使い方の間違い。
>>170
いい加減、人にボロを出させて貶すためだけの質問をやめてくれないか？
説明もめんどくさいし、俺のお里がしれようとなんだろうと、関係ないんだよ。
大事なのはお前の主張の正しさはだろ。直接内容に言及しろよ。
まあ、俺が言ってる普通のテストってのは単体テスト→結合テストとやってC0〜C2
満たしたりする昔ながらの開発スタイルだな。
0174デフォルトの名無しさん
2006/06/21(水) 15:09:01TDD礼さんな主張をしてるやつはいないよ。
むしろ、
>似たようなことは熟練プログラマなら昔から普通にやってたことだから
こんなこと言ってる君がTDD礼賛っぽいなｗ
まあ俺も同意見だったりするが。TDD礼賛のレスをしたのはこれがはじめてかなｗ
0175デフォルトの名無しさん
2006/06/21(水) 15:14:44>実は俺も手書きでしか書いたことがないからわからないんだ。
なんでそこでJUnit使わないの？
>TDDに使わないJUnitなんか何が便利なのかわからん。
わからないのに、わかった奴に難癖付けてるんだ。
>だがJUnitはTDD用なので、もっと便利なツールを作るのは簡単だ。
簡単なのに、xUnit登場以前はそのようなツールが出回らなかったのは何故なんでしょう？
>だが、少なくともTDD以外でJUnit使っておいて、機能が足りない、使えないとか言ってるのは
>お門違いなんだよ。
誰もそんなこと主張してませんよ。TDD以外でJUnitを使うと便利だから使うって奴は多いけど。
>いい加減、人にボロを出させて貶すためだけの質問をやめてくれないか？
理由もなしに他人を貶めてるのは君の方なんだけどなぁ。
>単体テスト
だから、単体テストってどうやってやるのか教えてよ。それがわからないとJUnitを
単体テストでつかっちゃいかんという理由がわからないんだよ。
0176デフォルトの名無しさん
2006/06/21(水) 15:32:52JUnit登場から日本でのTDD本発売までには数年のラグがあるけど、その間に日本でJUnitを
使ってた奴はみんな馬鹿なんだね。
（一部の間では有名な）「テスト熱中症」の記事に感激した奴も馬鹿なんだ。これもTDD本のかなり前。
誰もがKent Beckの真意なんか汲み取れたわけではなかったと思うよ。その当時はね。
君は君の考えで、TDD以外でJUnitを使わなけりゃいいだけじゃないの？
何で他人を批判するのかねぇ。
0177デフォルトの名無しさん
2006/06/21(水) 15:53:40自説を展開するのに都合がわるかったんだろうか。
0178デフォルトの名無しさん
2006/06/21(水) 16:01:04向けさせるということもある。
自分の書いたコードを直接テストできるようにと考えながらコードを書くと、自然と結合度が
低く、凝集度が高いモジュールになっていく。駄目な奴は何をどうやらせても駄目だが。
コードレベルと同等の詳細設計をやらせるところでは無意味だが。
0179デフォルトの名無しさん
2006/06/21(水) 16:10:13Unixでtar ballからソフトウェアをインストールしたことある人ならわかるだろうが、
多くのソフトには数百ものテストが添付されていたりする。
これは、自分のマシンで正しく動くことを確認するためだけではなく、改造したときに
他に影響を与えていないかどうかの確認にとても役立つ。
翻って自分が関係するプロジェクトに目を向けると、同じような構図であることが
すぐにわかるはずだ。メンテナンスするものにとって、テストスィートの存在ほど
心強いものはない。譬えそれが不完全なものであったとしても。
0180デフォルトの名無しさん
2006/06/21(水) 16:14:20いわゆる「単体テスト」フェーズで、後付でJUnitのテストを書いても全くかまわない。
出来上がったテストスィートの効果には、なんの影響も及ぼさない。
0181デフォルトの名無しさん
2006/06/21(水) 16:17:12漏れが使ってるのはJUnit(Java)とTUT(C++)だ。
XPの教科書どおりテスト先に書き始めることもあるけど、
テストが後追いになることもある。
デバグ作業中に漏れに気づいてテストを追加することもあるし、
テストを追加するうちに内容が複雑になりすぎて
テスト自体をリファクタリング（メソッドやクラスの分割）するようなこともある。
一応基本は単体テストだがトップレベルに近いクラスは純粋な単体動作は書きにくいから
（ダミーの動作が複雑になりすぎる場合とかね。）
結合テスト寄りな内容になることも当然ある。
どんな手法も万能ではないから杓子定規にする意味はないわな。
大事なのは教義に忠実かどうかではなく
メリット・デメリットのバランスが重要。
教義はメリット・デメリットの着眼点として役立つが、
教義では想定してないメリット・デメリットが後から見つかるのもよくある話。
0182デフォルトの名無しさん
2006/06/21(水) 16:19:10このスレを読むからいかんのだ。馬鹿だなぁ、俺って orz
0183デフォルトの名無しさん
2006/06/21(水) 16:22:220185デフォルトの名無しさん
2006/06/21(水) 16:33:310186デフォルトの名無しさん
2006/06/21(水) 16:37:14大抵自分が間違ってたりするんだよね。
まあ、２ちゃんでは逆の場合もあるけどね。しったか君が粘着した場合とか。
0187デフォルトの名無しさん
2006/06/21(水) 16:46:23Ａ「コーディング終わりました」
リダ「じゃテストやっといて」
・・・
リダ「テスト終わった？」
Ａ「はい終わりました」
リダ「バグ全部取れた？」
Ａ「はい取れました」
リダ「じゃインストーラくっつけてサーバ置いといて」
てな感じのDQN会社ですから orz
俺はxUnit使ってるけど orz
0188デフォルトの名無しさん
2006/06/21(水) 16:55:35いや、ある意味それで会社が廻ってるんだからすごいとも言えるぞ。
実は高スキルな連中ばかりいるんじゃね？
0189デフォルトの名無しさん
2006/06/21(水) 16:58:38間違っちゃいないんだろうけど、自己主張・こだわりが強く、視野と許容性が狭い人間。
優秀な若いエンジニアにはありがちなケース。
0190デフォルトの名無しさん
2006/06/21(水) 17:02:120191デフォルトの名無しさん
2006/06/21(水) 17:12:11JUnitの使い方もわからない馬鹿どもはほおっておけって。ここで数人にわからせてやったって
世の中には馬鹿がくさるほどいるからな。時間の無駄だ。
>>対85
視野の狭い原理主義者なんかほおっておけって。奴を説得しても君にはなんのメリットもないぞ。
使う時間の無駄だ。
0192デフォルトの名無しさん
2006/06/21(水) 17:15:500193デフォルトの名無しさん
2006/06/21(水) 17:24:28私が入る前まで開発されてた版は殆ど1人で3年掛けてコツコツ書いてたらしい。
がC++/Rubyが入り混じる10万行規模（後に機能が整理されて6万行規模に）の
C言語サブセット処理系で単体テストなし。
いきなり結合テストとしてCソースを喰わせていて、
後から参加してデバッグ手伝わされたり移植させられたりでエラい目にあった。
正直絶対メンテできないコードだと思った。
ので既存のコンパイラ・フレームワークを使って
後継新版を開発する話を提案してついでに言語環境もJavaに移し、JUnitも導入してもらった。
まぁ、スケジュールは多少遅れ気味だけどプログラミング的には
去年よりは幸せになったと思う。多分。
0194デフォルトの名無しさん
2006/06/21(水) 17:33:38ってのがTDDではないってのも目新しい。
0195デフォルトの名無しさん
2006/06/21(水) 17:56:47・JUnitはKent Beckが作った
・Kent BeckはTDDをやる目的でJUnitを作った
・だからTDD以外でJUnitを使うのはあやまり
というもの以上でも以下でもないから。
コーディングという文脈ではなくテストと言う文脈でJUnitを使うところも結構あると思うが（>>84も多分そうだろう）、
件の彼は以上の理由でもってただ切り捨ててるだけ。死語の感はあるが、馬鹿の壁というやつだろう。
「何故TDD以外でJUnitを使ってはいけないのか」に明確な理由を示さないのがその証拠。
しかも件の彼の会社なりチームで、どのような単体テストをどのように実行しているのかを説明できないのもその証拠。
0196デフォルトの名無しさん
2006/06/21(水) 18:03:55「TDDでやらないからだ。TDDでやればJUnitは有用なのだ」
一理ある。
しかしこれはいただけない。
「JUnitって便利だからTDD以外でも使ってるよ」
「それはJUnitの正しい使い方じゃない。TDD以外でJUnitを使うのはあやまり」
0197デフォルトの名無しさん
2006/06/21(水) 18:07:54例えば相互に干渉しうる優先順位つきの要求を
複数のスレッドから受け取って順に処理するスケジューラのクラスを作るのだが、
テスト、どうやって書く？
典型的なシナリオを幾つか準備するくらいしか手はないかな？
0198デフォルトの名無しさん
2006/06/21(水) 18:09:05不穏なところで人も殺せるし、無難なところでペーパナイフの代わりになるんだよ。
便利だったらそれでいいじゃん。由来は関係ない。
0199デフォルトの名無しさん
2006/06/21(水) 18:20:34具体的な内容がわからないので的外れかもしれないけど、そのスケジューラに登録するオブジェクトなり
スレッドなりをテストコード側で用意して情報を取得しassetする。Mock ObjectとかStubとか。
あるいは、「スレッド」などのテストしづらい部分を分割して、個別にテストするとか。
0200デフォルトの名無しさん
2006/06/21(水) 18:27:09「スレッドから要求を受け取ってスケジューリングする」機能を、
「スレッドから要求を受け取る」「スケジューリングする」に分割してテストするってことです。
0201デフォルトの名無しさん
2006/06/21(水) 18:53:34で、その中の何割か（正確にはしらん）がJavaで書かれてたんだけど、その単体テストはJUnit使えという指示
だったんだよね。もちろんプロジェクト全体は、がちがちのWF。
NT○-D○TＡがいつからJUnit使うようになったかしらんけどさ、JUnitって何？な世界に、JUnitで行きましょうって
提言した猛者がいるはずなんだよな。俺尊敬するよ。その人。
0202デフォルトの名無しさん
2006/06/21(水) 18:57:40面子のレベルが一番の問題ってことさ
0203デフォルトの名無しさん
2006/06/21(水) 19:02:28ちっちっちっ。
注目して欲しいところはそこじゃなくて「採用した」ってところ。今までJUnitのテストコード自身がevidenceに
なることなんてなかったからね。
0204デフォルトの名無しさん
2006/06/21(水) 19:07:49あれだけの規模の企業だから部署によってまちまちだけど、
業界・オープンソースコミュニティでは有名な
Javaエンジニアを何名も擁する部署だってある。
0205デフォルトの名無しさん
2006/06/21(水) 19:15:18日立やNECの子会社と同じような感じかと・・・
0206デフォルトの名無しさん
2006/06/21(水) 19:20:26Java関係で有名な人って他に誰か居ないの？
0207デフォルトの名無しさん
2006/06/21(水) 19:21:15書籍や雑誌やWEBでちゃんと情報収集してるか？
イベントやカンファレンスに行ってるか？
みかかデータの一部は業界の急先鋒だぞ。
0208デフォルトの名無しさん
2006/06/21(水) 20:10:010209デフォルトの名無しさん
2006/06/21(水) 20:16:24俺は各社用サーバが用意されてる環境で、bashとvim入れていいかってみかかデータに聞いたら、
フリーソフトは駄目と言われて、それいらい、そういう会社なんだと思ってる。
え、もちろん入れたよ。だって効率わるいじゃん。
0210デフォルトの名無しさん
2006/06/21(水) 20:21:190211デフォルトの名無しさん
2006/06/21(水) 20:21:35突っ込むのも馬鹿らしくなってきた。
0212デフォルトの名無しさん
2006/06/21(水) 20:28:34少なくとも俺は84みたいな用途にJUnitを使いたくないがな。
たかがtrueとfalseのためにいつもテストメソッドを
分割するなんてやってられんよ。
ツール使って自動生成するならともかく。
0213デフォルトの名無しさん
2006/06/21(水) 20:30:410214デフォルトの名無しさん
2006/06/21(水) 20:44:380215デフォルトの名無しさん
2006/06/21(水) 20:47:190216デフォルトの名無しさん
2006/06/21(水) 20:47:39>たかがtrueとfalseのためにいつもテストメソッドを
>分割する
なんて誰も言ってないが。
最後まで勘違いレスごくろうさん。
0218209
2006/06/21(水) 20:51:020219デフォルトの名無しさん
2006/06/21(水) 20:52:150220デフォルトの名無しさん
2006/06/21(水) 20:53:04まあ気にするなよ工藤さん
0221デフォルトの名無しさん
2006/06/21(水) 20:53:32これは、テストメソッドに日本語書くかどうかと近い問題だと思うよ。
test閾値は100〜200までならおｋ()
test閾値が100〜200をはみ出したら例外飛ぶわな()
みたいなテストメソッドをガンガン書いてる。
少し前の俺なら卒倒もののコードだが、
最近これでグリーンバー伸びてくのを確認する方が
外人がxUnit使うときの感覚に近いんじゃないかと思ってる。
0222デフォルトの名無しさん
2006/06/21(水) 20:54:22理解してないんじゃなかろうか。
0223デフォルトの名無しさん
2006/06/21(水) 20:56:160224デフォルトの名無しさん
2006/06/21(水) 20:57:11サーバで動くものをサーバで開発してるのに、バージョン管理したいなら手元のWindows PCでやればー？
（口調は脚色）とか言われたしｗ
0225デフォルトの名無しさん
2006/06/21(水) 20:57:27そういうところは多いかもしれないな。
0226デフォルトの名無しさん
2006/06/21(水) 20:58:36まだ粘着するか。true/falseなんか誰も問題にしてないというのに。
0227デフォルトの名無しさん
2006/06/21(水) 20:59:590228デフォルトの名無しさん
2006/06/21(水) 21:01:07HOTOHOTO呆れたYO
0229デフォルトの名無しさん
2006/06/21(水) 21:01:520230デフォルトの名無しさん
2006/06/21(水) 21:01:57ばーかｗｗｗｗ
0231デフォルトの名無しさん
2006/06/21(水) 21:02:05JUnitやcvsが標準でついててよかったよｗ
0232デフォルトの名無しさん
2006/06/21(水) 21:13:35ゲイツと寝てろ。
0233デフォルトの名無しさん
2006/06/21(水) 21:25:500234デフォルトの名無しさん
2006/06/21(水) 21:59:54うわ、ホントだ。こんなんじゃsetUp()、tearDown()は使えないな。
0235デフォルトの名無しさん
2006/06/21(水) 22:01:33JUnitやCVSを却下した部署と
某Oかもと氏がいる部署とは違うんでしょ。きっと。
0236デフォルトの名無しさん
2006/06/23(金) 01:10:39NTTや役所系から仕事とってきてNECや富士通や日立、IBMに投げるだけ。
0237デフォルトの名無しさん
2006/06/23(金) 01:16:30これだけの大企業、いろんな形態の仕事がある。
「NTTデータって」と一括りにするのは間違いのもと。
＞NECや富士通や日立、IBMに投げるだけ。
分野によっては（というか、そのほうが多いと推測するが）、
NEC、富士通、日立、IBMはむしろライバル企業。
0238デフォルトの名無しさん
2006/06/23(金) 01:48:59官庁のネットワークのインフラかなんかの話だったけど。
0239デフォルトの名無しさん
2006/06/23(金) 15:37:50受け取った要求が正しい順番でキューに入ってるかどうかと
順番通りにいれたキューの処理が正しく行われてるかを調べるってこと？
0240デフォルトの名無しさん
2006/06/26(月) 23:51:24観点がずれちゃわないかそれでは
複数スレッドの取り合いでスレッド相互の行き過ぎのバリエーションを見たいんだろ
>>197の試験は必須だよ
キー入力待ち埋め込んで状態作ったことあったかな
0241デフォルトの名無しさん
2006/06/26(月) 23:56:39逆かｗ読み飛ばしてｗ
ごめん
0242デフォルトの名無しさん
2006/06/27(火) 00:13:32CppUnitでは苦労したが・・・
0243デフォルトの名無しさん
2006/06/27(火) 14:37:36Test()アノテーションで捕捉してる例外や
自分でcatchしてる以外の例外はエラーとして中断するよ。
0244デフォルトの名無しさん
2006/07/07(金) 14:44:14自分はJavaだからJUnit重宝してるもんで、
C#で書くことになったバイトにもテケトーに薦めてしまったが。
0245デフォルトの名無しさん
2006/07/07(金) 20:41:510246244
2006/07/11(火) 13:54:160247デフォルトの名無しさん
2006/07/11(火) 15:28:11ttp://www.xprogramming.com/
からだな。
0248デフォルトの名無しさん
2006/07/11(火) 17:34:27それはそれで結構だが、諸般の事情でXPを徹底できないときでも
Unitテストのフレームワークは有効だと思うが。
0250デフォルトの名無しさん
2006/07/12(水) 13:47:48http://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か。
0251デフォルトの名無しさん
2006/08/04(金) 15:24:480252デフォルトの名無しさん
2006/08/23(水) 00:03:550253デフォルトの名無しさん
2006/09/12(火) 02:54:180254デフォルトの名無しさん
2006/10/11(水) 14:34:210255デフォルトの名無しさん
2006/10/11(水) 20:44:57移行措置でアダプタとsuitメソッド使ってるけど
個別テストの実行ができなくて面倒。
0256デフォルトの名無しさん
2006/10/12(木) 04:05:19テストランナー自身がException捕まえず
丸投げで外に投げてテストランナーごと死ぬって仕様は如何なものか？
またそのテストランナーを内部からツールメニューで立ち上げてると
問答無用で一緒に死ぬVisualStudio2005のガラスのような頑健性も如何なものか？
最初テスト走らせるたびに落ちて何事かと思ったぞ…。
外部で立ち上げて走らせなおしてようやく原因が分かったよ。
0257デフォルトの名無しさん
2006/10/12(木) 04:12:190258デフォルトの名無しさん
2006/10/12(木) 04:57:16どこら辺から読み始めるとお得？
0259デフォルトの名無しさん
2006/10/12(木) 05:14:190260デフォルトの名無しさん
2006/10/12(木) 05:17:48ケチｗ途中でウザくなったけどCSUnitとか気になる
まだ自宅でしか使わないけど(´･ω･`)
0261256
2006/10/12(木) 08:13:07Assertionの失敗の例外を時々見逃してしまうらしい。バグか…。
0262デフォルトの名無しさん
2006/10/13(金) 21:28:44学生とみかかについてかよｗ何のｽﾚだよｗｗｗ
0263デフォルトの名無しさん
2006/10/13(金) 23:26:07＜完＞
ご愛読ありがとうございました。
次レスからはunitテストについての新スレが始まります。ご期待ください。
0264デフォルトの名無しさん
2006/10/14(土) 01:52:09つぶれるぐらいの例外…
…そう、 Throwableをはるかに跳躍した例外をthrowしたい。
finallyをさせる暇さえ与えさせない
0265デフォルトの名無しさん
2006/10/14(土) 12:32:24例外っつーか想定外っつーか。
0266デフォルトの名無しさん
2006/10/14(土) 22:20:20電気渡さなければいいんじゃないか？
ここまで書けば何をすればいいかわかるよな？ｗ
0267デフォルトの名無しさん
2006/10/15(日) 08:37:01まあそれと大手町爆破すればOKっぽい
0268デフォルトの名無しさん
2006/10/16(月) 13:02:310269デフォルトの名無しさん
2006/10/17(火) 15:54:190270デフォルトの名無しさん
2006/11/13(月) 12:48:50自分は正解を手で書いといてそいつと出力結果を1行づつ読み込んで比較する
assertion用メソッドを書いている。
ただ問題があって仕様が変わるたびにXMLファイルを書き直すのが面倒で、
つい比較用に出力したXMLファイルを目で眺めて参照用ファイルとしてリネームして流用しちまうこと…。
この場合、目で見るときに間違いを見落とすことがあり、それでもテストは通るからチェックにかからない。
0271デフォルトの名無しさん
2006/11/13(月) 23:21:25正直言ってる意味がよくわからない
0272デフォルトの名無しさん
2006/11/13(月) 23:50:45XPathとかで、必要とされる要素が必要とされる階層にあると確認できれば
それで良しとしてくれなきゃ、きりがない。
0273デフォルトの名無しさん
2006/11/14(火) 12:41:43読み込み側のプログラムではXMLパーサとか使ってるけど
対象プログラムは出力専用で、テストでしか読まないからなぁ。
0274デフォルトの名無しさん
2006/11/14(火) 21:56:22jaxbでいいんじゃね？
型チェックも出来るし、Objectからデータとってチェックすればいいし。
まぁテストだけのために使うか？ｗｗｗって話だが・・・
0275272
2006/11/15(水) 00:27:12俺が言ってるのは、以下のような感じで構造を確認すれば？って事なんだが。
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,ドキュメント,期待値);
っていうメソッド作れば、楽にならんか？
見当違いの事言ってたらすまんね。
0276デフォルトの名無しさん
2006/11/15(水) 08:08:26そういうのならXMLUnitってのがあるよ。
0277デフォルトの名無しさん
2006/11/15(水) 16:36:59↓これすか？
配布元
http://xmlunit.sourceforge.net/
日本語解説
http://634.ayumu-baby.com/xmlunit/index.html
0278デフォルトの名無しさん
2006/11/15(水) 16:42:09配布元サイトで対応するJUnitの版に関して書いてある部分を見つけられないが…。
0279デフォルトの名無しさん
2006/11/15(水) 21:31:33きっとJUnit4には未対応だろうね。でも、javadoc見ると
org.junit.Assertに対応するorg.custommonkey.xmlunit.XMLAssertというクラスがあるので、
これをimport staticすれば、JUnit4のテストケースでも使えるんじゃないかと思う。
0280デフォルトの名無しさん
2006/11/16(木) 11:08:22次は使ってみるか…。
0281デフォルトの名無しさん
2006/11/16(木) 23:00:00「単純クラスで試してみればいい」に１００ペカリ
0282sage
2006/11/17(金) 16:10:57これどうやって使うんでしょう？アドイン形式なので他のやつよりよさげなんだけど・・・。
0283デフォルトの名無しさん
2006/11/20(月) 00:26:35http://sourceforge.net/project/showfiles.php?group_id=15278
0284デフォルトの名無しさん
2006/11/20(月) 00:43:57マルチウザい。
具体的にどういうところが変わったのよ？
人柱レポートよろ。
0285デフォルトの名無しさん
2007/01/05(金) 15:55:40話が進まないので、もう言いだしっぺのキミが人柱でヨロ。
0286デフォルトの名無しさん
2007/02/15(木) 20:13:20http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/junit/string-converter.html
作者の石井勝さんは、JR福知山線脱線事故でお亡くなりになられたそうです。ご冥福をお祈りします。
0287デフォルトの名無しさん
2007/02/15(木) 20:24:46Quick Junitはsf.jpにプロジェクトがあるけど。
0288286
2007/02/16(金) 10:11:58うーん、残念です。非常に便利なモノなのですがね……。
0289デフォルトの名無しさん
2007/02/16(金) 11:58:01JUnit Converterと比べるとイマイチ。
0290デフォルトの名無しさん
2007/02/17(土) 21:42:33自分で似たようなの作った後にCommons LangのReflectionToStringBuilder見つけてへこんでたのに、
さらに便利なのがあったとは。
0291デフォルトの名無しさん
2007/03/06(火) 00:25:310292デフォルトの名無しさん
2007/03/27(火) 01:35:21AntのJunitタスクで似たような機能が合ったんですが．
単体テストツールからテスト仕様書・結果報告書を自動生成したいんですよねー．
0293デフォルトの名無しさん
2007/03/27(火) 02:59:30http://www.atmarkit.co.jp/farc/rensai/open04/open04c.html
0294デフォルトの名無しさん
2007/04/01(日) 09:22:440295デフォルトの名無しさん
2007/06/21(木) 11:07:29テストクラスごとに1回だけ実行するというのは@BeforeClassでできますが、テスト全部の前に1回だけ実行というのはできますか？
Log4jの初期化をしたいだけなんですが、そのためにTestSuiteを作ってって言うのはめんどくさい・・・。
JUnitのFAQみたら@BeforeClassでテストクラスに1回だけ初期化するってだけでも「テストのデザインがよろしくない」って注意してるし。
@BeforeAllTestみたいなの追加してくれないかな。
0296デフォルトの名無しさん
2007/06/22(金) 05:18:351回作ってしまえばあとは楽なんだから
0297デフォルトの名無しさん
2007/06/22(金) 08:25:14クラスのstaticイニシャライザで代用するとか
0298295
2007/06/22(金) 13:15:57「全部のテストをしたい」「このクラスだけテストをしたい」と言う要求に対しても常に「1回だけ実行」と言うのをしたいので 297 の方法じゃダメなんですよね。
テストランナに対して初期化時の処理とかを設定できれば良いんだけど。
しばらくは全部のテストを実行するようにして、その中のクラスのstaticイニシャライザで初期化するようにします。
ありがとうございました！
0299デフォルトの名無しさん
2007/08/10(金) 19:26:430300デフォルトの名無しさん
2007/08/10(金) 20:11:340301デフォルトの名無しさん
2007/08/10(金) 20:53:110302デフォルトの名無しさん
2007/09/09(日) 20:58:310303デフォルトの名無しさん
2007/09/09(日) 21:55:34秀丸マクロでいいからテストコードを自動生成汁
0304デフォルトの名無しさん
2007/09/09(日) 22:34:54テストのためのテストほど醜いものはないな
0305デフォルトの名無しさん
2007/09/09(日) 22:50:22カバレッジツールが流行りだしたらば、無駄なテストコードが増えた
そしていつの間にかテストの目的がカバレッジになる、アホらしい
0306デフォルトの名無しさん
2007/09/09(日) 23:11:28結局トータルでは損になるだろ
ほとんどのバグは実際動かしてみてみないと分からんのだし
0307デフォルトの名無しさん
2007/09/09(日) 23:45:51ってことは、テストケースで引っかかるバグってほとんど出ないってこと？
そんなこと無いと思うけどなあ
0308デフォルトの名無しさん
2007/09/10(月) 00:15:38逆に考えるんだ。
奴等はカバレッジさえみたせば満足する、と。
0309デフォルトの名無しさん
2007/09/10(月) 00:17:05そんなのテストコード書かなくてもちょっと実行すればとれる
テストコード書く時間と比べたら結局損じゃない
0310デフォルトの名無しさん
2007/09/10(月) 00:21:51その「ちょっと実行すれば」の部分を自動化して
容易に見つかるバグを洗い出すのも重要な目的だと思うんだが
0311デフォルトの名無しさん
2007/09/10(月) 00:32:39想像力が働くなら、普通そんなバグは作らないでしょ
バグっても原因が分かるからすぐ取れるし
テストコードを書く本人が分かってないからバグるんだと思うけどなあ
0312デフォルトの名無しさん
2007/09/10(月) 00:40:56どんな優秀な人間でも、普通はケアレスミスってのがあるんだけど……
ってか、>>311の言うとおりならバグの無いソフト書けるんじゃね？
0313デフォルトの名無しさん
2007/09/10(月) 00:54:52ああ、その通りなんだわ。
で、作成されたコードがどうなったか教えてやろう。
throws Exception が全てのメソッドに装備された
確かに例外処理が記述しなくていいからカバレッジが見る見るあがった。
そして、納品したんだが、後のことは知らん。
0314デフォルトの名無しさん
2007/09/10(月) 00:55:04それが事前に想定できてテストにかけるんなら
バグの無いソフトがもともと書けるんじゃねえかという
0315デフォルトの名無しさん
2007/09/10(月) 01:22:06ワタシ ニホンゴ ムツカシイヨ
0316デフォルトの名無しさん
2007/09/10(月) 01:38:49テスト書いた経験少ない人が 自分の書いたコードをテストするとそう考えやすい。
自分の書いたコードをテストするなって格言もあるけど。
0317デフォルトの名無しさん
2007/09/22(土) 12:17:40みんなどうやってるの？
0318デフォルトの名無しさん
2007/09/22(土) 13:23:28単体テストでは基本的に発見できないのでメソッドテストのみとする
形だけでもっていうならば負荷を高くして試す
最終的にマルチスレッドの品質は設計とコードレビューで保つしかないと偉い人も言っている。
0319デフォルトの名無しさん
2007/09/22(土) 16:22:55俺も>>318と一緒、結合・負荷テストで品質確保してる
0320デフォルトの名無しさん
2007/09/23(日) 23:44:33結局そうするしかないんですね。残念。
0321デフォルトの名無しさん
2007/09/24(月) 01:06:14いや、残念も何もマルチスレッドのバグがどういう状況で発生するか考えれば単体テストでテストすることがいかに困難か解るだろ
0322デフォルトの名無しさん
2007/09/24(月) 17:30:06いや、そうなんだけどさ。
マルチスレッドテストパターンみたいのを研究している人とかないかなーと。
0323デフォルトの名無しさん
2007/09/24(月) 20:39:11GUIと同じようにプログラムによってテストが共通になりにくいから無理だろ
Swingですらテストフレームワークはかなり使いにくい
0324デフォルトの名無しさん
2007/09/25(火) 00:26:01マルチスレッドプログラムのテスト容易化設計という意味でならば、
なにか研究されているんじゃないかな。自分も個人的なノウハウ
みたいなものは持っているけど。
そういったテストのことを考慮せずに設計されたプログラムをどう
テストするかという話ならばご愁傷様。それは構造化されていない
スパゲティプログラムをどうテストするかという話に等しい。
■ このスレッドは過去ログ倉庫に格納されています