ＸＰのxUnitは使えてる？

ねぇ、XPはともかくxUnitはツールとして使えてますか？
ユニットテストできないクラスの方が多くないですか？
数学ライブラリとか単純なストリングクラスレベルのものであれば
可能ですが、そうでないものは難しいのではないかと思うのですが
実際に触れられているか、または、触ったことがある方教えてちょ。

hage

テストファーストは、単にコーディングする前にテストする、という
だけでなくテストがコードに優先する、ということだと解釈して
います。

従って、テストできないコードはテストできるように書き換えなければ
いけない、というのがXP的な姿勢ではないですかね。まあ確かに既存の
コードを書き換えるときには大変ですが。

実装の都合よりインターフェイスを重視してクラスを設計すること。
テストしにくい部分を別クラスに追い出していくこと。
そういうクラスの責務をはっきりさせる習慣がつくのがいい感じ。

あとコーディング、変更に伴うケアレスミスが激減すること。
これは大きい。

なんとなく設計,実装しているとユニットテストできないクラスは多く
なってしまいます。

テストが難しい理由はなぜかを考え、テストしやすくするにはどうすれば
良いのかを考えましょう。それが良い設計への第一歩です。

既出
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=989482113&ls=100

すべてのクラスを単体テストするのは無理. 大きなシステムになるほど
できない. そんなものです.

>>7
意味が良くわからないんだけど、単体テストしてないって事じゃないよね？

>>7の主張って、
前半はともかく後半は謎だな。
どんな大きなシステムだろうと、しかるべき(大きさ)のクラスが
集まって作られているなら、それらのクラス「は」単体テストできるだろうに…。

大きさゆえにドキュな設計者がよってたかってドキュ設計をしてしまった、
というならば手のつけようが無いだろうけども。

>>7-9
ここは実は結構気になっている点です。
基本的には（よい設計であれば）、
すべてのクラスの単体テストは本当に行える、
そして行わなければならない、ということですか？

>>10
単体テストとか結合テストって用語自体が構造化言語までしか想定してないから
議論が噛み合わなくなることが多いけど、基本的にテストできない設計は駄目な
設計と考えるべきだと思う。
複雑すぎるクラスはテスト可能な粒度まで分割して、Compositパターンで再構築
するとかしてね。

あと、個人的にはGUIテストは単体テストじゃなくて機能テストだと思うので、
xUnitで苦労してテスト書くよりXPチームに参加してるユーザがやる方が良いと
思う。

>>332
ほんとどうやるんだろう？
俺も今これを実装したいと思ってるところ。

ある程度は「単体テストにかける場合ならではの設計」ってのは
有るけども、それが「それ以外の面に対して害になる」ってことは
あんまり無く、むしろ益になることが多いんで、
それはそれでいいと思われ。

ついでにリファクタを一種のフレームワークとして捉えるといいんじゃないかな。
つまりテストしやすく改良しやすいコードを書くという枠組み。
もちろん、枠だからといって、他のプログラミング的側面を阻害されたりはしないし。

>>12
ん？すれ違いっすか？なんか気になった。

この下のプログラムで実行できないんですが、何処が悪いのかわかりません。
教えてください。
コマンド１と２は「作成中」とメッセージを出し、コマンド３は
終了するか否か？ってやつです。


Option Explicit

Sub Wait()

MsgBox "作成中"

End Sub

Private Sub Command1_Click()

Call Wait

End Sub

Private Sub Command2_Click()

Call Wait

End Sub

Private Sub Command3_Click()

Dim Answer As String

Answer = MsgBox("終了しますか?", vbYesNo, "Msgbox")

If Answer = ybYes Then
End
End If

End Sub

Private Sub Form_Load()

Label1.Caption = "管理人"
Command1.Caption = "初期設定"
Command2.Caption = "開始"
Command3.Caption = "終了"
Form1.Cartion = "組込み関数"

End Sub

>>14
XPもxUnitも知らねーなら素直に「教えてください」って言えよ。

XPのxUnitってクラス単位のテストで単体テストをするときの単位はクラス
のように理解しているのですがあっていますか？

