20100925xutp
19
Configurable Test Double 2010年9月25日土曜日
-
Upload
hiroyuki-ohnaka -
Category
Documents
-
view
724 -
download
2
Transcript of 20100925xutp
Configurable Test Double
2010年9月25日土曜日
間接的な入力、間接的な出力としてユニークな値を必要とする場合、Test Doubleを必要とする
Configuration Test DoubleはTest Doubleを再使用することにより、Test Code Dupicationを減少する方法です。
2010年9月25日土曜日
How It works
Test DoubleはSUTから返されるか、引数として渡すことが期待される値を保持するインスタンス変数といっしょにビルドされる。
テストのsetupのフェーズで、Test Doubleのインターフェースの適切なメソッドを通じて、これらの変数を初期化する。
2010年9月25日土曜日
When to Use it似ているが少し違う振舞いが(Test Doubleに)必要で、その際にTest Code DuplicationやObscure Testを避けたい場合。
後者(Obscure Test)の場合、Test Double のどのような値が使われているのか注視する必要がある。それが難しいなら、Hard-Coded Test Doubleを使うのもよいでしょう。
2010年9月25日土曜日
Implemention Notes
Test Double とは、Configuration test Double でもある。
設定可能なTest StubsとTest Spliesの設定は、それらのメソッドが呼ばれたときの応答を設定するのみで済む。Mock Objects の場合は、期待値を設定する方法を用意する必要もある。
2010年9月25日土曜日
どの方法でConfigurable Test Doubleを構築するか
関係のある2つの独立した決定を含んでいます。
(1)Configurable Test Doubleをどのように構築するか
(2)Configurable Test Doubleをどのようにコーディングするか
2010年9月25日土曜日
一つ目の方法は、設定のためのインターフェースを用意する方法。
もう一つの方法は、Configuration Test Doubleに二つのモードをもたせて構築する方法です。
2010年9月25日土曜日
手動で組み立てる。
ついている時は、Configurable Test Doubleを構築する方法が用意されています。(1)コードジェネレーター(2)オブジェクトを実行時に「でっちあげる」ツール。
! http://xprogramming.com をチェックしましょう。
2010年9月25日土曜日
Configurable Test Doubleに値を設定するメソッドから構成され、Four-Phase Testのfixture をsetupをセットアップするphaseにおいて、これらのメソッドを呼び出すだけで済みます。
SUTは Test Doubleとは違うメソッドを使用します。
Varidation:Configration Interface
2010年9月25日土曜日
Configuration Interface には二つの流儀がある。
一つは MockMakerのような必要な値それぞれメソッドを用意する方法。
もう一つはJMockのような、期待されるふるまいを作り出すための、汎用的なインターフェースをもっているものです。よくデザインされた、流れるインターフェースが、読解と理解をより容易にする。
2010年9月25日土曜日
テストメソッドがSUTとエクササイズする前に、どうやってメソッドを呼び出すのか？
record and playbackという形式にたどり着いたときに、この方法はもう少し理にかなったものになる。
Configration Mode
2010年9月25日土曜日
SUTのそれぞれのメソッドがConfiguration Modeと”usage mode”の二つのパスを持つことを期待される。
2010年9月25日土曜日
Hand-build Test Double
Hard-Coded Test Double はHand-Build Test Doubleから派生するものであり、hand-builtによるか、生成されたかによる。
この本では、Hand-Build Test Double を例として多用している。
2010年9月25日土曜日
third party のツールが用意されていない場合や、ツールを使用することに障壁がある場合にも、Hand-Built Test Doublesは使用することができる。
2010年9月25日土曜日
早期のツールには、静的に生成されたTest Doubleを生成するものがあった。
対象となるクラスのインターフェースに変更が入るたびに、コードを再生成する必要がある。
これは、インターフェースに変更がはいるたびに、自動化されたビルドスクリプトが走ることが保証されている場合に、都合がよい。
Staticaly Generated Test Double
2010年9月25日土曜日
インターフェースに変更を加えるとき、生成されたコードにどのようにリファクタリングを加えればいいか？
モダンなリファクタリングツールを使えば、生成されたコードもリファクタリングすることは可能。
2010年9月25日土曜日
だが、引数のチェックロジックや、新しいパラメータへの変数はそのままになってしまう。それゆえに、リファクタリングが完了したあとに、再生成する必要があります。
2010年9月25日土曜日
最近のツールには、リフレクション機能などを使って、実行時にConfigurable test doubleを生成するものがある。
これらのConfigurable Test Doubleは、振る舞いを実行時に解釈するか、実行可能なコードを動的に生成します。
Dinamically Generaterd Test
2010年9月25日土曜日
それゆえに、生成され、メンテナンスや再生されるソースコードは存在しない。気を配るべきソースコードが存在しないという利点があるが、疑いの目でみるなら、それは欠点。
今日の大半のツールは、引数がどのように渡されたかに興味がないなら、大半のツールは「気にしないで済む」引数を渡します。Mock Objectsを使うなら、大半の場合Retrieval Interfaceは不要となる。
2010年9月25日土曜日
