Index: [Article Count Order] [Thread]

Date:  Thu, 26 Jul 2001 16:33:34 +0900
From:  ono@....jp
Subject:  [XP-jp:02277] Endo-Testing (Re: )
To:  extremeprogramming-jp@....jp
Message-Id:  <20010726163334Y.ono@....jp>
In-Reply-To:  Your message of "Wed, 25 Jul 2001 21:52:02 -0700 (PDT)"	<31096999.996123125804.JavaMail.imail@derby>
References:  <31096999.996123125804.JavaMail.imail@derby>
X-Mail-Count: 02277

小野 剛です。小林さん、はじめまして。

>> Regarding [XP-jp:02267] assert で表現できないメソッドのテスト; tomkob@....jp adds:

 > しかし、実際に使うメソッドでは、ファイルの入出力や、DBの読み書き、
 > など、assert文ではテストできない又はし難いメソッドが多く存在します。

私はいま、"Extreme Programming Examined" という、XP に関する
論文集を読んでいるのですが、これの 

	Ch 17. 
	"Endo-Testing: Unit Testing with Mock Objects"
	by Tim Machkinnon, Steve Freeman, Philip Craig

という論文で提案されている方法が、小林さんの問題に関連が深いかと
思います。online でも読めるようですね。

	http://www.sidewize.com/company/mockobjects.pdf
	(英語ですが、コードだけ見ても雰囲気は伝わると思います)

渋川さんが [XP-jp:02274] でおっしゃっていた方法に近いのですが、
複合テストではなく、あくまで単体テストにするというところが違う
かもしれません。

簡単にまとめると、 
  1) DB や I/O などのエミュレーションを行う MockObject というものを作る
  2) テストコードは、そいつをターゲットコードに渡した後に、ターゲット
     コードを実行する(必要なら、通常の assert を行う)
  3) 実行後に、MockObject の assert を呼ぶ(これにより、DB に何が渡ったか、
     I/O の呼出しがあった回数は予想通りか、といったことを確認する)

という手法です。2) をするにはターゲットコードの改変が必要になる
はずですが、そのような改変はターゲットコードの外部依存性を多少なり
減らす方向に設計を改善するのだから問題なし、という理屈のようです。

論文を読んでみて、私もちょっと試してみようかという気になっていますが、
どなたか既にやっている人っていますか?

// Tsuyoshi ONO // 
e-Communications Dept, Telecom & Service Company /  SONY Corporation 
email: ono@....jp
"Be completely flexible on how we get there, but be totally 
 uncompromising on where we are going." -- Martin Fowler