あっている場合、単体テストってどういう風に考えればよいんですか？

例えば、３層でシステムを構築した場合、プレゼンテーション層は、
アプリケーション層やデータ層に依存することになりますが、
プレゼンテーション層用のクラスの単体テストをしようとすると
下層のクラスが必要になりますよね。この場合総合テストになってしまう
ように思うのですが、どういう風にやればいいんでしょう？
同じように、あるクラスがいくつかのクラスのオブジェクトを利用して
いる場合の単体テストも単体ではないですよね？

こういう悩みがあるので、 >>7 で言われていること納得できてしまうの
ですが、認識に間違いがありましたらアドバイスお願いします。

当方もおおむね単体テストはクラス単位という理解で進めています。

また、単体テストは、そのクラスに対応するコードが直接実装している
機能に対して行う、というように考えています。
具体的にはプレゼンテーション層のクラスの単体テストでは、そのクラスが
依存しているアプリケーション層、データ層のクラスは全て正しく動いて
いるとしてテストを書きます。

たとえばデータを0個入力したときに特殊処理があるとします。
その特殊処理の処理責任がプレゼンテーション層にあれば、もちろん
プレゼンテーション層の単体テストの対象になります。しかし、処理責任が
アプリケーション層,データ層のクラスにあれば、プレゼンテーション層の
単体テストには必ずしも入れはしません。

>>17

なんとなくxUnitの精神から逸脱してる感じがするっす。
階層ごとに処理責任があるってとこまでは同意するけど、

>処理責任がアプリケーション層,データ層のクラスにあれば、
>プレゼンテーション層の単体テストには必ずしも入れはしません。

ってのはちょっとね。
プレゼンテーション層の単体テストにアプリケーション層のテストを
「含める」って事があり得るとしたら問題だと思うよ。

>>16
下層をテストするために「ダミーの中層クラス」を作るんじゃないんですか？
で、そのダミー中層自体がTestクラスになってりゃいい、と。

で、動きが確認された下層クラスに、本物の中層クラスを乗せ、
その上にダミー上層テストクラスを乗せて…

という風に順繰り(再帰的?)にやるのではないかと推察します。どう？

>>18
ここらへんはどんなプロジェクトにも通用する指針を作りにくいところだと思います。

もしかするとうまく伝わっていないかもしれないので、少し補足します。
クラスFoo,Gooがあり、GooはFooを使用しているとします。
Fooが実現する機能は、Fooで実装した機能です。
Gooの実現する機能は、Gooで実装した機能+Fooが実現する機能です。

単体テストは「〜が実現する機能」を対象にするのではなく、「〜で実装した機能」に
対して行うのがよいのではないか、というのがオレの主張です。

17の例では「データが0個の時の特殊処理」がFooで実装した機能なのかGooで実装した
機能なのかによって、Foo,Gooのどちらかの単体テストに割り当てるのかを決めればよい
ということです。

いかがでしょうか？他にも良い指針があったら教えてください。

えっとね、ちょっと今眠いから具体的なことが上手く書けないけど、
基本的には17さんの方針でおっけーだと思う。

気になってたのは、GooをテストするときにFooの実装を意識するのか
どうかってとこで、「意識しちゃマズいよね」ってのがxUnitの基本思想
だと思うと言いたかったわけです。

んじゃ今宵はこの辺で。

ユニットテストはクラス単位でテストするけど、他のクラスを利用してはならない
という決まりはないと思う。has_a のクラスがあればそれを所有している状態が
そのオブジェクトのあるべき姿なのでそのままでテストするべき。
setUp() でオブジェクトを生成する時に必要な周辺のオブジェクトも一緒に作る。

委譲が単純なメッセージの転送で結果が自明だと思うならテストを省いてもいいかも
しれないけど、リファクタリングの結果メソッドの移動で委譲の形になったのなら、
その変更の影響確認の意味があるのでテストを削ることはない。

あと、setXXX(), getXXX() などの自明なメソッドや、GUIなどのテストが難しいも
のを無理してテストに含める必要もない。

