「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホームWikipedia翻訳一覧 > Wikipedia翻訳

Wikipedia翻訳

モックオブジェクト(Mock object)

法律: IT 百科事典

モックオブジェクト(Mock object)

オブジェクト指向プログラミングにおいて、モックオブジェクトとは、管理されたやり方で実体オブジェクトの振る舞いをまねるシミュレーション用のオブジェクトである。プログラマは一般的に、他のオブジェクトの振る舞いをテストするためにモックオブジェクトを作成する。それは自動車デザイナーが車の衝突における人間の動的挙動をシミュレートするために安全試験用の人形を使うのと同じようなものである。

目次

1 使う理由
2 技術的詳細
 2.1 モックとフェイク、スタブ
 2.2 期待値の設定
 2.3 ログの記録を残す
3 テスト駆動開発における利用
4 限界
5 関連項目
6 参考文献
7 外部リンク

使う理由

単体テストにおいて、モックオブジェクトは複雑な実体オブジェクトの振る舞いを真似ることができ、それゆえ、実体オブジェクトを単体テストの中に組み込むことが実際的でないときや不可能なときに役に立つものである。オブジェクトが次に述べる特徴のいずれかをもつ場合、かわりにモックオブジェクトを使うことが有用かもしれない:

・非決定性の結果を出すオブジェクト(例えば、現在時刻や現在温度)
・作ることや再現することが困難な状態(例えば、ネットワークエラー)
・遅い(例えば、テストの前に初期化される必要のある完全なデータベース)
・まだ存在していないか、挙動を変える可能性がある
・テスト目的のために(実際の仕事のためではなく)、排他的に情報やメソッドを含む必要がある。
例えば、特定の時刻にベルを鳴らすアラームクロック・プログラムは、外部から現在時刻を取ってくるかもしれない。これを試すためには、テストでは正確にベルが鳴らされるかどうかを確認するためにアラームの時間まで待たなければならない。モックオブジェクトが実際のオブジェクトの代わりに使われるなら、ベルを鳴らす時間にプログラムを設定することができ(実際にそのときにその時間であろうとなかろうと)、そうすることでアラームクロック・プログラムを分離してテストすることができる。

技術的詳細

モックオブジェクトは実際のオブジェクトと同じインタフェースをもち、まねることで、クライアント・オブジェクトが実際のオブジェクトを利用しているのかモックオブジェクトを利用しているのかを意識せずにいることを可能にする。多くの利用可能なモックオブジェクトのフレームワークは、戻り値だけでなく、どのメソッドをどのような順番でモックオブジェクトで呼び出すのかや、どのパラメータを渡すのかについて、プログラマが細かく指定できるようにする。このようにして、ネットワークソケットのような複雑なオブジェクトの振る舞いをモックオブジェクトによって模倣することが可能となり、それにより、プログラマはテスト対象のオブジェクトがそのようなモックオブジェクトの置かれた多種多様な状態に適切に反応しているかどうかを知ることが出来る。

モックとフェイク、スタブ

モックとフェイク、スタブの分類は、文献全体の中で非常に矛盾している[1] [2] [3] [4] [5] [6]。だが、文献の間で一致していることは、それらはすべてテスト環境において同じインタフェースを顕在化させることによって生産オブジェクトを代表しているということである。

モックやフェイク、スタブから生じるもののいずれが最も単純なものであるかというのは一致していないが、最も単純なものは常にあらかじめ定められた反応を返す(メソッドスタブがそうであるように)。その領域の反対側では、最も複雑なオブジェクトが複雑なロジックと例外などを備えた生産オブジェクトを完全に模倣することになる。モックやフェイク、スタブの3つのいずれがそのような定義と合致しているかそうでないかは、またも文献全体を通じて一貫していない。

例えば、複雑な範囲の両端において、モックやフェイク、スタブのメソッドを実装することは、それぞれの呼び出しの文脈を調べるための表明文を含むかもしれない。例えば、モックオブジェクトはメソッドが呼び出される順番を表明するかもしれない、あるいは、メソッドの呼び出しの中でのデータの一貫性を表明するかもしれない。

『The Art of Unit Testing』[7]という本の中で、モックは、オブジェクトとの相互作用が生じたかどうかを確かめることで、テストが失敗したか通ったかを判じる手助けをするフェイクオブジェクトとして説明されている。他の全てのものはスタブと定義されている。その本の中で、フェイクとは実体ではないもののことであり、それは、それらの使用に基づくと、スタブとモックのいずれでもありうる。

