ＸＰのxUnitは使えてる？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGユニットテストできないクラスの方が多くないですか？
数学ライブラリとか単純なストリングクラスレベルのものであれば
可能ですが、そうでないものは難しいのではないかと思うのですが
実際に触れられているか、または、触ったことがある方教えてちょ。
002291
01/08/30 10:02ID:AuuQmmaUという決まりはないと思う。has_a のクラスがあればそれを所有している状態が
そのオブジェクトのあるべき姿なのでそのままでテストするべき。
setUp() でオブジェクトを生成する時に必要な周辺のオブジェクトも一緒に作る。
委譲が単純なメッセージの転送で結果が自明だと思うならテストを省いてもいいかも
しれないけど、リファクタリングの結果メソッドの移動で委譲の形になったのなら、
その変更の影響確認の意味があるのでテストを削ることはない。
あと、setXXX(), getXXX() などの自明なメソッドや、GUIなどのテストが難しいも
のを無理してテストに含める必要もない。
「リファクタリング」の本にも、100%のカバレッジにこだわって結局テストしなく
なってしまうよりも、できるところからどんどんテストを書いていった方がいいと
書いてあった。
00233
01/08/30 13:13ID:SlMm8NNoそういったクラスの単体テストに関しては、XP導入篇にやり方が書いてあるので、
立ち読みでもいいので読んでみるといいと思います。
基本的にはそのクラスが依存している下層クラスのダミーを作ってテストする、
ということになると思います。
0024IDEなんてクソ
01/08/30 21:48ID:ZAelFQ6sとにかくコーディングしまくって、家に帰るときに全部xUnitで自動実行。
翌朝、デグレードしていないことを確認して、別の観点でテストを書きまくる。
クソみたいなテストでも、何回も書き直すと自分のスキルになる。
単体とか結合とかは、人件費よりCPU時間の方が貴重な頃のクソ概念。
屁理屈こねてるぐらいならコーディングしろ。
それがイヤならプログラマやめな。
002517
01/08/31 00:05ID:sK1P25wQ単体テストはホワイトボックステストなので、GooのテストがFooの実装を意識したものに
なっていてもかまわないのではないかと思います。いかが？
>>24
漢らしい！ある意味extremeですな。それでうまく進められるのなら、全くOKだと思います。
オレはそれほど漢気(ｵﾄｺｷﾞ)がないので、テストの効果は低下させずにテストの規模を
少なくできる方法を考えたいと思います。
24氏の方法だと、特定のクラス階層を取り出して再利用するときに、テストコードの
切り分けに手間がかかりませんか？テストを単体,結合に分けておくとそのような時には
便利ではないかと思います。
このあたりの考察,議論が屁理屈ではなくて、仕事の質を高める理屈につながることを
願います。
002616
01/08/31 00:31ID:r3.yQrDE1. 基本は、クラス単位でテストをする。
2. has-aクラスを持っているのであればそれらは生成してもよい。
3. 利用関係のクラスはダミークラスを用意する。
という方針で進めればよいという風に理解しましたがあっていますか？
あっていた場合、私自身悩んでいたのは、3.についてです。本当にダミー
クラスを用意することができるのか？ 単純なシステムであれば、
可能に思えますが、複雑なものであればダミークラスを用意し、それら
の用意したクラスがうまく連携するかどうかの補償する必要が発生し、
ダミークラスのユニットテストが必要になり、それをするのにさらに
ダミークラスが必要になる...。つまり、ダミークラスが必要がなくなるまで
それを繰り返すか、どこかで妥協する必要があるんじゃないだろうかという
こと。それにより、複雑なシステムではユニットテストは難しくなって
くるのではないかという疑問へとつながります。ここら辺は、みなさん
問題なくできていますか？ Webアプリ程度のものであれば可能に思え
ますが、マルチスレッドなシステムとか大規模なシステムは、
GUIに近づくほど難しいと感じます。
0027デフォルトの名無しさん
01/08/31 00:31ID:4nm4VJrc0028デフォルトの名無しさん
01/08/31 00:59ID:6bUtDlqkFoo(interface), FooImpl, MockFoo, FooImplTest
をつくるけど 駄目？
ちょっと面倒だけど、ほかのクラスの実装にほとんどたよらずに
テストできるのでいいかんじ。
002916
01/08/31 02:42ID:r3.yQrDE購入してみようかと思ったのですが、あまり評価がよくないようなのですが、
実際のところみなさんどう思いましたか？
http://www.amazon.co.jp/exec/obidos/ASIN/4894714914/ref=b_br_r_4_3/249-6364008-4713114
0030デフォルトの名無しさん
01/08/31 11:33ID:FX.uO0Uc評判が悪いのは、『実行計画』の方です。
内容そのものが悪いというわけではなく、訳がヒドイという理由で評判が悪いです。
『導入編』の方はそのようなことはありませんでした（精読したわけではないですけど）
00313
01/08/31 11:50ID:l23fvLAEいや、一番ひどいのは「入門」です。これは、
http://objectclub.esm.co.jp/eXtremeProgramming/ec-errata.txt
と併用しないと理解できません。
もっとも「実行計画」も基本的に同じ人間が翻訳しているので出来はよくない
ですが。「導入編」はわかりやすいし、おまけもついているのでお勧めです。
003230
01/08/31 12:50ID:FX.uO0Ucあ、そうでしたね。
あまりに酷かったので、俺の記憶から消去してました（藁
00338
01/08/31 12:52ID:pdlIkxbsあえてsageずに激しく同意。
大学受験レベルの訳が出来てないのには閉口する。
導入編があれば入門も実行計画もいらんのではないかと思うよ。
0034デフォルトの名無しさん
01/08/31 14:58ID:SVE3wbvcHttpRequestを使ってるクラスが多くて、
そういうクラスをどうやってXUNITでテストできるのでしょうか？
DB系のクラスも難しい
結局ブラウザで地道にやってます
0035sage
01/08/31 16:33ID:BPhzZYhEhttp://wiki.esm.co.jp:8080/xp/29
じゃだめ？
>34
0036デフォルトの名無しさん
01/08/31 16:41ID:SYzSjnws簡易サーバ作れば？
んでsetUp() でlocalhostとかで起動しとく
0037デフォルトの名無しさん
01/08/31 16:58ID:FX.uO0Uc>DB系のクラスも難しい
これはテストしやすいと思うけどなぁ。
テストしづらいとしたら、それは、メソッドが複雑である、ということでは？
どういう所が難しいの？
0038IDEなんてクソ
01/09/01 00:59ID:t2cxml/2コアサーブレット＆ＪＳＰかなんかのサンプルに
ＵＲＬ指定してＰＯＳＴするＡｐｐｌｅｔのコード
が出てたのでそいつを改造してJUnitしたことはあ
るけど、そういうことではないのかな？
あんまり真剣にやったわけじゃないから、細かいこ
とはわからんが、中途半端なフレームワーク使うよ
り、人のコード改造した方が生産性はあがるぞ。
0039IDEなんてクソ
01/09/01 01:03ID:t2cxml/2ちなみにサンプルのコードは以下のＵＲＬから落とせるよ。
http://books.softbank.co.jp/isbn/1431/
SendPost.javaとかいうファイル名だったとおもう。
0040デフォルトの名無しさん
01/09/01 03:56ID:lnjRwD/QRequestの使用するメソッドだけを備えたラッパーを
つくれば幸せになるかも
>>37
DB関連はUnit単位ならどうということはないけど、
実際のDBを使用するテスト(Acceptance?)となると
データを用意する -> テストする -> 後始末
となりやっぱり面倒かと
004110
01/09/01 14:39ID:EO8HRrv6なるほど、やはり仮想クラスのダミーを作って
テストするということですね。
とりあえず、導入編を買って読んでみます。
0042デフォルトの名無しさん
01/09/01 21:07ID:ln0xQxLk>データを用意する -> テストする -> 後始末
>となりやっぱり面倒かと
というか、それってxUnitの全否定に繋がるような気が・・・。
0043「人のバグ見て、わがバグなおせ」
01/09/01 22:18ID:FG67tGr.君には向いていない職業だね。
早く出世するか、転職するか選んだ方がいいよ。
プログラマが「コーディングがイヤ」とか「コーディングに自信がない」
って言ったらおしまい。
「血を見るのがイヤ」とか「盲腸切るの自信が無い」なんて言う外科医に
命預けられる？
あんたの顧客も同じ気持ちだよ。
0044デフォルトの名無しさん
01/09/01 23:47ID:npROBw1Mやっぱり、そこで苦しくなってくるのがDB絡みだな。
パフォーマンスや時間やライセンスの都合で、
DB空間を必要な数だけ構築できない場合には、
複数の開発者(＆デバッグ者)が同一のDB空間に相乗りすることになり、
うまく(素早くってのも含めて。delete * from HOGEHOGEとかをやれるかどうか)
必要なデータを用意＆抹消するのが困難になったりする。
言いかえれば、空間を好きなだけ作ることが
パフォーマンスや、ましてライセンスに、縛られるという
DBMSの構造が駄目駄目だ、ということなんだけども。
というわけで、大抵の商用DBMSベンダーは、いってよし。
そうそう。
http://www.zdnet.co.jp/enterprise/0108/30/01083006.html
今時WaterFall開発を薦めるという勇気有るドキュ記事。
言ってること、これ、変だろ。
(乱暴にいえば)渡して「から」デバッグするのがSpiralだろうに、
バグは許されないからWaterFallしろってのは、勘違い。
00458
01/09/02 00:04ID:VPRUB6jg優良スレに育ちつつあるんだから煽りモード控えめで行きましょう。
00468
01/09/02 00:08ID:VPRUB6jgDBに対するxUnitの適用方法ですが、導入編に示唆的な一節があります。
“テストをできる限り高速で走らせるためには、安全性を考えあわせた上で、
なるべく実際のデータベースにはアクセスしないことが基本的なルールだ。”
（導入編131ページより）
004740
01/09/02 02:56ID:BNPFq0lAプログラムは好きですよ、ほんと。
>>46
それは、ＤＢ周りのクラスを使うがわの話であり
ＤＢ周りのクラスそのもののテストにはＤＢやらＳＱＬやらが
関係してくると思います、多分。
現実のリソースに触るようなテストはできれば別系統にしておいて
実行速度をあげるという意味だったかと。僕もそうしてます。
004840
01/09/02 03:20ID:BNPFq0lAxUnitマンセー！否定だなんて！
ただSQLがらみだと何度もテスト実行可能なように
setUpやらtearDownやらに手間がかかって
やだなあ、とか思いません？
僕がSQL嫌いなだけかもしらないけど。
っていうかなんか楽な方法ないですか？
0049デフォルトの名無しさん
01/09/02 03:39ID:yCMII86.初期化・終了処理周りのルーチンワークが面倒なら
xUnit拡張してSQL Unitかそこまで行かなくても
SQLTestCaseでも作ってやればいいんじゃない？
本質的に複雑で面倒でライブラリ化不可能ならあきらめるしかないかもね...
005040
01/09/02 04:08ID:BNPFq0lAならやってますが、個々のテストで必要なデータが
結構ちがうためデータのそれはどうにも…。
外部にバッチをおいてテスト前に必要なＳＱＬを
実行するようにしたこともあったけど、あんまり
気持ちよくない。xUnitだけで完結しないし。
0051デフォルトの名無しさん
01/09/02 10:02ID:BlWYAHM.生DBにアクセスしないかどうかをユーザーの自由意志で決められる場合は、そうでしょうね。
OODBとかJDO(藁)みたいに、なかば暗黙化されてる場合に、ちょっと困るなぁと。
DBを切り離すわけにもいかないし、パフォーマンスやライセンスで足引っ張られるのは厳然たる事実だし。
某環境でObject1つを生成するのに1秒かかった時は本当に鬱になった。
00528
01/09/03 01:49ID:1RRG7AyI>それは、ＤＢ周りのクラスを使うがわの話であり
「DB周りのクラス」がどこまでを指すかが気になるなぁ。
この辺の認識って十人十色ですよね。
皆さんは大体どのあたりをイメージされてますか？
0053デフォルトの名無しさん
01/09/03 14:22ID:fElqx/V6>ただSQLがらみだと何度もテスト実行可能なように
>setUpやらtearDownやらに手間がかかって
>やだなあ、とか思いません？
いや、だから、何を「やだなあ」と思っているのか、読み取れないんですが・・・。
>>50
>ならやってますが、個々のテストで必要なデータが
>結構ちがうためデータのそれはどうにも…。
問題はこれだけですか？
結局「面度くさい」ということですか？
だったらしかたないですねぇ。
0054＿＿
01/09/03 23:53ID:eYogrFz2でも、テストデータを作るのも楽しくない？
テストデータを生成するロジックを考えるのも楽しいよ。
制約があるから、知恵を絞る楽しさがあるんだじゃないかな？
制約なくなったら、俺は仕事しない。納期もないだろうしね。
005540
01/09/04 02:58ID:u0uEF7woちょっと長いけどこんな感じ？(with JUnit)
public FooCreatorTest extends TestCase {
public static Test suite() {
return new TestDBSuite(FooCreatorTest.class) {
protected void doSetUpDB(Connection conn)
throws SQLException
{
conn.executeQuery("create table foo ....");
conn.executeQuery("create table baa ...");
conn.executeQuery("insert into foo...");
// だらだらと続く
}
protected void doTearDonw(Connection conn)
throws SQLException
{
conn.executeQuery("drop table foo");
conn.executeQuery("drop table baa");
}
}
//以下テストが続く
}
このやり方だと長ったらしくＳＱＬが続く上に
テストのためのＳＱＬ自体が間違いを含んでいたり,
エスケープが面倒だったりと結構いやなものです。
ＳＱＬを直に使うためＤＢに依存も起きます。
テストに要する時間が通常の三倍くらいってとこかな。
怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？
で、なんかいい方法ないっすか？
005640
01/09/04 03:06ID:u0uEF7woあとexecuteQuery --> execute ですね…
>>54
それはちょっとむごいかと
つうか僕が新人ですよ！
一番きつい制約が時間なので、できるだけ安いコストで
テストしたいです。
0057通りすがりのプログラマ
01/09/04 07:26ID:172vGpu.やはり読みづらいですか。
デザインパターンとか、XPはいい方向だと思うのですが、
どうにも良書が少なくて、取り入れづらくて。
最先端で天狗になっちゃって誰も何も言えないのかな。
0058通りすがりのプログラマ
01/09/04 08:36ID:172vGpu.この手の訳書が出ないことを嘆いてますが、間違いなく足ひっぱってるとおもわれ。
分からなかったら俺のセミナーを聞け！なのかな。
導入編訳者が違うので買ってみま。
005953
01/09/04 14:27ID:xkDT0p0oこれは仕方がないですね。
>テストのためのＳＱＬ自体が間違いを含んでいたり,
これは間違わないようにするしかないです。
>エスケープが面倒だったりと結構いやなものです。
何をエスケープするんでしょう？
>ＳＱＬを直に使うためＤＢに依存も起きます。
それも仕方がないですね。
>怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？
怠慢おおいに結構。
>で、なんかいい方法ないっすか？
create table - drop tableは本当に必要なんですか？それも毎回？
Singleton patternとRollbackをうまく使えば、テストに要する時間は短縮できます。
テストデータ生成も、Insert文を直接書くのではなく、CSVをInsert文に変換する
クラスなどを作って、間違いをなくすようにする。
こんなとこかな。
0060デフォルトの名無しさん
01/09/04 22:39ID:2dtERGnw新人ならやめちゃえよ。今からならやり直せるよ。
大体、そんなに自動化しちゃったら、お前ができる仕事なくなるよ。
楽する方法を考えるのが、今の仕事なんじゃないの？
ＸＰ以前に、仕事に対する姿勢が問題じゃん。
006140
01/09/05 02:05ID:nluvb.ck何度よんでも一回だけ処理をしてくれるSetUp用の
クラスは、データが重複する場合は作ります。
create - drop は趣味の問題かもしれません。
ごみは残さないって感じで。
データの量が多い場合は外に出しますが
少ない場合はテストに内臓のほうがよいような気がします。
エスケープは正規表現かなにかと勘違いしたかも、すみません…
0062デフォルトの名無しさん
01/09/05 13:16ID:42ScEOYYじゃぁ、結局何が問題なの？
つまるところ「面倒くさい」ってとこに帰着するのかな？
それって、xUnitを全否定することでは・・・(loop)
0063デフォルトの名無しさん
NGNGこんな奴が「xUnitは役立たない」って知ったかぶって言いふらすんだろうな。
役立たないのは、、、
ま、それ以上は言わないよ。大人だから。
00648
NGNG大人なら初めから黙ってるよろし。
いたづらに煽るばかりのﾚｽはｳｻﾞい事この上なし。
というわけで話題提供を試みてみる。
実DBにアクセスしないとできないテストが多岐にわたるようであれば、それこ
そリファクタリングの対象とすべきでは？
「DBにアクセスするな」というのは、テストの手間を惜しむという面もあるが
、DBへの依存度が低い設計を強制するという面も忘れてはならないと思う。
0065デフォルトの名無しさん
NGNGそれからUnitTest自体のリファクタリングも必要だよね。
0066デフォルトの名無しさん
NGNGタイトルだって、xUnitの効果に疑問があるわけでしょ？
で、よくよく聞いてみると、「めんどくさいことしたくない」でしょ？
何処が優良スレなんだよ。別のスレたてて議論しよ。
00678
NGNG別スレでも「めんどくさいことしたくない」派が書き込むのは不可避。
なぜなら彼らのほうが多数派だから。
改革派だけでオナニー議論したところでこの業界は変わらない。
66さんの同僚にも「めんどくさいことしたくない」派がたくさん居るはず。
このスレで説得する方法を磨いてみては？
P.S.懐疑派を煽るのはXPの価値を貶めるだけなので止めましょう。
00688
NGNG「XPエクストリーム・プログラミング導入編」は良書なので否定派も肯定派も
ご一読を。（税抜2400yenナリ）
0069デフォルトの名無しさん
NGNG0070デフォルトの名無しさん
NGNGというかこれって、いわゆるOOPと(R)DBのインピーダンスミスマッチの話だよね。
あっちの世界とこっちの世界を行き来するためのコードがナニかと煩雑になるというあれ。
JDOだっけ？あれにでも期待するといいんじゃないかな。最終的には。
一方、今すぐ最終段階になれるわけでもないんで、DBアクセスをライブラリ化しとく
ってのは必要になるだろうね。毎度毎度JDBCコードを素で書いていたらやってられん。
「ライブラリ化する」というリファクタリング(?)は、必要だと思われ。
>>68
導入編ですか。買ってみます。たしか薄い本ですよね。持ち運べるのが嬉しい。
0072デフォルトの名無しさん
NGNGどうせリストラするんだから、きっかけをあげればいい。
仕事しない奴10人より、やる気のある新人の方が役立つよ。
何もみんな一緒にＸＰする必要なし。少数精鋭でいきましょう。
結果を残せば経営陣は何もいえないよ。
■ このスレッドは過去ログ倉庫に格納されています