「リファクタリング」の本にも、100%のカバレッジにこだわって結局テストしなく
なってしまうよりも、できるところからどんどんテストを書いていった方がいいと
書いてあった。

>>16

そういったクラスの単体テストに関しては、XP導入篇にやり方が書いてあるので、
立ち読みでもいいので読んでみるといいと思います。

基本的にはそのクラスが依存している下層クラスのダミーを作ってテストする、
ということになると思います。

理屈なんかどうでも良くて、作るものの数倍の規模のテストを書きまくる。
とにかくコーディングしまくって、家に帰るときに全部xUnitで自動実行。
翌朝、デグレードしていないことを確認して、別の観点でテストを書きまくる。
クソみたいなテストでも、何回も書き直すと自分のスキルになる。
単体とか結合とかは、人件費よりCPU時間の方が貴重な頃のクソ概念。
屁理屈こねてるぐらいならコーディングしろ。
それがイヤならプログラマやめな。

>>21
単体テストはホワイトボックステストなので、GooのテストがFooの実装を意識したものに
なっていてもかまわないのではないかと思います。いかが？

>>24
漢らしい！ある意味extremeですな。それでうまく進められるのなら、全くOKだと思います。

オレはそれほど漢気(ｵﾄｺｷﾞ)がないので、テストの効果は低下させずにテストの規模を
少なくできる方法を考えたいと思います。

24氏の方法だと、特定のクラス階層を取り出して再利用するときに、テストコードの
切り分けに手間がかかりませんか？テストを単体,結合に分けておくとそのような時には
便利ではないかと思います。

このあたりの考察,議論が屁理屈ではなくて、仕事の質を高める理屈につながることを
願います。

みなさんアドバイスありがとうございました。

1. 基本は、クラス単位でテストをする。
2. has-aクラスを持っているのであればそれらは生成してもよい。
3. 利用関係のクラスはダミークラスを用意する。

という方針で進めればよいという風に理解しましたがあっていますか？

あっていた場合、私自身悩んでいたのは、3.についてです。本当にダミー
クラスを用意することができるのか？　単純なシステムであれば、
可能に思えますが、複雑なものであればダミークラスを用意し、それら
の用意したクラスがうまく連携するかどうかの補償する必要が発生し、
ダミークラスのユニットテストが必要になり、それをするのにさらに
ダミークラスが必要になる...。つまり、ダミークラスが必要がなくなるまで
それを繰り返すか、どこかで妥協する必要があるんじゃないだろうかという
こと。それにより、複雑なシステムではユニットテストは難しくなって
くるのではないかという疑問へとつながります。ここら辺は、みなさん
問題なくできていますか？　Webアプリ程度のものであれば可能に思え
ますが、マルチスレッドなシステムとか大規模なシステムは、
GUIに近づくほど難しいと感じます。

:%s/Goo/Bar/g

Fooを作る場合
Foo(interface), FooImpl, MockFoo, FooImplTest
をつくるけど　駄目？
ちょっと面倒だけど、ほかのクラスの実装にほとんどたよらずに
テストできるのでいいかんじ。

>>23
購入してみようかと思ったのですが、あまり評価がよくないようなのですが、
実際のところみなさんどう思いましたか？

http://www.amazon.co.jp/exec/obidos/ASIN/4894714914/ref=b_br_r_4_3/249-6364008-4713114

>>29
評判が悪いのは、『実行計画』の方です。
内容そのものが悪いというわけではなく、訳がヒドイという理由で評判が悪いです。
『導入編』の方はそのようなことはありませんでした（精読したわけではないですけど）

>>30
いや、一番ひどいのは「入門」です。これは、
http://objectclub.esm.co.jp/eXtremeProgramming/ec-errata.txt
と併用しないと理解できません。

もっとも「実行計画」も基本的に同じ人間が翻訳しているので出来はよくない
ですが。「導入編」はわかりやすいし、おまけもついているのでお勧めです。

>いや、一番ひどいのは「入門」です。これは、

あ、そうでしたね。
あまりに酷かったので、俺の記憶から消去してました（藁

>>30,31
あえてsageずに激しく同意。
大学受験レベルの訳が出来てないのには閉口する。
導入編があれば入門も実行計画もいらんのではないかと思うよ。