期待値の設定

継承サブシステムがモックとされる場合の例について考える。実体の権限クラスに合うように、モックオブジェクトはisUserAllowed(task : Task) : boolean [8] メソッドを実装する。実体クラスには存在しない isAllowed : boolean プロパティも顕在化させるなら多くの利点が付随する。これはユーザが次の呼び出しで権限が得られるまたは得られないという期待値をテストコードが設定することを容易にし、それゆえ、どちらの場合においてもシステムの残りの部分の振る舞いを容易にテスト出来るようにする。

同様に、モックのみの設定は、サブシステムへの後に続く呼び出しが、例外処理の実行をもたらすことや、応答なしに未決定の状態にすること、nullを返すことなどを確実に起きるようにする。こうして、予期された反応に関してだけでなく、バックエンドのサブシステムにおいて現実的な故障条件に関するクライアントの振る舞いを開発し、テストすることが可能になる。そのような単純で柔軟なモックシステムがなければ、適切な考慮を行い、これらの条件のそれぞれをテストすることは、非常に困難なものとなりうる。

ログの記録を残す

モックデータベースオブジェクトのsave(person : Person)メソッドは(もしあるとしても)あまり実装コードを含まないかもしれない。存在を確認することはなく、他のいかなる実装もないかもしれないという以外には、おそらくPersonオブジェクトの効力は保存のために渡される(上記のフェイクとモックの議論を参照)。

これは見逃された機会である。モックメソッドはパブリックのログの文字列に書き込みを加えることが可能である。書き込みは「Person saved」 [9] :146–7 だけにすぎないか、名前やIDのようなpersonオブジェクトのインスタンスの詳細を含むかもしれない。テストコードがモックデータベースに関わる一連の様々な操作の後にログの文字列の最終的な内容を確認することもあるのであれば、そのときは、それぞれの場合の正確なデータベースの保存する期待値が実行されたことを確認することが可能となる。これはそれ以外では気づかれないような、性能を低下させるバグを見つけられるようにする。例えば、開発者がデータの喪失を心配して、一度で十分な場合にもsave()の呼び出しを繰り返しコードに書くといった場合である。

テスト駆動開発における利用

テスト駆動開発(TDD)メソッドで働くプログラマはソフトウェアを書くときにモックオブジェクトを利用する。モックオブジェクトはより複雑な実体オブジェクトのインタフェース要件を満たし、代役を務める;このようにして、モックオブジェクトはプログラマが複雑な基底クラスや協調クラスを呼び出すことなく、一つの領域で書き、機能性を単体テストで試すことを可能にする[9] :144–5。モックオブジェクトを使うことは、開発者が依存関係について心配することなく試験対象システムの振る舞いに関するテストに集中できるようにする。例えば、特定の状態に置かれた複合的なオブジェクトを基礎とした複合アルゴリズムの試験は、実際のオブジェクトの代わりにモックオブジェクトを使うことで明確に表現することが可能となる。

複雑性の問題と関心の分離から得られる利点を別にすると、実用感度の問題が関係する。TDDを使うソフトウェアの現実的部分の開発は、軽く数百の単体テストを伴うことがありうる。これらの多くはデータベースやウェブサービス、その他の通信システムやネットワークシステムとの通信を生じさせ、そうして一連の単体テストはすぐに一定の間隔で行うには遅すぎるようになる。これが今度は、TDDの基本的な主義を維持するための悪習慣や開発者の抵抗をもたらす。

モックオブジェクトが実体オブジェクトの代わりになると、端末相互間の機能性のさらなるテストが必要とされる。これらは単体テストというよりは結合テストとなる。

限界

