113481Sgiacomo.travaglini@arm.com 213481Sgiacomo.travaglini@arm.com 313481Sgiacomo.travaglini@arm.com# Introduction: Why Google C++ Testing Framework? # 413481Sgiacomo.travaglini@arm.com 513481Sgiacomo.travaglini@arm.com_Google C++ Testing Framework_ helps you write better C++ tests. 613481Sgiacomo.travaglini@arm.com 713481Sgiacomo.travaglini@arm.comNo matter whether you work on Linux, Windows, or a Mac, if you write C++ code, 813481Sgiacomo.travaglini@arm.comGoogle Test can help you. 913481Sgiacomo.travaglini@arm.com 1013481Sgiacomo.travaglini@arm.comSo what makes a good test, and how does Google C++ Testing Framework fit in? We believe: 1113481Sgiacomo.travaglini@arm.com 1. Tests should be _independent_ and _repeatable_. It's a pain to debug a test that succeeds or fails as a result of other tests. Google C++ Testing Framework isolates the tests by running each of them on a different object. When a test fails, Google C++ Testing Framework allows you to run it in isolation for quick debugging. 1213481Sgiacomo.travaglini@arm.com 1. Tests should be well _organized_ and reflect the structure of the tested code. Google C++ Testing Framework groups related tests into test cases that can share data and subroutines. This common pattern is easy to recognize and makes tests easy to maintain. Such consistency is especially helpful when people switch projects and start to work on a new code base. 1313481Sgiacomo.travaglini@arm.com 1. Tests should be _portable_ and _reusable_. The open-source community has a lot of code that is platform-neutral, its tests should also be platform-neutral. Google C++ Testing Framework works on different OSes, with different compilers (gcc, MSVC, and others), with or without exceptions, so Google C++ Testing Framework tests can easily work with a variety of configurations. (Note that the current release only contains build scripts for Linux - we are actively working on scripts for other platforms.) 1413481Sgiacomo.travaglini@arm.com 1. When tests fail, they should provide as much _information_ about the problem as possible. Google C++ Testing Framework doesn't stop at the first test failure. Instead, it only stops the current test and continues with the next. You can also set up tests that report non-fatal failures after which the current test continues. Thus, you can detect and fix multiple bugs in a single run-edit-compile cycle. 1513481Sgiacomo.travaglini@arm.com 1. The testing framework should liberate test writers from housekeeping chores and let them focus on the test _content_. Google C++ Testing Framework automatically keeps track of all tests defined, and doesn't require the user to enumerate them in order to run them. 1613481Sgiacomo.travaglini@arm.com 1. Tests should be _fast_. With Google C++ Testing Framework, you can reuse shared resources across tests and pay for the set-up/tear-down only once, without making tests depend on each other. 1713481Sgiacomo.travaglini@arm.com 1813481Sgiacomo.travaglini@arm.comSince Google C++ Testing Framework is based on the popular xUnit 1913481Sgiacomo.travaglini@arm.comarchitecture, you'll feel right at home if you've used JUnit or PyUnit before. 2013481Sgiacomo.travaglini@arm.comIf not, it will take you about 10 minutes to learn the basics and get started. 2113481Sgiacomo.travaglini@arm.comSo let's go! 2213481Sgiacomo.travaglini@arm.com 2313481Sgiacomo.travaglini@arm.com_Note:_ We sometimes refer to Google C++ Testing Framework informally 2413481Sgiacomo.travaglini@arm.comas _Google Test_. 2513481Sgiacomo.travaglini@arm.com 2613481Sgiacomo.travaglini@arm.com# Setting up a New Test Project # 2713481Sgiacomo.travaglini@arm.com 2813481Sgiacomo.travaglini@arm.comTo write a test program using Google Test, you need to compile Google 2913481Sgiacomo.travaglini@arm.comTest into a library and link your test with it. We provide build 3013481Sgiacomo.travaglini@arm.comfiles for some popular build systems: `msvc/` for Visual Studio, 3113481Sgiacomo.travaglini@arm.com`xcode/` for Mac Xcode, `make/` for GNU make, `codegear/` for Borland 3213481Sgiacomo.travaglini@arm.comC++ Builder, and the autotools script (deprecated) and 3313481Sgiacomo.travaglini@arm.com`CMakeLists.txt` for CMake (recommended) in the Google Test root 3413481Sgiacomo.travaglini@arm.comdirectory. If your build system is not on this list, you can take a 3513481Sgiacomo.travaglini@arm.comlook at `make/Makefile` to learn how Google Test should be compiled 3613481Sgiacomo.travaglini@arm.com(basically you want to compile `src/gtest-all.cc` with `GTEST_ROOT` 3713481Sgiacomo.travaglini@arm.comand `GTEST_ROOT/include` in the header search path, where `GTEST_ROOT` 3813481Sgiacomo.travaglini@arm.comis the Google Test root directory). 3913481Sgiacomo.travaglini@arm.com 4013481Sgiacomo.travaglini@arm.comOnce you are able to compile the Google Test library, you should 4113481Sgiacomo.travaglini@arm.comcreate a project or build target for your test program. Make sure you 4213481Sgiacomo.travaglini@arm.comhave `GTEST_ROOT/include` in the header search path so that the 4313481Sgiacomo.travaglini@arm.comcompiler can find `"gtest/gtest.h"` when compiling your test. Set up 4413481Sgiacomo.travaglini@arm.comyour test project to link with the Google Test library (for example, 4513481Sgiacomo.travaglini@arm.comin Visual Studio, this is done by adding a dependency on 4613481Sgiacomo.travaglini@arm.com`gtest.vcproj`). 4713481Sgiacomo.travaglini@arm.com 4813481Sgiacomo.travaglini@arm.comIf you still have questions, take a look at how Google Test's own 4913481Sgiacomo.travaglini@arm.comtests are built and use them as examples. 5013481Sgiacomo.travaglini@arm.com 5113481Sgiacomo.travaglini@arm.com# Basic Concepts # 5213481Sgiacomo.travaglini@arm.com 5313481Sgiacomo.travaglini@arm.comWhen using Google Test, you start by writing _assertions_, which are statements 5413481Sgiacomo.travaglini@arm.comthat check whether a condition is true. An assertion's result can be _success_, 5513481Sgiacomo.travaglini@arm.com_nonfatal failure_, or _fatal failure_. If a fatal failure occurs, it aborts 5613481Sgiacomo.travaglini@arm.comthe current function; otherwise the program continues normally. 5713481Sgiacomo.travaglini@arm.com 5813481Sgiacomo.travaglini@arm.com_Tests_ use assertions to verify the tested code's behavior. If a test crashes 5913481Sgiacomo.travaglini@arm.comor has a failed assertion, then it _fails_; otherwise it _succeeds_. 6013481Sgiacomo.travaglini@arm.com 6113481Sgiacomo.travaglini@arm.comA _test case_ contains one or many tests. You should group your tests into test 6213481Sgiacomo.travaglini@arm.comcases that reflect the structure of the tested code. When multiple tests in a 6313481Sgiacomo.travaglini@arm.comtest case need to share common objects and subroutines, you can put them into a 6413481Sgiacomo.travaglini@arm.com_test fixture_ class. 6513481Sgiacomo.travaglini@arm.com 6613481Sgiacomo.travaglini@arm.comA _test program_ can contain multiple test cases. 6713481Sgiacomo.travaglini@arm.com 6813481Sgiacomo.travaglini@arm.comWe'll now explain how to write a test program, starting at the individual 6913481Sgiacomo.travaglini@arm.comassertion level and building up to tests and test cases. 7013481Sgiacomo.travaglini@arm.com 7113481Sgiacomo.travaglini@arm.com# Assertions # 7213481Sgiacomo.travaglini@arm.com 7313481Sgiacomo.travaglini@arm.comGoogle Test assertions are macros that resemble function calls. You test a 7413481Sgiacomo.travaglini@arm.comclass or function by making assertions about its behavior. When an assertion 7513481Sgiacomo.travaglini@arm.comfails, Google Test prints the assertion's source file and line number location, 7613481Sgiacomo.travaglini@arm.comalong with a failure message. You may also supply a custom failure message 7713481Sgiacomo.travaglini@arm.comwhich will be appended to Google Test's message. 7813481Sgiacomo.travaglini@arm.com 7913481Sgiacomo.travaglini@arm.comThe assertions come in pairs that test the same thing but have different 8013481Sgiacomo.travaglini@arm.comeffects on the current function. `ASSERT_*` versions generate fatal failures 8113481Sgiacomo.travaglini@arm.comwhen they fail, and **abort the current function**. `EXPECT_*` versions generate 8213481Sgiacomo.travaglini@arm.comnonfatal failures, which don't abort the current function. Usually `EXPECT_*` 8313481Sgiacomo.travaglini@arm.comare preferred, as they allow more than one failures to be reported in a test. 8413481Sgiacomo.travaglini@arm.comHowever, you should use `ASSERT_*` if it doesn't make sense to continue when 8513481Sgiacomo.travaglini@arm.comthe assertion in question fails. 8613481Sgiacomo.travaglini@arm.com 8713481Sgiacomo.travaglini@arm.comSince a failed `ASSERT_*` returns from the current function immediately, 8813481Sgiacomo.travaglini@arm.compossibly skipping clean-up code that comes after it, it may cause a space leak. 8913481Sgiacomo.travaglini@arm.comDepending on the nature of the leak, it may or may not be worth fixing - so 9013481Sgiacomo.travaglini@arm.comkeep this in mind if you get a heap checker error in addition to assertion 9113481Sgiacomo.travaglini@arm.comerrors. 9213481Sgiacomo.travaglini@arm.com 9313481Sgiacomo.travaglini@arm.comTo provide a custom failure message, simply stream it into the macro using the 9413481Sgiacomo.travaglini@arm.com`<<` operator, or a sequence of such operators. An example: 9513481Sgiacomo.travaglini@arm.com``` 9613481Sgiacomo.travaglini@arm.comASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length"; 9713481Sgiacomo.travaglini@arm.com 9813481Sgiacomo.travaglini@arm.comfor (int i = 0; i < x.size(); ++i) { 9913481Sgiacomo.travaglini@arm.com EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i; 10013481Sgiacomo.travaglini@arm.com} 10113481Sgiacomo.travaglini@arm.com``` 10213481Sgiacomo.travaglini@arm.com 10313481Sgiacomo.travaglini@arm.comAnything that can be streamed to an `ostream` can be streamed to an assertion 10413481Sgiacomo.travaglini@arm.commacro--in particular, C strings and `string` objects. If a wide string 10513481Sgiacomo.travaglini@arm.com(`wchar_t*`, `TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is 10613481Sgiacomo.travaglini@arm.comstreamed to an assertion, it will be translated to UTF-8 when printed. 10713481Sgiacomo.travaglini@arm.com 10813481Sgiacomo.travaglini@arm.com## Basic Assertions ## 10913481Sgiacomo.travaglini@arm.com 11013481Sgiacomo.travaglini@arm.comThese assertions do basic true/false condition testing. 11113481Sgiacomo.travaglini@arm.com 11213481Sgiacomo.travaglini@arm.com| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 11313481Sgiacomo.travaglini@arm.com|:--------------------|:-----------------------|:-------------| 11413481Sgiacomo.travaglini@arm.com| `ASSERT_TRUE(`_condition_`)`; | `EXPECT_TRUE(`_condition_`)`; | _condition_ is true | 11513481Sgiacomo.travaglini@arm.com| `ASSERT_FALSE(`_condition_`)`; | `EXPECT_FALSE(`_condition_`)`; | _condition_ is false | 11613481Sgiacomo.travaglini@arm.com 11713481Sgiacomo.travaglini@arm.comRemember, when they fail, `ASSERT_*` yields a fatal failure and 11813481Sgiacomo.travaglini@arm.comreturns from the current function, while `EXPECT_*` yields a nonfatal 11913481Sgiacomo.travaglini@arm.comfailure, allowing the function to continue running. In either case, an 12013481Sgiacomo.travaglini@arm.comassertion failure means its containing test fails. 12113481Sgiacomo.travaglini@arm.com 12213481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 12313481Sgiacomo.travaglini@arm.com 12413481Sgiacomo.travaglini@arm.com## Binary Comparison ## 12513481Sgiacomo.travaglini@arm.com 12613481Sgiacomo.travaglini@arm.comThis section describes assertions that compare two values. 12713481Sgiacomo.travaglini@arm.com 12813481Sgiacomo.travaglini@arm.com| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 12913481Sgiacomo.travaglini@arm.com|:--------------------|:-----------------------|:-------------| 13013481Sgiacomo.travaglini@arm.com|`ASSERT_EQ(`_val1_`, `_val2_`);`|`EXPECT_EQ(`_val1_`, `_val2_`);`| _val1_ `==` _val2_ | 13113481Sgiacomo.travaglini@arm.com|`ASSERT_NE(`_val1_`, `_val2_`);`|`EXPECT_NE(`_val1_`, `_val2_`);`| _val1_ `!=` _val2_ | 13213481Sgiacomo.travaglini@arm.com|`ASSERT_LT(`_val1_`, `_val2_`);`|`EXPECT_LT(`_val1_`, `_val2_`);`| _val1_ `<` _val2_ | 13313481Sgiacomo.travaglini@arm.com|`ASSERT_LE(`_val1_`, `_val2_`);`|`EXPECT_LE(`_val1_`, `_val2_`);`| _val1_ `<=` _val2_ | 13413481Sgiacomo.travaglini@arm.com|`ASSERT_GT(`_val1_`, `_val2_`);`|`EXPECT_GT(`_val1_`, `_val2_`);`| _val1_ `>` _val2_ | 13513481Sgiacomo.travaglini@arm.com|`ASSERT_GE(`_val1_`, `_val2_`);`|`EXPECT_GE(`_val1_`, `_val2_`);`| _val1_ `>=` _val2_ | 13613481Sgiacomo.travaglini@arm.com 13713481Sgiacomo.travaglini@arm.comIn the event of a failure, Google Test prints both _val1_ and _val2_. 13813481Sgiacomo.travaglini@arm.com 13913481Sgiacomo.travaglini@arm.comValue arguments must be comparable by the assertion's comparison 14013481Sgiacomo.travaglini@arm.comoperator or you'll get a compiler error. We used to require the 14113481Sgiacomo.travaglini@arm.comarguments to support the `<<` operator for streaming to an `ostream`, 14213481Sgiacomo.travaglini@arm.combut it's no longer necessary since v1.6.0 (if `<<` is supported, it 14313481Sgiacomo.travaglini@arm.comwill be called to print the arguments when the assertion fails; 14413481Sgiacomo.travaglini@arm.comotherwise Google Test will attempt to print them in the best way it 14513481Sgiacomo.travaglini@arm.comcan. For more details and how to customize the printing of the 14613481Sgiacomo.travaglini@arm.comarguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).). 14713481Sgiacomo.travaglini@arm.com 14813481Sgiacomo.travaglini@arm.comThese assertions can work with a user-defined type, but only if you define the 14913481Sgiacomo.travaglini@arm.comcorresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding 15013481Sgiacomo.travaglini@arm.comoperator is defined, prefer using the `ASSERT_*()` macros because they will 15113481Sgiacomo.travaglini@arm.comprint out not only the result of the comparison, but the two operands as well. 15213481Sgiacomo.travaglini@arm.com 15313481Sgiacomo.travaglini@arm.comArguments are always evaluated exactly once. Therefore, it's OK for the 15413481Sgiacomo.travaglini@arm.comarguments to have side effects. However, as with any ordinary C/C++ function, 15513481Sgiacomo.travaglini@arm.comthe arguments' evaluation order is undefined (i.e. the compiler is free to 15613481Sgiacomo.travaglini@arm.comchoose any order) and your code should not depend on any particular argument 15713481Sgiacomo.travaglini@arm.comevaluation order. 15813481Sgiacomo.travaglini@arm.com 15913481Sgiacomo.travaglini@arm.com`ASSERT_EQ()` does pointer equality on pointers. If used on two C strings, it 16013481Sgiacomo.travaglini@arm.comtests if they are in the same memory location, not if they have the same value. 16113481Sgiacomo.travaglini@arm.comTherefore, if you want to compare C strings (e.g. `const char*`) by value, use 16213481Sgiacomo.travaglini@arm.com`ASSERT_STREQ()` , which will be described later on. In particular, to assert 16313481Sgiacomo.travaglini@arm.comthat a C string is `NULL`, use `ASSERT_STREQ(NULL, c_string)` . However, to 16413481Sgiacomo.travaglini@arm.comcompare two `string` objects, you should use `ASSERT_EQ`. 16513481Sgiacomo.travaglini@arm.com 16613481Sgiacomo.travaglini@arm.comMacros in this section work with both narrow and wide string objects (`string` 16713481Sgiacomo.travaglini@arm.comand `wstring`). 16813481Sgiacomo.travaglini@arm.com 16913481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 17013481Sgiacomo.travaglini@arm.com 17113481Sgiacomo.travaglini@arm.com_Historical note_: Before February 2016 `*_EQ` had a convention of calling it as 17213481Sgiacomo.travaglini@arm.com`ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. 17313481Sgiacomo.travaglini@arm.comNow `*_EQ` treats both parameters in the same way. 17413481Sgiacomo.travaglini@arm.com 17513481Sgiacomo.travaglini@arm.com## String Comparison ## 17613481Sgiacomo.travaglini@arm.com 17713481Sgiacomo.travaglini@arm.comThe assertions in this group compare two **C strings**. If you want to compare 17813481Sgiacomo.travaglini@arm.comtwo `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead. 17913481Sgiacomo.travaglini@arm.com 18013481Sgiacomo.travaglini@arm.com| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 18113481Sgiacomo.travaglini@arm.com|:--------------------|:-----------------------|:-------------| 18213481Sgiacomo.travaglini@arm.com| `ASSERT_STREQ(`_str1_`, `_str2_`);` | `EXPECT_STREQ(`_str1_`, `_str_2`);` | the two C strings have the same content | 18313481Sgiacomo.travaglini@arm.com| `ASSERT_STRNE(`_str1_`, `_str2_`);` | `EXPECT_STRNE(`_str1_`, `_str2_`);` | the two C strings have different content | 18413481Sgiacomo.travaglini@arm.com| `ASSERT_STRCASEEQ(`_str1_`, `_str2_`);`| `EXPECT_STRCASEEQ(`_str1_`, `_str2_`);` | the two C strings have the same content, ignoring case | 18513481Sgiacomo.travaglini@arm.com| `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case | 18613481Sgiacomo.travaglini@arm.com 18713481Sgiacomo.travaglini@arm.comNote that "CASE" in an assertion name means that case is ignored. 18813481Sgiacomo.travaglini@arm.com 18913481Sgiacomo.travaglini@arm.com`*STREQ*` and `*STRNE*` also accept wide C strings (`wchar_t*`). If a 19013481Sgiacomo.travaglini@arm.comcomparison of two wide strings fails, their values will be printed as UTF-8 19113481Sgiacomo.travaglini@arm.comnarrow strings. 19213481Sgiacomo.travaglini@arm.com 19313481Sgiacomo.travaglini@arm.comA `NULL` pointer and an empty string are considered _different_. 19413481Sgiacomo.travaglini@arm.com 19513481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 19613481Sgiacomo.travaglini@arm.com 19713481Sgiacomo.travaglini@arm.comSee also: For more string comparison tricks (substring, prefix, suffix, and 19813481Sgiacomo.travaglini@arm.comregular expression matching, for example), see the [Advanced Google Test Guide](AdvancedGuide.md). 19913481Sgiacomo.travaglini@arm.com 20013481Sgiacomo.travaglini@arm.com# Simple Tests # 20113481Sgiacomo.travaglini@arm.com 20213481Sgiacomo.travaglini@arm.comTo create a test: 20313481Sgiacomo.travaglini@arm.com 1. Use the `TEST()` macro to define and name a test function, These are ordinary C++ functions that don't return a value. 20413481Sgiacomo.travaglini@arm.com 1. In this function, along with any valid C++ statements you want to include, use the various Google Test assertions to check values. 20513481Sgiacomo.travaglini@arm.com 1. The test's result is determined by the assertions; if any assertion in the test fails (either fatally or non-fatally), or if the test crashes, the entire test fails. Otherwise, it succeeds. 20613481Sgiacomo.travaglini@arm.com 20713481Sgiacomo.travaglini@arm.com``` 20813481Sgiacomo.travaglini@arm.comTEST(test_case_name, test_name) { 20913481Sgiacomo.travaglini@arm.com ... test body ... 21013481Sgiacomo.travaglini@arm.com} 21113481Sgiacomo.travaglini@arm.com``` 21213481Sgiacomo.travaglini@arm.com 21313481Sgiacomo.travaglini@arm.com 21413481Sgiacomo.travaglini@arm.com`TEST()` arguments go from general to specific. The _first_ argument is the 21513481Sgiacomo.travaglini@arm.comname of the test case, and the _second_ argument is the test's name within the 21613481Sgiacomo.travaglini@arm.comtest case. Both names must be valid C++ identifiers, and they should not contain underscore (`_`). A test's _full name_ consists of its containing test case and its 21713481Sgiacomo.travaglini@arm.comindividual name. Tests from different test cases can have the same individual 21813481Sgiacomo.travaglini@arm.comname. 21913481Sgiacomo.travaglini@arm.com 22013481Sgiacomo.travaglini@arm.comFor example, let's take a simple integer function: 22113481Sgiacomo.travaglini@arm.com``` 22213481Sgiacomo.travaglini@arm.comint Factorial(int n); // Returns the factorial of n 22313481Sgiacomo.travaglini@arm.com``` 22413481Sgiacomo.travaglini@arm.com 22513481Sgiacomo.travaglini@arm.comA test case for this function might look like: 22613481Sgiacomo.travaglini@arm.com``` 22713481Sgiacomo.travaglini@arm.com// Tests factorial of 0. 22813481Sgiacomo.travaglini@arm.comTEST(FactorialTest, HandlesZeroInput) { 22913481Sgiacomo.travaglini@arm.com EXPECT_EQ(1, Factorial(0)); 23013481Sgiacomo.travaglini@arm.com} 23113481Sgiacomo.travaglini@arm.com 23213481Sgiacomo.travaglini@arm.com// Tests factorial of positive numbers. 23313481Sgiacomo.travaglini@arm.comTEST(FactorialTest, HandlesPositiveInput) { 23413481Sgiacomo.travaglini@arm.com EXPECT_EQ(1, Factorial(1)); 23513481Sgiacomo.travaglini@arm.com EXPECT_EQ(2, Factorial(2)); 23613481Sgiacomo.travaglini@arm.com EXPECT_EQ(6, Factorial(3)); 23713481Sgiacomo.travaglini@arm.com EXPECT_EQ(40320, Factorial(8)); 23813481Sgiacomo.travaglini@arm.com} 23913481Sgiacomo.travaglini@arm.com``` 24013481Sgiacomo.travaglini@arm.com 24113481Sgiacomo.travaglini@arm.comGoogle Test groups the test results by test cases, so logically-related tests 24213481Sgiacomo.travaglini@arm.comshould be in the same test case; in other words, the first argument to their 24313481Sgiacomo.travaglini@arm.com`TEST()` should be the same. In the above example, we have two tests, 24413481Sgiacomo.travaglini@arm.com`HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test 24513481Sgiacomo.travaglini@arm.comcase `FactorialTest`. 24613481Sgiacomo.travaglini@arm.com 24713481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 24813481Sgiacomo.travaglini@arm.com 24913481Sgiacomo.travaglini@arm.com# Test Fixtures: Using the Same Data Configuration for Multiple Tests # 25013481Sgiacomo.travaglini@arm.com 25113481Sgiacomo.travaglini@arm.comIf you find yourself writing two or more tests that operate on similar data, 25213481Sgiacomo.travaglini@arm.comyou can use a _test fixture_. It allows you to reuse the same configuration of 25313481Sgiacomo.travaglini@arm.comobjects for several different tests. 25413481Sgiacomo.travaglini@arm.com 25513481Sgiacomo.travaglini@arm.comTo create a fixture, just: 25613481Sgiacomo.travaglini@arm.com 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 25713481Sgiacomo.travaglini@arm.com 1. Inside the class, declare any objects you plan to use. 25813481Sgiacomo.travaglini@arm.com 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. 25913481Sgiacomo.travaglini@arm.com 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function). 26013481Sgiacomo.travaglini@arm.com 1. If needed, define subroutines for your tests to share. 26113481Sgiacomo.travaglini@arm.com 26213481Sgiacomo.travaglini@arm.comWhen using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to 26313481Sgiacomo.travaglini@arm.comaccess objects and subroutines in the test fixture: 26413481Sgiacomo.travaglini@arm.com``` 26513481Sgiacomo.travaglini@arm.comTEST_F(test_case_name, test_name) { 26613481Sgiacomo.travaglini@arm.com ... test body ... 26713481Sgiacomo.travaglini@arm.com} 26813481Sgiacomo.travaglini@arm.com``` 26913481Sgiacomo.travaglini@arm.com 27013481Sgiacomo.travaglini@arm.comLike `TEST()`, the first argument is the test case name, but for `TEST_F()` 27113481Sgiacomo.travaglini@arm.comthis must be the name of the test fixture class. You've probably guessed: `_F` 27213481Sgiacomo.travaglini@arm.comis for fixture. 27313481Sgiacomo.travaglini@arm.com 27413481Sgiacomo.travaglini@arm.comUnfortunately, the C++ macro system does not allow us to create a single macro 27513481Sgiacomo.travaglini@arm.comthat can handle both types of tests. Using the wrong macro causes a compiler 27613481Sgiacomo.travaglini@arm.comerror. 27713481Sgiacomo.travaglini@arm.com 27813481Sgiacomo.travaglini@arm.comAlso, you must first define a test fixture class before using it in a 27913481Sgiacomo.travaglini@arm.com`TEST_F()`, or you'll get the compiler error "`virtual outside class 28013481Sgiacomo.travaglini@arm.comdeclaration`". 28113481Sgiacomo.travaglini@arm.com 28213481Sgiacomo.travaglini@arm.comFor each test defined with `TEST_F()`, Google Test will: 28313481Sgiacomo.travaglini@arm.com 1. Create a _fresh_ test fixture at runtime 28413481Sgiacomo.travaglini@arm.com 1. Immediately initialize it via `SetUp()` , 28513481Sgiacomo.travaglini@arm.com 1. Run the test 28613481Sgiacomo.travaglini@arm.com 1. Clean up by calling `TearDown()` 28713481Sgiacomo.travaglini@arm.com 1. Delete the test fixture. Note that different tests in the same test case have different test fixture objects, and Google Test always deletes a test fixture before it creates the next one. Google Test does not reuse the same test fixture for multiple tests. Any changes one test makes to the fixture do not affect other tests. 28813481Sgiacomo.travaglini@arm.com 28913481Sgiacomo.travaglini@arm.comAs an example, let's write tests for a FIFO queue class named `Queue`, which 29013481Sgiacomo.travaglini@arm.comhas the following interface: 29113481Sgiacomo.travaglini@arm.com``` 29213481Sgiacomo.travaglini@arm.comtemplate <typename E> // E is the element type. 29313481Sgiacomo.travaglini@arm.comclass Queue { 29413481Sgiacomo.travaglini@arm.com public: 29513481Sgiacomo.travaglini@arm.com Queue(); 29613481Sgiacomo.travaglini@arm.com void Enqueue(const E& element); 29713481Sgiacomo.travaglini@arm.com E* Dequeue(); // Returns NULL if the queue is empty. 29813481Sgiacomo.travaglini@arm.com size_t size() const; 29913481Sgiacomo.travaglini@arm.com ... 30013481Sgiacomo.travaglini@arm.com}; 30113481Sgiacomo.travaglini@arm.com``` 30213481Sgiacomo.travaglini@arm.com 30313481Sgiacomo.travaglini@arm.comFirst, define a fixture class. By convention, you should give it the name 30413481Sgiacomo.travaglini@arm.com`FooTest` where `Foo` is the class being tested. 30513481Sgiacomo.travaglini@arm.com``` 30613481Sgiacomo.travaglini@arm.comclass QueueTest : public ::testing::Test { 30713481Sgiacomo.travaglini@arm.com protected: 30813481Sgiacomo.travaglini@arm.com virtual void SetUp() { 30913481Sgiacomo.travaglini@arm.com q1_.Enqueue(1); 31013481Sgiacomo.travaglini@arm.com q2_.Enqueue(2); 31113481Sgiacomo.travaglini@arm.com q2_.Enqueue(3); 31213481Sgiacomo.travaglini@arm.com } 31313481Sgiacomo.travaglini@arm.com 31413481Sgiacomo.travaglini@arm.com // virtual void TearDown() {} 31513481Sgiacomo.travaglini@arm.com 31613481Sgiacomo.travaglini@arm.com Queue<int> q0_; 31713481Sgiacomo.travaglini@arm.com Queue<int> q1_; 31813481Sgiacomo.travaglini@arm.com Queue<int> q2_; 31913481Sgiacomo.travaglini@arm.com}; 32013481Sgiacomo.travaglini@arm.com``` 32113481Sgiacomo.travaglini@arm.com 32213481Sgiacomo.travaglini@arm.comIn this case, `TearDown()` is not needed since we don't have to clean up after 32313481Sgiacomo.travaglini@arm.comeach test, other than what's already done by the destructor. 32413481Sgiacomo.travaglini@arm.com 32513481Sgiacomo.travaglini@arm.comNow we'll write tests using `TEST_F()` and this fixture. 32613481Sgiacomo.travaglini@arm.com``` 32713481Sgiacomo.travaglini@arm.comTEST_F(QueueTest, IsEmptyInitially) { 32813481Sgiacomo.travaglini@arm.com EXPECT_EQ(0, q0_.size()); 32913481Sgiacomo.travaglini@arm.com} 33013481Sgiacomo.travaglini@arm.com 33113481Sgiacomo.travaglini@arm.comTEST_F(QueueTest, DequeueWorks) { 33213481Sgiacomo.travaglini@arm.com int* n = q0_.Dequeue(); 33313481Sgiacomo.travaglini@arm.com EXPECT_EQ(NULL, n); 33413481Sgiacomo.travaglini@arm.com 33513481Sgiacomo.travaglini@arm.com n = q1_.Dequeue(); 33613481Sgiacomo.travaglini@arm.com ASSERT_TRUE(n != NULL); 33713481Sgiacomo.travaglini@arm.com EXPECT_EQ(1, *n); 33813481Sgiacomo.travaglini@arm.com EXPECT_EQ(0, q1_.size()); 33913481Sgiacomo.travaglini@arm.com delete n; 34013481Sgiacomo.travaglini@arm.com 34113481Sgiacomo.travaglini@arm.com n = q2_.Dequeue(); 34213481Sgiacomo.travaglini@arm.com ASSERT_TRUE(n != NULL); 34313481Sgiacomo.travaglini@arm.com EXPECT_EQ(2, *n); 34413481Sgiacomo.travaglini@arm.com EXPECT_EQ(1, q2_.size()); 34513481Sgiacomo.travaglini@arm.com delete n; 34613481Sgiacomo.travaglini@arm.com} 34713481Sgiacomo.travaglini@arm.com``` 34813481Sgiacomo.travaglini@arm.com 34913481Sgiacomo.travaglini@arm.comThe above uses both `ASSERT_*` and `EXPECT_*` assertions. The rule of thumb is 35013481Sgiacomo.travaglini@arm.comto use `EXPECT_*` when you want the test to continue to reveal more errors 35113481Sgiacomo.travaglini@arm.comafter the assertion failure, and use `ASSERT_*` when continuing after failure 35213481Sgiacomo.travaglini@arm.comdoesn't make sense. For example, the second assertion in the `Dequeue` test is 35313481Sgiacomo.travaglini@arm.com`ASSERT_TRUE(n != NULL)`, as we need to dereference the pointer `n` later, 35413481Sgiacomo.travaglini@arm.comwhich would lead to a segfault when `n` is `NULL`. 35513481Sgiacomo.travaglini@arm.com 35613481Sgiacomo.travaglini@arm.comWhen these tests run, the following happens: 35713481Sgiacomo.travaglini@arm.com 1. Google Test constructs a `QueueTest` object (let's call it `t1` ). 35813481Sgiacomo.travaglini@arm.com 1. `t1.SetUp()` initializes `t1` . 35913481Sgiacomo.travaglini@arm.com 1. The first test ( `IsEmptyInitially` ) runs on `t1` . 36013481Sgiacomo.travaglini@arm.com 1. `t1.TearDown()` cleans up after the test finishes. 36113481Sgiacomo.travaglini@arm.com 1. `t1` is destructed. 36213481Sgiacomo.travaglini@arm.com 1. The above steps are repeated on another `QueueTest` object, this time running the `DequeueWorks` test. 36313481Sgiacomo.travaglini@arm.com 36413481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 36513481Sgiacomo.travaglini@arm.com 36613481Sgiacomo.travaglini@arm.com_Note_: Google Test automatically saves all _Google Test_ flags when a test 36713481Sgiacomo.travaglini@arm.comobject is constructed, and restores them when it is destructed. 36813481Sgiacomo.travaglini@arm.com 36913481Sgiacomo.travaglini@arm.com# Invoking the Tests # 37013481Sgiacomo.travaglini@arm.com 37113481Sgiacomo.travaglini@arm.com`TEST()` and `TEST_F()` implicitly register their tests with Google Test. So, unlike with many other C++ testing frameworks, you don't have to re-list all your defined tests in order to run them. 37213481Sgiacomo.travaglini@arm.com 37313481Sgiacomo.travaglini@arm.comAfter defining your tests, you can run them with `RUN_ALL_TESTS()` , which returns `0` if all the tests are successful, or `1` otherwise. Note that `RUN_ALL_TESTS()` runs _all tests_ in your link unit -- they can be from different test cases, or even different source files. 37413481Sgiacomo.travaglini@arm.com 37513481Sgiacomo.travaglini@arm.comWhen invoked, the `RUN_ALL_TESTS()` macro: 37613481Sgiacomo.travaglini@arm.com 1. Saves the state of all Google Test flags. 37713481Sgiacomo.travaglini@arm.com 1. Creates a test fixture object for the first test. 37813481Sgiacomo.travaglini@arm.com 1. Initializes it via `SetUp()`. 37913481Sgiacomo.travaglini@arm.com 1. Runs the test on the fixture object. 38013481Sgiacomo.travaglini@arm.com 1. Cleans up the fixture via `TearDown()`. 38113481Sgiacomo.travaglini@arm.com 1. Deletes the fixture. 38213481Sgiacomo.travaglini@arm.com 1. Restores the state of all Google Test flags. 38313481Sgiacomo.travaglini@arm.com 1. Repeats the above steps for the next test, until all tests have run. 38413481Sgiacomo.travaglini@arm.com 38513481Sgiacomo.travaglini@arm.comIn addition, if the text fixture's constructor generates a fatal failure in 38613481Sgiacomo.travaglini@arm.comstep 2, there is no point for step 3 - 5 and they are thus skipped. Similarly, 38713481Sgiacomo.travaglini@arm.comif step 3 generates a fatal failure, step 4 will be skipped. 38813481Sgiacomo.travaglini@arm.com 38913481Sgiacomo.travaglini@arm.com_Important_: You must not ignore the return value of `RUN_ALL_TESTS()`, or `gcc` 39013481Sgiacomo.travaglini@arm.comwill give you a compiler error. The rationale for this design is that the 39113481Sgiacomo.travaglini@arm.comautomated testing service determines whether a test has passed based on its 39213481Sgiacomo.travaglini@arm.comexit code, not on its stdout/stderr output; thus your `main()` function must 39313481Sgiacomo.travaglini@arm.comreturn the value of `RUN_ALL_TESTS()`. 39413481Sgiacomo.travaglini@arm.com 39513481Sgiacomo.travaglini@arm.comAlso, you should call `RUN_ALL_TESTS()` only **once**. Calling it more than once 39613481Sgiacomo.travaglini@arm.comconflicts with some advanced Google Test features (e.g. thread-safe death 39713481Sgiacomo.travaglini@arm.comtests) and thus is not supported. 39813481Sgiacomo.travaglini@arm.com 39913481Sgiacomo.travaglini@arm.com_Availability_: Linux, Windows, Mac. 40013481Sgiacomo.travaglini@arm.com 40113481Sgiacomo.travaglini@arm.com# Writing the main() Function # 40213481Sgiacomo.travaglini@arm.com 40313481Sgiacomo.travaglini@arm.comYou can start from this boilerplate: 40413481Sgiacomo.travaglini@arm.com``` 40513481Sgiacomo.travaglini@arm.com#include "this/package/foo.h" 40613481Sgiacomo.travaglini@arm.com#include "gtest/gtest.h" 40713481Sgiacomo.travaglini@arm.com 40813481Sgiacomo.travaglini@arm.comnamespace { 40913481Sgiacomo.travaglini@arm.com 41013481Sgiacomo.travaglini@arm.com// The fixture for testing class Foo. 41113481Sgiacomo.travaglini@arm.comclass FooTest : public ::testing::Test { 41213481Sgiacomo.travaglini@arm.com protected: 41313481Sgiacomo.travaglini@arm.com // You can remove any or all of the following functions if its body 41413481Sgiacomo.travaglini@arm.com // is empty. 41513481Sgiacomo.travaglini@arm.com 41613481Sgiacomo.travaglini@arm.com FooTest() { 41713481Sgiacomo.travaglini@arm.com // You can do set-up work for each test here. 41813481Sgiacomo.travaglini@arm.com } 41913481Sgiacomo.travaglini@arm.com 42013481Sgiacomo.travaglini@arm.com virtual ~FooTest() { 42113481Sgiacomo.travaglini@arm.com // You can do clean-up work that doesn't throw exceptions here. 42213481Sgiacomo.travaglini@arm.com } 42313481Sgiacomo.travaglini@arm.com 42413481Sgiacomo.travaglini@arm.com // If the constructor and destructor are not enough for setting up 42513481Sgiacomo.travaglini@arm.com // and cleaning up each test, you can define the following methods: 42613481Sgiacomo.travaglini@arm.com 42713481Sgiacomo.travaglini@arm.com virtual void SetUp() { 42813481Sgiacomo.travaglini@arm.com // Code here will be called immediately after the constructor (right 42913481Sgiacomo.travaglini@arm.com // before each test). 43013481Sgiacomo.travaglini@arm.com } 43113481Sgiacomo.travaglini@arm.com 43213481Sgiacomo.travaglini@arm.com virtual void TearDown() { 43313481Sgiacomo.travaglini@arm.com // Code here will be called immediately after each test (right 43413481Sgiacomo.travaglini@arm.com // before the destructor). 43513481Sgiacomo.travaglini@arm.com } 43613481Sgiacomo.travaglini@arm.com 43713481Sgiacomo.travaglini@arm.com // Objects declared here can be used by all tests in the test case for Foo. 43813481Sgiacomo.travaglini@arm.com}; 43913481Sgiacomo.travaglini@arm.com 44013481Sgiacomo.travaglini@arm.com// Tests that the Foo::Bar() method does Abc. 44113481Sgiacomo.travaglini@arm.comTEST_F(FooTest, MethodBarDoesAbc) { 44213481Sgiacomo.travaglini@arm.com const string input_filepath = "this/package/testdata/myinputfile.dat"; 44313481Sgiacomo.travaglini@arm.com const string output_filepath = "this/package/testdata/myoutputfile.dat"; 44413481Sgiacomo.travaglini@arm.com Foo f; 44513481Sgiacomo.travaglini@arm.com EXPECT_EQ(0, f.Bar(input_filepath, output_filepath)); 44613481Sgiacomo.travaglini@arm.com} 44713481Sgiacomo.travaglini@arm.com 44813481Sgiacomo.travaglini@arm.com// Tests that Foo does Xyz. 44913481Sgiacomo.travaglini@arm.comTEST_F(FooTest, DoesXyz) { 45013481Sgiacomo.travaglini@arm.com // Exercises the Xyz feature of Foo. 45113481Sgiacomo.travaglini@arm.com} 45213481Sgiacomo.travaglini@arm.com 45313481Sgiacomo.travaglini@arm.com} // namespace 45413481Sgiacomo.travaglini@arm.com 45513481Sgiacomo.travaglini@arm.comint main(int argc, char **argv) { 45613481Sgiacomo.travaglini@arm.com ::testing::InitGoogleTest(&argc, argv); 45713481Sgiacomo.travaglini@arm.com return RUN_ALL_TESTS(); 45813481Sgiacomo.travaglini@arm.com} 45913481Sgiacomo.travaglini@arm.com``` 46013481Sgiacomo.travaglini@arm.com 46113481Sgiacomo.travaglini@arm.comThe `::testing::InitGoogleTest()` function parses the command line for Google 46213481Sgiacomo.travaglini@arm.comTest flags, and removes all recognized flags. This allows the user to control a 46313481Sgiacomo.travaglini@arm.comtest program's behavior via various flags, which we'll cover in [AdvancedGuide](AdvancedGuide.md). 46413481Sgiacomo.travaglini@arm.comYou must call this function before calling `RUN_ALL_TESTS()`, or the flags 46513481Sgiacomo.travaglini@arm.comwon't be properly initialized. 46613481Sgiacomo.travaglini@arm.com 46713481Sgiacomo.travaglini@arm.comOn Windows, `InitGoogleTest()` also works with wide strings, so it can be used 46813481Sgiacomo.travaglini@arm.comin programs compiled in `UNICODE` mode as well. 46913481Sgiacomo.travaglini@arm.com 47013481Sgiacomo.travaglini@arm.comBut maybe you think that writing all those main() functions is too much work? We agree with you completely and that's why Google Test provides a basic implementation of main(). If it fits your needs, then just link your test with gtest\_main library and you are good to go. 47113481Sgiacomo.travaglini@arm.com 47213481Sgiacomo.travaglini@arm.com## Important note for Visual C++ users ## 47313481Sgiacomo.travaglini@arm.comIf you put your tests into a library and your `main()` function is in a different library or in your .exe file, those tests will not run. The reason is a [bug](https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=244410&siteid=210) in Visual C++. When you define your tests, Google Test creates certain static objects to register them. These objects are not referenced from elsewhere but their constructors are still supposed to run. When Visual C++ linker sees that nothing in the library is referenced from other places it throws the library out. You have to reference your library with tests from your main program to keep the linker from discarding it. Here is how to do it. Somewhere in your library code declare a function: 47413481Sgiacomo.travaglini@arm.com``` 47513481Sgiacomo.travaglini@arm.com__declspec(dllexport) int PullInMyLibrary() { return 0; } 47613481Sgiacomo.travaglini@arm.com``` 47713481Sgiacomo.travaglini@arm.comIf you put your tests in a static library (not DLL) then `__declspec(dllexport)` is not required. Now, in your main program, write a code that invokes that function: 47813481Sgiacomo.travaglini@arm.com``` 47913481Sgiacomo.travaglini@arm.comint PullInMyLibrary(); 48013481Sgiacomo.travaglini@arm.comstatic int dummy = PullInMyLibrary(); 48113481Sgiacomo.travaglini@arm.com``` 48213481Sgiacomo.travaglini@arm.comThis will keep your tests referenced and will make them register themselves at startup. 48313481Sgiacomo.travaglini@arm.com 48413481Sgiacomo.travaglini@arm.comIn addition, if you define your tests in a static library, add `/OPT:NOREF` to your main program linker options. If you use MSVC++ IDE, go to your .exe project properties/Configuration Properties/Linker/Optimization and set References setting to `Keep Unreferenced Data (/OPT:NOREF)`. This will keep Visual C++ linker from discarding individual symbols generated by your tests from the final executable. 48513481Sgiacomo.travaglini@arm.com 48613481Sgiacomo.travaglini@arm.comThere is one more pitfall, though. If you use Google Test as a static library (that's how it is defined in gtest.vcproj) your tests must also reside in a static library. If you have to have them in a DLL, you _must_ change Google Test to build into a DLL as well. Otherwise your tests will not run correctly or will not run at all. The general conclusion here is: make your life easier - do not write your tests in libraries! 48713481Sgiacomo.travaglini@arm.com 48813481Sgiacomo.travaglini@arm.com# Where to Go from Here # 48913481Sgiacomo.travaglini@arm.com 49013481Sgiacomo.travaglini@arm.comCongratulations! You've learned the Google Test basics. You can start writing 49113481Sgiacomo.travaglini@arm.comand running Google Test tests, read some [samples](Samples.md), or continue with 49213481Sgiacomo.travaglini@arm.com[AdvancedGuide](AdvancedGuide.md), which describes many more useful Google Test features. 49313481Sgiacomo.travaglini@arm.com 49413481Sgiacomo.travaglini@arm.com# Known Limitations # 49513481Sgiacomo.travaglini@arm.com 49613481Sgiacomo.travaglini@arm.comGoogle Test is designed to be thread-safe. The implementation is 49713481Sgiacomo.travaglini@arm.comthread-safe on systems where the `pthreads` library is available. It 49813481Sgiacomo.travaglini@arm.comis currently _unsafe_ to use Google Test assertions from two threads 49913481Sgiacomo.travaglini@arm.comconcurrently on other systems (e.g. Windows). In most tests this is 50013481Sgiacomo.travaglini@arm.comnot an issue as usually the assertions are done in the main thread. If 50113481Sgiacomo.travaglini@arm.comyou want to help, you can volunteer to implement the necessary 50213481Sgiacomo.travaglini@arm.comsynchronization primitives in `gtest-port.h` for your platform. 503