Servlet系にXUNITは使えますか？

HttpRequestを使ってるクラスが多くて、
そういうクラスをどうやってXUNITでテストできるのでしょうか？
DB系のクラスも難しい
結局ブラウザで地道にやってます

HttpUnit
http://wiki.esm.co.jp:8080/xp/29
じゃだめ？

>34

>>34 80版ポートを開いてHTTPを聞いてダミーデータ（ファイルとか)をそのまま返す
簡易サーバ作れば？
んでsetUp() でlocalhostとかで起動しとく

>>34
>DB系のクラスも難しい

これはテストしやすいと思うけどなぁ。
テストしづらいとしたら、それは、メソッドが複雑である、ということでは？

どういう所が難しいの？

>>34
コアサーブレット＆ＪＳＰかなんかのサンプルに
ＵＲＬ指定してＰＯＳＴするＡｐｐｌｅｔのコード
が出てたのでそいつを改造してJUnitしたことはあ
るけど、そういうことではないのかな？
あんまり真剣にやったわけじゃないから、細かいこ
とはわからんが、中途半端なフレームワーク使うよ
り、人のコード改造した方が生産性はあがるぞ。

>>38
ちなみにサンプルのコードは以下のＵＲＬから落とせるよ。
http://books.softbank.co.jp/isbn/1431/
SendPost.javaとかいうファイル名だったとおもう。

>>34
Requestの使用するメソッドだけを備えたラッパーを
つくれば幸せになるかも

>>37
DB関連はUnit単位ならどうということはないけど、
実際のDBを使用するテスト(Acceptance?)となると
データを用意する -> テストする -> 後始末
となりやっぱり面倒かと

>>23
なるほど、やはり仮想クラスのダミーを作って
テストするということですね。
とりあえず、導入編を買って読んでみます。

>>40
>データを用意する -> テストする -> 後始末
>となりやっぱり面倒かと

というか、それってxUnitの全否定に繋がるような気が・・・。

>>40
君には向いていない職業だね。
早く出世するか、転職するか選んだ方がいいよ。
プログラマが「コーディングがイヤ」とか「コーディングに自信がない」
って言ったらおしまい。
「血を見るのがイヤ」とか「盲腸切るの自信が無い」なんて言う外科医に
命預けられる？
あんたの顧客も同じ気持ちだよ。

>>42
やっぱり、そこで苦しくなってくるのがDB絡みだな。
パフォーマンスや時間やライセンスの都合で、
DB空間を必要な数だけ構築できない場合には、
複数の開発者(＆デバッグ者)が同一のDB空間に相乗りすることになり、
うまく(素早くってのも含めて。delete * from HOGEHOGEとかをやれるかどうか)
必要なデータを用意＆抹消するのが困難になったりする。

言いかえれば、空間を好きなだけ作ることが
パフォーマンスや、ましてライセンスに、縛られるという
DBMSの構造が駄目駄目だ、ということなんだけども。

というわけで、大抵の商用DBMSベンダーは、いってよし。

そうそう。
http://www.zdnet.co.jp/enterprise/0108/30/01083006.html
今時WaterFall開発を薦めるという勇気有るドキュ記事。
言ってること、これ、変だろ。
(乱暴にいえば)渡して「から」デバッグするのがSpiralだろうに、
バグは許されないからWaterFallしろってのは、勘違い。

>>43
優良スレに育ちつつあるんだから煽りモード控えめで行きましょう。

>>44
DBに対するxUnitの適用方法ですが、導入編に示唆的な一節があります。

“テストをできる限り高速で走らせるためには、安全性を考えあわせた上で、
なるべく実際のデータベースにはアクセスしないことが基本的なルールだ。”
（導入編131ページより）

んーなんか誤解を与えたようで。
プログラムは好きですよ、ほんと。

>>46
それは、ＤＢ周りのクラスを使うがわの話であり
ＤＢ周りのクラスそのもののテストにはＤＢやらＳＱＬやらが
関係してくると思います、多分。

