.. _advancedguide: ======= 上級ガイド ======= .. Advanced topics on using Google C++ Testing Framework *Google C++ Testing Framework を利用した高度なトピック* * :ref:`adv_more_assertions` * :ref:`adv_explicit_success_and_failure` * :ref:`adv_exception_assertion` * :ref:`adv_predicate_assertions` * :ref:`adv_using_an_existing_boolean_function` * :ref:`adv_using_a_function_that_returns_an_assertionresult` * :ref:`adv_using_a_predicate-formatter` * :ref:`adv_floating-point_comparision` * :ref:`adv_floating-point_macros` * :ref:`adv_floating-point_predicate-format_functions` * :ref:`adv_windows_hresult_assertions` * :ref:`adv_type_assertions` * :ref:`adv_assertion_placement` * :ref:`adv_etaaching_gtest_how_to_print_your_values` * :ref:`adv_death_tests` * :ref:`adv_how_to_write_a_death_test` * :ref:`adv_regular_expression_syntax` * :ref:`adv_how_it_works` * :ref:`adv_death_tests_and_threads` * :ref:`adv_death_test_styles` * :ref:`adv_caveats` * :ref:`adv_using_assertions_in_sub-routines` * :ref:`adv_adding_traces_to_assertions` * :ref:`adv_propagating_fatal_failures` * :ref:`adv_asserting_on_subroutines` * :ref:`adv_checking_for_failures_in_the_current_test` * :ref:`adv_logging_additional_information` * :ref:`adv_sharing_resouces_btw_tests` * :ref:`adv_global_setup_teardown` * :ref:`adv_value_parameterized_tests` * :ref:`adv_how_to_write_value-parameterized_tests` * :ref:`adv_creating_value-parameterized_abstract_tests` * :ref:`adv_typed_tests` * :ref:`adv_type-parameterized_tests` * :ref:`adv_testing_private_code` * :ref:`adv_static_functions` * :ref:`adv_private_class_members` * :ref:`adv_catching_failures` * :ref:`adv_getting_the_current_tests_names` * :ref:`adv_extending_google_test_by_handling_test_events` * :ref:`adv_defining_event_listeners` * :ref:`adv_using_event_listeners` * :ref:`adv_generating_failures_in_listeners` * :ref:`adv_running_test_programs_advanced_options` * :ref:`adv_selecting_tests` * :ref:`adv_listing_test_names` * :ref:`adv_running_a_subset_of_the_tests` * :ref:`adv_temporarily_disabling_tests` * :ref:`adv_temporarily_enabling_disabled_tests` * :ref:`adv_repeating_the_tests` * :ref:`adv_shuffling_the_tests` * :ref:`adv_controlling_thest_output` * :ref:`adv_colored_terminal_output` * :ref:`adv_suppressing_the_elapsed_time` * :ref:`adv_generating_an_xml_report` * :ref:`adv_controlling_how_failures_are_reported` * :ref:`adv_turning_assertion_failures_into_bread-points` * :ref:`adv_disabling_catching_test-thrown-exception` * :ref:`adv_letting_another_testing_framework_drive` * :ref:`adv_fusing_google_test_source_files` * :ref:`adv_where_to_go_from_here` .. Now that you have read Primer and learned how to write tests using Google Test, it's time to learn some new tricks. This document will show you more assertions as well as how to construct complex failure messages, propagate fatal failures, reuse and speed up your test fixtures, and use various flags with your tests. さて，あなたは :ref:`primer` を読み終え，Google Test を使ったテストの書き方が分かったことでしょう．ここでは，今までとは別のアサーション，複雑な失敗メッセージの作成方法，致命的な失敗の伝播方法，テストフィクスチャの再利用と高速化手法，そして，テストで用いる様々なフラグの利用法について解説します． .. More Assertions .. _adv_more_assertions: その他のアサーション ==================== .. This section covers some less frequently used, but still significant, assertions. ここでは，利用頻度は低いですが重要なアサーションを紹介します． .. Explicit Success and Failure .. _adv_explicit_success_and_failure: 明示的な成功と失敗 ---------------------- .. These three assertions do not actually test a value or expression. Instead, they generate a success or failure directly. Like the macros that actually perform a test, you may stream a custom failure message into the them. これら3つのアサーションは，実際には値や式のテストを行いません．その代り，成功や失敗を直接生成します．実際にテストを行うマクロと同じように，これらのアサーションでもユーザ定義の失敗メッセージを利用できます． .. csv-table:: :header: SUCCEED(); .. Generates a success. This does NOT make the overall test succeed. A test is considered successful only if none of its assertions fail during its execution. 成功を生成します．しかし，これはテスト全体を成功させるものでは **ありません** ．テスト実行時に，そこに含まれるすべてのアサーションが失敗しなかった場合にのみ，そのテスト全体が成功したとみなされます． .. Note: SUCCEED() is purely documentary and currently doesn't generate any user-visible output. However, we may add SUCCEED() messages to Google Test's output in the future. *注意* ：SUCCEED() は，書くことができるだけで，ユーザに見える形での出力は一切行いません．しかし，将来的には Google Test の出力に SUCCEED() メッセージを追加する予定です． .. FAIL(); ADD_FAILURE(); ADD_FAILURE_AT("file_path", line_number); .. csv-table:: :header: :widths: 10,15,40 "FAIL();", "ADD_FAILURE();", "ADD_FAILURE_AT(""file_path"", line_number);" .. FAIL() generates a fatal failure, while ADD_FAILURE() and ADD_FAILURE_AT() generate a nonfatal failure. These are useful when control flow, rather than a Boolean expression, deteremines the test's success or failure. For example, you might want to write something like: FAIL() は，致命的な失敗を生成します．一方，ADD_FAILURE() と ADD_FAILURE_AT() は，致命的ではない失敗を生成します．これらは，テストが成功か失敗かを決めるのに，ブール式ではなくプログラムの制御フローを用いる場合に役立ちます． 例えば，次のような書き方をしたい場合があるでしょう： .. code-block:: c switch(expression) { case 1: ... some checks ... case 2: ... some other checks ... default: FAIL() << "We shouldn't get here."; // ここに来てはダメ. } .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Exception Assertions .. _adv_exception_assertion: 例外アサーション ------------------- .. These are for verifying that a piece of code throws (or does not throw) an exception of the given type: これらは，あるコードが，決められた型の例外を投げる（または，投げない）かを検証します． .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_THROW(statement, exception_type); EXPECT_THROW(statement, exception_type); statement throws an exception of the given type .. ASSERT_ANY_THROW(statement); EXPECT_ANY_THROW(statement); statement throws an exception of any type .. ASSERT_NO_THROW(statement); EXPECT_NO_THROW(statement); statement doesn't throw any exception .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,15 "ASSERT_THROW(statement, exception_type);", "EXPECT_THROW(statement, exception_type);", "statement が与えられた型の例外を投げる" "ASSERT_ANY_THROW(statement);", "EXPECT_ANY_THROW(statement);", "statement が任意の型の例外を投げる" "ASSERT_NO_THROW(statement);", "EXPECT_NO_THROW(statement);", "statement が例外を投げない" .. Examples: 例： .. code-block:: c ASSERT_THROW(Foo(5), bar_exception); EXPECT_NO_THROW({ int n = 5; Bar(&n); }); .. Availability: Linux, Windows, Mac; since version 1.1.0. *利用可能な環境：* Linux，Windows，Mac．ただし，バージョン 1.1.0以降． .. Predicate Assertions for Better Error Messages .. _adv_predicate_assertions: エラーメッセージを改善する述語アサーション --------------------------------------------------- .. Even though Google Test has a rich set of assertions, they can never be complete, as it's impossible (nor a good idea) to anticipate all the scenarios a user might run into. Therefore, sometimes a user has to use EXPECT_TRUE() to check a complex expression, for lack of a better macro. This has the problem of not showing you the values of the parts of the expression, making it hard to understand what went wrong. As a workaround, some users choose to construct the failure message by themselves, streaming it into EXPECT_TRUE(). However, this is awkward especially when the expression has side-effects or is expensive to evaluate. Google Test は現在も豊富なアサーションを提供していますが，これが完璧になることはありません．ユーザが遭遇する可能性のある全てのシナリオに備えておくことは不可能ですし，仮にできたとしても，良い考えとは言えません．そのため，このマクロを補うために，ユーザが EXPECT_TRUE() を使って複雑な式を検証しなければならないこともあるでしょう．これには，式の一部の値を見ることができないという問題があり，このせいで問題箇所を特定するのが難しくなります．回避策として，ユーザ自身が失敗メッセージを作り，それを EXPECT_TRUE() の引数に使う，という方法があります．しかし，式に副作用があったり，式の評価が重い処理だった場合，この方法は特に問題になります． .. Google Test gives you three different options to solve this problem: Google Test には，この問題を解決する3つの選択肢があります： .. Using an Existing Boolean Function .. _adv_using_an_existing_boolean_function: 既存のブール関数を利用する ^^^^^^^^^^^^^^^^^ .. If you already have a function or a functor that returns bool (or a type that can be implicitly converted to bool), you can use it in a predicate assertion to get the function arguments printed for free: bool値（または暗黙の型変換でbool値にできる型）を返す関数またはファンクタが既にある場合，それを述語アサーションに与えるだけで，関数の引数を表示できます． .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_PRED1(pred1, val1); EXPECT_PRED1(pred1, val1); pred1(val1) returns true .. ASSERT_PRED2(pred2, val1, val2); EXPECT_PRED2(pred2, val1, val2); pred2(val1, val2) returns true .. ... ... ... .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,15 "ASSERT_PRED1(pred1, val1);", "EXPECT_PRED1(pred1, val1);", "pred1(val1) が true を返す" "ASSERT_PRED2(pred2, val1, val2);", "EXPECT_PRED2(pred2, val1, val2);", "pred2(val1, val2) が true を返す" "...", "...", "..." .. In the above, predn is an n-ary predicate function or functor, where val1, val2, ..., and valn are its arguments. The assertion succeeds if the predicate returns true when applied to the given arguments, and fails otherwise. When the assertion fails, it prints the value of each argument. In either case, the arguments are evaluated exactly once. 上述の predn は n 個の引数を取る述語関数またはファンクタで，val1, val2, ..., valn が引数を表します．指定した引数を与えられた述語（関数）が true の場合，アサーションは成功します．そうでない場合は失敗します．アサーションが失敗すると，引数が表示されます．いずれの場合も，引数は1度だけ評価されます． .. Here's an example. Given 例を示します．例えば，以下が与えられたとしましょう． .. // Returns true iff m and n have no common divisors except 1. .. bool MutuallyPrime(int m, int n) { ... } .. const int a = 3; .. const int b = 4; .. const int c = 10; .. code-block:: c // m と n が互いに素な場合のみ true を返します bool MutuallyPrime(int m, int n) { ... } const int a = 3; const int b = 4; const int c = 10; .. the assertion EXPECT_PRED2(MutuallyPrime, a, b); will succeed, while the assertion EXPECT_PRED2(MutuallyPrime, b, c); will fail with the message アサーション EXPECT_PRED2(MutuallyPrime, a, b); は成功しますが，EXPECT_PRED2(MutuallyPrime, b, c); は失敗して次のようなメッセージを出力します． .. MutuallyPrime(b, c) is false, where .. b is 4 .. c is 10 :: MutuallyPrime(b, c) is false, where b is 4 c is 10 .. Notes: **注意** ： .. If you see a compiler error "no matching function to call" when using ASSERT_PRED* or EXPECT_PRED*, please see this for how to resolve it. .. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know. #. ASSERT_PRED* または EXPECT_PRED* を利用した際に "no matching function to call" というコンパイルエラーがでる問題を解決するには， :ref:`FAQ` を参照してください． #. 現在用意されているのは，引数 5 個以下の述語アサーションのみです．さらに多くの引数を取る必要があれば，我々に知らせてください． .. Availability: Linux, Windows, Mac *利用可能な環境：* Linux，Windows，Mac． .. Using a Function That Returns an AssertionResult .. _adv_using_a_function_that_returns_an_assertionresult: AssertionResult を返す関数を利用する ^^^^^^^^^^^^^^^^^^^^^^^ .. While EXPECT_PRED*() and friends are handy for a quick job, the syntax is not satisfactory: you have to use different macros for different arities, and it feels more like Lisp than C++. The ::testing::AssertionResult class solves this problem. 上で紹介した EXPECT_PRED*() とその仲間は，ちょっとした仕事をする際に役立ちます．ただし，構文が十分とは言えないので，引数の数が異なる場合は別のマクロを使う必要があります．これは C++ というよりも Lisp に近いかもしれません．::testing::AssertionResult クラスを使えば，この問題を解決できます． .. An AssertionResult object represents the result of an assertion (whether it's a success or a failure, and an associated message). You can create an AssertionResult using one of these factory functions: AssertionResultオブジェクトは，アサーションの結果（成功したか失敗したか，および関連メッセージ）を表します． 次のファクトリ関数のいずれかを使って，AssertionResult を作成できます． .. namespace testing { .. // Returns an AssertionResult object to indicate that an assertion has .. // succeeded. .. AssertionResult AssertionSuccess(); .. // Returns an AssertionResult object to indicate that an assertion has .. // failed. .. AssertionResult AssertionFailure(); .. } .. code-block:: c namespace testing { // アサーションが成功したことを示す AssertionResult オブジェクト // を返します． AssertionResult AssertionSuccess(); // アサーションが失敗したことを示す AssertionResult オブジェクト // を返します． AssertionResult AssertionFailure(); } .. You can then use the << operator to stream messages to the AssertionResult object. そして，<< 演算子を使って AssertionResult オブジェクトにメッセージを追加できます． .. To provide more readable messages in Boolean assertions (e.g. EXPECT_TRUE()), write a predicate function that returns AssertionResult instead of bool. For example, if you define IsEven() as: Boolean アサーション（EXPECT_TRUE()）で，もっと読みやすいメッセージを出力するためには，bool の代わりに AssertionResult を返す述語関数を作ります． 例えば，IsEven()を次のように定義したとしましょう： .. code-block:: c ::testing::AssertionResult IsEven(int n) { if ((n % 2) == 0) return ::testing::AssertionSuccess(); else return ::testing::AssertionFailure() << n << " is odd"; } .. instead of: これは，以下の代わりになります． .. code-block:: c bool IsEven(int n) { return (n % 2) == 0; } .. the failed assertion EXPECT_TRUE(IsEven(Fib(4))) will print: EXPECT_TRUE(IsEven(Fib(4))) は失敗するアサーションで，次のような出力を行います． :: Value of: IsEven(Fib(4)) Actual: false (3 is odd) Expected: true .. instead of a more opaque AssertionResult を使わないと，少し説明不足な出力となります． :: Value of: IsEven(Fib(4)) Actual: false Expected: true .. If you want informative messages in EXPECT_FALSE and ASSERT_FALSE as well, and are fine with making the predicate slower in the success case, you can supply a success message: EXPECT_FALSE や ASSERT_FALSE でも同様の分かりやすいメッセージを使いたいならば，（失敗メッセージではなく）成功メッセージを出力することもできます．ただし，成功する場合にも述語関数を作るので，多少処理が遅くなっても問題ない場合に使ってください： .. code-block:: c ::testing::AssertionResult IsEven(int n) { if ((n % 2) == 0) return ::testing::AssertionSuccess() << n << " is even"; else return ::testing::AssertionFailure() << n << " is odd"; } .. Then the statement EXPECT_FALSE(IsEven(Fib(6))) will print この場合 EXPECT_FALSE(IsEven(Fib(6))) は，次のような出力を行います． :: Value of: IsEven(Fib(6)) Actual: true (8 is even) Expected: false .. Availability: Linux, Windows, Mac; since version 1.4.1. *利用可能な環境：* Linux，Windows，Mac．ただし，バージョン 1.4.1以降． .. Using a Predicate-Formatter .. _adv_using_a_predicate-formatter: 述語フォーマッタを利用する ^^^^^^^^^^^^^^^^^ .. If you find the default message generated by (ASSERT|EXPECT)_PRED* and (ASSERT|EXPECT)_(TRUE|FALSE) unsatisfactory, or some arguments to your predicate do not support streaming to ostream, you can instead use the following predicate-formatter assertions to fully customize how the message is formatted: (ASSERT|EXPECT)_PRED* や (ASSERT|EXPECT)_(TRUE|FALSE) が生成するデフォルトメッセージが不十分な場合や，述語関数の引数がストリーム ostream への出力をサポートしていない場合，代わりに次の述語フォーマッタアサーションを利用することができます： .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_PRED_FORMAT1(pred_format1, val1); EXPECT_PRED_FORMAT1(pred_format1, val1`); pred_format1(val1) is successful .. ASSERT_PRED_FORMAT2(pred_format2, val1, val2); EXPECT_PRED_FORMAT2(pred_format2, val1, val2); pred_format2(val1, val2) is successful .. ... ... ... .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,10 "ASSERT_PRED_FORMAT1(pred_format1, val1);", "EXPECT_PRED_FORMAT1(pred_format1, val1);", "pred_format1(val1) が成功する" "ASSERT_PRED_FORMAT2(pred_format2, val1, val2);", "EXPECT_PRED_FORMAT2(pred_format2, val1, val2);", "pred_format2(val1, val2) が成功する" "...", "...", "..." .. The difference between this and the previous two groups of macros is that instead of a predicate, (ASSERT|EXPECT)_PRED_FORMAT* take a predicate-formatter (pred_formatn), which is a function or functor with the signature: これが以前の2種類のマクロと異なる点は，(ASSERT|EXPECT)_PRED_FORMAT* は述語関数の代わりに述語フォーマッタ（pred_formatn）を受け取る，という事です．これは，次のような形式の関数またはファンクタです： :: ::testing::AssertionResult PredicateFormattern(const char* expr1, const char* expr2, ... const char* exprn, T1 val1, T2 val2, ... Tn valn); .. where val1, val2, ..., and valn are the values of the predicate arguments, and expr1, expr2, ..., and exprn are the corresponding expressions as they appear in the source code. The types T1, T2, ..., and Tn can be either value types or reference types. For example, if an argument has type Foo, you can declare it as either Foo or const Foo&, whichever is appropriate. val1, val2, ..., valn は引数の値です． expr1, expr2, ..., exprn はその引数に対応した式や変数の名前で，これはソースコード中に書かれているものです．型 T1, T2, ..., Tn は値型でも参照型でも構いません．例えば，引数の型が Foo だとすると，これを Foo または const Foo& のどちらで宣言しても構いません．どちらでも，適切です． .. A predicate-formatter returns a ::testing::AssertionResult object to indicate whether the assertion has succeeded or not. The only way to create such an object is to call one of these factory functions: 述語フォーマッタは，アサーションが成功したが失敗したかを示すオブジェクト::testing::AssertionResult を返します． このようなオブジェクトを作成する唯一の方法は，これらのファクトリ関数を使うことです： .. As an example, let's improve the failure message in the previous example, which uses EXPECT_PRED2(): 例として，以前の EXPECT_PRED2() の説明で出てきた失敗メッセージを改良してみましょう： .. // Returns the smallest prime common divisor of m and n, .. // or 1 when m and n are mutually prime. .. int SmallestPrimeCommonDivisor(int m, int n) { ... } .. // A predicate-formatter for asserting that two integers are mutually prime. .. ::testing::AssertionResult AssertMutuallyPrime(const char* m_expr, .. const char* n_expr, .. int m, .. int n) { .. if (MutuallyPrime(m, n)) .. return ::testing::AssertionSuccess(); .. return ::testing::AssertionFailure() .. << m_expr << " and " << n_expr << " (" << m << " and " << n .. << ") are not mutually prime, " << "as they have a common divisor " .. << SmallestPrimeCommonDivisor(m, n); .. } .. code-block:: c // m と n の公約数のうち，最小の素数を返します． // また，m と n が互いに素の場合は 1 を返します． int SmallestPrimeCommonDivisor(int m, int n) { ... } // 2つの整数が互いに素かを調べるアサーション用の述語フォーマッタ． ::testing::AssertionResult AssertMutuallyPrime(const char* m_expr, const char* n_expr, int m, int n) { if (MutuallyPrime(m, n)) return ::testing::AssertionSuccess(); return ::testing::AssertionFailure() << m_expr << " and " << n_expr << " (" << m << " and " << n << ") are not mutually prime, " << "as they have a common divisor " << SmallestPrimeCommonDivisor(m, n); } .. With this predicate-formatter, we can use この述語フォーマッタを用いて，次のように書くことができます． .. code-block:: c EXPECT_PRED_FORMAT2(AssertMutuallyPrime, b, c); .. to generate the message これは，以下のメッセージを出力します． :: b and c (4 and 10) are not mutually prime, as they have a common divisor 2. .. As you may have realized, many of the assertions we introduced earlier are special cases of (EXPECT|ASSERT)_PRED_FORMAT*. In fact, most of them are indeed defined using (EXPECT|ASSERT)_PRED_FORMAT*. 既に気づいているかもしれませんが，以前に紹介したアサーションの多くは，(EXPECT|ASSERT)_PRED_FORMAT* の特別な場合です．実際，それらは (EXPECT|ASSERT)_PRED_FORMAT* を用いて定義されています． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Floating-Point Comparison .. _adv_floating-point_comparision: 浮動小数点数の比較 ------------------------ .. Comparing floating-point numbers is tricky. Due to round-off errors, it is very unlikely that two floating-points will match exactly. Therefore, ASSERT_EQ 's naive comparison usually doesn't work. And since floating-points can have a wide value range, no single fixed error bound works. It's better to compare by a fixed relative error bound, except for values close to 0 due to the loss of precision there. 浮動小数点数の比較は，微妙な問題です．丸め誤差があるので，2つの浮動小数点数が完全に一致することは非常にまれです．よって，ASSERT_EQ での比較は上手くいきません．また，浮動小数点数の値のとる範囲は広いので，ある固定の誤差範囲を使っても上手くいきません． 相対誤差範囲で比較するのは，それよりは良い方法ですが，0 に近い値は精度が低いのでやはり上手くいきません． .. In general, for floating-point comparison to make sense, the user needs to carefully choose the error bound. If they don't want or care to, comparing in terms of Units in the Last Place (ULPs) is a good default, and Google Test provides assertions to do this. Full details about ULPs are quite long; if you want to learn more, see this article on float comparison. 一般的に，浮動小数点数の比較を上手く行うには，ユーザが慎重に誤差範囲を指定する必要があります．そのような手間をかけたくない場合，最下位桁単位（Units in the Last Place: ULPs）を使って比較するのは良い方法と言えますし，Google Test のアサーションでもそうしています．ULPs について詳しく述べると，非常に長くなります．詳細については， `浮動小数点数の比較に関するこの記事 `_ を読んでください． .. Floating-Point Macros .. _adv_floating-point_macros: 浮動小数点マクロ ^^^^^^^^^^^ .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_FLOAT_EQ(expected, actual); EXPECT_FLOAT_EQ(expected, actual); the two float values are almost equal .. ASSERT_DOUBLE_EQ(expected, actual); EXPECT_DOUBLE_EQ(expected, actual); the two double values are almost equal .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,15 "ASSERT_FLOAT_EQ(expected, actual);", "EXPECT_FLOAT_EQ(expected, actual);", "2つの float 値が，ほぼ等しい" "ASSERT_DOUBLE_EQ(expected, actual);", "EXPECT_DOUBLE_EQ(expected, actual);", "2つの double 値が，ほぼ等しい" .. By "almost equal", we mean the two values are within 4 ULP's from each other. ここでの「ほぼ等しい」とは，2つの値の差が 4 ULPs 以内になることを意味しています． .. The following assertions allow you to choose the acceptable error bound: 次のアサーションを使うと，許容誤差範囲を指定することができます． .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_NEAR(val1, val2, abs_error); EXPECT_NEAR(val1, val2, abs_error); the difference between val1 and val2 doesn't exceed the given absolute error .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,20 "ASSERT_NEAR(val1, val2, abs_error);", "EXPECT_NEAR(val1, val2, abs_error);", "val1 と val2 の差が，与えられた絶対誤差以内に収まる" .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Floating-Point Predicate-Format Functions .. _adv_floating-point_predicate-format_functions: 浮動小数点述語フォーマット関数 ^^^^^^^^^^^^^^^^^^^^ .. Some floating-point operations are useful, but not that often used. In order to avoid an explosion of new macros, we provide them as predicate-format functions that can be used in predicate assertion macros (e.g. EXPECT_PRED_FORMAT2, etc). 便利ではあるものの使用頻度は低い，という浮動小数点処理が存在します．これらに対して新しいマクロが爆発的に増えないように，述語アサーションマクロ（例えば，EXPECT_PRED_FORMAT2 など）で利用できる述語フォーマット関数が用意されています． :: EXPECT_PRED_FORMAT2(::testing::FloatLE, val1, val2); EXPECT_PRED_FORMAT2(::testing::DoubleLE, val1, val2); .. Verifies that val1 is less than, or almost equal to, val2. You can replace EXPECT_PRED_FORMAT2 in the above table with ASSERT_PRED_FORMAT2. これは，val1 が val2 以下であることをテストします． EXPECT_PRED_FORMAT2 を ASSERT_PRED_FORMAT2 に変更することもできます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Windows HRESULT assertions .. _adv_windows_hresult_assertions: Windows HRESULT アサーション ---------------------------- .. These assertions test for HRESULT success or failure. これらのアサーションは，HRESULT が成功か失敗かをテストします． .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_HRESULT_SUCCEEDED(expression); EXPECT_HRESULT_SUCCEEDED(expression); expression is a success HRESULT .. ASSERT_HRESULT_FAILED(expression); EXPECT_HRESULT_FAILED(expression); expression is a failure HRESULT .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,15 "ASSERT_HRESULT_SUCCEEDED(expression);", "EXPECT_HRESULT_SUCCEEDED(expression);", "expression が success HRESULT" "ASSERT_HRESULT_FAILED(expression);", "EXPECT_HRESULT_FAILED(expression);", "expression が failure HRESULT" .. The generated output contains the human-readable error message associated with the HRESULT code returned by expression. ここで生成される出力には，人間が読めるエラーメッセージが含まれています．これは，expression が返す HRESULT コードに関連するものです． .. You might use them like this: 例えば，次のようにして利用できます： .. code-block:: c CComPtr shell; ASSERT_HRESULT_SUCCEEDED(shell.CoCreateInstance(L"Shell.Application")); CComVariant empty; ASSERT_HRESULT_SUCCEEDED(shell->ShellExecute(CComBSTR(url), empty, empty, empty, empty)); .. Availability: Windows. *利用可能な環境：* Windows． .. Type Assertions .. _adv_type_assertions: 型アサーション ------------------- .. You can call the function この関数の呼び出し方は次のようになります． :: ::testing::StaticAssertTypeEq(); .. to assert that types T1 and T2 are the same. The function does nothing if the assertion is satisfied. If the types are different, the function call will fail to compile, and the compiler error message will likely (depending on the compiler) show you the actual values of T1 and T2. This is mainly useful inside template code. これは，T1 と T2 の型が同じであることをアサートします．型が等しくアサーションが成功する場合は，この関数は何もしません．型が異なる場合は，この関数呼び出しはコンパイルに失敗します．おそらく（コンパイラに依存しますが），コンパイルエラーメッセージで T1 と T2 の実際の値が表示されるでしょう．これは，主にテンプレートコード内で利用されるものです． .. Caveat: When used inside a member function of a class template or a function template, StaticAssertTypeEq() is effective only if the function is instantiated. For example, given: *注意：* クラステンプレートのメンバ関数内，または関数テンプレート内で利用する場合，StaticAssertTypeEq() は，その関数がインスタンス化されて始めて効果があります．例えば，次のようなクラステンプレートが定義されたとします： .. code-block:: c template class Foo { public: void Bar() { ::testing::StaticAssertTypeEq(); } }; .. the code: そして，実際のコードが次のようになっているとします： .. code-block:: c void Test1() { Foo foo; } .. will not generate a compiler error, as Foo::Bar() is never actually instantiated. Instead, you need: ここで，Foo::Bar() は実際にはインスタンス化されないので，このコードはコンパイルエラーを起こしません．代わりに .. code-block:: c void Test2() { Foo foo; foo.Bar(); } .. to cause a compiler error. というコードは，正しくコンパイルエラーを発生させます． .. Availability: Linux, Windows, Mac; since version 1.3.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.3.0 以降． .. Assertion Placement .. _adv_assertion_placement: アサーションの配置 ----------------------- .. You can use assertions in any C++ function. In particular, it doesn't have to be a method of the test fixture class. The one constraint is that assertions that generate a fatal failure (FAIL* and ASSERT_*) can only be used in void-returning functions. This is a consequence of Google Test not using exceptions. By placing it in a non-void function you'll get a confusing compile error like "error: void value not ignored as it ought to be". アサーションは，任意の C++ 関数で利用できます．特に，テストフィクスチャクラスのメソッドにする必要はありません．ただし，致命的な失敗を発生させるアサーション（FAIL* と ASSERT_*）は，void を返す関数内でのみ利用できるという制約があります．これは，Google Test が例外を利用していないことが原因です．もし void 関数以外で利用しようとすると， "error: void value not ignored as it ought to be" というようなコンパイルエラーに悩まされることになるでしょう． .. If you need to use assertions in a function that returns non-void, one option is to make the function return the value in an out parameter instead. For example, you can rewrite T2 Foo(T1 x) to void Foo(T1 x, T2* result). You need to make sure that *result contains some sensible value even when the function returns prematurely. As the function now returns void, you can use any assertion inside of it. もし，void 以外を返す関数でアサーションを利用したい場合の選択肢の1つは，戻り値の代わりに引数で値を返す関数に変更する，というものです．例えば，T2 Foo(T1 x) を void Foo(T1 x, T2* result) に変更します．ただし，この関数が最後まで実行されずに返ったとしても，*result に意味のある値が入るようにする必要があります．この関数は void を返すので，関数内で自由にアサーションを使うことができます． .. If changing the function's type is not an option, you should just use assertions that generate non-fatal failures, such as ADD_FAILURE* and EXPECT_*. 関数の型を変更する方法が使えなければ，ADD_FAILURE* や EXPECT_* のような，致命的ではない失敗を発生するアサーションを利用するしかないでしょう． .. Note: Constructors and destructors are not considered void-returning functions, according to the C++ language specification, and so you may not use fatal assertions in them. You'll get a compilation error if you try. A simple workaround is to transfer the entire body of the constructor or destructor to a private void-returning method. However, you should be aware that a fatal assertion failure in a constructor does not terminate the current test, as your intuition might suggest; it merely returns from the constructor early, possibly leaving your object in a partially-constructed state. Likewise, a fatal assertion failure in a destructor may leave your object in a partially-destructed state. Use assertions carefully in these situations! *注意* ： C++ の仕様によれば，コンストラクタとデストラクタは，voidを返す関数とはみなされません．よって，その中で致命的な失敗を発生させるアサーションを使うことはできません．もし使おうとすれば，コンパイルエラーになります．単純な回避策としては，コンストラクタとデストラクタの中身全体を void を返す private なメソッドに移してしまうことです．しかし，直感的に分かるかもしれませんが，コンストラクタ内の致命的なアサーションは現在のテストを終了させないことに注意してください．これは，部分的に作成されたオブジェクトをそのままにして，単にコンストラクタから早く返るだけです．同じように，デストラクタ内のアサーションの致命的失敗も，オブジェクトを部分的に破棄した状態にします．このような状況では，注意してアサーションを利用してください． .. Teaching Google Test How to Print Your Values .. _adv_etaaching_gtest_how_to_print_your_values: Google Test に値の表示方法を教示する ========================== .. When a test assertion such as EXPECT_EQ fails, Google Test prints the argument values to help you debug. It does this using a user-extensible value printer. EXPECT_EQ のようなテストアサーションが失敗すると，Google Test は，デバッグしやすいように引数の値を表示します．この表示は，ユーザが拡張可能な値プリンタを利用して行われます． .. This printer knows how to print built-in C++ types, native arrays, STL containers, and any type that supports the << operator. For other types, it prints the raw bytes in the value and hopes that you the user can figure it out. このプリンタは，C++ の組み込み型，ネイティブな配列，STL コンテナ，<< 演算子をサポートする任意の型を出力することができます．しかし，その他の型の場合は，生のバイト値を表示して，ユーザがそれの意味を分かってくれることを願うのみです． .. As mentioned earlier, the printer is extensible. That means you can teach it to do a better job at printing your particular type than to dump the bytes. To do that, define << for your type: 前述したように，このプリンタは拡張可能です．これは，ある特定の型を出力する際には，バイト値をダンプするより良い方法を教示することができる，ということを意味します．そのためには，その型に対して << 演算子を定義します： .. code-block:: c #include namespace foo { class Bar { ... }; // Google Test が，これのインスタンスを出力できるようになってほしい． // Bar の定義と「同じ」名前空間で << 演算子を定義することが重要です． // C++ のルックアップルールは，それに依存しています． ::std::ostream& operator<<(::std::ostream& os, const Bar& bar) { return os << bar.DebugString(); // bar を os に出力するのに必要な処理を書きます } } // 名前空間 foo .. Sometimes, this might not be an option: your team may consider it bad style to have a << operator for Bar, or Bar may already have a << operator that doesn't do what you want (and you cannot change it). If so, you can instead define a PrintTo() function like this: この選択肢をとれない場合があるかもしれません：あなたのチームが，Bar に対して << 演算子を定義するのは悪いスタイルであると見なしている場合，Bar に対して既に << 演算子が定義されていて，その動作が望むものではない（そして，その変更もできない）場合，などです．その場合，代わりに PrintTo() 関数を次のように定義することができます： .. code-block:: c #include namespace foo { class Bar { ... }; // Bar の定義と「同じ」名前空間で PrintTo() を定義することが重要です． // C++ のルックアップルールは，それに依存しています． void PrintTo(const Bar& bar, ::std::ostream* os) { *os << bar.DebugString(); // bar を os に出力するのに必要な処理を書きます } } // 名前空間 foo .. If you have defined both << and PrintTo(), the latter will be used when Google Test is concerned. This allows you to customize how the value appears in Google Test's output without affecting code that relies on the behavior of its << operator. << と PrintTo() の両方が定義されている場合，Google Test は後者を利用します．このおかげで，自身の << 演算子の動作に依存するコードに影響を与えることなく，Google Test の出力に値を表示する方法をカスタマイズできます． .. If you want to print a value x using Google Test's value printer yourself, just call ::testing::PrintToString(x), which returns an std::string: Google Test の値プリンタを用いて，x の値を自分で出力したいならば， std::string を返す ::testing::PrintToString(x) を呼び出すだけです： .. code-block:: c vector > bar_ints = GetBarIntVector(); EXPECT_TRUE(IsCorrectBarIntVector(bar_ints)) << "bar_ints = " << ::testing::PrintToString(bar_ints); .. Death Tests .. _adv_death_tests: Death テスト ============ .. In many applications, there are assertions that can cause application failure if a condition is not met. These sanity checks, which ensure that the program is in a known good state, are there to fail at the earliest possible time after some program state is corrupted. If the assertion checks the wrong condition, then the program may proceed in an erroneous state, which could lead to memory corruption, security holes, or worse. Hence it is vitally important to test that such assertion statements work as expected. 多くのアプリケーションにおいて，条件が満たされない場合にアプリケーションを落としてしまうアサーションが存在します．これらのチェックは，プログラムが正常な状態にあることを保障し，プログラムが異常状態になった場合にできるだけ迅速に失敗させるためにあります．アサーションがチェックする条件が間違っていると，誤った状態で処理が進み，メモリ破壊やセキュリティホール，それ以上の障害の原因になる可能性があります．よって，このようなアサーションが期待通りに動作することをテストするのは，極めて重要といえます． .. Since these precondition checks cause the processes to die, we call such tests death tests. More generally, any test that checks that a program terminates (except by throwing an exception) in an expected fashion is also a death test. これらの前提条件チェックはプロセスを殺してしまうので，このようなテストを *Death テスト* と呼びます．より一般的には，プログラムが期待通りの方法で終了すること（ただし例外によるものを除く）をチェックするテスト全般を Death テストと呼びます． .. Note that if a piece of code throws an exception, we don't consider it "death" for the purpose of death tests, as the caller of the code could catch the exception and avoid the crash. If you want to verify exceptions thrown by your code, see Exception Assertions. あるコードの一部が例外を投げる場合，それは Death テストが対象とする「Death」とは見なされないので，そのコード部分を呼び出した側が，その例外をキャッチしてクラッシュを避けることができます．あなたのコードが例外を投げらていることを検証したい場合は， :ref:`adv_exception_assertion` の項を参照してください． .. If you want to test EXPECT_*()/ASSERT_*() failures in your test code, see Catching Failures. また，テストコード中の EXPECT_*()/ASSERT_*() の失敗をテストしたいならば， :ref:`adv_catching_failures` の項を参照してください． .. How to Write a Death Test .. _adv_how_to_write_a_death_test: Deathテストの書き方 ------------------- .. Google Test has the following macros to support death tests: Google Test では，Death テストをサポートする次のマクロが用意されています： .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_DEATH(statement, regex`); EXPECT_DEATH(statement, regex`); statement crashes with the given error .. ASSERT_DEATH_IF_SUPPORTED(statement, regex`); EXPECT_DEATH_IF_SUPPORTED(statement, regex`); if death tests are supported, verifies that statement crashes with the given error; otherwise verifies nothing .. ASSERT_EXIT(statement, predicate, regex`); EXPECT_EXIT(statement, predicate, regex`); statement exits with the given error and its exit code matches predicate .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,25 "ASSERT_DEATH(statement, regex);", "EXPECT_DEATH(statement, regex);", "与えられたエラーが発生し，statement がクラッシュ" "ASSERT_DEATH_IF_SUPPORTED(statement, regex);", "EXPECT_DEATH_IF_SUPPORTED(statement, regex);", "Death テストがサポートされていれば，statement が与えられたエラーでクラッシュすることを検証し，そうでなければ何もしない" "ASSERT_EXIT(statement, predicate, regex);", "EXPECT_EXIT(statement, predicate, regex);", "statement が与えられたエラーで終了し，終了コードが predicate にマッチする" .. where statement is a statement that is expected to cause the process to die, predicate is a function or function object that evaluates an integer exit status, and regex is a regular expression that the stderr output of statement is expected to match. Note that statement can be any valid statement (including compound statement) and doesn't have to be an expression. ここで，statement は，プロセスを殺すであろう文，predicate は，終了ステータスを評価する関数またはファンクタ， regex は，statement の標準出力とマッチする正規表現，をそれぞれ意味します．statement は1つの式である必要はなく，（複合的な命令文も含む）あらゆる有効な命令文を指定することができます． .. As usual, the ASSERT variants abort the current test function, while the EXPECT variants do not. 通常，ASSERT バージョンは現在のテスト関数を終了させますが，EXPECT バージョンは終了させません． .. Note: We use the word "crash" here to mean that the process terminates with a non-zero exit status code. There are two possibilities: either the process has called exit() or _exit() with a non-zero value, or it may be killed by a signal. *注意* ： ここでは，プログラムが 0 以外のステータスコードで終了することを「クラッシュ」と呼んでいます．これには，次の2つの原因が考えられます：プロセスが exit() または _exit() を0ではない引数で呼び出した場合． あるいは，シグナルによって殺された場合，です． .. This means that if statement terminates the process with a 0 exit code, it is not considered a crash by EXPECT_DEATH. Use EXPECT_EXIT instead if this is the case, or if you want to restrict the exit code more precisely. これはつまり，statement が終了コード 0 でプロセスを終了させても，EXPECT_DEATH はクラッシュとは判断しない，という事です． .. A predicate here must accept an int and return a bool. The death test succeeds only if the predicate returns true. Google Test defines a few predicates that handle the most common cases: ここでの述語関数は，必ず int 型を受け取り bool 型を返す必要があります．述語関数が true を返した場合のみ，Death テストが成功します．Google Test では，頻繁に利用される述語関数をいくつか定義しています： .. code-block:: c ::testing::ExitedWithCode(exit_code) .. This expression is true if the program exited normally with the given exit code. この式は，プログラムが引数の終了コードで正常終了した場合に true を返します． .. code-block:: c ::testing::KilledBySignal(signal_number) // Windowsでは無効． .. This expression is true if the program was killed by the given signal. この式は，プログラムが引数のシグナルに殺された場合に true を返します． .. The *_DEATH macros are convenient wrappers for *_EXIT that use a predicate that verifies the process' exit code is non-zero. *_DEATH は便利なマクロで，プロセスの終了コードがゼロではないことを検証する述語関数を引数にした場合の *_EXIT をラップしたものです． .. Note that a death test only cares about three things: Death テストでは，次の3点に注意してください： .. does statement abort or exit the process? .. (in the case of ASSERT_EXIT and EXPECT_EXIT) does the exit status satisfy predicate? Or (in the case of ASSERT_DEATH and EXPECT_DEATH) is the exit status non-zero? And .. does the stderr output match regex? #. statement は，プロセスを強制終了または終了させたか？ #. （ASSERT_EXIT と EXPECT_EXIT の場合） 終了ステータスは，predicate を満たすか？または（ASSERT_DEATH と EXPECT_DEATH の場合）終了ステータスは 0 以外の値か？ #. 標準エラー出力は regex とマッチするか？ .. In particular, if statement generates an ASSERT_* or EXPECT_* failure, it will not cause the death test to fail, as Google Test assertions don't abort the process. 特に，statement が ASSERT_* または EXPECT_* の失敗を引き起こした場合でも，Google Test のアサーションはプロセスを強制終了させないので，Death テストの失敗とはなりません． .. To write a death test, simply use one of the above macros inside your test function. For example, 上述のマクロの 1 つをテスト関数の中で使用するだけで，Death テストを書くことができます．次に例を示します： .. code-block:: c TEST(My*DeathTest*, Foo) { // この Death テストは，複合文を利用します． ASSERT_DEATH({ int n = 5; Foo(&n); }, "Error on line .* of Foo()"); } TEST(MyDeathTest, NormalExit) { EXPECT_EXIT(NormalExit(), ::testing::ExitedWithCode(0), "Success"); } TEST(MyDeathTest, KillMyself) { EXPECT_EXIT(KillMyself(), ::testing::KilledBySignal(SIGKILL), "Sending myself unblockable signal"); } .. verifies that: これは，次のことを検証します： .. calling Foo(5) causes the process to die with the given error message, .. calling NormalExit() causes the process to print "Success" to stderr and exit with exit code 0, and .. calling KillMyself() kills the process with signal SIGKILL. * Foo(5) がプロセスをクラッシュさせ，与えられたエラーメッセージを出力する． * NormalExit() によって，プロセスは標準エラー出力に "Success" を出力し，終了コード 0 で終了する． * KillMyself() は，シグナル SIGKILL によってプロセスを殺す． .. The test function body may contain other assertions and statements as well, if necessary. 今までと同様に，必要ならばテスト関数内に他のアサーションや文を含めることができます． .. Important: We strongly recommend you to follow the convention of naming your test case (not test) *DeathTest when it contains a death test, as demonstrated in the above example. The Death Tests And Threads section below explains why. *重要* ： 上述のサンプルと同じく，Death テストを含むテストケース（テストではありません）を，*DeathTest という名前にする事を強く勧めます．その理由は， :ref:`adv_death_tests_and_threads` のセクションで説明します． .. If a test fixture class is shared by normal tests and death tests, you can use typedef to introduce an alias for the fixture class and avoid duplicating its code: 通常のテストとDeath テストとで，テストフィクスチャクラスを共有する場合，typedef でフィクスチャクラスに別名を与え，同じコードが複製されることを防ぎます． .. code-block:: c class FooTest : public ::testing::Test { ... }; typedef FooTest FooDeathTest; TEST_F(FooTest, DoesThis) { // 通常のテスト } TEST_F(FooDeathTest, DoesThat) { // Death テスト } .. (ASSERT|EXPECT)_DEATH_IF_SUPPORTED are new in v1.4.0. *利用可能な環境：* Linux，Windows（MSVC 8.0 以降が必要），Cygwin，Mac．（ただし，後者3つは，バージョン 1.3.0 以降でサポートされます）．(ASSERT|EXPECT)_DEATH_IF_SUPPORTED は，バージョン 1.4.0 で導入されました． .. Regular Expression Syntax .. _adv_regular_expression_syntax: 正規表現の構文 -------------- .. On POSIX systems (e.g. Linux, Cygwin, and Mac), Google Test uses the POSIX extended regular expression syntax in death tests. To learn about this syntax, you may want to read this Wikipedia entry. POSIX システム（例えば，Linux，Cygwin，Macなど）環境において，Google Test の Death テストでは `POSIX拡張正規表現 `_ 構文を利用しています．この構文について知りたければ， `このWikipediaエントリー `_ が参考になるでしょう． .. On Windows, Google Test uses its own simple regular expression implementation. It lacks many features you can find in POSIX extended regular expressions. For example, we don't support union ("x|y"), grouping ("(xy)"), brackets ("[xy]"), and repetition count ("x{5,7}"), among others. Below is what we do support (A denotes a literal character, period (.), or a single \\ escape sequence; x and y denote regular expressions.): Windows環境での Google Test は，シンプルな正規表現の独自実装を利用しています．しかし，POSIX拡張正規表現と比べると多くの機能が不足しています．例えば，結合（"x|y"），グループ化（"(xy)"），カギ括弧（"[xy]"），繰り返し（"x{5,7}"）などがサポートされていません．サポートされる構文を以下に示します（A は，ある1文字，ピリオド（.）または 1つの \\ エスケープシーケンスを表します．また，x と y は通常の正規表現を表します．）： .. c matches any literal character c .. \\d matches any decimal digit .. \\D matches any character that's not a decimal digit .. \\f matches \f .. \\n matches \n .. \\r matches \r .. \\s matches any ASCII whitespace, including \n .. \\S matches any character that's not a whitespace .. \\t matches \t .. \\v matches \v .. \\w matches any letter, _, or decimal digit .. \\W matches any character that \\w doesn't match .. \\c matches any literal character c, which must be a punctuation .. . matches any single character except \n .. A? matches 0 or 1 occurrences of A .. A* matches 0 or many occurrences of A .. A+ matches 1 or many occurrences of A .. ^ matches the beginning of a string (not that of each line) .. $ matches the end of a string (not that of each line) .. xy matches x followed by y .. csv-table:: :header: :widths: 5,30 c, 任意のリテラル文字 c にマッチします \\\\d, 任意の数字にマッチします \\\\D, 数字ではない任意の文字にマッチします \\\\f, \\f にマッチします \\\\n, \\n にマッチします \\\\r, \\r にマッチします \\\\s, \\n を含む，任意のASCII空白にマッチします \\\\S, 空白ではない任意の文字にマッチします \\\\t, \\t にマッチします \\\\v, \\v にマッチします \\\\w, 任意のアルファベット，アンダースコア，数字にマッチします \\\\W, \\w がマッチしない任意の文字にマッチします \\\\c, 任意の句読記号にマッチします ., \\n ではない任意の1文字にマッチします A?, A の0回または1回の繰り返しにマッチします A*, A の0回以上の繰り返しにマッチします A+, A の1回以上の繰り返しにマッチします ^, 文字列の先頭にマッチします（行頭ではありません） $, 文字列の末尾にマッチします（行末ではありません） xy, x とその後ろの y にマッチします .. To help you determine which capability is available on your system, Google Test defines macro GTEST_USES_POSIX_RE=1 when it uses POSIX extended regular expressions, or GTEST_USES_SIMPLE_RE=1 when it uses the simple version. If you want your death tests to work in both cases, you can either #if on these macros or use the more limited syntax only. 自分のシステムでどちらの正規表現機能を有効にするかを決めるには，Google Test が定義するマクロを利用します．POSIX拡張正規表現を利用する場合は，マクロ GTEST_USES_POSIX_RE=1 ，シンプル版を利用する場合は，マクロ GTEST_USES_SIMPLE_RE=1 を使います．どちらの場合でもDeath テストを動作させたい場合，#if でこれらのマクロを場合分けするか，または，両方でサポートされている限られた構文だけを利用してください． .. How It Works .. _adv_how_it_works: 動作説明 ------------ .. Under the hood, ASSERT_EXIT() spawns a new process and executes the death test statement in that process. The details of of how precisely that happens depend on the platform and the variable ::testing::GTEST_FLAG(death_test_style) (which is initialized from the command-line flag --gtest_death_test_style). 内部的には，ASSERT_EXIT() が新しいプロセスを作り，そのプロセス内でDeathテスト文を実行します．厳密にどのような動作をするかというのは，そのプラットフォームと（コマンドラインフラグ ---gtest_death_test_style によって初期化される）変数 ::testing::GTEST_FLAG(death_test_style) に依存します． .. On POSIX systems, fork() (or clone() on Linux) is used to spawn the child, after which: .. If the variable's value is "fast", the death test statement is immediately executed. .. If the variable's value is "threadsafe", the child process re-executes the unit test binary just as it was originally invoked, but with some extra flags to cause just the single death test under consideration to be run. .. On Windows, the child is spawned using the CreateProcess() API, and re-executes the binary to cause just the single death test under consideration to be run - much like the threadsafe mode on POSIX. * POSIXシステムでは，子プロセスを作るためにfork()（Linuxでは clone()）が利用されます．そして： * 変数の値が "fast" の場合，Deathテスト文は即座に実行されます． * 変数の値が "threadsafe" の場合，子プロセスがユニットテストバイナリを再実行します．これは，元々と同じように実行されますが，実行待機中のDeathテストを1つだけ起動するためのフラグを追加する点が異なります． * Windows では，子プロセスを作るためにCreateProcess() APIが利用されます．そして，実行待機中のDeathテストが1つだけ起動されるように，子プロセスでバイナリが再実行されます．これは，POSIX での threadsafe モードと同じです． .. Other values for the variable are illegal and will cause the death test to fail. Currently, the flag's default value is "fast". However, we reserve the right to change it in the future. Therefore, your tests should not depend on this. 変数にこれ以外の値が入ることは不正であり，その場合 Death テストは失敗します．現在のところ，フラグのデフォルト値は "fast" です．しかし，将来的には変更される可能性があります．よって，これに依存するようなテストを書かないようにしてください． .. In either case, the parent process waits for the child process to complete, and checks that どちらの場合でも，親プロセスは子プロセスの終了を待ちます．そして，次のチェックを行います .. the child's exit status satisfies the predicate, and .. the child's stderr matches the regular expression. #. 子プロセスの終了ステータスが，述語関数を満足しているか #. 子プロセスの標準エラー出力が，正規表現にマッチしているか .. If the death test statement runs to completion without dying, the child process will nonetheless terminate, and the assertion fails. 子プロセスが終了したにもかかわらず，Deathテスト文がクラッシュせずに終了した場合，アサーションは失敗します． .. Death Tests And Threads .. _adv_death_tests_and_threads: Death テストとスレッド ---------------------------- .. The reason for the two death test styles has to do with thread safety. Due to well-known problems with forking in the presence of threads, death tests should be run in a single-threaded context. Sometimes, however, it isn't feasible to arrange that kind of environment. For example, statically-initialized modules may start threads before main is ever reached. Once threads have been created, it may be difficult or impossible to clean them up. Death テストに2種類のスタイルがある理由は，スレッドセーフな実行のためです．マルチスレッドでプロセスを生成すると，様々な問題を引き起こす可能性があることは広く知られています．そのため，Deathテストはシングルスレッドで実行される必要があります．しかし，そのような環境を用意するのが不可能な場合もあります．例えば，静的に初期化されるモジュールでは，メインスレッドよりも前にスレッドを開始する可能性があります．一度複数のスレッドが作成されると，それらを完全に終了させるのは難しく，場合によっては不可能です． .. Google Test has three features intended to raise awareness of threading issues. Google Test には，スレッド問題に対する意識を高めるための3つの機能があります． .. A warning is emitted if multiple threads are running when a death test is encountered. .. Test cases with a name ending in "DeathTest" are run before all other tests. .. It uses clone() instead of fork() to spawn the child process on Linux (clone() is not available on Cygwin and Mac), as fork() is more likely to cause the child to hang when the parent process has multiple threads. #. Death テスト実行時に複数のスレッド実行されていると，警告が出されます． #. "DeathTest" で終わる名前のテストケースは，他の全てのテストよりも前に実行されます． #. fork() を使うと，親プロセスがマルチスレッドの場合に，子プロセスをハングアップさせる可能性が高いので，Linux（CygwinやMacではclone() は利用できません）で子プロセスを生成する場合は，fork() の代わりに clone() を利用します． .. It's perfectly fine to create threads inside a death test statement; they are executed in a separate process and cannot affect the parent. Death テスト文の中でマルチスレッドを作成するのは全く問題ありません．それらは別々のプロセスで実行され，親プロセスに影響を与えることが不可能だからです． .. Death Test Styles .. _adv_death_test_styles: Death テストのスタイル -------------------------- .. The "threadsafe" death test style was introduced in order to help mitigate the risks of testing in a possibly multithreaded environment. It trades increased test execution time (potentially dramatically so) for improved thread safety. We suggest using the faster, default "fast" style unless your test has specific problems with it. "threadsafe" な Death テストスタイルは，マルチスレッドが可能な環境でのテストのリスクを低減するために導入されました．テストの実行時間（非常に遅くなる可能性もあります）とスレッドの安全性はトレードオフの関係にあります．テストに特別な問題がない限り，高速なデフォルトの "fast" スタイルを使うことをお勧めします． .. You can choose a particular style of death tests by setting the flag programmatically: プログラム内でフラグをセットすることで，Death テストのスタイルを選択できます： .. code-block:: c ::testing::FLAGS_gtest_death_test_style = "threadsafe"; .. You can do this in main() to set the style for all death tests in the binary, or in individual tests. Recall that flags are saved before running each test and restored afterwards, so you need not do that yourself. For example: main() でこれを行って，バイナリ内のすべての Death テストのスタイルを決めることもできますし，各テストのスタイルを個々に決めることもできます．フラグは各テストの実行前に保存され，実行後に復元されることを思い出してください．ユーザが復元作業を行う必要はありません．例えば： .. code-block:: c TEST(MyDeathTest, TestOne) { ::testing::FLAGS_gtest_death_test_style = "threadsafe"; // このテストは "threadsafe" スタイルで実行されます： ASSERT_DEATH(ThisShouldDie(), ""); } TEST(MyDeathTest, TestTwo) { // このテストは "fast" スタイルで実行されます： ASSERT_DEATH(ThisShouldDie(), ""); } int main(int argc, char** argv) { ::testing::InitGoogleTest(&argc, argv); ::testing::FLAGS_gtest_death_test_style = "fast"; return RUN_ALL_TESTS(); } .. Caveats .. _adv_caveats: 注意事項 ---------- .. The statement argument of ASSERT_EXIT() can be any valid C++ statement. If it leaves the current function via a return statement or by throwing an exception, the death test is considered to have failed. Some Google Test macros may return from the current function (e.g. ASSERT_TRUE()), so be sure to avoid them in statement. ASSERT_EXIT() の statement 引数には，任意の有効な C++ の文が利用できます．return 文や例外を投げることで現在の関数から抜けた場合，Death テストは失敗したと見なされます．Google Test のマクロが，現在の関数からリターンしてしまう可能性のあるもの（例えば， ASSERT_TRUE() ）は，statement に含めないようにしてください． .. Since statement runs in the child process, any in-memory side effect (e.g. modifying a variable, releasing memory, etc) it causes will not be observable in the parent process. In particular, if you release memory in a death test, your program will fail the heap check as the parent process will never see the memory reclaimed. To solve this problem, you can statement は子プロセスで実行されるので，それが引き起こすメモリに対する副作用（例えば，変数の変更，メモリ解放など）は，親プロセスからは観測できません．具体的に言えば，Death テスト内でメモリを解放すると，親プロセスからは回収されたメモリが見えなくなるので，プログラムはヒープチェックに失敗します． この問題を解決するためにできることは，次の通りです． .. try not to free memory in a death test; .. free the memory again in the parent process; or .. do not use the heap checker in your program. #. Death テスト中はメモリを解放しない #. 親プロセス内で再びメモリを解放する #. プログラムでヒープチェックを行わない .. Due to an implementation detail, you cannot place multiple death test assertions on the same line; otherwise, compilation will fail with an unobvious error message. 実装上の問題で，複数の Death テストアサーションを同じ行に書くことはできません．もし書けば，コンパイルが失敗して，不可解なエラーメッセージが出力されます． .. Despite the improved thread safety afforded by the "threadsafe" style of death test, thread problems such as deadlock are still possible in the presence of handlers registered with pthread_atfork(3). Death テストの "threadsafe" スタイルによってスレッド安全性が向上したにもかかわらず，pthread_atfork(3) で登録されたハンドラが存在する場合は，デッドロックなどのスレッド問題は依然として起こりえます． .. Using Assertions in Sub-routines .. _adv_using_assertions_in_sub-routines: サブルーチンでのアサーションの利用 ================================== .. Adding Traces to Assertions .. _adv_adding_traces_to_assertions: アサーションにトレースを追加する -------------------------------------- .. If a test sub-routine is called from several places, when an assertion inside it fails, it can be hard to tell which invocation of the sub-routine the failure is from. You can alleviate this problem using extra logging or custom failure messages, but that usually clutters up your tests. A better solution is to use the SCOPED_TRACE macro: テストサブルーチンが複数の場所から呼び出されて，その内部のアサーションが失敗したとき，サブルーチンのどの呼び出しに原因があるのか特定が難しくなる場合があります．ロギングを追加したり，独自の失敗メッセージを利用したりして分かりやすくすることもできますが，大抵はテストコードが汚くなります．もっと良い解決法は，SCOPED_TRACE マクロを利用することです． .. csv-table:: :header: SCOPED_TRACE(message); .. where message can be anything streamable to std::ostream. This macro will cause the current file name, line number, and the given message to be added in every failure message. The effect will be undone when the control leaves the current lexical scope. ここで，message は，std::ostream に出力可能な任意のメッセージです．このマクロは，現在のファイル名，行数，与えられたメッセージを各失敗メッセージに追加します．この効果は，現在の静的スコープを抜けると解除されます． .. For example, 以下に例を示します． .. 10: void Sub1(int n) { .. 11: EXPECT_EQ(1, Bar(n)); .. 12: EXPECT_EQ(2, Bar(n + 1)); .. 13: } .. 14: .. 15: TEST(FooTest, Bar) { .. 16: { .. 17: SCOPED_TRACE("A"); // This trace point will be included in .. 18: // every failure in this scope. .. 19: Sub1(1); .. 20: } .. 21: // Now it won't. .. 22: Sub1(9); .. 23: } .. code-block:: c void Sub1(int n) { EXPECT_EQ(1, Bar(n)); EXPECT_EQ(2, Bar(n + 1)); } TEST(FooTest, Bar) { { SCOPED_TRACE("A"); // このトレースポイントは，スコープ内の // 全ての失敗に追加されます． Sub1(1); } // ここは既に効果範囲外です． Sub1(9); } .. could result in messages like these: この結果，出力されるメッセージは次のようになります： :: path/to/foo_test.cc:11: Failure Value of: Bar(n) Expected: 1 Actual: 2 Trace: path/to/foo_test.cc:17: A path/to/foo_test.cc:12: Failure Value of: Bar(n + 1) Expected: 2 Actual: 3 .. Without the trace, it would've been difficult to know which invocation of Sub1() the two failures come from respectively. (You could add an extra message to each assertion in Sub1() to indicate the value of n, but that's tedious.) トレースがなければ，この2つの失敗がそれぞれ，Sub1() のどの呼び出しで起こったものかを知るのは困難でしょう．（Sub1() 内の各アサーションに，n の値を表すメッセージを追加することもできますが，面倒な方法です．） .. Some tips on using SCOPED_TRACE: SCOPED_TRACE を使う際のヒント： .. With a suitable message, it's often enough to use SCOPED_TRACE at the beginning of a sub-routine, instead of at each call site. .. When calling sub-routines inside a loop, make the loop iterator part of the message in SCOPED_TRACE such that you can know which iteration the failure is from. .. Sometimes the line number of the trace point is enough for identifying the particular invocation of a sub-routine. In this case, you don't have to choose a unique message for SCOPED_TRACE. You can simply use "". .. You can use SCOPED_TRACE in an inner scope when there is one in the outer scope. In this case, all active trace points will be included in the failure messages, in reverse order they are encountered. .. The trace dump is clickable in Emacs' compilation buffer - hit return on a line number and you'll be taken to that line in the source file! #. 多くの場合，サブルーチンの最初で，適切なメッセージを与えた SCOPED_TRACE を呼び出すだけで充分です．サブルーチンを呼び出す度に使う必要はありません． #. ループ内でサブルーチンを呼び出す場合，どのイテレータで失敗したのか分かるように，SCOPED_TRACE のメッセージに，ループイテレータが含まれるようにしてください． #. サブルーチンの呼び出し箇所を特定するために，トレースポイントの行番号だけで十分な場合もあります．その場合，SCOPED_TRACE に一意なメッセージを入れる必要はありません．単に，"" と指定することができます． #. あるスコープのさらに内側にあるスコープ内で SCOPED_TRACE を使うことができます．その場合，すべての有効なトレースポイントが，発生とは逆の順番で失敗メッセージに含まれます． #. トレースダンプは，Emacs のコンパイルバッファ内でクリックすることができます．行番号を選択するとソースファイルの該当行に飛びます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Propagating Fatal Failures .. _adv_propagating_fatal_failures: 致命的な失敗の伝播 ------------------ .. A common pitfall when using ASSERT_* and FAIL* is not understanding that when they fail they only abort the current function, not the entire test. For example, the following test will segfault: ASSERT_* や FAIL* を使う際によく陥る間違いは，それが失敗した場合に，テスト全体ではなく *現在の関数* のみを終了させるということを理解していない事によります． 例えば，次のテストはセグメンテーションフォルトを引き起こします． .. void Subroutine() { .. // Generates a fatal failure and aborts the current function. .. ASSERT_EQ(1, 2); .. // The following won't be executed. .. ... .. } .. TEST(FooTest, Bar) { .. Subroutine(); .. // The intended behavior is for the fatal failure .. // in Subroutine() to abort the entire test. .. // The actual behavior: the function goes on after Subroutine() returns. .. int* p = NULL; .. *p = 3; // Segfault! .. } .. code-block:: c void Subroutine() { // 致命的な失敗を生成し，現在の関数を抜けます． ASSERT_EQ(1, 2); // これ以降は実行されません． ... } TEST(FooTest, Bar) { Subroutine(); // Subroutine() 内部で致命的な失敗が起きた時に // 期待される挙動は，テスト全体を終了することです． // 実際の挙動：Subroutine() から返った後もこの関数は動作し続けます． int* p = NULL; *p = 3; // セグメンテーションフォルト } .. Since we don't use exceptions, it is technically impossible to implement the intended behavior here. To alleviate this, Google Test provides two solutions. You could use either the (ASSERT|EXPECT)_NO_FATAL_FAILURE assertions or the HasFatalFailure() function. They are described in the following two subsections. 我々は例外を利用していないので，ここで期待通りの動作を実装するのは技術的に不可能です．これを解決するため，Google Test では2つの方法を用意しています．(ASSERT|EXPECT)_NO_FATAL_FAILURE アサーション，または HasFatalFailure() 関数を利用することができます． これについては，以降の2つのサブセクションで説明します． .. Asserting on Subroutines .. _adv_asserting_on_subroutines: サブルーチンでのアサート ^^^^^^^^^^^^^^^^ .. As shown above, if your test calls a subroutine that has an ASSERT_* failure in it, the test will continue after the subroutine returns. This may not be what you want. 以前に説明したように，テストでサブルーチンを呼び出し，そこで ASSERT_* が失敗した場合，サブルーチンから返った後もテストは続行されます．これは，ユーザ望む挙動ではないかもしれません． .. Often people want fatal failures to propagate like exceptions. For that Google Test offers the following macros: 致命的な失敗を例外のように伝播したいと考えることがあります．そこで，Google Test では，以下のマクロが用意されています． .. Fatal assertion Nonfatal assertion Verifies .. ASSERT_NO_FATAL_FAILURE(statement); EXPECT_NO_FATAL_FAILURE(statement); statement doesn't generate any new fatal failures in the current thread. .. csv-table:: :header: 致命的なアサーション, 致命的ではないアサーション, 検証内容 :widths: 15,15,20 "ASSERT_NO_FATAL_FAILURE(statement);", "EXPECT_NO_FATAL_FAILURE(statement);", "statement が， 現在のスレッドで新たな失敗を生成しない" .. Only failures in the thread that executes the assertion are checked to determine the result of this type of assertions. If statement creates new threads, failures in these threads are ignored. この種類のアサーションでは，アサーションを実行するスレッド内の失敗のみがチェックされ，それによってアサーション結果が決まります． statement が新しいスレッドを作ったとしても，そのスレッドでの失敗は無視されます． .. Examples: 例: .. code-block:: c ASSERT_NO_FATAL_FAILURE(Foo()); int i; EXPECT_NO_FATAL_FAILURE({ i = Bar(); }); .. Availability: Linux, Windows, Mac. Assertions from multiple threads are currently not supported. *利用可能な環境：* Linux，Windows，Mac．現在のところ，マルチスレッドでのアサーションはサポートされていません． .. Checking for Failures in the Current Test .. _adv_checking_for_failures_in_the_current_test: 現在のテストで失敗のチェック ^^^^^^^^^^^^^^^^^^^ .. HasFatalFailure() in the ::testing::Test class returns true if an assertion in the current test has suffered a fatal failure. This allows functions to catch fatal failures in a sub-routine and return early. ::testing::Test クラスの HasFatalFailure() は，現在のテスト内のアサーションが致命的な失敗を起こした場合に true を返します．これにより，サブルーチン内の致命的な失敗をキャッチして，より早くリターンすることができます． .. code-block:: c class Test { public: ... static bool HasFatalFailure(); }; .. The typical usage, which basically simulates the behavior of a thrown exception, is: 典型的な使い方は，例外が投げられ場合と同様で，次のようになります： .. TEST(FooTest, Bar) { .. Subroutine(); .. // Aborts if Subroutine() had a fatal failure. .. if (HasFatalFailure()) .. return; .. // The following won't be executed. .. ... .. } .. code-block:: c TEST(FooTest, Bar) { Subroutine(); // Subroutine() で致命的な失敗が起こると終了． if (HasFatalFailure()) return; // これ以降は処理してほしくない． ... } .. If HasFatalFailure() is used outside of TEST() , TEST_F() , or a test fixture, you must add the ::testing::Test:: prefix, as in: HasFatalFailure() を TEST()，TEST_F()，またはテストフィクスチャ の外側で使う場合は，必ず次のように，先頭に ::testing::Test を追加してください． .. code-block:: c if (::testing::Test::HasFatalFailure()) return; .. Similarly, HasNonfatalFailure() returns true if the current test has at least one non-fatal failure, and HasFailure() returns true if the current test has at least one failure of either kind. 同様に，HasNonfatalFailure() は，現在のテストに1つでも致命的ではない失敗が含まれていれば true を返します．そして，HasFailure() は，致命的か致命的でないかに関わらず，現在のテストに1つでもエラーが含まれていれば， true を返します． .. Availability: Linux, Windows, Mac. HasNonfatalFailure() and HasFailure() are available since version 1.4.0. *利用可能な環境：* Linux，Windows，Mac．HasNonfatalFailure() と HasFailure() は，バージョン 1.4.0 以降で利用可能． .. Logging Additional Information .. _adv_logging_additional_information: その他の情報のロギング ====================== .. In your test code, you can call RecordProperty("key", value) to log additional information, where value can be either a C string or a 32-bit integer. The last value recorded for a key will be emitted to the XML output if you specify one. For example, the test テストコード中に，RecordProperty("key", value) 呼び出して追加情報のログを取ることができます．ここで，value は，C文字列または32ビット整数を表します．key に対して記録された最後の値が，例えば，XMLを指定すればその形式で出力されます． 例えば，次のテストを考えましょう． .. code-block:: c TEST_F(WidgetUsageTest, MinAndMaxWidgets) { RecordProperty("MaximumWidgets", ComputeMaxUsage()); RecordProperty("MinimumWidgets", ComputeMinUsage()); } .. will output XML like this: ここで出力されるXMLは，次のようになります： :: ... ... .. Note: *注意* ： .. RecordProperty() is a static member of the Test class. Therefore it needs to be prefixed with ::testing::Test:: if used outside of the TEST body and the test fixture class. .. key must be a valid XML attribute name, and cannot conflict with the ones already used by Google Test (name, status, time, and classname). * RecordProperty() は，Test クラスの static なメンバです．したがって，Test やテストフィクスチャクラスの外側で利用する場合は，先頭に ::testing::Test:: をつける必要があります． * key は，有効な XML 属性名でなければいけません．また，Google Test で利用している名前（name, status, time, classname）と同じものを使うことはできません .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Sharing Resources Between Tests in the Same Test Case .. _adv_sharing_resouces_btw_tests: 同じテストケースに属するテスト間でリソースを共有する ==================================================== .. Google Test creates a new test fixture object for each test in order to make tests independent and easier to debug. However, sometimes tests use resources that are expensive to set up, making the one-copy-per-test model prohibitively expensive. Google Test は，各テストを独立にしてデバッグしやすくするために，，各テスト毎に新しいテストフィクスチャオブジェクトを作成します． しかし，初期化にかかるコストが大きいリソースを使う場合，これを1つのテスト毎にコピーするモデルでは，コストがかかりすぎる場合があります． .. If the tests don't change the resource, there's no harm in them sharing a single resource copy. So, in addition to per-test set-up/tear-down, Google Test also supports per-test-case set-up/tear-down. To use it: テストがリソースを変更しない場合は，1つのリソースコピーを共有しても問題はありません．Google Test では，1つのテスト毎に set-up/tear-down を行う方法に加えて，テストケース毎に set-up/tear-down を行う方法もサポートしています．それを使用するには： .. In your test fixture class (say FooTest ), define as static some member variables to hold the shared resources. .. to set up the shared resources and a static void TearDownTestCase() function to tear them down. .. That's it! Google Test automatically calls SetUpTestCase() before running the first test in the FooTest test case (i.e. before creating the first FooTest object), and calls TearDownTestCase() after running the last test in it (i.e. after deleting the last FooTest object). In between, the tests can use the shared resources. テストフィクスチャクラス（ここでは，FooTest とします）内に，共有リソースを格納する static なメンバ変数を定義します． 同じテストフィクスチャクラス内に，共有リソースを初期化するための static void SetUpTestCase() 関数（SetupTestCase という風に小文字の u と綴らないように注意してください）を定義します． 同じく，共有リソースの終了処理を行う static void TearDownTestCase() を定義します． これだけです．Google Test は，FooTest テストケースの 最初のテスト が実行されるよりも前に（つまり，最初の FooTest オブジェクトが作成されるよりも前に） SetUpTestCase() を自動的に呼び出します．そして，最後のテスト の後で（つまり，最後の FooTest オブジェクトが削除された後で），TearDownTestCase() を呼び出します．この間，テストは共有リソースを利用できます． .. Remember that the test order is undefined, so your code can't depend on a test preceding or following another. Also, the tests must either not modify the state of any shared resource, or, if they do modify the state, they must restore the state to its original value before passing control to the next test. テストの順序は未定義なので，前や後で実行されるテストに依存するようなコードを書かないようにしてください．また，テストは共有リソースの状態を変更してはいけません．あるいは，状態を変更した場合は，次のテストに移行する前に必ず元の状態に戻さなければいけません． .. Here's an example of per-test-case set-up and tear-down: ここで，テストケース毎の set-up と tear-down の例を示します： .. code-block:: c class FooTest : public ::testing::Test { protected: // テストケース毎の set-up． // このテストケースの最初のテストよりも前に呼び出されます． // 必要ならば変更するしてください． static void SetUpTestCase() { shared_resource_ = new ...; } // テストケース毎の tear-down． // このテストケースの最後のテストの後で呼び出されます． // 必要ならば変更するしてください． static void TearDownTestCase() { delete shared_resource_; shared_resource_ = NULL; } // テスト毎の set-up と tear-down も通常通り定義できます． virtual void SetUp() { ... } virtual void TearDown() { ... } // 高コストのリソースが，全てのテストで共有されます． static T* shared_resource_; }; T* FooTest::shared_resource_ = NULL; TEST_F(FooTest, Test1) { ... ここで，shared_resource を参照できます ... } TEST_F(FooTest, Test2) { ... ここで，shared_resource を参照できます ... } .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Global Set-Up and Tear-Down .. _adv_global_setup_teardown: グローバルな Set-Up と Tear-Down ================================ .. Just as you can do set-up and tear-down at the test level and the test case level, you can also do it at the test program level. Here's how. まさに今，テスト単位あるいはテストケース単位で set-up や tear-down を実行したのと同様に，プログラム単位でそれらを実行することができます．ここでは，その方法を説明します． .. First, you subclass the ::testing::Environment class to define a test environment, which knows how to set-up and tear-down: まず，テスト環境を定義するための ::testing::Environment クラスの派生クラスを作り，そこに set-up と tear-down を定義します： .. code-block:: c class Environment { public: virtual ~Environment() {} // 環境の初期化方法を定義するには，これをオーバーライドしてください． virtual void SetUp() {} // 環境の終了処理を定義するには，これをオーバーライドしてください． virtual void TearDown() {} }; .. Then, you register an instance of your environment class with Google Test by calling the ::testing::AddGlobalTestEnvironment() function: そして， ::testing::AddGlobalTestEnvironment() 関数を使って，Environment クラスのインスタンスを Google Test に登録します． .. code-block:: c Environment* AddGlobalTestEnvironment(Environment* env); .. Now, when RUN_ALL_TESTS() is called, it first calls the SetUp() method of the environment object, then runs the tests if there was no fatal failures, and finally calls TearDown() of the environment object. RUN_ALL_TESTS() が実行されると，Environment オブジェクトの SetUp() メソッドが最初に呼び出されます．そこで致命的な失敗がなければ，以降のテストが実行され，最後に Environment オブジェクトの TearDown() が呼び出されます． .. It's OK to register multiple environment objects. In this case, their SetUp() will be called in the order they are registered, and their TearDown() will be called in the reverse order. 複数の Environment オブジェクトを登録しても問題ありません．その場合，登録した順番に SetUp() が実行され，その逆の準場で TearDown() が実行されます． .. Note that Google Test takes ownership of the registered environment objects. Therefore do not delete them by yourself. 登録された Environment オブジェクトの所有権は Google Test にあることに注意してください．したがって，ユーザはそれらを削除しないでください． .. You should call AddGlobalTestEnvironment() before RUN_ALL_TESTS() is called, probably in main(). If you use gtest_main, you need to call this before main() starts for it to take effect. One way to do this is to define a global variable like this: ユーザは，RUN_ALL_TESTS() よりも前に，おそらくは main() 関数で AddGlobalTestEnvironment() を呼び出す必要があります．gtest_main を利用する場合は，これを main() の開始前に呼ぶ必要があります．これを行う方法の1つは，次のようにグローバス変数を定義することです： .. code-block:: c ::testing::Environment* const foo_env = ::testing::AddGlobalTestEnvironment(new FooEnvironment); .. However, we strongly recommend you to write your own main() and call AddGlobalTestEnvironment() there, as relying on initialization of global variables makes the code harder to read and may cause problems when you register multiple environments from different translation units and the environments have dependencies among them (remember that the compiler doesn't guarantee the order in which global variables from different translation units are initialized). しかし，ユーザが自分の main() を書いて，そこで AddGlobalTestEnvironment() を呼び出すことを強く勧めます． グローバル変数の初期化に依存するコードは，読みにくくなります． また，異なる翻訳単位（オブジェクトファイル）で複数の Environment オブジェクトを登録し，それらが互いに依存している場合，問題が起こる可能性があります（コンパイラは，グローバル変数の初期化順序を保証しないことを思い出してください）． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Value Parameterized Tests .. _adv_value_parameterized_tests: 値をパラメータ化したテスト ========================== .. Value-parameterized tests allow you to test your code with different parameters without writing multiple copies of the same test. *値をパラメータ化したテスト* を用いると，同じテストをコピーしなくても，異なるパラメータでコードをテストできます． .. Suppose you write a test for your code and then realize that your code is affected by a presence of a Boolean command line flag. 例えば，ユーザがテストを書いた後に，テスト対象のコードがコマンドラインで与えられるブール値のフラグに影響される事に気づいたとします． .. code-block:: c TEST(MyCodeTest, TestFoo) { // foo() をテストするコード． } .. Usually people factor their test code into a function with a Boolean parameter in such situations. The function sets the flag, then executes the testing code. 通常は，テストコードの一部を関数に分割して，その引数にブール値を受け取るようにします．その関数でフラグをセットし，その後テストコードを実行します． .. code-block:: c void TestFooHelper(bool flag_value) { flag = flag_value; // foo() をテストするコード． } TEST(MyCodeTest, TestFooo) { TestFooHelper(false); TestFooHelper(true); } .. But this setup has serious drawbacks. First, when a test assertion fails in your tests, it becomes unclear what value of the parameter caused it to fail. You can stream a clarifying message into your EXPECT/ASSERT statements, but it you'll have to do it with all of them. Second, you have to add one such helper function per test. What if you have ten tests? Twenty? A hundred? しかし，この初期化方法には重大な問題があります．まず，テスト中のアサーションが失敗した場合，パラメータのどのような値が失敗の原因なのかが分からなくなるという点です．EXPECT/ASSERT に識別するためのメッセージを追加することもできますが，すべてを自分でやる必要があります．2つ目の問題点として，テスト毎にこのようなヘルパ関数を書く必要があるという点が挙げられます．10個のテストがある場合はどうでしょうか？ 20個なら？ 100個なら？ .. Value-parameterized tests will let you write your test only once and then easily instantiate and run it with an arbitrary number of parameter values. 値をパラメータ化したテストを利用すると，テストを1度だけ書き，それをインスタンス化して，任意の個数のパラメータで実行することができます． .. Here are some other situations when value-parameterized tests come handy: 値をパラメータ化したテストが便利な，いくつかの状況を説明します： .. You wan to test different implementations of an OO interface. .. You want to test your code over various inputs (a.k.a. data-driven testing). This feature is easy to abuse, so please exercise your good sense when doing it! * オブジェクト指向インタフェースの異なる実装をテストしたい場合 * 様々な入力でコードをテストしたい場合（これは，データ駆動テストとして知られています）．この特徴は乱用されやすいので，このような使い方をするときは是非ともセンスを磨いてください． .. How to Write Value-Parameterized Tests .. _adv_how_to_write_value-parameterized_tests: 値をパラメータ化したテストの書き方 ---------------------------------- .. To write value-parameterized tests, first you should define a fixture class. It must be derived from both ::testing::Test and ::testing::WithParamInterface (the latter is a pure interface), where T is the type of your parameter values. For convenience, you can just derive the fixture class from ::testing::TestWithParam, which itself is derived from both ::testing::Test and ::testing::WithParamInterface. T can be any copyable type. If it's a raw pointer, you are responsible for managing the lifespan of the pointed values. 値をパラメータ化したテストを書くには，まずフィクスチャクラスを定義する必要があります．また，それは ::testing::Test および ::testing::WithParamInterface の両方から派生しなければいけません（後者は，純粋インタフェースです）．ここで T は，パラメータ値の型を表します．利便性のため，::testing::Test と ::testing::WithParamInterface の両方から派生した ::testing::TestWithParam から，フィクスチャクラスを派生させることもできます．Tはコピー可能な任意の型です．これが通常のポインタである場合，ユーザはポインタが示す値の管理を行う責任があります． .. code-block:: c class FooTest : public ::testing::TestWithParam { // ここは，通常のフィクスチャクラスのメンバと同じように書くことができます． // テストパラメータにアクセスするには，クラスから GetParam() を呼び出します． // TestWithParam. }; // 既に存在するフィクスチャクラスにパラメータを追加したい場合は： class BaseTest : public ::testing::Test { ... }; class BarTest : public BaseTest, public ::testing::WithParamInterface { ... }; .. Then, use the TEST_P macro to define as many test patterns using this fixture as you want. The _P suffix is for "parameterized" or "pattern", whichever you prefer to think. 次に，希望の個数のテストパターンを定義するためのマクロ TEST_P を使います．この _P というサフィックスは，"Parameterized" または "pattern" を意味しますが，好きな方で考えてください． .. TEST_P(FooTest, DoesBlah) { .. // Inside a test, access the test parameter with the GetParam() method .. // of the TestWithParam class: .. EXPECT_TRUE(foo.Blah(GetParam())); .. ... .. } .. TEST_P(FooTest, HasBlahBlah) { .. ... .. } .. code-block:: c TEST_P(FooTest, DoesBlah) { // テスト内部では，TestWithParam クラスの GetParam() メソッド // を用いてテストパラメータにアクセスしてください： EXPECT_TRUE(foo.Blah(GetParam())); ...} TEST_P(FooTest, HasBlahBlah) { ... } .. Finally, you can use INSTANTIATE_TEST_CASE_P to instantiate the test case with any set of parameters you want. Google Test defines a number of functions for generating test parameters. They return what we call (surprise!) parameter generators. Here is a summary of them, which are all in the testing namespace: 最後に，任意のパラメータセットを与えたテストケースをインスタンス化するために，INSTANTIATE_TEST_CASE_P を使います． Google Test では，テストパラメータを生成するいくつかの関数を定義しています．これは，(なんと！)パラメータジェネレータ と呼ばれるものを返します．ここでは，その概要を示します．これはすべて， testing 名前空間に存在します． .. Range(begin, end[, step]) Yields values {begin, begin+step, begin+step+step, ...}. The values do not include end. step defaults to 1. .. Values(v1, v2, ..., vN) Yields values {v1, v2, ..., vN}. .. ValuesIn(container) and ValuesIn(begin, end) Yields values from a C-style array, an STL-style container, or an iterator range [begin, end). container, begin, and end can be expressions whose values are determined at run time. .. Bool() Yields sequence {false, true}. .. Combine(g1, g2, ..., gN) Yields all combinations (the Cartesian product for the math savvy) of the values generated by the N generators. This is only available if your system provides the header. If you are sure your system does, and Google Test disagrees, you can override it by defining GTEST_HAS_TR1_TUPLE=1. See comments in include/gtest/internal/gtest-port.h for more information. .. csv-table:: :header: :widths: 10,35 "Range(begin, end[, step])", "{begin, begin+step, begin+step+step, ...} という値を生成します．end は値に含まれません．step のデフォルト値は1です．" "Values(v1, v2, ..., vN)", "{v1, v2, ..., vN} という値を生成します．" "ValuesIn(container) と ValuesIn(begin, end)", "C言語形式の配列，STL形式のコンテナ，またはイテレータの範囲 [begin, end) で表される値を生成します．" "Bool()", "シーケンス {false, true} を生成します．container, begin, end という表現により，その値を実行時に決定することができます．" "Combine(g1, g2, ..., gN)", "N 個のジェネレータから作成された値のすべての組み合わせ（数学でいうデカルト積）を生成します．これは，ユーザのシステムに ヘッダが存在する場合のみ有効です．システムにヘッダが間違いなく存在するにも関わらず，Google Test がないという場合は，GTEST_HA S_TR1_TUPLE=1 を定義することでオーバーライドできます．詳細は， `include/gtest/internal/gtest-port.h `_ のコメントを参照してください．" .. For more details, see the comments at the definitions of these functions in the source code. 詳細については， `ソースコード `_ 中でこれらの関数を定義している箇所のコメントを参照してください． .. The following statement will instantiate tests from the FooTest test case each with parameter values "meeny", "miny", and "moe". 以下の文は，テストケース FooTest のテストに，それぞれパラメータ値 "meeny"，"miny"，"moe" を与えてインスタンス化します． .. code-block:: c INSTANTIATE_TEST_CASE_P(InstantiationName, FooTest, ::testing::Values("meeny", "miny", "moe")); .. To distinguish different instances of the pattern (yes, you can instantiate it more than once), the first argument to INSTANTIATE_TEST_CASE_P is a prefix that will be added to the actual test case name. Remember to pick unique prefixes for different instantiations. The tests from the instantiation above will have these names: あるパターンを持った別のインスタンス（そう，ユーザは1度以上インスタンス化できるのです）を区別するために， INSTANTIATE_TEST_CASE_P の最初の引数として，実際のテストケース名の先頭に追加されるプリフィックスを与えます．異なるインスタンスには，異なるプリフィックスを与えてください．以上のようにインスタンス化されたテストは，以下のような名前を持ちます： * InstantiationName/FooTest.DoesBlah/0 for "meeny" * InstantiationName/FooTest.DoesBlah/1 for "miny" * InstantiationName/FooTest.DoesBlah/2 for "moe" * InstantiationName/FooTest.HasBlahBlah/0 for "meeny" * InstantiationName/FooTest.HasBlahBlah/1 for "miny" * InstantiationName/FooTest.HasBlahBlah/2 for "moe" .. You can use these names in --gtest_filter. これらの名前は， :ref:`---gtest_filter ` で利用できます． .. This statement will instantiate all tests from FooTest again, each with parameter values "cat" and "dog": 次の文は，FooTest の全てのテストにそれぞれ "cat" および "dog" というパラメータを与えてインスタンス化します． .. code-block:: c const char* pets[] = {"cat", "dog"}; INSTANTIATE_TEST_CASE_P(AnotherInstantiationName, FooTest, ::testing::ValuesIn(pets)); .. The tests from the instantiation above will have these names: このようにインスタンス化されたテストは，次のような名前になります． * AnotherInstantiationName/FooTest.DoesBlah/0 for "cat" * AnotherInstantiationName/FooTest.DoesBlah/1 for "dog" * AnotherInstantiationName/FooTest.HasBlahBlah/0 for "cat" * AnotherInstantiationName/FooTest.HasBlahBlah/1 for "dog" .. Please note that INSTANTIATE_TEST_CASE_P will instantiate all tests in the given test case, whether their definitions come before or after the INSTANTIATE_TEST_CASE_P statement. INSTANTIATE_TEST_CASE_P は，与えられたテストケース内の 全ての テストをインスタンス化することに注意してください．テスト自体の定義が INSTANTIATE_TEST_CASE_P 文の前にあるか後にあるかは関係ありません． .. You can see these files for more examples. `これらの `_ `ファイル `_ に，別の例が載っています． .. Availability: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0. *利用可能な環境：* Linux，Windows（MSVC 8.0以降が必要），Mac．バージョン 1.2.0 以降． .. Creating Value-Parameterized Abstract Tests .. _adv_creating_value-parameterized_abstract_tests: 値をパラメータ化した抽象テスト --------------------------------------- .. In the above, we define and instantiate FooTest in the same source file. Sometimes you may want to define value-parameterized tests in a library and let other people instantiate them later. This pattern is known as abstract tests. As an example of its application, when you are designing an interface you can write a standard suite of abstract tests (perhaps using a factory function as the test parameter) that all implementations of the interface are expected to pass. When someone implements the interface, he can instantiate your suite to get all the interface-conformance tests for free. これまでの説明では，FooTest の定義とインスタンス化を同じソースファイル内でおこなっていました．しかし，ライブラリ内に 値をパラメータ化したテスト を定義し，後で別のユーザがそれをインスタンス化する，という使い方をしたい場合もあります． このパターンは， *抽象テスト* として知られています．1つの利用例として，インタフェースを設計する場合を考えてみます．そこでは，インタフェースの実装すべてが通過できるはずの標準的な抽象テストスイートを書くことができます（おそらく，テストパラメータとしてファクトリ関数が利用されるでしょう）．そして，インタフェースを実装する人は，インタフェースの適合テストを取得するために，あなたのテストスイートを自由にインスタンス化することができます． .. To define abstract tests, you should organize your code like this: 抽象テストを定義するには， 次のようにコードを構造化する必要があります： .. Put the definition of the parameterized test fixture class (e.g. FooTest) in a header file, say foo_param_test.h. Think of this as declaring your abstract tests. .. Put the TEST_P definitions in foo_param_test.cc, which includes foo_param_test.h. Think of this as implementing your abstract tests. #. パラメータ化されたテストのフィクスチャクラス（例えば，FooTest）の定義は，例えば foo_param_test.h という名前のヘッダファイルに書いてください． これは，抽象テストの *宣言* と見なせます． #. TEST_P の定義は，foo_param_test.cc に書いてください．ここでは，foo_param_test.h がインクルードされます．これは，抽象テストの *実装* と見なせます． .. Once they are defined, you can instantiate them by including foo_param_test.h, invoking INSTANTIATE_TEST_CASE_P(), and linking with foo_param_test.cc. You can instantiate the same abstract test case multiple times, possibly in different source files. これが1度定義された後は，foo_param_test.h をインクルードして， INSTANTIATE_TEST_CASE_P() を呼び出し，foo_param_test.cc をリンクすることで，自由にテストをインスタンス化することができます．異なるソースファイルで，同じ抽象テストを複数回インスタンス化することができます． .. Typed Tests .. _adv_typed_tests: 型付けテスト ============ .. Suppose you have multiple implementations of the same interface and want to make sure that all of them satisfy some common requirements. Or, you may have defined several types that are supposed to conform to the same "concept" and you want to verify it. In both cases, you want the same test logic repeated for different types. 同じインタフェースの複数の実装があり，全ての実装がある共通の要求に対して安全であることを確認したいとします．あるいは，同じ「コンセプト」を満足するはずの複数の定義型があり，そのことを確認したいとします．どちらの場合も，同じテストロジックを異なる型に対して繰り返したい，ということになります． .. While you can write one TEST or TEST_F for each type you want to test (and you may even factor the test logic into a function template that you invoke from the TEST), it's tedious and doesn't scale: if you want m tests over n types, you'll end up writing m*n TESTs. テスト対象となるそれぞれの型に対して TEST_F や TEST を書くことはできますが （さらに，テストロジックの一部を関数テンプレートに分離して，それを TEST から呼び出すことになるでしょう），それは面倒でスケールしない作業です．つまり，m 個のテストを n 個の型に対して行いたい場合，m*n 個の TEST が必要になってしまいます． .. Typed tests allow you to repeat the same test logic over a list of types. You only need to write the test logic once, although you must know the type list when writing typed tests. Here's how you do it: *型付けテスト* を使うと，同じテストロジックを型のリストに対して繰り返すことができます．型付けテストを書く時点で型リストが分かっている必要がありますが，テストロジックは1度書くだけで構いません．ここでは，その方法を説明します： .. First, define a fixture class template. It should be parameterized by a type. Remember to derive it from ::testing::Test: まず，フィクスチャクラステンプレートを定義します．これは，型でパラメータ化する必要があります．また，::testing::Test を継承することを忘れないでください： .. code-block:: c template class FooTest : public ::testing::Test { public: ... typedef std::list List; static T shared_; T value_; }; .. Next, associate a list of types with the test case, which will be repeated for each type in the list: 次に，型リストと，リスト内のそれぞれの型に対して繰り返されるテストケースとを関連付けます． .. code-block:: c typedef ::testing::Types MyTypes; TYPED_TEST_CASE(FooTest, MyTypes); .. The typedef is necessary for the TYPED_TEST_CASE macro to parse correctly. Otherwise the compiler will think that each comma in the type list introduces a new macro argument. typedef は，TYPED_TEST_CASE マクロが正しくパースを行うために必要です．これがないと，コンパイラは，型リスト中のカンマをマクロ引数の区切り文字と見なしてしまいます． .. Then, use TYPED_TEST() instead of TEST_F() to define a typed test for this test case. You can repeat this as many times as you want: 次に，TEST_F() の代わりに TYPED_TEST() を使って，このテストケースにおける型付けテストを定義します．必要なだけ，テストの定義を行ってください .. TYPED_TEST(FooTest, DoesBlah) { .. // Inside a test, refer to the special name TypeParam to get the type .. // parameter. Since we are inside a derived class template, C++ requires .. // us to visit the members of FooTest via 'this'. .. TypeParam n = this->value_; .. // To visit static members of the fixture, add the 'TestFixture::' .. // prefix. .. n += TestFixture::shared_; .. // To refer to typedefs in the fixture, add the 'typename TestFixture::' .. // prefix. The 'typename' is required to satisfy the compiler. .. typename TestFixture::List values; .. values.push_back(n); .. ... .. } .. code-block:: c TYPED_TEST(FooTest, DoesBlah) { // テスト内部で型パラメータを取得するには，特別な名前 TypeParam を参照します． // 派生クラステンプレート内部なので，FooTest のメンバにアクセスするには // 'this' を使う必要があります． TypeParam n = this->value_; // フィクスチャの static なメンバにアクセスするには， // 'TestFixutre::' プリフィックスを追加します． n += TestFixture::shared_; // フィクスチャ内で typedef されたメンバにアクセスするには，'typename TestFixture::' プリフィックスを追加します． // 'typename' は，コンパイラに型名であることを知らせるためにあります． typename TestFixture::List values; values.push_back(n); ... } TYPED_TEST(FooTest, HasPropertyA) { ... } TYPED_TEST(FooTest, HasPropertyA) { ... } .. You can see samples/sample6_unittest.cc for a complete example. 完全な例を見るには，samples/sample6_unittest.cc を参照してください． .. Availability: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.1.0. *利用可能な環境：* Linux，Windows（MSVC 8.0以降が必要），Mac．バージョン 1.1.0 以降． .. Type-Parameterized Tests .. _adv_type-parameterized_tests: 型をパラメータ化したテスト ========================== .. Type-parameterized tests are like typed tests, except that they don't require you to know the list of types ahead of time. Instead, you can define the test logic first and instantiate it with different type lists later. You can even instantiate it more than once in the same program. *型をパラメータ化したテスト* は型付けテストと似ていますが，事前に型のリストを知っておく必要がない，という点が異なります．その代り，まずテストロジックを定義し，後から異なる型リストを与えてインスタンス化します．同じプログラム中で，複数回インスタンス化することもできます． .. If you are designing an interface or concept, you can define a suite of type-parameterized tests to verify properties that any valid implementation of the interface/concept should have. Then, the author of each implementation can just instantiate the test suite with his type to verify that it conforms to the requirements, without having to write similar tests repeatedly. Here's an example: あなたがインタフェースやコンセプトを設計する立場ならば，インタフェース/コンセプトの実装すべてが持つべきプロパティを検証するための，型をパラメータ化したテストスイートを定義できます．そして，各実装を行う人々は，その実装が要求を満たしていることを確認するために，テストスイートをそれぞれの型でインスタンス化することができます． 以下に，例を示します： .. First, define a fixture class template, as we did with typed tests: まず，型付けテストの場合と同様に，フィクスチャクラステンプレートを定義します： .. code-block:: c template class FooTest : public ::testing::Test { ... }; .. Next, declare that you will define a type-parameterized test case: 次に，型をパラメータ化したテストケースを宣言します： .. code-block:: c TYPED_TEST_CASE_P(FooTest); .. The _P suffix is for "parameterized" or "pattern", whichever you prefer to think. この _P というサフィックスは，"Parameterized" または "pattern" を意味しますが，好きな方で考えてください． .. Then, use TYPED_TEST_P() to define a type-parameterized test. You can repeat this as many times as you want: そして，TYPED_TEST_P() を用いて，型をパラメータ化したテストを定義します．必要なだけ，テストの定義を行ってください .. TYPED_TEST_P(FooTest, DoesBlah) { .. // Inside a test, refer to TypeParam to get the type parameter. .. TypeParam n = 0; .. ... .. } .. TYPED_TEST_P(FooTest, HasPropertyA) { ... } .. code-block:: c TYPED_TEST_P(FooTest, DoesBlah) { // テスト内部で型パラメータを取得するには，特別な名前 TypeParam を参照します． TypeParam n = 0; ... } TYPED_TEST_P(FooTest, HasPropertyA) { ... } .. Now the tricky part: you need to register all test patterns using the REGISTER_TYPED_TEST_CASE_P macro before you can instantiate them. The first argument of the macro is the test case name; the rest are the names of the tests in this test case: さて，ここがトリッキーな箇所です：これらをインスタンス化する前に，REGISTER_TYPED_TEST_CASE_P マクロを用いて全てのテストパターンを登録する必要があります．マクロの最初の引数は，テストケースの名前です．そして，それ以降の引数は，そのテストケースに属するテストの名前です． .. code-block:: c REGISTER_TYPED_TEST_CASE_P(FooTest, DoesBlah, HasPropertyA); .. Finally, you are free to instantiate the pattern with the types you want. If you put the above code in a header file, you can #include it in multiple C++ source files and instantiate it multiple times. 最後に，好きな型を与えて，自由にインスタンス化を行います．上述のコードをヘッダファイルに書けば，複数の C++ ソースファイルに #include 文を書いて，複数回インスタンス化することができます． .. code-block:: c typedef ::testing::Types MyTypes; INSTANTIATE_TYPED_TEST_CASE_P(My, FooTest, MyTypes); .. To distinguish different instances of the pattern, the first argument to the INSTANTIATE_TYPED_TEST_CASE_P macro is a prefix that will be added to the actual test case name. Remember to pick unique prefixes for different instances. このパターンにおける異なるインスタンスを区別するために，INSTANTIATE_TYPED_TEST_CASE_P マクロの最初の引数として，実際のテストケース名の先頭に追加されるプリフィックスを渡します．異なるインスタンスには，異なるプリフィックスを与えてください． .. In the special case where the type list contains only one type, you can write that type directly without ::testing::Types<...>, like this: 型リストが 1 つの型しか含まない特別な場合は，::testing::Types<...> なしで直接，次にように書くことができます． .. code-block:: c INSTANTIATE_TYPED_TEST_CASE_P(My, FooTest, int); .. You can see samples/sample6_unittest.cc for a complete example 完全な例を見るには，samples/sample6_unittest.cc を参照してください． .. Availability: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.1.0. *利用可能な環境：* Linux，Windows（MSVC 8.0以降が必要），Mac．バージョン 1.1.0 以降． .. Testing Private Code .. _adv_testing_private_code: Private コードのテスト ====================== .. If you change your software's internal implementation, your tests should not break as long as the change is not observable by users. Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces. ソフトの内部的実装を変更しても，ユーザからその変更が見えない限りは，テストは失敗するべきではありません．よって， *ブラックボックステストの原則* に従い，大部分のコードテストは public インタフェースを使って行われるべきです． .. If you still find yourself needing to test internal implementation code, consider if there's a better design that wouldn't require you to do so. If you absolutely have to test non-public interface code though, you can. There are two cases to consider: もし，まだ内部的な実装コードをテストする必要があるならば，そうしなくてもよい設計がないかどうか考えてください．しかし，どうしても public ではないインタフェースを通してテストを行わなければならない場合は，そうすることもできます．2つの場合を考えてみましょう： .. Static functions (not the same as static member functions!) or unnamed namespaces, and .. Private or protected class members * static な関数（ static なメンバ関数という意味ではありません），または匿名の名前空間 * private または protected なクラスメンバ .. Static Functions .. _adv_static_functions: Static な関数 ------------- .. Both static functions and definitions/declarations in an unnamed namespace are only visible within the same translation unit. To test them, you can #include the entire .cc file being tested in your *_test.cc file. (#including .cc files is not a good way to reuse code - you should not do this in production code!) 匿名の名前空間に属する static な関数とその定義/宣言はどちらも，同じ翻訳単位からのみ参照できます．それらをテストするために，*_test.cc ファイル内で，テスト対象となる .cc ファイル全体を #include することができます．（コードを再利用するために .cc ファイルをインクルードするのは良い方法とはいえません - 製品版のコードでは，このようなことしないでください！） .. However, a better approach is to move the private code into the foo::internal namespace, where foo is the namespace your project normally uses, and put the private declarations in a *-internal.h file. Your production .cc files and your tests are allowed to include this internal header, but your clients are not. This way, you can fully test your internal implementation without leaking it to your clients. しかし，より良い方法は，private なコードを foo::internal 名前空間に移動し， private 宣言を *-internal.h で行うことです．ここで，foo は，プロジェクトで通常使用している名前空間です．製品版の .cc ファイルやテストからは，この internal ヘッダをインクルードすることができますが，顧客側からはできません．この方法では，内部実装を顧客側に晒すことなく完全にテストができます． .. Private Class Members .. _adv_private_class_members: Private クラスメンバ -------------------- .. Private class members are only accessible from within the class or by friends. To access a class' private members, you can declare your test fixture as a friend to the class and define accessors in your fixture. Tests using the fixture can then access the private members of your production class via the accessors in the fixture. Note that even though your fixture is a friend to your production class, your tests are not automatically friends to it, as they are technically defined in sub-classes of the fixture. private なクラスメンバは，そのクラスや friend クラスからのみアクセス可能です．クラスの Private メンバにアクセスするには，テストフィクスチャをそのクラスの friend として宣言して，フィクスチャクラスにアクセサを定義します．そして，そのフィクスチャを利用するテストは，フィクスチャのアクセサを介してクラスの private メンバにアクセスできます． フィクスチャクラスは製品版クラスの friend ではありますが，テストも自動的にその friend になるわけではなく，フィクスチャの派生クラスとして定義されることに注意してください． .. Another way to test private members is to refactor them into an implementation class, which is then declared in a *-internal.h file. Your clients aren't allowed to include this header but your tests can. Such is called the Pimpl (Private Implementation) idiom. private なメンバをテストするもう1つの方法は，そのメンバを実装クラスとして書き出し，宣言だけを *-internal.h ファイル内で行うことです．顧客側は，このヘッダファイルをインクルードできませんが，テストからはインクルード可能です．これは，Pimpl（Private Implementation）イディオムと呼ばれます． .. Or, you can declare an individual test as a friend of your class by adding this line in the class body: 次のような行をクラスに追加して，個々のテストをクラスの friend として宣言する，という方法もあります． .. code-block:: c FRIEND_TEST(TestCaseName, TestName); For example, // foo.h #include "gtest/gtest_prod.h" // FRIEND_TEST を定義します class Foo { ... private: FRIEND_TEST(FooTest, BarReturnsZeroOnNull); int Bar(void* x); }; // foo_test.cc ... TEST(FooTest, BarReturnsZeroOnNull) { Foo foo; EXPECT_EQ(0, foo.Bar(NULL)); // Foo の private メンバ Bar() を使います． } .. Pay special attention when your class is defined in a namespace, as you should define your test fixtures and tests in the same namespace if you want them to be friends of your class. For example, if the code to be tested looks like: あなたのクラスがある名前空間内で定義されている場合は特に注意してください．つまり，テストフィクスチャとテストを，あなたのクラスの friend としたいならば，それらは同じ名前空間内で定義する必要があります．例えば，次のようなコードをテストしたいとします： .. code-block:: c namespace my_namespace { class Foo { friend class FooTest; FRIEND_TEST(FooTest, Bar); FRIEND_TEST(FooTest, Baz); ... definition of the class Foo ... }; } // my_namespace 名前空間 .. Your test code should be something like: この場合，テストコードは次のようになります： .. code-block:: c namespace my_namespace { class FooTest : public ::testing::Test { protected: ... }; TEST_F(FooTest, Bar) { ... } TEST_F(FooTest, Baz) { ... } } // my_namespace 名前空間 .. Catching Failures .. _adv_catching_failures: 失敗をキャッチする ================== .. If you are building a testing utility on top of Google Test, you'll want to test your utility. What framework would you use to test it? Google Test, of course. Google Test を使ってテストユーティリティを作ると，そのテストユーティリティのテストをしたくなります． そのテストには，何のテストフレームワークを使いたいですか？もちろん Google Test ですよね． .. The challenge is to verify that your testing utility reports failures correctly. In frameworks that report a failure by throwing an exception, you could catch the exception and assert on it. But Google Test doesn't use exceptions, so how do we test that a piece of code generates an expected failure? ここでの問題は，あなたのテストユーティリティが正しく失敗を報告するかどうかを検証することです．例外を投げることで失敗を報告するフレームワークでは，それをキャッチしてアサートすることもできるでしょう．しかし，Google Test では例外を利用しません．コードが期待通りに失敗を生成するかどうかを，どうやってテストすればいいのでしょうか？ .. "gtest/gtest-spi.h" contains some constructs to do this. After #including this header, you can use "gtest/gtest-spi.h" には，これを行うためのクラス類が含まれています． このヘッダをインクルードすると，次のマクロを利用できます． .. csv-table:: :header: "EXPECT_FATAL_FAILURE(statement, substring);" .. to assert that statement generates a fatal (e.g. ASSERT_*) failure whose message contains the given substring, or use これは，致命的な失敗（例えば，ASSERT_*）を生成する *statement* をアサートします．この失敗メッセージには，与えられた *substring* が含まれます． .. csv-table:: :header: "EXPECT_NONFATAL_FAILURE(statement, substring);" .. if you are expecting a non-fatal (e.g. EXPECT_*) failure. 致命的ではない失敗（例えば，EXPECT_*）を想定する場合は，こちらを利用してください． .. For technical reasons, there are some caveats: 技術的な理由により，いくつの制限があります： .. You cannot stream a failure message to either macro. .. statement in EXPECT_FATAL_FAILURE() cannot reference local non-static variables or non-static members of this object. .. statement in EXPECT_FATAL_FAILURE() cannot return a value. どちらのマクロでも，失敗メッセージをストリームに出力することができません． EXPECT_FATAL_FAILURE() の statement は，static ではないローカル変数や，this オブジェクトの static ではないメンバを参照できません． EXPECT_FATAL_FAILURE() の statement は，値を返すことはできません． .. Note: Google Test is designed with threads in mind. Once the synchronization primitives in "gtest/internal/gtest-port.h" have been implemented, Google Test will become thread-safe, meaning that you can then use assertions in multiple threads concurrently. Before *注意* ： Google Test はスレッドを考慮して設計されています．1度 "gtest/internal/gtest-port.h" の同期プリミティブがインスタンス化されると，Google Test はスレッドセーフになります．つまり，それ以降はマルチスレッドで同時にアサーションを利用できます． .. that, however, Google Test only supports single-threaded usage. Once thread-safe, EXPECT_FATAL_FAILURE() and EXPECT_NONFATAL_FAILURE() will capture failures in the current thread only. If statement creates new threads, failures in these threads will be ignored. If you want to capture failures from all threads instead, you should use the following macros: しかし，それ以前では，シングルスレッドでのみ利用できます．1度スレッドセーフになると，EXPECT_FATAL_FAILURE() と EXPECT_NONFATAL_FAILURE() は，現在のスレッドにおける失敗だけをキャッチするようになります．statement が新しいスレッドを作成する場合も，そのスレッドでの失敗は無視されます．もし全てのスレッドでの失敗をキャッチしたい場合は，次のマクロを利用する必要があります． .. csv-table:: :header: "EXPECT_FATAL_FAILURE_ON_ALL_THREADS(statement, substring);" "EXPECT_NONFATAL_FAILURE_ON_ALL_THREADS(statement, substring);" .. Getting the Current Test's Name .. _adv_getting_the_current_tests_names: 現在のテスト名を取得する ======================== .. Sometimes a function may need to know the name of the currently running test. For example, you may be using the SetUp() method of your test fixture to set the golden file name based on which test is running. The ::testing::TestInfo class has this information: 現在実行しているテストの名前が必要になる事態が考えられます．例えば，テストフィクスチャの SetUp() メソッド中で，期待値の書かれたファイル名を実行中のテストに基づいて決めることがあるかもしれません．::testing::TestInfo クラスには，この情報が入っています． .. namespace testing { .. class TestInfo { .. public: .. // Returns the test case name and the test name, respectively. .. // .. // Do NOT delete or free the return value - it's managed by the .. // TestInfo class. .. const char* test_case_name() const; .. const char* name() const; .. }; .. } // namespace testing .. code-block:: c namespace testing { class TestInfo { public: // それぞれ，テストケース名とテスト名を返します． // // 返されるポインタは TestInfo クラスで管理されるので， // 削除したり解放したりしないでください． const char* test_case_name() const; const char* name() const; }; } // namespace testing .. To obtain a TestInfo object for the currently running test, call .. current_test_info() on the UnitTest singleton object: 実行中のテストに対する TestInfo オブジェクトを取得するには， UnitTest シングルトンオブジェクトで current_test_info() を呼び出してください． .. // Gets information about the currently running test. .. // Do NOT delete the returned object - it's managed by the UnitTest class. .. const ::testing::TestInfo* const test_info = .. ::testing::UnitTest::GetInstance()->current_test_info(); .. printf("We are in test %s of test case %s.\n", .. test_info->name(), test_info->test_case_name()); .. code-block:: c // 現在実行中のテストに関する情報を取得します． // 返されるオブジェクトは UnitTest クラスで管理されるので，削除しないでください． const ::testing::TestInfo* const test_info = printf("We are in test %s of test case %s.\n", test_info->name(), test_info->test_case_name()); .. current_test_info() returns a null pointer if no test is running. In particular, you cannot find the test case name in TestCaseSetUp(), TestCaseTearDown() (where you know the test case name implicitly), or functions called from them. テストが実行中でない場合， current_test_info() は，NULLポインタを返します．具体的に言えば，TestCaseSetUp() や TestCaseTearDown() （この時点で，テストケース名は既に分かっているわけですが），そこから呼び出される関数では，テストケース名を取得することはできません． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Extending Google Test by Handling Test Events .. _adv_extending_google_test_by_handling_test_events: テストイベントをハンドリングして Google Test を拡張する ======================================================= .. Google Test provides an event listener API to let you receive notifications about the progress of a test program and test failures. The events you can listen to include the start and end of the test program, a test case, or a test method, among others. You may use this API to augment or replace the standard console output, replace the XML output, or provide a completely different form of output, such as a GUI or a database. You can also use test events as checkpoints to implement a resource leak checker, for example. Google Test にはイベントリスナー API が用意されており，テストプログラムの進捗やテストの失敗に関する通知を受け取ることができます． 受け取ることができるイベントは，テストプログラムやテストケース，テストメソッドなどの開始と終了です． このAPIを利用して，コンソールへの標準出力の拡張，置き換えを行ったり，XML 出力を置き換えたり，さらには GUI やデータベースのように出力形式が全く異なるものを提供したり，といったことが可能になります．例えば，リソースリークチェッカーを実装するためのチェックポイントとして，テストイベントを利用できます． .. Availability: Linux, Windows, Mac; since v1.4.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.4.0 以降． .. Defining Event Listeners .. _adv_defining_event_listeners: イベントリスナーの定義 ---------------------- .. To define a event listener, you subclass either testing::TestEventListener or testing::EmptyTestEventListener. The former is an (abstract) interface, where each pure virtual method can be overridden to handle a test event (For example, when a test starts, the OnTestStart() method will be called.). The latter provides an empty implementation of all methods in the interface, such that a subclass only needs to override the methods it cares about. イベントリスナーを定義するためには， `testing::TestEventListener `_ または `testing::EmptyTestEventListener `_ を継承します．前者は（抽象）インタフェースで，その純仮想メソッドがオーバーライドされ，テストイベントとして扱われます（例えば，テストが開始したときに OnTestStart() メソッドが呼び出されます）．後者が提供するインタフェースメソッドの実装はすべて空で，派生クラスで必要なメソッドだけをオーバーライドします． .. When an event is fired, its context is passed to the handler function as an argument. The following argument types are used: イベントが起こると，そのコンテキストがハンドラ関数の引数に渡されます．渡される引数の型は，次に示すとおりです： .. UnitTest reflects the state of the entire test program, .. TestCase has information about a test case, which can contain one or more tests, .. TestInfo contains the state of a test, and .. TestPartResult represents the result of a test assertion. * `UnitTest `_ は，テストプログラム全体の状態を反映するものです． * `TestCase `_ は，テストケースに関する情報を持ちます．テストケースには，1つ以上のテストが含まれます． * `TestInfo `_ は，テストの状態に関するものです． * `TestPartResult `_ は，テストアサーションの結果を表します． .. An event handler function can examine the argument it receives to find out interesting information about the event and the test program's state. Here's an example: イベントハンドラ関数は，渡された引数を検査して，そのイベントとテストプログラムの状態に関する情報を得ることができます．次に例を示します： .. code-block:: c class MinimalistPrinter : public ::testing::EmptyTestEventListener { // テスト開始前に呼ばれます． virtual void OnTestStart(const ::testing::TestInfo& test_info) { printf("*** Test %s.%s starting.\n", test_info.test_case_name(), test_info.name()); } // アサーションが失敗した後，または SUCCEED() が実行された後に呼ばれます． virtual void OnTestPartResult( const ::testing::TestPartResult& test_part_result) { printf("%s in %s:%d\n%s\n", test_part_result.failed() ? "*** Failure" : "Success", test_part_result.file_name(), test_part_result.line_number(), test_part_result.summary()); } // テスト終了後に呼ばれます． virtual void OnTestEnd(const ::testing::TestInfo& test_info) { printf("*** Test %s.%s ending.\n", test_info.test_case_name(), test_info.name()); } }; .. Using Event Listeners .. _adv_using_event_listeners: イベントリスナーを利用する -------------------------- .. To use the event listener you have defined, add an instance of it to the Google Test event listener list (represented by class TestEventListeners - note the "s" at the end of the name) in your main() function, before calling RUN_ALL_TESTS(): 定義したイベントリスナーを使うには，そのインスタンスを Google Test イベントリスナーリスト（これは， `TestEventListeners `_ クラスで表されます．最後の "s" に注意してください）に登録します．この登録作業は，main() 関数内で RUN_ALL_TEST() を呼ぶよりも前に行います． .. int main(int argc, char** argv) { .. ::testing::InitGoogleTest(&argc, argv); .. // Gets hold of the event listener list. .. ::testing::TestEventListeners& listeners = .. ::testing::UnitTest::GetInstance()->listeners(); .. // Adds a listener to the end. Google Test takes the ownership. .. listeners.Append(new MinimalistPrinter); .. return RUN_ALL_TESTS(); .. } .. code-block:: c int main(int argc, char** argv) { ::testing::InitGoogleTest(&argc, argv); // イベントリスナーリストを取得します． ::testing::TestEventListeners& listeners = ::testing::UnitTest::GetInstance()->listeners(); // 末尾にリスナーを追加します．Google Test に所有権が移ります． listeners.Append(new MinimalistPrinter); return RUN_ALL_TESTS(); } .. There's only one problem: the default test result printer is still in effect, so its output will mingle with the output from your minimalist printer. To suppress the default printer, just release it from the event listener list and delete it. You can do so by adding one line: ここで1つ問題があります：テスト結果のデフォルト出力リスナーもまだ生きているので，その出力が，あなたのリスナーからの出力と混ざってしまいます．デフォルトの出力を抑制するには，それをイベントリスナーリストから外して削除してください．そのためには，以下のように1行追加します： .. code-block:: c ... delete listeners.Release(listeners.default_result_printer()); listeners.Append(new MinimalistPrinter); return RUN_ALL_TESTS(); .. Now, sit back and enjoy a completely different output from your tests. For more details, you can read this sample. 後は，テストが今までとはまったく違う出力をする様子を堪能してください．さらに詳細を知りたい場合は， `サンプル `_ を参照できます． .. You may append more than one listener to the list. When an On*Start() or OnTestPartResult() event is fired, the listeners will receive it in the order they appear in the list (since new listeners are added to the end of the list, the default text printer and the default XML generator will receive the event first). An On*End() event will be received by the listeners in the reverse order. This allows output by listeners added later to be framed by output from listeners added earlier. リストに2つ以上のリスナーを追加する可能性もあります．On*Start() または OnTestPartResult() イベントが起こると，リスナーはリストに並んだ順にそれを受け取ります（新しいリスナーはリストの末尾に追加されていくので，デフォルト出力リスナーとデフォルトXMLジェネレータが最初にイベントを受け取ります）．また，On*End() イベントは，それとは *逆の* 順番で受け取られます．これによって，前のリスナーの出力に後のリスナーの出力を追加していくことができます． .. Generating Failures in Listeners .. _adv_generating_failures_in_listeners: リスナー内で失敗を発生させる ---------------------------- .. You may use failure-raising macros (EXPECT_*(), ASSERT_*(), FAIL(), etc) when processing an event. There are some restrictions: イベントを処理する際に，失敗を生成するマクロ（EXPECT_*()，ASSERT_*()，FAIL()，など）を利用することがあります．これには，いくつかの制限があります： .. You cannot generate any failure in OnTestPartResult() (otherwise it will cause OnTestPartResult() to be called recursively). .. A listener that handles OnTestPartResult() is not allowed to generate any failure. #. OnTestPartResult() の中では失敗を生成することはできません（そうしないと， OnTestPartResult() が再帰的に呼ばれてしまいます）． #. OnTestPartResult() をハンドルするリスナーも，失敗を生成することはできません． .. When you add listeners to the listener list, you should put listeners that handle OnTestPartResult() before listeners that can generate failures. This ensures that failures generated by the latter are attributed to the right test by the former. リスナーリストにリスナーを追加する際，OnTestPartResult() をハンドルするリスナーは，失敗を生成する可能性のあるリスナーよりも前に置く必要があります．こうすることで，後者のリスナーによって生成された失敗は，正しく実行されたテストによるものであることが前者のリスナーによって保障されることになります． .. We have a sample of failure-raising listener here. 失敗を生成するリスナーのサンプルは， `ここ `_ にあります． .. Running Test Programs: Advanced Options .. _adv_running_test_programs_advanced_options: テストプログラムを実行する：高度なオプション ============================================ .. Google Test test programs are ordinary executables. Once built, you can run them directly and affect their behavior via the following environment variables and/or command line flags. For the flags to work, your programs must call ::testing::InitGoogleTest() before calling RUN_ALL_TESTS(). Google Test のテストプログラムは，通常の実行ファイルです．1度ビルドされると，直接実行することができますし，以下の環境変数やコマンドラインフラグを用いて挙動を変更することもできます．フラグを利用するには，プログラムで RUN_ALL_TESTS() を呼ぶ前に ::testing::InitGoogleTest() を呼ばなければいけません． .. To see a list of supported flags and their usage, please run your test program with the --help flag. You can also use -h, -?, or /? for short. This feature is added in version 1.3.0. サポートされるフラグと使い方の一覧を見るには，テストプログラムに ---help フラグを付けて実行してみてください．-h や -?，/? などの短縮形も利用できます．この機能は，バージョン 1.3.0 で追加されました． .. If an option is specified both by an environment variable and by a flag, the latter takes precedence. Most of the options can also be set/read in code: to access the value of command line flag --gtest_foo, write ::testing::GTEST_FLAG(foo). A common pattern is to set the value of a flag before calling ::testing::InitGoogleTest() to change the default value of the flag: 環境変数とフラグの両方でオプションが指定されると，フラグのほうが優先されます．オプションの大部分は，コード内でも設定/読み込みが可能です：コマンドラインフラグ ---gtest_foo の値にアクセスするには，::testing::GTEST_FLAG(foo) とします．よくあるのは，フラグのデフォルト値を変更するために，::testing::InitGoogleTest() を呼ぶ前にフラグの値をセットするというパターンです： .. code-block:: c int main(int argc, char** argv) { // 経過時間表示をデフォルトで無効にします． ::testing::GTEST_FLAG(print_time) = false; // これにより，コマンドラインフラグを上書きできます． ::testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS(); } .. Selecting Tests .. _adv_selecting_tests: テストを選択する ---------------- .. This section shows various options for choosing which tests to run. このセクションでは，実行するテストを選択するための様々なオプションを説明します． .. Listing Test Names .. _adv_listing_test_names: テスト名の一覧 ^^^^^^^^^ .. Sometimes it is necessary to list the available tests in a program before running them so that a filter may be applied if needed. Including the flag --gtest_list_tests overrides all other flags and lists tests in the following format: 例えばテストをフィルタでふるい分けるために，プログラム実行前に，有効なテスト一覧を必要とする場合があります． ---gtest_list_tests フラグは，他のフラグをすべて上書きして，次のようなフォーマットのテスト一覧を取得します： :: TestCase1. TestName1 TestName2 TestCase2. TestName .. None of the tests listed are actually run if the flag is provided. There is no corresponding environment variable for this flag. このフラグが与えられた場合に一覧に挙げられたテストは，実際には実行されません．また，このフラグに対応する環境変数はありません． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Running a Subset of the Tests .. _adv_running_a_subset_of_the_tests: テストの部分的な実行 ^^^^^^^^^^^^^ .. By default, a Google Test program runs all tests the user has defined. Sometimes, you want to run only a subset of the tests (e.g. for debugging or quickly verifying a change). If you set the GTEST_FILTER environment variable or the --gtest_filter flag to a filter string, Google Test will only run the tests whose full names (in the form of TestCaseName.TestName) match the filter. デフォルトでは，Google Test プログラムは，ユーザが定義したすべてのテストを実行します．しかし，ある一部のテストだけを実行したい場合もあるでしょう（例えば，デバッグ時や変更をすばやく確認したい場合など）．GTEST_FILTER 環境変数，または ---gtest_filter フラグでフィルタ文字列を設定すると，Google Test は，（TestCaseName.TestName の形式で表される）名前全体がフィルタにマッチするテストだけを実行します． .. The format of a filter is a ':'-separated list of wildcard patterns (called the positive patterns) optionally followed by a '-' and another ':'-separated pattern list (called the negative patterns). A test matches the filter if and only if it matches any of the positive patterns but does not match any of the negative patterns. フィルタのフォーマットは，’：’ で区切られたワイルドカードパターンのリスト（ポジティブパターン）と，’：’ で区切られた別のパターンの先頭に ’-’ がついたリスト（ネガティブパターン）です．任意のポジティブパターンにマッチし，どのネガティブパターンにもマッチしなかった場合のみ，そのテストはフィルタにマッチしたとみなされます． .. A pattern may contain '*' (matches any string) or '?' (matches any single character). For convenience, the filter '*-NegativePatterns' can be also written as '-NegativePatterns'. パターンには，'*'（任意の文字列にマッチ）や '?'（任意の1文字にマッチ）が含まれる場合があります．利便性のため，フィルタ '*-NegativePatterns' は，'-NegativePatterns' と書くこともできます． .. For example: 以下に例を示します： .. ./foo_test Has no flag, and thus runs all its tests. .. ./foo_test --gtest_filter=* Also runs everything, due to the single match-everything * value. .. ./foo_test --gtest_filter=FooTest.* Runs everything in test case FooTest. .. ./foo_test --gtest_filter=*Null*:*Constructor* Runs any test whose full name contains either "Null" or "Constructor". .. ./foo_test --gtest_filter=-*DeathTest.* Runs all non-death tests. .. ./foo_test --gtest_filter=FooTest.*-FooTest.Bar Runs everything in test case FooTest except FooTest.Bar. * ./foo_test は，フラグなしの状態です．全てのテストが実行されます． * ./foo_test ---gtest_filter=\* も全てのテストが実行されます．\* は任意の文字列にマッチします． * ./foo_test ---gtest_filter=FooTest.* は，テストケース FooTest 内の全てのテストを実行します． * ./foo_test ---gtest_filter=\*Null\*:\*Constructor\* では，完全な名前に "NULL" または "Constructor" を含むテストが全て実行されます． * ./foo_test ---gtest_filter=-\*DeathTest.\* は，Death テスト以外を実行します． * ./foo_test ---gtest_filter=FooTest.*-FooTest.Bar は，テストケース FooTest 内の全てのテストが実行されます．ただし， FooTest.Bar は除きます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Temporarily Disabling Tests .. _adv_temporarily_disabling_tests: テストを一時的に無効にする ^^^^^^^^^^^^^^^^^ .. This is better than commenting out the code or using #if 0, as disabled tests are still compiled (and thus won't rot). もし失敗するテストがあり，それがすぐには直せない場合，そのテストの名前に DISABLE\_ プレフィックスをつけることができます．すると，そのテストは実行されません．無効にしたテストもコンパイルはされる（よって，いつの間にかコンパイルできなくなることもない）ので，これは，#if 0 でコードをコメントアウトするよりも良い方法です． .. If you need to disable all tests in a test case, you can either add DISABLED_ to the front of the name of each test, or alternatively add it to the front of the test case name. あるテストケースの全てのテストを無効にする必要があるなら，DISABLED\_ を各テスト名の先頭に付けることもできますが，テストケース名の先頭に追加することもできます． .. For example, the following tests won't be run by Google Test, even though they will still be compiled: 例えば，以下のテストはコンパイルはされますが，Google Test では実行されません： .. code-block:: c // Foo が Abc するかどうかのテスト． TEST(FooTest, DISABLED_DoesAbc) { ... } class DISABLED_BarTest : public ::testing::Test { ... }; // Bar が Xyz するかどうかのテスト． TEST_F(DISABLED_BarTest, DoesXyz) { ... } .. Note: This feature should only be used for temporary pain-relief. You still have to fix the disabled tests at a later date. As a reminder, Google Test will print a banner warning you if a test program contains any disabled tests. *注意 ：* この機能は，一時的な対処として使うべきものです．無効にしたテストは，後で修正しなければいけません．テストプログラムに無効なテストが含まれているときには，Google Test がリマインダーとしてバナー警告を表示します． .. Tip: You can easily count the number of disabled tests you have using grep. This number can be used as a metric for improving your test quality. *ヒント：* 無効なテストの数は grep を使って簡単に数えることができます．この個数は，テスト品質改善の指標として利用できます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Temporarily Enabling Disabled Tests .. _adv_temporarily_enabling_disabled_tests: 無効にしたテストを一時的に有効にする ^^^^^^^^^^^^^^^^^^^^^^^^ .. To include disabled tests in test execution, just invoke the test program with the --gtest_also_run_disabled_tests flag or set the GTEST_ALSO_RUN_DISABLED_TESTS environment variable to a value other than 0. You can combine this with the --gtest_filter flag to further select which disabled tests to run. :ref:`無効にしたテスト ` を実行するには， ---gtest_also_run_disabled_tests フラグを付けて，または 環境変数 GTEST_ALSO_RUN_DISABLED_TESTS を 0 以外に設定してからテストプログラムを実行するだけです．これを ---gtest_filter フラグと組み合わせて，無効化されたテストのどれを実行するかを選択することもできます． .. Availability: Linux, Windows, Mac; since version 1.3.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.3.0 以降． .. Repeating the Tests .. _adv_repeating_the_tests: テストを繰り返す ------------------ .. Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it will fail only 1% of the time, making it rather hard to reproduce the bug under a debugger. This can be a major source of frustration. たまに，成功したり失敗したりするテストに出くわすことがあります．1% の割合で失敗するバグで，デバッガを使って再現するのがかなり難しいこともあります．このようなバグが，フラストレーションの原因になります． .. The --gtest_repeat flag allows you to repeat all (or selected) test methods in a program many times. Hopefully, a flaky test will eventually fail and give you a chance to debug. Here's how to use it: ---gtest_repat フラグを利用すると，プログラム中の全ての（または，選択された）テストメソッドを複数回繰り返すことができます．上手くいくと，そのテストが失敗してデバッグのチャンスが生まれるかもしれません．この使い方は以下の通りです： .. $ foo_test --gtest_repeat=1000 Repeat foo_test 1000 times and don't stop at failures. .. $ foo_test --gtest_repeat=-1 A negative count means repeating forever. .. $ foo_test --gtest_repeat=1000 --gtest_break_on_failure Repeat foo_test 1000 times, stopping at the first failure. This is especially useful when running under a debugger: when the testfails, it will drop into the debugger and you can then inspect variables and stacks. .. $ foo_test --gtest_repeat=1000 --gtest_filter=FooBar Repeat the tests whose name matches the filter 1000 times. .. csv-table:: :header: :widths: 10, 30 "$ foo_test ---gtest_repeat=1000", "foo_test を 1000 回繰り返します．失敗しても停止しません．" "$ foo_test ---gtest_repeat=-1", "負の数を与えると，無限に繰り返します．" "$ foo_test ---gtest_repeat=1000 ---gtest_break_on_failure", "foo_test を 1000 回繰り返しますが，最初の失敗で停止します．これは特に，デバッガ上で実行している場合に役立ちます：テストが失敗したときに，デバッガに移動し，変数やスタックを調べることができます．" "$ foo_test ---gtest_repeat=1000 ---gtest_filter=FooBar", "フィルタにマッチする名前のテストを 1000 回繰り返します．" .. If your test program contains global set-up/tear-down code registered using AddGlobalTestEnvironment(), it will be repeated in each iteration as well, as the flakiness may be in it. You can also specify the repeat count by setting the GTEST_REPEAT environment variable. AddGlobalTestEnvironment() によって登録されたグローバル set-up/tear-down コードが含まれる場合，それが低い再現性の原因になっている可能性もありますが，その登録も各繰り返しで毎回行われます． 環境変数 GTEST_REPEAT をセットすることで，繰り返し回数を指定することもできます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Shuffling the Tests .. _adv_shuffling_the_tests: テストをシャッフルする ------------------------ .. You can specify the --gtest_shuffle flag (or set the GTEST_SHUFFLE environment variable to 1) to run the tests in a program in a random order. This helps to reveal bad dependencies between tests. ---gtest_shuffle フラグを利用する（または環境変数 GTEST_SHUFFLE を 1 にセットする）ことで，プログラム中のテストをランダムな順序で実行できます．これによって，テスト間に良くない依存関係がないかを調べることができます． .. By default, Google Test uses a random seed calculated from the current time. Therefore you'll get a different order every time. The console output includes the random seed value, such that you can reproduce an order-related test failure later. To specify the random seed explicitly, use the --gtest_random_seed=SEED flag (or set the GTEST_RANDOM_SEED environment variable), where SEED is an integer between 0 and 99999. The seed value 0 is special: it tells Google Test to do the default behavior of calculating the seed from the current time. Google Test は，デフォルトで，現在時刻から計算されたランダムシードを利用します．したがって，実行するたびに，その実行順序はバラバラになります．テスト順序に依存する失敗を後で再現できるように，ランダムシードの値はコンソールにも出力されます． ランダムシードを明示的に指定するには，---gtest_random_seed=SEED（または環境変数 GTEST_RANDOM_SEED）を利用してください．ここで，SEED は，0 から 99999 の範囲にある整数です．シード値 0 は特別な値です：これが指定されると，Google Test は，現在の時刻からシード値を計算するデフォルトの動作を行います． .. If you combine this with --gtest_repeat=N, Google Test will pick a different random seed and re-shuffle the tests in each iteration. これと，---gtest_repeat=N を組み合わせると，Google Test は，各繰り返しにおいて異なるランダムシードでシャッフルされたテストを行います．． .. Availability: Linux, Windows, Mac; since v1.4.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.4.0 以降． .. Controlling Test Output .. _adv_controlling_thest_output: テストの出力を制御する ------------------------ .. This section teaches how to tweak the way test results are reported. このセクションでは，報告テスト結果をカスタマイズする方法について説明します． .. Colored Terminal Output .. _adv_colored_terminal_output: 色付きのターミナル出力 ^^^^^^^^^^^^^^ .. Google Test can use colors in its terminal output to make it easier to spot the separation between tests, and whether tests passed. Google Test では，テストのうち成功したテストはどれかを簡単に見分けられるように，ターミナル出力に色を付けることができます． .. You can set the GTEST_COLOR environment variable or set the --gtest_color command line flag to yes, no, or auto (the default) to enable colors, disable colors, or let Google Test decide. When the value is auto, Google Test will use colors if and only if the output goes to a terminal and (on non-Windows platforms) the TERM environment variable is set to xterm or xterm-color. 環境変数 GTEST_COLOR または ---gtest_color フラグに，yes ，no ，auto（デフォルト）を与えることができます．それぞれ，色付き，色なし，Google Test が自動決定，という事を意味します．auto が指定された場合，出力対象がターミナルで，かつ（Windows 以外のプラットフォームで）環境変数 TERM が xterm または xterm-color にセットされている場合のみ，色を利用します． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Suppressing the Elapsed Time .. _adv_suppressing_the_elapsed_time: 経過時間表示を抑制する ^^^^^^^^^^^^^^ .. By default, Google Test prints the time it takes to run each test. To suppress that, run the test program with the --gtest_print_time=0 command line flag. Setting the GTEST_PRINT_TIME environment variable to 0 has the same effect. Google Test は，デフォルトで各テストの実行時間を表示します．これを抑制するには，---gtest_print_time=0 フラグを付けてテストプログラムを実行します．また，環境変数 GTEST_PRINT_TIME に 0 をセットしても同じです． .. Availability: Linux, Windows, Mac. (In Google Test 1.3.0 and lower, the default behavior is that the elapsed time is not printed.) *利用可能な環境：* Linux，Windows，Mac．（バージョン 1.3.0 以前の Google Test では，経過時間を表示しない のがデフォルト動作です） .. Generating an XML Report .. _adv_generating_an_xml_report: XMLレポート ^^^^^^^^ .. Google Test can emit a detailed XML report to a file in addition to its normal textual output. The report contains the duration of each test, and thus can help you identify slow tests. Google Test では，通常のテキスト出力に加えて，XML 形式のレポートをファイルに出力できます． このレポートには各テストの実行時間が出力されており，どのテストに時間がかかっているのかを知ることができます． .. To generate the XML report, set the GTEST_OUTPUT environment variable or the --gtest_output flag to the string "xml:_path_to_output_file_", which will create the file at the given location. You can also just use the string "xml", in which case the output can be found in the test_detail.xml file in the current directory. XMLレポートを出力するには，環境変数 GEST_OUTPUT または ---gtest_output フラグに，文字列 "xml:_path_to_output_file_" をセットします．指定された場所にファイルが作られます． test_detail.xml という名前のファイルをカレントディレクトリに出力する場合は，単に "xml" とだけ指定することもできます． .. If you specify a directory (for example, "xml:output/directory/" on Linux or "xml:output\directory\" on Windows), Google Test will create the XML file in that directory, named after the test executable (e.g. foo_test.xml for test program foo_test or foo_test.exe). If the file already exists (perhaps left over from a previous run), Google Test will pick a different name (e.g. foo_test_1.xml) to avoid overwriting it. ディレクトリを指定すると（例えば，Linux では "xml:output/directory/" ，Windows では "xml:output\directory\"），Google Test は，テスト実行ファイルに基づいた名前の XML ファイルをそのディレクトリに作成します（例えば，foo_test または foo_test.exe というテストプログラムの場合，foo_test.xml ）．そのファイルが既に存在する場合（おそらくは，前回の実行結果が残っているのでしょう），Google Test は上書きしないように，違う名前（例えば， foo_test_1.xml）で保存します． .. The report uses the format described here. It is based on the junitreport Ant task and can be parsed by popular continuous build systems like Hudson. Since that format was originally intended for Java, a little interpretation is required to make it apply to Google Test tests, as shown here: レポートで利用されるフォーマットについて説明します．これは junitreport Ant タスクに基づいており， `Hudson `_ のような有名な continuous build system で解析することができます．このフォーマットは元々 java を意識したものだったので，それを Google Test のテストに適用するには，次のように少しだけ読み替えが必要です： :: .. The root element corresponds to the entire test program. .. elements correspond to Google Test test cases. .. elements correspond to Google Test test functions. * ルート要素 は，テストプログラム全体に対応します． * 要素 は，Google Test のテストケースに対応します． * 要素 は，Gogle Test のテスト関数に対応します． .. For instance, the following program 例えば，次のプログラム .. code-block:: c TEST(MathTest, Addition) { ... } TEST(MathTest, Subtraction) { ... } TEST(LogicTest, NonContradiction) { ... } .. could generate this report: は，次のレポートを生成します :: .. Things to note: 注意事項： .. The tests attribute of a or element tells how many test functions the Google Test program or test case contains, while the failures attribute tells how many of them failed. .. The time attribute expresses the duration of the test, test case, or entire test program in milliseconds. .. Each element corresponds to a single failed Google Test assertion. .. Some JUnit concepts don't apply to Google Test, yet we have to conform to the DTD. Therefore you'll see some dummy elements and attributes in the report. You can safely ignore these parts. * 要素 や の属性 tests は，Google Test プログラム，またはテストケースに含まれるテスト関数の個数を表し，属性 failures は，そのうち失敗したテスト関数の個数を表します． * 属性 time は，そのテスト，テストケース，テストプログラム全体の実行時間をミリ秒単位で表します． * 1つの要素 は，失敗した Google Test アサーション1つに対応します． * Google Test には適用されない JUnit コンセプトもありますが，今のところ DTD には従う必要があります．よって，レポート中にダミー要素やダミー属性が含まれることがあります．それらは無視しても安全です． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Controlling How Failures Are Reported .. _adv_controlling_how_failures_are_reported: 失敗のレポート方法を制御する ------------------------------ .. Turning Assertion Failures into Break-Points .. _adv_turning_assertion_failures_into_bread-points: アサーション失敗箇所にブレークポイントを設置する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. When running test programs under a debugger, it's very convenient if the debugger can catch an assertion failure and automatically drop into interactive mode. Google Test's break-on-failure mode supports this behavior. デバッガ上でテストプログラムを実行しているとき，デバッガがアサーションの失敗をキャッチして自動的にインタラクティブモードに移行してくれると非常に便利です．Google Test の break-on-failure モードは，この動作をサポートします． .. To enable it, set the GTEST_BREAK_ON_FAILURE environment variable to a value other than 0 . Alternatively, you can use the --gtest_break_on_failure command line flag. これを有効にするには，環境変数 GTEST_BREAK_ON_FAILURE に 0 以外の値をセットします．または， ---gtest_break_on_failure フラグを利用することもできます． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Disabling Catching Test-Thrown Exceptions .. _adv_disabling_catching_test-thrown-exception: テストが投げる例外のキャッチを無効化する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Google Test can be used either with or without exceptions enabled. If a test throws a C++ exception or (on Windows) a structured exception (SEH), by default Google Test catches it, reports it as a test failure, and continues with the next test method. This maximizes the coverage of a test run. Also, on Windows an uncaught exception will cause a pop-up window, so catching the exceptions allows you to run the tests automatically. Google Test は，例外が有効な環境と無効な環境のどちらでも利用できます．テストが C++ 例外や（Windows で）構造化例外（SEH）を投げる場合， Google Test は，デフォルトでそれをキャッチして，テスト失敗として報告します．そして，次のテストメソッドを引き続き実行します．これによって，テスト実行のカバレッジが最大化されます．また，Windows 環境においては，例外を捕まえなかった場合にポップアップウィンドウが出現するので，自動的なテスト実行のためには例外をちゃんと捕まえることが必要です． .. When debugging the test failures, however, you may instead want the exceptions to be handled by the debugger, such that you can examine the call stack when an exception is thrown. To achieve that, set the GTEST_CATCH_EXCEPTIONS environment variable to 0, or use the --gtest_catch_exceptions=0 flag when running the tests. しかし，失敗したテストのデバッグを行っているとき，例外が投げられた時のコールスタックを調査するために，その例外をデバッガでハンドルしたいと思うことがあるかもしれません．そのためには，GTEST_CATCH_EXCEPTIONS 環境変数を 0 にセットするか，テスト実行時に ---gtest_catch_exception=0 フラグを利用してください． .. Availability: Linux, Windows, Mac. *利用可能な環境：* Linux，Windows，Mac． .. Letting Another Testing Framework Drive .. _adv_letting_another_testing_framework_drive: 別の Testing Framework と一緒に使う ^^^^^^^^^^^^^^^^^^^^^^^^ .. If you work on a project that has already been using another testing framework and is not ready to completely switch to Google Test yet, you can get much of Google Test's benefit by using its assertions in your existing tests. Just change your main() function to look like: 既に別の testing framework を利用するプロジェクトで作業をしていて，Google Test に完全に切り替える準備がまだ整っていないならば，既存のテスト中で Google Test のアサーションを利用することで，Google Test の恩恵の大半を享受でます． main() 関数を次のように変更してください： .. code-block:: c #include "gtest/gtest.h" int main(int argc, char** argv) { ::testing::GTEST_FLAG(throw_on_failure) = true; // 重要：Google Test は必ず初期化してください． ::testing::InitGoogleTest(&argc, argv); ... whatever your existing testing framework requires ... } .. With that, you can use Google Test assertions in addition to the native assertions your testing framework provides, for example: こうすることで，既存の testing framework が提供するアサーションに加え，Google Test のアサーションを利用することができます．例を示します： .. code-block:: c void TestFooDoesBar() { Foo foo; EXPECT_LE(foo.Bar(1), 100); // Google Test のアサーション． CPPUNIT_ASSERT(foo.IsEmpty()); // 元々のアサーション． } .. If a Google Test assertion fails, it will print an error message and throw an exception, which will be treated as a failure by your host testing framework. If you compile your code with exceptions disabled, a failed Google Test assertion will instead exit your program with a non-zero code, which will also signal a test failure to your test runner. Google Test のアサーションが失敗すると，エラーメッセージを表示して例外を投げます．この例外は，testing framework によって失敗として扱われます．例外を無効にしてコードをコンパイルした場合，Google Test のアサーションが失敗すると，0 ではない終了コードでプログラムが終了します．これも，テスト失敗のシグナルを testing framework に送信します． .. If you don't write ::testing::GTEST_FLAG(throw_on_failure) = true; in your main(), you can alternatively enable this feature by specifying the --gtest_throw_on_failure flag on the command-line or setting the GTEST_THROW_ON_FAILURE environment variable to a non-zero value. もし，main() に ::testing::GTEST_FLAG(throw_on_failure) = true; を書かない場合，代わりに，---gtest_throw_on_failure フラグを指定するか，環境変数 GTEST_THROW_ON_FAILURE を 0 以外の値にセットすることでこの機能を有効にできます． .. Availability: Linux, Windows, Mac; since v1.3.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.3.0 以降． .. Distributing Test Functions to Multiple Machines .. _adv_distributing_test_functions_to_multiple_machines: テスト関数を複数のマシンに分散する ------------------------------------- .. If you have more than one machine you can use to run a test program, you might want to run the test functions in parallel and get the result faster. We call this technique sharding, where each machine is called a shard. テストプログラムを実行するためのマシンが2台以上ある場合，テスト関数を並列に実行して，より早く結果を得たいと考えるかもしれません．我々は，この技術を *sharding* ，各マシンを *shard* と呼んでいます．． .. Google Test is compatible with test sharding. To take advantage of this feature, your test runner (not part of Google Test) needs to do the following: Google Test は，test sharding と互換性があります．この機能を利用するには，テストランナー（Google Test のことではありません）が次のことを行う必要があります： .. Allocate a number of machines (shards) to run the tests. .. On each shard, set the GTEST_TOTAL_SHARDS environment variable to the total number of shards. It must be the same for all shards. .. On each shard, set the GTEST_SHARD_INDEX environment variable to the index of the shard. Different shards must be assigned different indices, which must be in the range [0, GTEST_TOTAL_SHARDS - 1]. .. Run the same test program on all shards. When Google Test sees the above two environment variables, it will select a subset of the test functions to run. Across all shards, each test function in the program will be run exactly once. .. Wait for all shards to finish, then collect and report the results. * テストを実行するために複数台のマシン（shards）を割り当てます． * 各 shard で，環境変数 GTEST_TOTAL_SHARDS に shard の総数をセットします．これは，すべての shard で同じ値になります． * 各 shard で，環境変数 GTEST_SHARD_INDEX に，その shard のインデックスをセットします．異なる shard には，異なるインデックスが割り当てられます．インデックスは，必ず [0, GTEST_TOTAL_SHARDS - 1] の範囲内の値です． * すべての shard 上で，同じテストプログラムを実行します．Google Test は上述の環境変数を確認して，実行するテスト関数のサブセットを選択します．プログラムの1つのテスト関数は，すべての shard に渡って 1度だけ実行されます． * すべての shard が終了するのを待ち，結果レポートが集められます． .. Your project may have tests that were written without Google Test and thus don't understand this protocol. In order for your test runner to figure out which test supports sharding, it can set the environment variable GTEST_SHARD_STATUS_FILE to a non-existent file path. If a test program supports sharding, it will create this file to acknowledge the fact (the actual contents of the file are not important at this time; although we may stick some useful information in it in the future.); otherwise it will not create it. プロジェクトの中に Google Test を使わずに書かれたテストが混ざっていて，このプロトコルを理解できないかもしれません．どのテストが sharding をサポートしているかを，テストランナー側が検出するために，環境変数 GTEST_SHARD_STATUS_FILE に存在しないファイルパスをセットします．テストプログラムが sharding をサポートしていれば，それを知らせるためにファイルが作られます（今回の場合，実際のファイルの中身は重要ではありません．将来的には，ここに有用な情報を載せるかもしれませんが）．sharding がサポートされていなければ，ファイルが作られません． .. Here's an example to make it clear. Suppose you have a test program foo_test that contains the following 5 test functions: 分かりやすい例を示します．次の 5 個のテスト関数を含むテストプログラム foo_test を考えてください： .. code-block:: c TEST(A, V) TEST(A, W) TEST(B, X) TEST(B, Y) TEST(B, Z) .. and you have 3 machines at your disposal. To run the test functions in parallel, you would set GTEST_TOTAL_SHARDS to 3 on all machines, and set GTEST_SHARD_INDEX to 0, 1, and 2 on the machines respectively. Then you would run the same foo_test on each machine. そして，自由に使えるマシンが3台あるとします．これらのテスト関数を並列に実行するために，すべてのマシンの環境変数 GTEST_TOTAL_SHARDS に 3 をセットします．また，各マシンの環境変数 GTEST_SHARD_INDEX には，それぞれ 0, 1, 2 をセットします．そして，各マシンで同じ foo_test を実行します． .. Google Test reserves the right to change how the work is distributed across the shards, but here's one possible scenario: Google Test には，shard 間で仕事がどのように分散されるかを変更する権限がありますが，ここでは1つの事例を示すにとどめます： .. code-block:: c Machine #0 runs A.V and B.X. Machine #1 runs A.W and B.Y. Machine #2 runs B.Z. .. Availability: Linux, Windows, Mac; since version 1.3.0. *利用可能な環境：* Linux，Windows，Mac．バージョン 1.3.0 以降． .. Fusing Google Test Source Files .. _adv_fusing_google_test_source_files: Google Test のソースファイルを結合する ========================= .. Google Test's implementation consists of ~30 files (excluding its own tests). Sometimes you may want them to be packaged up in two files (a .h and a .cc) instead, such that you can easily copy them to a new machine and start hacking there. For this we provide an experimental Python script fuse_gtest_files.py in the scripts/ directory (since release 1.3.0). Assuming you have Python 2.4 or above installed on your machine, just go to that directory and run Google Test の実装は，（自身のテストを除いて）約 30 のファイルから構成されます．新しいマシンに簡単にコピーして使うために，これらを 2つのファイル（.h と .cc ）にまとめたい場合があります． scripts/ ディレクトリに，このための実験的な Python スクリプト fuse_gtest_files.py を用意しています（バージョン 1.3.0 以降）．マシンに Python 2.4 以降がインストールされていれば，そのディレクトリに移動して，次のように実行 :: python fuse_gtest_files.py OUTPUT_DIR .. and you should see an OUTPUT_DIR directory being created with files gtest/gtest.h and gtest/gtest-all.cc in it. These files contain everything you need to use Google Test. Just copy them to anywhere you want and you are ready to write tests. You can use the scripts/test/Makefile file as an example on how to compile your tests against them. すると，OUTPUT_DIR ディレクトリに，gtest/gtest.h と gtest/gtest-all.cc が作成されているはずです．これらのファイルには，Google Test を使うためのすべてが含まれています．これらを好きな場所にコピーするだけで，テストを書く準備が整います．これを使ってテストをコンパイルする例として，ファイル `scripts/test/Makefile `_ が参考になります． .. Where to Go from Here .. _adv_where_to_go_from_here: 次のステップ ======== .. Congratulations! You've now learned more advanced Google Test tools and are ready to tackle more complex testing tasks. If you want to dive even deeper, you can read the Frequently-Asked Questions. おめでとうございます．さて， Google Test のより高度な使い方を学び，さらに複雑なテストに取り組む準備ができました．さらに深い理解を求めるなら， :ref:`FAQ` を読んでください．