モックオブジェクトの使用は単体テストを、試験されるコードの実装と密接に結びつける。例えば、多くのモックオブジェクトのフレームワークは、モックオブジェクトのメソッドが、試験される実体オブジェクトによって呼び出された順番と回数について開発者が確認することを可能にする;それゆえ、試験されたコードのその後のリファクタリングでは、たとえすべてのモックオブジェクトのメソッドが以前の実装の取り決めに今でも従っているとしても、テストの失敗が引き起こされることとなる。これは、単体テストは内部の実装よりもむしろメソッドの外部の振る舞いを試験するべきだということの例証となる。一連の単体テストの一部としてのモックオブジェクトの過度の使用は、リファクタリングが行われるシステム展開中にテストそれ自身に行われる必要のあるメンテナンスの量の劇的な増加をもたらす結果になることがある。展開中のそのようなテストの不適切なメンテナンスは、そうでなければ実体クラスのインスタンスを使用する単体テストによって見つけられていたであろうバグを見逃させてしまうことになりうる。逆に言えば、あるメソッドを簡単なモックにすることは完全な実体クラスを設定するよりもはるかに少ない設定を要するだけで済み、それゆえメンテナンスの必要性を減らすかもしれない。

モックオブジェクトはそれらが模倣するオブジェクトの振る舞いを正確にモデル化しなければならず、それはモックされるオブジェクトが他の開発者やプロジェクトからのものであるときや、まだ書かれてさえいないときには成し遂げるのは困難となりうる。振る舞いが正確にモデル化されていないなら、単体テストはそれが実行されたときと同じ条件で実行時に失敗が起きるときであっても試験の通過を記録するかもしれず、したがって単体テストを不正確な状態にする [10] 。

関連項目

ソフトウェアテストポータル

抽象メソッド
ダミーコード
Hamcrest
メソッドスタブ
テストダブル

参考文献

1. 「スタブとモック」

2. 「時代遅れ:モックとスタブはスパイではない」

3. 「XUnitPatterns.comのモックとフェイク、スタブ、ダミー」

4. 「モックとスタブの違いとは?」

5. 「フェイクとモック、スタブの違いとは?」

6. Feathers, Michael (2005). "Sensing and separation". Working effectively with legacy code. NJ: Prentice Hall. p. 23 et seq. ISBN 0-13-117705-2.

7. Osherove, Roy (2009). "Interaction testing with mock objects et seq". The art of unit testing. Manning. ISBN 978-1-933988-27-6.

8. これらの例は統一モデリング言語で使われているものに似た用語を使っている。

9. a b Beck, Kent (2003). Test-Driven Development By Example. Boston: Addison Wesley. ISBN 0-321-14653-0.

10. InJava.com to Mocking | O'Reilly Media

外部リンク

Tim Mackinnon (8 September 2009). 『モックオブジェクトの略史』. Mockobjects.com/.

テストダブル:単体テストパターンに関する本の一節

モックオブジェクトに関するすべて! モックオブジェクトについてのポータル

『複雑な単体テストにモックオブジェクトを使う』IBM developerWorks. 16 October 2006. Archived from the original on 4 May 2007.

モックオブジェクトでの単体テストIBM DeveloperWorks

モックはスタブではないマーティン・ファウラー)。モックオブジェクトを使ったテストの開発についての記事。「古典的な」テストの流儀と「モッキストの」テストの流儀を識別し、比較している。デザインとメンテナンスへの影響について要点に触れている。

PDF
更新日:2017-02-19 19:00:23 shikimi 1  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://en.wikipedia.org/wiki/Mock_object Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

shikimi さんの翻訳記事

ダブル・ラチェット・アルゴリズム

ダブル・ラチェット・アルゴリズム 「ダブル・ラチェット」はこの項目へ転送されています。工具については レンチ を参照下さい。 暗号技術において、ダブル・ラチェット・アルゴリズ…2017-09-03 12:17:25

女性の権利はSDGsとインターネットにどのような関係があるか?

女性の権利はSDGsとインターネットにどのような関係があるか? 2017年8月2日、スリランカ 女性は均質な集団ではなく、科学技術へのアクセスもまた、数多くの他の要因、例えば年齢や階級…2017-08-20 18:48:26

性的権利とインターネット:第3回EROTICS国際調査、現在開始!

性的権利とインターネット:第3回EROTICS国際調査、現在開始! 2017年7月19日 EROTICS国際調査が戻ってきた! もしあなたが、インターネットを自らの主張を促進するために使用している…2017-08-13 11:09:21

フェミニストの自律的な基盤に関する継続中の会話:エリカ・スミスとKéfir

フェミニストの自律的な基盤に関する継続中の会話:エリカ・スミスとKéfir 2017年8月2日、メキシコ 2017年7月に始動した小さな資金調達として、あるいはフェミニストの自由な技術共同体…2017-08-13 10:58:57