現実のリソースに触るようなテストはできれば別系統にしておいて
実行速度をあげるという意味だったかと。僕もそうしてます。

>>42
xUnitマンセー！否定だなんて！

ただSQLがらみだと何度もテスト実行可能なように
setUpやらtearDownやらに手間がかかって
やだなあ、とか思いません？
僕がSQL嫌いなだけかもしらないけど。

っていうかなんか楽な方法ないですか？

>>48
初期化・終了処理周りのルーチンワークが面倒なら
xUnit拡張してSQL Unitかそこまで行かなくても
SQLTestCaseでも作ってやればいいんじゃない？

本質的に複雑で面倒でライブラリ化不可能ならあきらめるしかないかもね...

DBSetUPを作ってConnectionの準備、後始末くらい
ならやってますが、個々のテストで必要なデータが
結構ちがうためデータのそれはどうにも…。

外部にバッチをおいてテスト前に必要なＳＱＬを
実行するようにしたこともあったけど、あんまり
気持ちよくない。xUnitだけで完結しないし。

>>46
生DBにアクセスしないかどうかをユーザーの自由意志で決められる場合は、そうでしょうね。
OODBとかJDO(藁)みたいに、なかば暗黙化されてる場合に、ちょっと困るなぁと。
DBを切り離すわけにもいかないし、パフォーマンスやライセンスで足引っ張られるのは厳然たる事実だし。
某環境でObject1つを生成するのに1秒かかった時は本当に鬱になった。

>>47
>それは、ＤＢ周りのクラスを使うがわの話であり

「DB周りのクラス」がどこまでを指すかが気になるなぁ。
この辺の認識って十人十色ですよね。

皆さんは大体どのあたりをイメージされてますか？

>>48
>ただSQLがらみだと何度もテスト実行可能なように
>setUpやらtearDownやらに手間がかかって
>やだなあ、とか思いません？

いや、だから、何を「やだなあ」と思っているのか、読み取れないんですが・・・。

>>50
>ならやってますが、個々のテストで必要なデータが
>結構ちがうためデータのそれはどうにも…。

問題はこれだけですか？
結局「面度くさい」ということですか？

だったらしかたないですねぇ。

めんどくさい仕事は新人に「教育」名目で押し付ける。
でも、テストデータを作るのも楽しくない？
テストデータを生成するロジックを考えるのも楽しいよ。
制約があるから、知恵を絞る楽しさがあるんだじゃないかな？
制約なくなったら、俺は仕事しない。納期もないだろうしね。

>>53
ちょっと長いけどこんな感じ？(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");
}
}
//以下テストが続く
}

このやり方だと長ったらしくＳＱＬが続く上に
テストのためのＳＱＬ自体が間違いを含んでいたり,
エスケープが面倒だったりと結構いやなものです。
ＳＱＬを直に使うためＤＢに依存も起きます。
テストに要する時間が通常の三倍くらいってとこかな。

怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？

で、なんかいい方法ないっすか？

インデント消えてるし…
あとexecuteQuery --> execute ですね…

>>54
それはちょっとむごいかと
つうか僕が新人ですよ！

一番きつい制約が時間なので、できるだけ安いコストで
テストしたいです。

>>33
やはり読みづらいですか。
デザインパターンとか、XPはいい方向だと思うのですが、
どうにも良書が少なくて、取り入れづらくて。
最先端で天狗になっちゃって誰も何も言えないのかな。

パターンハッチングも逝ってます。
この手の訳書が出ないことを嘆いてますが、間違いなく足ひっぱってるとおもわれ。

分からなかったら俺のセミナーを聞け！なのかな。
導入編訳者が違うので買ってみま。

>このやり方だと長ったらしくＳＱＬが続く上に
これは仕方がないですね。

>テストのためのＳＱＬ自体が間違いを含んでいたり,
これは間違わないようにするしかないです。

>エスケープが面倒だったりと結構いやなものです。
何をエスケープするんでしょう？

>ＳＱＬを直に使うためＤＢに依存も起きます。
それも仕方がないですね。

>怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？
怠慢おおいに結構。

