.. _for_dummies: ====== 超入門編 ====== .. Google C++ Mocking Framework for Dummies *サルでも分かる Google C++ Mocking Framework* * :ref:`fordummies_what_is_gcpp_mocking` * :ref:`fordummies_why_gmock` * :ref:`fordummies_getting_started` * :ref:`fordummies_a_case_for_mock_turtles` * :ref:`fordummies_writing_mock_class` * :ref:`fordummies_how_to_define` * :ref:`fordummies_where_to_put_it` * :ref:`fordummies_using_mocks_in_tests` * :ref:`fordummies_using_gmock_with_any_testing_framework` * :ref:`fordummies_setting_expectations` * :ref:`fordummies_general_syntax` * :ref:`fordummies_matchers` * :ref:`fordummies_cardinality` * :ref:`fordummies_actions` * :ref:`fordummies_using_multiple_expectations` * :ref:`fordummies_ordered_vs_unordered` * :ref:`fordummies_uninteresting_calls` * :ref:`fordummies_what_now` .. (Note: If you get compiler errors that you don't understand, be sure to consult Google Mock Doctor.) （注意：分からないコンパイルエラーが出たら， :ref:`Google Mock Doctor ` を試してください．） .. What Is Google C++ Mocking Framework? .. _fordummies_what_is_gcpp_mocking: Google C++ Mocking Framework とは何か？ ========================== .. When you write a prototype or test, often it's not feasible or wise to rely on real objects entirely. A mock object implements the same interface as a real object (so it can be used as one), but lets you specify at run time how it will be used and what it should do (which methods will be called? in which order? how many times? with what arguments? what will they return? etc). プロトタイプやテストを書くとき，実際のオブジェクトにべったり依存するのは不可能だったり，賢明とはいえないことだったりします． **モックオブジェクト** は，実際のオブジェクトと同じインタフェースを実装したものです（そして同じように利用できます）．ただし，実行時の使われ方や動作内容（どのメソッドが呼ばれるか，どんな順番で呼ばれるか，何回呼ばれるか，引数は何か，何を返すか，など）を指定することができます． .. Note: It is easy to confuse the term fake objects with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community: **注意** ：フェイクオブジェクト と モックオブジェクト は，混同されがちです．実際は，テスト駆動開発（TDD）コミュニティにおける，フェイクオブジェクトとモックオブジェクトの意味はまったく異なります． .. Fake objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake. .. Mocks are objects pre-programmed with expectations, which form a specification of the calls they are expected to receive. * **フェイク** オブジェクトは動作する実装ですが，通常は，（おそらく処理を軽くするための）省略を行っているので，これは製品には適したものではありません．例えば，メモリ上のファイルシステムは，一種のフェイクといえます． * **モック** は，Expectation を利用して事前にプログラムされたオブジェクトです．この Expectation が，期待される関数呼び出しの仕様を決定します． .. If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the interaction between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks. この説明が抽象的過ぎると感じても心配はありません．最も重要なことは，モックの場合，モックとモックを利用するコードとのインタラクションが可能である，ということです．モックを使い始めれば，フェイクとモックの違いがさらに明確になるでしょう． .. Google C++ Mocking Framework (or Google Mock for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what jMock and EasyMock do to Java. Google C++ Mocking Framework（略して Google Mock）は，モッククラスを作成して使用するためのライブラリ（カッコいいので，「フレームワーク」と言うこともあります）です．つまり，Java における `jMock `_ や `EasyMock `_ の C++ 版です． .. Using Google Mock involves three basic steps: Google Mock を使うための3つの基本ステップは，次の様になります： .. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class; .. Create some mock objects and specify its expectations and behavior using an intuitive syntax; .. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises. #. 簡単なマクロを使ってモック化したいインタフェースを記述します．これが，モッククラスの実装に展開されます． #. モックオブジェクトを作成し，直感的な構文を利用して Expectation と 動作を規定します． #. モックオブジェクトを利用するコードを実行します．Google Mock は，Expectation 違反が起こると即座にそれをキャッチします． .. Why Google Mock? .. _fordummies_why_gmock: どうして Google Mock を使うのか？ ===================== .. While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is hard: モックオブジェクトをうまく使えば，不要な依存関係がなくなり，テストを高速で確実なものにできますが，いかんせん C++ のモックを手動で書くのは大変です： .. Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it. .. The quality of those manually written mocks is a bit, uh, unpredictable. You may see some really polished ones, but you may also see some that were hacked up in a hurry and have all sorts of ad hoc restrictions. .. The knowledge you gained from using one mock doesn't transfer to the next. * モックを実装する必要があるとします．しかし，この仕事は退屈でミスが起こりやすいものです．皆が敬遠するのも無理ありません． * 手で書かれたモックの品質は，なんというか，予測しにくいものです．中には洗練されたものもあるかもしれませんが，あわてて作られたその場しのぎのものもあるかもしれません． * そして，あるモックを利用して得た知識は，次に受け継がれません． .. In contrast, Java and Python programmers have some fine mock frameworks, which automate the creation of mocks. As a result, mocking is a proven effective technique and widely adopted practice in those communities. Having the right tool absolutely makes the difference. これとは対照的に，Java と Python のプログラマには，モックの作成を自動化してくれる良いモックフレームワークがあります．よって，モック化は効率的なテクニックで，これらのコミュニティでは広く受け入れられた習慣となっています．適切な道具を得ることが非常に重要なのです． .. Google Mock was built to help C++ programmers. It was inspired by jMock and EasyMock, but designed with C++'s specifics in mind. It is your friend if any of the following problems is bothering you: Google Mock は，C++ プログラマ達を助けるために作られました．これは `jMock `_ や `EasyMock `_ に着想を得たものですが，C++ の仕様を考慮して設計されています．次のような問題で悩んでいるならば，これが役に立つでしょう： .. You are stuck with a sub-optimal design and wish you had done more prototyping before it was too late, but prototyping in C++ is by no means "rapid". .. Your tests are slow as they depend on too many libraries or use expensive resources (e.g. a database). .. Your tests are brittle as some resources they use are unreliable (e.g. the network). .. You want to test how your code handles a failure (e.g. a file checksum error), but it's not easy to cause one. .. You need to make sure that your module interacts with other modules in the right way, but it's hard to observe the interaction; therefore you resort to observing the side effects at the end of the action, which is awkward at best. .. You want to "mock out" your dependencies, except that they don't have mock implementations yet; and, frankly, you aren't thrilled by some of those hand-written mocks. * 準最適化設計で行き詰まり，手遅れになる前にもっとプロトタイピングをしていれば，と後悔している．しかし，C++ でのプロトタイピングは決して「早く」ない． * 多くのライブラリに依存しすぎて，またはコストの高いリソース（例えば，データベース）を使用しているせいで，テストが遅い． * 使用しているリソースの信頼性が低い（例えば，ネットワーク）せいで，テストが不安定である． * プログラムが失敗（例えば，チェックサムエラー）をどのように処理するかのテストをしたいが，それを起こすのが難しい． * モジュール間のインタフェースが正しいことを確認する必要があるが，そのインタラクションを観測するのは大変なので，つい動作終了時の副作用結果を観測するだけ，という不恰好な方法で済ませてしまう． * 依存対象の「モック」を作成したいが，モックの実装はやりたくない．正直に言って，モックを手書きする作業はつまらない． .. We encourage you to use Google Mock as: 以下に，Google Mock のお勧め利用方法を示します： .. a design tool, for it lets you experiment with your interface design early and often. More iterations lead to better designs! .. a testing tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators. * デザインツールとして利用すれば，インタフェースデザインの実験を初期段階で何度も行うことができます．多く使い込むほどに良いデザインになります． * テストツールとして利用すれば，外部依存関係を切り離し，自分のモジュールと相手とのやり取りを徹底的に検証できます． .. Getting Started .. _fordummies_getting_started: はじめ方 ===== .. Using Google Mock is easy! Inside your C++ source file, just #include "gtest/gtest.h" and "gmock/gmock.h", and you are ready to go. Google Mock を使うのは簡単です！C++ ソースファイル内で， "gtest/gtest.h" と "gmock/gmock.h" を #include するだけで準備は終わりです． .. A Case for Mock Turtles .. _fordummies_a_case_for_mock_turtles: Mock Turtles の場合 ============= .. Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, Turtle) and code to that interface: さて，例を見ていきましょう． LOGO 風の描画用 API を使ったグラフィックプログラムを開発しているとします．これの動作が正しいかどうかを，どうやってテストすればよいのでしょうか？プログラムを実行して，その結果を検証用のスナップショット画像と比較することもできますが，そのようなテスト方法は，実行コストが高く不安定であることを認識してください（優れたアンチエイリアス機能を持つ新品のグラフィックカードにアップグレードしたら？それだけで，検証用の全ファイルを更新する必要ができてしまいます）．全てのテストをこのように行うのは，辛すぎる作業かもしれませんが，幸いにも，あなたは依存性の注入について学び，その実現方法を知っています：つまり，アプリケーションが描画用 API を直接叩く代わりに API をインタフェース（これを，Turtle と呼びましょう）でラップして，このインタフェースに対するコードを書きます． .. code-block:: c class Turtle { ... virtual ~Turtle() {} virtual void PenUp() = 0; virtual void PenDown() = 0; virtual void Forward(int distance) = 0; virtual void Turn(int degrees) = 0; virtual void GoTo(int x, int y) = 0; virtual int GetX() const = 0; virtual int GetY() const = 0; }; .. (Note that the destructor of Turtle must be virtual, as is the case for all classes you intend to inherit from - otherwise the destructor of the derived class will not be called when you delete an object through a base pointer, and you'll get corrupted program states like memory leaks.) （Turtle のデストラクタは， **必ず** virtual であることを注意してください．これは，ここから派生する **全て** のクラスでも同様です．そうしなければ，基底クラス型のポインタを介してオブジェクトを削除した場合に，派生クラスのデストラクタが呼ばれなくなり，メモリリークのような状態に陥るでしょう．） .. You can control whether the turtle's movement will leave a trace using PenUp() and PenDown(), and control its movement using Forward(), Turn(), and GoTo(). Finally, GetX() and GetY() tell you the current position of the turtle. PenUp() と PenDown() を利用して，turtle が移動の軌跡を残すか否かを制御できます．また，Forward() ，Turn() ，そして GoTo() を使って，それ自身の移動を制御できます．そして，GetX() と GetY() によって turtle の現在位置が分かります． .. Your program will normally use a real implementation of this interface. In tests, you can use a mock implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run much, much faster. 普段のプログラムでは，このインタフェースを本当に実装したものを利用するでしょう．テストでは，代わりにモック実装を利用します．これにより，どの描画プリミティブがプログラムから呼び出されたか，引数は何か，順番はどうか，といったチェックを簡単に行うことができます．このように書かれたテストは，非常にロバスト（マシンのアンチエイリアスが変化したせいで破綻したりはしません）で，解読とメンテナンスが容易（テストの目的は，画像ファイルではなくコードで表現されます），そして，テストの実施が各段に高速です． .. Writing the Mock Class .. _fordummies_writing_mock_class: モッククラスを書く ======================== .. If you are lucky, the mocks you need to use have already been implemented by some nice people. If, however, you find yourself in the position to write a mock class, relax - Google Mock turns this task into a fun game! (Well, almost.) 運が良ければ，だれか親切な人が，あなたが必要としているモックを既に書いているかもしれません．しかし，あなたが自分でモッククラスを書かなければいけないとしても，大丈夫，落ち着いてください．Gogle Mock にかかれば，この作業も楽しいゲーム（みたいなもの）に変わります． .. How to Define It .. _fordummies_how_to_define: どうやって定義するか ---------------------------------------- .. Using the Turtle interface as example, here are the simple steps you need to follow: Turtle インタフェースを例に考えてみましょう．ステップを簡単に示すと以下のようになります： .. Derive a class MockTurtle from Turtle. .. Take a virtual function of Turtle (while it's possible to mock non-virtual methods using templates, it's much more involved). Count how many arguments it has. .. In the public: section of the child class, write MOCK_METHODn(); (or MOCK_CONST_METHODn(); if you are mocking a const method), where n is the number of the arguments; if you counted wrong, shame on you, and a compiler error will tell you so. .. Now comes the fun part: you take the function signature, cut-and-paste the function name as the first argument to the macro, and leave what's left as the second argument (in case you're curious, this is the type of the function). .. Repeat until all virtual functions you want to mock are done. #. Turtle から MockTurtle クラスを派生させます． #. Trutle の仮想関数（テンプレートを利用して非仮想関数をモック化することも可能ですが，かなり複雑です）を調べて，引数の数を数えます． #. 派生クラスの public セクションに，MOCK_METHODn();（const メソッドをモック化する場合は， MOCK_CONST_METHODn();）を書きます．ここで n は，引数の数を表しますが，これを数え間違えると，コンパイルエラーで注意されます． #. ここが楽しい箇所です：関数のシグネチャを調べて，その関数名をマクロの1番目の引数に，残りを2番目の引数にします（念のため書いておくと，これが関数の型です）． #. これを，モック化したい仮想関数全てに対して繰り返します． .. After the process, you should have something like: この処理が終わると，次のようになっているでしょう： .. code-block:: c #include "gmock/gmock.h" // Google Mock はこのヘッダに． class MockTurtle : public Turtle { public: ... MOCK_METHOD0(PenUp, void()); MOCK_METHOD0(PenDown, void()); MOCK_METHOD1(Forward, void(int distance)); MOCK_METHOD1(Turn, void(int degrees)); MOCK_METHOD2(GoTo, void(int x, int y)); MOCK_CONST_METHOD0(GetX, int()); MOCK_CONST_METHOD0(GetY, int()); }; .. You don't need to define these mock methods somewhere else - the MOCK_METHOD* macros will generate the definitions for you. It's that simple! Once you get the hang of it, you can pump out mock classes faster than your source-control system can handle your check-ins. これらのモックメソッドを別の場所に書く必要はありません．MOCK_METHOD* マクロが，定義を生成してくれます．簡単ですね！一度コツが分かれば，ソース管理システムがチェックインを処理するよりも早く，モッククラスを作れるようになります． .. Tip: If even this is too much work for you, you'll find the gmock_gen.py tool in Google Mock's scripts/generator/ directory (courtesy of the cppclean project) useful. This command-line tool requires that you have Python 2.4 installed. You give it a C++ file and the name of an abstract class defined in it, and it will print the definition of the mock class for you. Due to the complexity of the C++ language, this script may not always work, but it can be quite handy when it does. For more details, read the user documentation. **ヒント：** これでも大変過ぎるというあなたのために，Google Mock の scripts/generator/ ディレクトリに gmock_gen.py という便利なツールが用意してあります（ `cppclean `_ プロジェクトからの好意によります）．このコマンドラインツールを使うには，Python 2.4 のインストールが必要です．このツールに，C++ ファイルと，そこで定義される抽象クラス名を与えると，モッククラスの定義が出力されます．C++ は複雑な言語なので，このスクリプトは常に完全に動作するわけではありませんが，動けば非常に便利なものです．詳細は， `ユーザドキュメント `_ を参照してください． .. Where to Put It .. _fordummies_where_to_put_it: どこに書くか -------------------------- .. When you define a mock class, you need to decide where to put its definition. Some people put it in a *_test.cc. This is fine when the interface being mocked (say, Foo) is owned by the same person or team. Otherwise, when the owner of Foo changes it, your test could break. (You can't really expect Foo's maintainer to fix every test that uses Foo, can you?) モッククラスを定義する場合，その定義をどこに書くかを決める必要があります．これを *_test.cc に書く人達もいます．同じ人や同じチームが，モック化されているインタフェース（ Foo とします）も所有しているならば，これは良い方法です．しかし，そうでない場合，Foo の所有者がそれを変更してしまうと，あなたのテストが破綻する可能性があります（Foo のメンテナが， Foo を利用しているあらゆるテストを修正してくれる，とは期待できませんよね？）． .. So, the rule of thumb is: if you need to mock Foo and it's owned by others, define the mock class in Foo's package (better, in a testing sub-package such that you can clearly separate production code and testing utilities), and put it in a mock_foo.h. Then everyone can reference mock_foo.h from their tests. If Foo ever changes, there is only one copy of MockFoo to change, and only tests that depend on the changed methods need to be fixed. そこで，大まかなルールを次のように決めます：他人の所有する Foo をモック化する必要がある場合，Foo パッケージの中でモッククラスを定義して（製品版コードとテストユーティリティを確実に分離できるように，テスト用サブパッケージ内で定義するとさらに良いでしょう），mock_foo.h 内にこれを含めます．そうすると，各テストから mock_foo.h を参照できます．Foo が変更されても，1つの MockFoo と，変更されたメソッドに依存するテストだけを修正すれば良いことになります． .. Another way to do it: you can introduce a thin layer FooAdaptor on top of Foo and code to this new interface. Since you own FooAdaptor, you can absorb changes in Foo much more easily. While this is more work initially, carefully choosing the adaptor interface can make your code easier to write and more readable (a net win in the long run), as you can choose FooAdaptor to fit your specific domain much better than Foo does. 別の方法：Foo の上に乗せる薄いレイヤー FooAdaptor を導入して，この新しいインタフェースに対するコードを書きます．この FooAdaptor の所有者は自分なので，Foo の変更をより簡単に吸収することができます．導入コストは少し高いですが，特定の目的に対して Foo よりも適切な FooAdaptor を選択することができるので，アダプタインタフェースを慎重に選択するとコーディングがより簡単になり，可読性も向上します（長期的に見れば利点のほうが多いでしょう）． .. Using Mocks in Tests .. _fordummies_using_mocks_in_tests: テストでモックを使う ============= .. Once you have a mock class, using it is easy. The typical work flow is: モッククラスが用意できたら，使うのは簡単です．典型的な手順は，次のようになります： .. Import the Google Mock names from the testing namespace such that you can use them unqualified (You only have to do it once per file. Remember that namespaces are a good idea and good for your health.). .. Create some mock objects. .. Specify your expectations on them (How many times will a method be called? With what arguments? What should it do? etc.). .. Exercise some code that uses the mocks; optionally, check the result using Google Test assertions. If a mock method is called more than expected or with wrong arguments, you'll get an error immediately. .. When a mock is destructed, Google Mock will automatically check whether all expectations on it have been satisfied. #. モックを制限無く利用できるように，Google Mock の名前をテスト用の名前空間からインポートします（各ファイルで1度だけ必要です．名前空間は優れたアイディアであることをお忘れなく）． #. モックオブジェクトを作成します． #. その Expectation を設定します（メソッドが何回呼ばれるのか？引数は何か？何を行うのか？など）． #. モックを利用したコードを実行します．Google Test のアサーションを利用して結果のチェックを行っても良いでしょう．モックメソッドが期待よりも多く呼び出される，または引数が誤っている，などの場合は，即座にエラーが起こります． #. モックがデストラクトされると，その全ての Expectation が満足されたかどうかを Google Mock が自動的に検証します． .. Here's an example: 以下に例を示します： .. code-block:: c #include "path/to/mock-turtle.h" #include "gmock/gmock.h" #include "gtest/gtest.h" using ::testing::AtLeast; // #1 TEST(PainterTest, CanDrawSomething) { MockTurtle turtle; // #2 EXPECT_CALL(turtle, PenDown()) // #3 .Times(AtLeast(1)); Painter painter(&turtle); // #4 EXPECT_TRUE(painter.DrawCircle(0, 0, 10)); } // #5 int main(int argc, char** argv) { // 以下の行は，テスト開始前に Google Mock （と Google Test） // を初期化するために必ず実行する必要があります． ::testing::InitGoogleMock(&argc, argv); return RUN_ALL_TESTS(); } .. As you might have guessed, this test checks that PenDown() is called at least once. If the painter object didn't call this method, your test will fail with a message like this: 想像通りかもしれませんが，これは PenDown() が少なくとも1度は呼ばれることをチェックするテストです．もし描画オブジェクトがこのメソッドを呼び出さなければ，テストは失敗し，次のようなメッセージを出力します :: path/to/my_test.cc:119: Failure Actual function call count doesn't match this expectation: Actually: never called; Expected: called at least once. .. Tip 1: If you run the test from an Emacs buffer, you can hit on the line number displayed in the error message to jump right to the failed expectation. **ヒント1：** Emacs のバッファからテストを実行している場合，エラーメッセージに表示された行番号上で を押して，失敗した Expectation の場所に飛ぶことができます． .. Tip 2: If your mock objects are never deleted, the final verification won't happen. Therefore it's a good idea to use a heap leak checker in your tests when you allocate mocks on the heap. **ヒント2：** もしモックオブジェクトが削除されなければ，最終的な検証作業が行われません．モックをヒープ上に確保する場合，テスト内でヒープリークチェッカーを使うのは良いアイディアです． .. Important note: Google Mock requires expectations to be set before the mock functions are called, otherwise the behavior is undefined. In particular, you mustn't interleave EXPECT_CALL()s and calls to the mock functions. **重要な注意事項：** Google Mock では，モック関数が呼び出される前に Expectation が設定されている必要があります．そうでない場合の挙動は未定義となります．特に，EXPECT_CALL() とモック関数の呼び出しをごちゃ混ぜにするのは，決してやってはいけません． .. This means EXPECT_CALL() should be read as expecting that a call will occur in the future, not that a call has occurred. Why does Google Mock work like that? Well, specifying the expectation beforehand allows Google Mock to report a violation as soon as it arises, when the context (stack trace, etc) is still available. This makes debugging much easier. この EXPECT_CALL() は，既に起こった呼び出しではなく，将来的に起こる呼び出しに対して期待する動作，と見るべきものです．Google Mock は，何故このような動作になっているのでしょうか？Expectation を予め決めておくことで，Google Mock は違反が起こったら即座に，つまり（スタックトレース，などの）コンテキストがまだ有効な状態で，それを報告することができます．これにより，デバッグが非常にやりやすくなります． .. Admittedly, this test is contrived and doesn't do much. You can easily achieve the same effect without using Google Mock. However, as we shall reveal soon, Google Mock allows you to do much more with the mocks. 正直なところ，このテストは不自然で，たいした仕事をしません．Google Mock 無しでも同様のことが簡単にできます．しかし，この後すぐに分かるように，Google Mock を使うことで，モックを利用してさらに多くのことができます． .. Using Google Mock with Any Testing Framework .. _fordummies_using_gmock_with_any_testing_framework: 任意の Testing Framework で Google Mock を利用する ================================ .. If you want to use something other than Google Test (e.g. CppUnit or CxxTest) as your testing framework, just change the main() function in the previous section to: Testing Framework として Google Test 以外のもの（例えば， CppUnito や CxxTest）を使いたい場合，上述のセクションの main() 関数を次のように変更するだけです： .. code-block:: c int main(int argc, char** argv) { // 以下の行で，Google Mock が失敗した場合に， // Testing Framework にテスト失敗と解釈される例外を投げるようにします． ::testing::GTEST_FLAG(throw_on_failure) = true; ::testing::InitGoogleMock(&argc, argv); // ... あなたのテストフレームワークで必要な処理を書きます ... } .. This approach has a catch: it makes Google Mock throw an exception from a mock object's destructor sometimes. With some compilers, this sometimes causes the test program to crash. You'll still be able to notice that the test has failed, but it's not a graceful failure. この方法には問題があります：Google Mock は，モックオブジェクトのデストラクタから時々例外を投げるようになります．コンパイラによっては，これによってテストプログラムが時々クラッシュします．テストの失敗に気づくことは可能ですが，綺麗な失敗ではありません． .. A better solution is to use Google Test's event listener API to report a test failure to your testing framework properly. You'll need to implement the OnTestPartResult() method of the event listener interface, but it should be straightforward. より良い方法は，Google Test のイベントリスナー API を利用して，テストの失敗を Testing Framework に適切に伝えることです．イベントリスナーインタフェースの OnTestPartResult() メソッドを実装する必要がありますが，それは単純な作業です． .. If this turns out to be too much work, we suggest that you stick with Google Test, which works with Google Mock seamlessly (in fact, it is technically part of Google Mock.). If there is a reason that you cannot use Google Test, please let us know. この作業が大変すぎると思うならば，やはり Google Mock （厳密に言えば，Google Mock の一部）とシームレスに動作する Google Test を使うことを勧めます．もし Google Test を利用できない理由があるならば，我々に連絡してください． .. Setting Expectations .. _fordummies_setting_expectations: Expectation を設定する ============== .. The key to using a mock object successfully is to set the right expectations on it. If you set the expectations too strict, your test will fail as the result of unrelated changes. If you set them too loose, bugs can slip through. You want to do it just right such that your test can catch exactly the kind of bugs you intend it to catch. Google Mock provides the necessary means for you to do it "just right." モックオブジェクトをうまく利用するためには，適切な Expectation を設定することが重要です．Expectation を厳しくしすぎると，関係ない変更からも影響を受けてテストが失敗します．逆に Expectation を緩くしすぎると，バグが入り込みます．意図したバグを正確にキャッチできるように，テストが丁度良く動作してほしいことでしょう．Google Mock は，この「丁度良い」動作に必要な手段を提供します． .. General Syntax .. _fordummies_general_syntax: 一般的な構文 ---------------- .. In Google Mock we use the EXPECT_CALL() macro to set an expectation on a mock method. The general syntax is: Google Mock では，モックメソッドの Expectation を設定するために EXPECT_CALL() マクロを使います．一般的な構文は次のようになります： .. code-block:: c EXPECT_CALL(mock_object, method(matchers)) .Times(cardinality) .WillOnce(action) .WillRepeatedly(action); .. The macro has two arguments: first the mock object, and then the method and its arguments. Note that the two are separated by a comma (,), not a period (.). (Why using a comma? The answer is that it was necessary for technical reasons.) このマクロには2つの引数があります：1番目はモックオブジェクトで，2番目はメソッドと引数です．これらは，ピリオド（.）ではなくカンマ（,）で区切られていることに注意してください（何故カンマを利用するのか？技術的な理由，というのがその答えです）． .. The macro can be followed by some optional clauses that provide more information about the expectation. We'll discuss how each clause works in the coming sections. マクロに，Expectation に関する情報を与える節を追加することもできます．それぞれの節の働きについては，以降のセクションで議論することにします． .. This syntax is designed to make an expectation read like English. For example, you can probably guess that この構文は，Expectation が英語のように読めるように設計されています．例えば，次のようになっているとしましょう： .. code-block:: c using ::testing::Return;... EXPECT_CALL(turtle, GetX()) .Times(5) .WillOnce(Return(100)) .WillOnce(Return(150)) .WillRepeatedly(Return(200)); .. says that the turtle object's GetX() method will be called five times, it will return 100 the first time, 150 the second time, and then 200 every time. Some people like to call this style of syntax a Domain-Specific Language (DSL). turtle オブジェクトの GetX() メソッドが5回呼ばれ，最初は 100 を返し，次に 150，それ以降は 200 を返す，ということが想像できます．このような構文スタイルを，ドメイン固有言語（DSL）と呼ぶ人もいます． .. Note: Why do we use a macro to do this? It serves two purposes: first it makes expectations easily identifiable (either by grep or by a human reader), and second it allows Google Mock to include the source file location of a failed expectation in messages, making debugging easier. **注意：** このようなことを行うのにマクロを利用しているのは何故でしょうか？これには2つの目的があります：1番目の目的は，（grep や 人間の読み手が）Expectation を簡単に識別できるようにすることです．そして2番目の目的は，Google Mock のメッセージに，失敗した Expectation がソースファイルのどこにあるかを含められるようにして，デバッグを簡単にすることです． .. Matchers: What Arguments Do We Expect? .. _fordummies_matchers: Matchers：期待する引数は何か？ ---------------------------------------- .. When a mock function takes arguments, we must specify what arguments we are expecting; for example: 引数を持つモック関数の場合，期待する引数を指定しなければいけません．例えば次のようになります． .. code-block:: c // turtle が100単位 前進することを期待します． EXPECT_CALL(turtle, Forward(100)); .. Sometimes you may not want to be too specific (Remember that talk about tests being too rigid? Over specification leads to brittle tests and obscures the intent of tests. Therefore we encourage you to specify only what's necessary - no more, no less.). If you care to check that Forward() will be called but aren't interested in its actual argument, write _ as the argument, which means "anything goes": 具体的過ぎる指定をしたくない場合もあるでしょう（テストが厳格すぎるかどうか，について述べていることに注意してください．過剰な指定は，テストを不安定に，テストの意図を不明確にします．よって，必要十分な指定のみを行うことをお勧めします）．Forward() が呼ばれるかどうかだけをチェックしたく，実際の引数には関心がないならば，引数には「何でも良い」を意味する _ を書いてください． .. code-block:: c using ::testing::_; ... // turtle が前進することを期待します． EXPECT_CALL(turtle, Forward(_)); .. _ is an instance of what we call matchers. A matcher is like a predicate and can test whether an argument is what we'd expect. You can use a matcher inside EXPECT_CALL() wherever a function argument is expected. _ は，matcher と呼ばれるもののインスタンスです．matcher は述語関数と同じように，引数が期待したものかどうかをテストするために利用できます．matcher は，EXPECT_CALL() 内部で，引数をとる関数が書かれてる場所でならどこでも利用できます． .. A list of built-in matchers can be found in the CheatSheet. For example, here's the Ge (greater than or equal) matcher: 組み込みの matcher 一覧は， :ref:`cheatsheet` にあります．ここでは，例として Ge（greater than or equal：以上） matcher を使ってみます： .. code-block:: c using ::testing::Ge;... EXPECT_CALL(turtle, Forward(Ge(100))); .. This checks that the turtle will be told to go forward by at least 100 units. これは，turtle が最低でも100単位前進するように命令されたことをチェックします． .. Cardinalities: How Many Times Will It Be Called? .. _fordummies_cardinality: Cardinalities：何回呼ばれるか？ --------------------------------------- .. The first clause we can specify following an EXPECT_CALL() is Times(). We call its argument a cardinality as it tells how many times the call should occur. It allows us to repeat an expectation many times without actually writing it as many times. More importantly, a cardinality can be "fuzzy", just like a matcher can be. This allows a user to express the intent of a test exactly. EXPECT_CALL() の後ろに指定できる最初の節は，Times() です．この引数は，呼び出しが何回起こるかを説明するものなので，これを **cardinality** と呼びます．これを利用すると，実際に何度も書かなくても Expectation を繰り返すことができます．さらに重要なのは，ardinality は matcher と同じように「あいまい」な表現ができるということです．これによって，ユーザはテストの意図を正確に表現できます． .. An interesting special case is when we say Times(0). You may have guessed - it means that the function shouldn't be called with the given arguments at all, and Google Mock will report a Google Test failure whenever the function is (wrongfully) called. Times(0) は，興味深い特別なケースです．想像がつくかもしれませんが…．この場合，関数は 1 度も呼ばれるべきではないので，関数が（不当にも）呼び出されると，Google Mock が Google Test に失敗を報告します． .. We've seen AtLeast(n) as an example of fuzzy cardinalities earlier. For the list of built-in cardinalities you can use, see the CheatSheet. あいまいな cardinality の例としては，先ほど AtLeast(n) を見ました．組み込みの cardinality の一覧は， :ref:`cheatsheet` にあります． .. The Times() clause can be omitted. If you omit Times(), Google Mock will infer the cardinality for you. The rules are easy to remember: Times() 節は，省略することができます． **Times() が省略されると， Google Mock は cardinality を推定します．** そのルールは，覚えやすいものです： .. If neither WillOnce() nor WillRepeatedly() is in the EXPECT_CALL(), the inferred cardinality is Times(1). .. If there are n WillOnce()'s but no WillRepeatedly(), where n >= 1, the cardinality is Times(n). .. If there are n WillOnce()'s and one WillRepeatedly(), where n >= 0, the cardinality is Times(AtLeast(n)). * WillOnce() または WillRepeatedly() の **どちらも** EXPECT_CALL() に **含まれない** 場合，推定される carinality は Times(1) です． * WillOnce() が n 個（ここで n >= 1）あり，WillRepeatedly() が **ない** 場合，cardinality は Times(n) です． * WillOnce() が n 個（ここで n >= 0）あり，WillRepeatedly() も **1つある** 場合，cardinality は Times(Atleast(n)) です． .. Quick quiz: what do you think will happen if a function is expected to be called twice but actually called four times? **確認クイズ：** 2回の呼び出しが期待されている関数が，実際には4回呼び出されると何が起こると思いますか？ .. Actions: What Should It Do? .. _fordummies_actions: Actions：何をするべきなのか？ ------------------------------------- .. Remember that a mock object doesn't really have a working implementation? We as users have to tell it what to do when a method is invoked. This is easy in Google Mock. モックオブジェクトは，実際に動作する実装を持っているわけではないことを忘れないでください．ユーザは，メソッドが呼び出されたときに何をすればよいのかを指示する必要があります．Google Mock では，これを簡単に行えます． .. First, if the return type of a mock function is a built-in type or a pointer, the function has a default action (a void function will just return, a bool function will return false, and other functions will return 0). If you don't say anything, this behavior will be used. まず，モック関数の戻り値の型が，組み込み型またはポインタである場合，関数の動作はデフォルト Action（void 関数は，単に関数から戻るだけです．bool 関数は false を返し，その他の関数は 0 を返します．）になります．特に指定しない場合，この動作が利用されます． .. Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of WillOnce() clauses followed by an optional WillRepeatedly(). For example, 次に，モック関数がデフォルト Action を持たない場合，またはデフォルト Action では問題がある場合，WillOnce() 節の連続（ WillRepeatedly() がその後ろに続く場合もあります）を利用して，Expectation がマッチするたびに起こされる Action を指定できます． .. code-block:: c using ::testing::Return;... EXPECT_CALL(turtle, GetX()) .WillOnce(Return(100)) .WillOnce(Return(200)) .WillOnce(Return(300)); .. This says that turtle.GetX() will be called exactly three times (Google Mock inferred this from how many WillOnce() clauses we've written, since we didn't explicitly write Times()), and will return 100, 200, and 300 respectively. この場合， turtle.GetX() が丁度3回（Time() 明示されていないので，Google Mock は WillOnce() 節が書かれた回数から，これを推定します）呼び出され，100，200，300 がそれぞれ返されます． .. code-block:: c using ::testing::Return;... EXPECT_CALL(turtle, GetY()) .WillOnce(Return(100)) .WillOnce(Return(200)) .WillRepeatedly(Return(300)); .. says that turtle.GetY() will be called at least twice (Google Mock knows this as we've written two WillOnce() clauses and a WillRepeatedly() while having no explicit Times()), will return 100 the first time, 200 the second time, and 300 from the third time on. この場合， turtle.GetY() が最低でも2回（Times() が明示されず，2つの WillOnce() 節と1つの WillRepeatedly() が書かれているので，Google Mock の推定値はこうなります）呼び出され，最初は 100 ，2回目は 200 ，それ以降は 300 が返されます． .. Of course, if you explicitly write a Times(), Google Mock will not try to infer the cardinality itself. What if the number you specified is larger than there are WillOnce() clauses? Well, after all WillOnce()s are used up, Google Mock will do the default action for the function every time (unless, of course, you have a WillRepeatedly().). もちろん，Times() を明示すれば， Google Mock は cardinality を推定しようとはしません．指定した数が，WillOnce() 節の数よりも多い場合はどうなるでしょう？WillOnce() が使い切られた後，Google Mock は 関数のデフォルトアクションを毎回実行します（もちろん，WillRepeatedly() がある場合は除きます）． .. What can we do inside WillOnce() besides Return()? You can return a reference using ReturnRef(variable), or invoke a pre-defined function, among others. WillOnce() 内部では， Return() 以外に何ができるのでしょうか？例えば，ReturnRef(variable) を利用して参照を返したり，事前に定義された関数を呼び出し :ref:`たり ` することができます． .. Important note: The EXPECT_CALL() statement evaluates the action clause only once, even though the action may be performed many times. Therefore you must be careful about side effects. The following may not do what you want: **重要な注意：** Action は何回も実行されるかもしれませんが，EXPECT_CALL() 文は，Action 節を1度だけ評価します．したがって，副作用には十分に注意しなければいけません．例えば，以下のようにすると期待する動作にはならないでしょう： .. code-block:: c int n = 100; EXPECT_CALL(turtle, GetX()) .Times(4) .WillOnce(Return(n++)); .. Instead of returning 100, 101, 102, ..., consecutively, this mock function will always return 100 as n++ is only evaluated once. Similarly, Return(new Foo) will create a new Foo object when the EXPECT_CALL() is executed, and will return the same pointer every time. If you want the side effect to happen every time, you need to define a custom action, which we'll teach in the CookBook. n++ は1度しか評価されないので，モック関数は常に 100 を返し，100，101，102 が連続して返されることはありません． 同様に， Return(new Foo) とすると，EXPECT_CALL() 実行時に Foo オブジェクトが作成され，同じポインタが毎回返されることになります． 副作用が毎回起こるようにしたいならば，カスタム Action を定義する必要があります．これについては， :ref:`クックブック ` で説明します． .. Time for another quiz! What do you think the following means? さてもう一度クイズの時間です！次のコードはどういう意味でしょうか？ .. code-block:: c using ::testing::Return;... EXPECT_CALL(turtle, GetY()) .Times(4) .WillOnce(Return(100)); .. Obviously turtle.GetY() is expected to be called four times. But if you think it will return 100 every time, think twice! Remember that one WillOnce() clause will be consumed each time the function is invoked and the default action will be taken afterwards. So the right answer is that turtle.GetY() will return 100 the first time, but return 0 from the second time on, as returning 0 is the default action for int functions. turtle.GetY() が4回呼ばれることが期待されているのは明らかです．しかし，そこで毎回 100 が返されると思った人，もう一度考えてみてください．関数が呼び出されるたびに1つの WillOnce() 節が消費され，その後はデフォルト Action が実行されます．つまり， turtle.GetY() は最初に 100 を返し，2回目からは 0 が返される，というのが正解です．int 関数のデフォルト Action が 0 を返すことだからです． .. Using Multiple Expectations .. _fordummies_using_multiple_expectations: 複数の Expectation を利用する ------------------------------------- .. So far we've only shown examples where you have a single expectation. More realistically, you're going to specify expectations on multiple mock methods, which may be from multiple mock objects. 今までは，1つの Expectation を利用する例だけを見てきました．より現実的に考えると，複数のモックオブジェクトにある複数のモックメソッドの Expectation を指定することになります． .. By default, when a mock method is invoked, Google Mock will search the expectations in the reverse order they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example: Google Mock のデフォルトでは，モックメソッドが呼び出されると，引数にマッチするアクティブな Expectation が見つかるまで，定義順とは逆方向に Expectation を探索します（「古いルールは新しいルールに上書きされる」と考えることができます）．マッチした Expectation に，有効な呼び出しが残っていなければ，上限違反による失敗が発生します． .. code-block:: c using ::testing::_;... EXPECT_CALL(turtle, Forward(_)); // #1 EXPECT_CALL(turtle, Forward(10)) // #2 .Times(2); .. If Forward(10) is called three times in a row, the third time it will be an error, as the last matching expectation (#2) has been saturated. If, however, the third Forward(10) call is replaced by Forward(20), then it would be OK, as now #1 will be the matching expectation. もし Forward(10) が3回連続で呼び出されると，最後にマッチする Expectation (#2) は，既に飽和状態なので，3回目の呼び出しはエラーになります．しかし，もし Forward(10) の3回目の呼び出しが Forward(20) となっていたなら，これは #1 にマッチするので問題ありません． .. Side note: Why does Google Mock search for a match in the reverse order of the expectations? The reason is that this allows a user to set up the default expectations in a mock object's constructor or the test fixture's set-up phase and then customize the mock by writing more specific expectations in the test body. So, if you have two expectations on the same method, you want to put the one with more specific matchers after the other, or the more specific rule would be shadowed by the more general one that comes after it. **傍注：** Google Mock は，どうして Expectation を逆順に探索するのでしょうか？こうすることで，ユーザは，モックオブジェクトのコンストラクタ，またはテストフィクスチャの set-up メソッド内でデフォルト Expectation を設定して，テスト本体に，より具体的な Expectation を書いてモックをカスタマイズできるからです．そして同じメソッドに 2つの Expectation がある場合，より具体的な matcher を持つ方を後ろに書くか，より具体的なルールを持つ方を一般的なルールを持つ方の後ろに書きます． .. Ordered vs Unordered Calls .. _fordummies_ordered_vs_unordered: 順序あり呼び出し と 順序なし呼び出し ------------------------------------------------ .. By default, an expectation can match a call even though an earlier expectation hasn't been satisfied. In other words, the calls don't have to occur in the order the expectations are specified. デフォルトでは，前に指定された Expectation が満足されていなくても，後ろで指定された Expectation が呼び出しにマッチできます．別の言い方をすれば，Expectation が指定された順序で呼び出しが起こる必要は無い，ということです． .. Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy: 期待される呼び出しがすべて，ある順序どおりに発生してほしい場合があるかもしれません．Google Mock でこれを実現するのは簡単です： .. code-block:: c using ::testing::InSequence;... TEST(FooTest, DrawsLineSegment) { ... { InSequence dummy; EXPECT_CALL(turtle, PenDown()); EXPECT_CALL(turtle, Forward(100)); EXPECT_CALL(turtle, PenUp()); } Foo(); } .. By creating an object of type InSequence, all expectations in its scope are put into a sequence and have to occur sequentially. Since we are just relying on the constructor and destructor of this object to do the actual work, its name is really irrelevant. InSequence 型のオブジェクトを作ることで，そのスコープ内の全ての Expectation がシーケンスに並び，その順序どおりに呼び出しが発生することが必要になります．実際の動作部分は，このオブジェクトのコンストラクタとデストラクタだけに依存しているので，その名前は何でもかまいません． .. In this example, we test that Foo() calls the three expected functions in the order as written. If a call is made out-of-order, it will be an error. この例では，Foo() が，3つの関数を書かれた順序どおりに呼び出すことをテストします．もし呼び出しの順序が違えば，エラーが起こります． .. (What if you care about the relative order of some of the calls, but not all of them? Can you specify an arbitrary partial order? The answer is ... yes! If you are impatient, the details can be found in the CookBook.) （呼び出し全体の順序ではなく，呼び出しの一部の相対的な順番だけが問題になる場合はどうでしょう？任意の部分の順序を指定することができるのでしょうか？答えは…できます！待ちきれないならば，この詳細は :ref:`クックブック ` に書かれています．） .. All Expectations Are Sticky (Unless Said Otherwise) .. _fordummies_all_expectations_are_sticky: 全ての Expectation は Sticky （そうではないと明示される場合は除外） ------------------------------------------------------------------------------------------------------------------------- .. Now let's do a quick quiz to see how well you can use this mock stuff already. How would you test that the turtle is asked to go to the origin exactly twice (you want to ignore any other instructions it receives)? さて，このモックをどの程度使いこなせるかを測るクイズをしましょう．turtle が原点に向かって進むように，丁度2回命令されたかどうか（その他の命令は全て無視したい）をテストするには，どうすれば良いでしょうか？ .. After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!): 自分で答えを考えてから，下の例と比べてみてください（まず，自分で解いてください．ズルはしないように！）： .. code-block:: c using ::testing::_;... EXPECT_CALL(turtle, GoTo(_, _)) // #1 .Times(AnyNumber()); EXPECT_CALL(turtle, GoTo(0, 0)) // #2 .Times(2); .. Suppose turtle.GoTo(0, 0) is called three times. In the third time, Google Mock will see that the arguments match expectation #2 (remember that we always pick the last matching expectation). Now, since we said that there should be only two such calls, Google Mock will report an error immediately. This is basically what we've told you in the "Using Multiple Expectations" section above. turtle.GoTo(0, 0) が3回呼び出されるとします．3回目の呼び出しで，Google Mock は，その引数が Expectation #2 にマッチするのを検出します（常に，最後にマッチした Expectation が選択されることを忘れないでください）．そのような呼び出しは2回だけ，と期待しているので，Google Mock は即座にエラーを報告します．これが，上述の「 :ref:`fordummies_using_multiple_expectations` 」のセクションで説明した基本的な動作です． .. This example shows that expectations in Google Mock are "sticky" by default, in the sense that they remain active even after we have reached their invocation upper bounds. This is an important rule to remember, as it affects the meaning of the spec, and is different to how it's done in many other mocking frameworks (Why'd we do that? Because we think our rule makes the common cases easier to express and understand.). **この例は，Google Mock の Expectation がデフォルトでは，「sticky」であることを表しています．** つまり，呼び出し回数が上限に達してもアクティブであり続ける，ということを意味します．これは，仕様の意味に影響を与え，他の mocking framework の動作とは異なる部分なので，忘れてはならない重要なルールです． .. Simple? Let's see if you've really understood it: what does the following code say? 簡単ですか？本当に理解したかどうか確認してみましょう：以下のコードの意味は何でしょうか？ .. code-block:: c using ::testing::Return; ... for (int i = n; i > 0; i--) { EXPECT_CALL(turtle, GetX()) .WillOnce(Return(10*i)); } .. If you think it says that turtle.GetX() will be called n times and will return 10, 20, 30, ..., consecutively, think twice! The problem is that, as we said, expectations are sticky. So, the second time turtle.GetX() is called, the last (latest) EXPECT_CALL() statement will match, and will immediately lead to an "upper bound exceeded" error - this piece of code is not very useful! turtle.GetX() が n 回呼び出されて， 10，20，30，…，が連続して返される，と思った人は，もう一度考えてください．問題は，先ほど述べたように Expectation が sticky である，ということです．2回目の turtle.GetX() が呼び出されると，最後（最新）の EXPECT_CALL() 文がマッチし，すぐに「上限超過」エラーが起こります．つまり，このコードはあまり役に立ちません！ .. One correct way of saying that turtle.GetX() will return 10, 20, 30, ..., is to explicitly say that the expectations are not sticky. In other words, they should retire as soon as they are saturated: turtle.GetX() が 10，20，30，…，を返すような正しい方法は，Expectation が sticky ではないことを明示することです．言い方を変えれば，飽和したらすぐに破棄されるべきだ，ということです． .. code-block:: c using ::testing::Return; ... for (int i = n; i > 0; i--) { EXPECT_CALL(turtle, GetX()) .WillOnce(Return(10*i)) .RetiresOnSaturation(); } .. And, there's a better way to do it: in this case, we expect the calls to occur in a specific order, and we line up the actions to match the order. Since the order is important here, we should make it explicit using a sequence: そして，さらに適切な方法があります：この場合，呼び出しが特定の順序で起こることを期待して，マッチする順序に Action を並べます．ここでは順序が重要なので，シーケンスを用いてそれを明示するべきです： .. code-block:: c using ::testing::InSequence; using ::testing::Return; ... { InSequence s; for (int i = 1; i <= n; i++) { EXPECT_CALL(turtle, GetX()) .WillOnce(Return(10*i)) .RetiresOnSaturation(); } } .. By the way, the other situation where an expectation may not be sticky is when it's in a sequence - as soon as another expectation that comes after it in the sequence has been used, it automatically retires (and will never be used to match any call). ところで，Expectation が sticky にならないもう1つの状況は，シーケンスに並んだときです．自分より後ろの Expectation が利用されるとすぐに，それは自動的に破棄されます（どの呼び出しにもマッチしなくなります）． .. Uninteresting Calls .. _fordummies_uninteresting_calls: 不要な呼び出し -------------------------------- .. A mock object may have many methods, and not all of them are that interesting. For example, in some tests we may not care about how many times GetX() and GetY() get called. モックオブジェクトには，多くのメソッドが含まれる場合がありますが，その全てに関心があるわけではありません．例えば，あるテストでは，GetX() や GetY() が何回呼び出されるかを気にする必要がないかもしれません． .. In Google Mock, if you are not interested in a method, just don't say anything about it. If a call to this method occurs, you'll see a warning in the test output, but it won't be a failure. Google Mock では，あるメソッドが不要な場合，何もする必要がありません．そのメソッドが呼び出されると，テストの出力に警告が表示されますが，これは失敗を意味するものではありません． .. What Now? .. _fordummies_what_now: 次のステップ ========== .. Congratulations! You've learned enough about Google Mock to start using it. Now, you might want to join the googlemock discussion group and actually write some tests using Google Mock - it will be fun. Hey, it may even be addictive - you've been warned. おめでとうございます！Google Mock を使い始める準備が整いました．早速， `googlemock `_ ディスカッショングループに参加したい，実際に Google Mock を利用したテストを書いてみたい，と考えるかもしれません．この作業は楽しくて，病み付きになる可能性すらあります．-- ちゃんと忠告しましたよ． .. Then, if you feel like increasing your mock quotient, you should move on to the CookBook. You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss. いろいろなモックを書いたなぁ，と思ったら :ref:`cookbook` を読んでみるべきです．Google Mock の高度な機能を多く学ぶことができ，楽しみがさらに広がります．