>で、なんかいい方法ないっすか？
create table - drop tableは本当に必要なんですか？それも毎回？
Singleton patternとRollbackをうまく使えば、テストに要する時間は短縮できます。
テストデータ生成も、Insert文を直接書くのではなく、CSVをInsert文に変換する
クラスなどを作って、間違いをなくすようにする。

こんなとこかな。

ちょっとは頭使おうよ。
新人ならやめちゃえよ。今からならやり直せるよ。
大体、そんなに自動化しちゃったら、お前ができる仕事なくなるよ。
楽する方法を考えるのが、今の仕事なんじゃないの？
ＸＰ以前に、仕事に対する姿勢が問題じゃん。

>>59
何度よんでも一回だけ処理をしてくれるSetUp用の
クラスは、データが重複する場合は作ります。

create - drop は趣味の問題かもしれません。
ごみは残さないって感じで。

データの量が多い場合は外に出しますが
少ない場合はテストに内臓のほうがよいような気がします。

エスケープは正規表現かなにかと勘違いしたかも、すみません…

>>61
じゃぁ、結局何が問題なの？
つまるところ「面倒くさい」ってとこに帰着するのかな？
それって、xUnitを全否定することでは・・・(loop)

要するに、仕事の結果だけ欲しくて、仕事したくないってことじゃん。
こんな奴が「xUnitは役立たない」って知ったかぶって言いふらすんだろうな。
役立たないのは、、、
ま、それ以上は言わないよ。大人だから。

>>63
大人なら初めから黙ってるよろし。
いたづらに煽るばかりのﾚｽはｳｻﾞい事この上なし。

というわけで話題提供を試みてみる。

実DBにアクセスしないとできないテストが多岐にわたるようであれば、それこ
そリファクタリングの対象とすべきでは？
「DBにアクセスするな」というのは、テストの手間を惜しむという面もあるが
、DBへの依存度が低い設計を強制するという面も忘れてはならないと思う。

>>64
それからUnitTest自体のリファクタリングも必要だよね。

でもさ>>1の聞きかたって、ある種の煽りでしょ？
タイトルだって、xUnitの効果に疑問があるわけでしょ？
で、よくよく聞いてみると、「めんどくさいことしたくない」でしょ？
何処が優良スレなんだよ。別のスレたてて議論しよ。

>>66
別スレでも「めんどくさいことしたくない」派が書き込むのは不可避。
なぜなら彼らのほうが多数派だから。
改革派だけでオナニー議論したところでこの業界は変わらない。

66さんの同僚にも「めんどくさいことしたくない」派がたくさん居るはず。
このスレで説得する方法を磨いてみては？

P.S.懐疑派を煽るのはXPの価値を貶めるだけなので止めましょう。

そろそろ煙たがられてるような気もするがめげずに啓蒙age。

「XPエクストリーム・プログラミング導入編」は良書なので否定派も肯定派も
ご一読を。（税抜2400yenナリ）

図書館を利用せよ

>>64
というかこれって、いわゆるOOPと(R)DBのインピーダンスミスマッチの話だよね。
あっちの世界とこっちの世界を行き来するためのコードがナニかと煩雑になるというあれ。

JDOだっけ？あれにでも期待するといいんじゃないかな。最終的には。

一方、今すぐ最終段階になれるわけでもないんで、DBアクセスをライブラリ化しとく
ってのは必要になるだろうね。毎度毎度JDBCコードを素で書いていたらやってられん。

「ライブラリ化する」というリファクタリング(?)は、必要だと思われ。

>>68
導入編ですか。買ってみます。たしか薄い本ですよね。持ち運べるのが嬉しい。

>>69
その手もあったね。スマンです。

>>70
前の2冊ほどは薄くないけど、持ち運べない程でもないです。
赤紫色のカバーで目立ちやすいのですぐ見つかると思います。

職場にいるめんどくさいことしたくない派は、揚げ足とってさらし者にする。
どうせリストラするんだから、きっかけをあげればいい。
仕事しない奴10人より、やる気のある新人の方が役立つよ。
何もみんな一緒にＸＰする必要なし。少数精鋭でいきましょう。
結果を残せば経営陣は何もいえないよ。