113481Sgiacomo.travaglini@arm.com 213481Sgiacomo.travaglini@arm.com 313481Sgiacomo.travaglini@arm.comIf you cannot find the answer to your question here, and you have read 413481Sgiacomo.travaglini@arm.com[Primer](V1_6_Primer.md) and [AdvancedGuide](V1_6_AdvancedGuide.md), send it to 513481Sgiacomo.travaglini@arm.comgoogletestframework@googlegroups.com. 613481Sgiacomo.travaglini@arm.com 713481Sgiacomo.travaglini@arm.com## Why should I use Google Test instead of my favorite C++ testing framework? ## 813481Sgiacomo.travaglini@arm.com 913481Sgiacomo.travaglini@arm.comFirst, let us say clearly that we don't want to get into the debate of 1013481Sgiacomo.travaglini@arm.comwhich C++ testing framework is **the best**. There exist many fine 1113481Sgiacomo.travaglini@arm.comframeworks for writing C++ tests, and we have tremendous respect for 1213481Sgiacomo.travaglini@arm.comthe developers and users of them. We don't think there is (or will 1313481Sgiacomo.travaglini@arm.combe) a single best framework - you have to pick the right tool for the 1413481Sgiacomo.travaglini@arm.comparticular task you are tackling. 1513481Sgiacomo.travaglini@arm.com 1613481Sgiacomo.travaglini@arm.comWe created Google Test because we couldn't find the right combination 1713481Sgiacomo.travaglini@arm.comof features and conveniences in an existing framework to satisfy _our_ 1813481Sgiacomo.travaglini@arm.comneeds. The following is a list of things that _we_ like about Google 1913481Sgiacomo.travaglini@arm.comTest. We don't claim them to be unique to Google Test - rather, the 2013481Sgiacomo.travaglini@arm.comcombination of them makes Google Test the choice for us. We hope this 2113481Sgiacomo.travaglini@arm.comlist can help you decide whether it is for you too. 2213481Sgiacomo.travaglini@arm.com 2313481Sgiacomo.travaglini@arm.com * Google Test is designed to be portable: it doesn't require exceptions or RTTI; it works around various bugs in various compilers and environments; etc. As a result, it works on Linux, Mac OS X, Windows and several embedded operating systems. 2413481Sgiacomo.travaglini@arm.com * Nonfatal assertions (`EXPECT_*`) have proven to be great time savers, as they allow a test to report multiple failures in a single edit-compile-test cycle. 2513481Sgiacomo.travaglini@arm.com * It's easy to write assertions that generate informative messages: you just use the stream syntax to append any additional information, e.g. `ASSERT_EQ(5, Foo(i)) << " where i = " << i;`. It doesn't require a new set of macros or special functions. 2613481Sgiacomo.travaglini@arm.com * Google Test automatically detects your tests and doesn't require you to enumerate them in order to run them. 2713481Sgiacomo.travaglini@arm.com * Death tests are pretty handy for ensuring that your asserts in production code are triggered by the right conditions. 2813481Sgiacomo.travaglini@arm.com * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop. 2913481Sgiacomo.travaglini@arm.com * You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure. 3013481Sgiacomo.travaglini@arm.com * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson. 3113481Sgiacomo.travaglini@arm.com * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_6_AdvancedGuide.md#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](V1_6_AdvancedGuide.md#value-parameterized-tests) or [types](V1_6_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can: 3213481Sgiacomo.travaglini@arm.com * expand your testing vocabulary by defining [custom predicates](V1_6_AdvancedGuide.md#predicate-assertions-for-better-error-messages), 3313481Sgiacomo.travaglini@arm.com * teach Google Test how to [print your types](V1_6_AdvancedGuide.md#teaching-google-test-how-to-print-your-values), 3413481Sgiacomo.travaglini@arm.com * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_6_AdvancedGuide.md#catching-failures), and 3513481Sgiacomo.travaglini@arm.com * reflect on the test cases or change the test output format by intercepting the [test events](V1_6_AdvancedGuide.md#extending-google-test-by-handling-test-events). 3613481Sgiacomo.travaglini@arm.com 3713481Sgiacomo.travaglini@arm.com## I'm getting warnings when compiling Google Test. Would you fix them? ## 3813481Sgiacomo.travaglini@arm.com 3913481Sgiacomo.travaglini@arm.comWe strive to minimize compiler warnings Google Test generates. Before releasing a new version, we test to make sure that it doesn't generate warnings when compiled using its CMake script on Windows, Linux, and Mac OS. 4013481Sgiacomo.travaglini@arm.com 4113481Sgiacomo.travaglini@arm.comUnfortunately, this doesn't mean you are guaranteed to see no warnings when compiling Google Test in your environment: 4213481Sgiacomo.travaglini@arm.com 4313481Sgiacomo.travaglini@arm.com * You may be using a different compiler as we use, or a different version of the same compiler. We cannot possibly test for all compilers. 4413481Sgiacomo.travaglini@arm.com * You may be compiling on a different platform as we do. 4513481Sgiacomo.travaglini@arm.com * Your project may be using different compiler flags as we do. 4613481Sgiacomo.travaglini@arm.com 4713481Sgiacomo.travaglini@arm.comIt is not always possible to make Google Test warning-free for everyone. Or, it may not be desirable if the warning is rarely enabled and fixing the violations makes the code more complex. 4813481Sgiacomo.travaglini@arm.com 4913481Sgiacomo.travaglini@arm.comIf you see warnings when compiling Google Test, we suggest that you use the `-isystem` flag (assuming your are using GCC) to mark Google Test headers as system headers. That'll suppress warnings from Google Test headers. 5013481Sgiacomo.travaglini@arm.com 5113481Sgiacomo.travaglini@arm.com## Why should not test case names and test names contain underscore? ## 5213481Sgiacomo.travaglini@arm.com 5313481Sgiacomo.travaglini@arm.comUnderscore (`_`) is special, as C++ reserves the following to be used by 5413481Sgiacomo.travaglini@arm.comthe compiler and the standard library: 5513481Sgiacomo.travaglini@arm.com 5613481Sgiacomo.travaglini@arm.com 1. any identifier that starts with an `_` followed by an upper-case letter, and 5713481Sgiacomo.travaglini@arm.com 1. any identifier that containers two consecutive underscores (i.e. `__`) _anywhere_ in its name. 5813481Sgiacomo.travaglini@arm.com 5913481Sgiacomo.travaglini@arm.comUser code is _prohibited_ from using such identifiers. 6013481Sgiacomo.travaglini@arm.com 6113481Sgiacomo.travaglini@arm.comNow let's look at what this means for `TEST` and `TEST_F`. 6213481Sgiacomo.travaglini@arm.com 6313481Sgiacomo.travaglini@arm.comCurrently `TEST(TestCaseName, TestName)` generates a class named 6413481Sgiacomo.travaglini@arm.com`TestCaseName_TestName_Test`. What happens if `TestCaseName` or `TestName` 6513481Sgiacomo.travaglini@arm.comcontains `_`? 6613481Sgiacomo.travaglini@arm.com 6713481Sgiacomo.travaglini@arm.com 1. If `TestCaseName` starts with an `_` followed by an upper-case letter (say, `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus invalid. 6813481Sgiacomo.travaglini@arm.com 1. If `TestCaseName` ends with an `_` (say, `Foo_`), we get `Foo__TestName_Test`, which is invalid. 6913481Sgiacomo.travaglini@arm.com 1. If `TestName` starts with an `_` (say, `_Bar`), we get `TestCaseName__Bar_Test`, which is invalid. 7013481Sgiacomo.travaglini@arm.com 1. If `TestName` ends with an `_` (say, `Bar_`), we get `TestCaseName_Bar__Test`, which is invalid. 7113481Sgiacomo.travaglini@arm.com 7213481Sgiacomo.travaglini@arm.comSo clearly `TestCaseName` and `TestName` cannot start or end with `_` 7313481Sgiacomo.travaglini@arm.com(Actually, `TestCaseName` can start with `_` -- as long as the `_` isn't 7413481Sgiacomo.travaglini@arm.comfollowed by an upper-case letter. But that's getting complicated. So 7513481Sgiacomo.travaglini@arm.comfor simplicity we just say that it cannot start with `_`.). 7613481Sgiacomo.travaglini@arm.com 7713481Sgiacomo.travaglini@arm.comIt may seem fine for `TestCaseName` and `TestName` to contain `_` in the 7813481Sgiacomo.travaglini@arm.commiddle. However, consider this: 7913481Sgiacomo.travaglini@arm.com``` 8013481Sgiacomo.travaglini@arm.comTEST(Time, Flies_Like_An_Arrow) { ... } 8113481Sgiacomo.travaglini@arm.comTEST(Time_Flies, Like_An_Arrow) { ... } 8213481Sgiacomo.travaglini@arm.com``` 8313481Sgiacomo.travaglini@arm.com 8413481Sgiacomo.travaglini@arm.comNow, the two `TEST`s will both generate the same class 8513481Sgiacomo.travaglini@arm.com(`Time_Files_Like_An_Arrow_Test`). That's not good. 8613481Sgiacomo.travaglini@arm.com 8713481Sgiacomo.travaglini@arm.comSo for simplicity, we just ask the users to avoid `_` in `TestCaseName` 8813481Sgiacomo.travaglini@arm.comand `TestName`. The rule is more constraining than necessary, but it's 8913481Sgiacomo.travaglini@arm.comsimple and easy to remember. It also gives Google Test some wiggle 9013481Sgiacomo.travaglini@arm.comroom in case its implementation needs to change in the future. 9113481Sgiacomo.travaglini@arm.com 9213481Sgiacomo.travaglini@arm.comIf you violate the rule, there may not be immediately consequences, 9313481Sgiacomo.travaglini@arm.combut your test may (just may) break with a new compiler (or a new 9413481Sgiacomo.travaglini@arm.comversion of the compiler you are using) or with a new version of Google 9513481Sgiacomo.travaglini@arm.comTest. Therefore it's best to follow the rule. 9613481Sgiacomo.travaglini@arm.com 9713481Sgiacomo.travaglini@arm.com## Why is it not recommended to install a pre-compiled copy of Google Test (for example, into /usr/local)? ## 9813481Sgiacomo.travaglini@arm.com 9913481Sgiacomo.travaglini@arm.comIn the early days, we said that you could install 10013481Sgiacomo.travaglini@arm.comcompiled Google Test libraries on `*`nix systems using `make install`. 10113481Sgiacomo.travaglini@arm.comThen every user of your machine can write tests without 10213481Sgiacomo.travaglini@arm.comrecompiling Google Test. 10313481Sgiacomo.travaglini@arm.com 10413481Sgiacomo.travaglini@arm.comThis seemed like a good idea, but it has a 10513481Sgiacomo.travaglini@arm.comgot-cha: every user needs to compile his tests using the _same_ compiler 10613481Sgiacomo.travaglini@arm.comflags used to compile the installed Google Test libraries; otherwise 10713481Sgiacomo.travaglini@arm.comhe may run into undefined behaviors (i.e. the tests can behave 10813481Sgiacomo.travaglini@arm.comstrangely and may even crash for no obvious reasons). 10913481Sgiacomo.travaglini@arm.com 11013481Sgiacomo.travaglini@arm.comWhy? Because C++ has this thing called the One-Definition Rule: if 11113481Sgiacomo.travaglini@arm.comtwo C++ source files contain different definitions of the same 11213481Sgiacomo.travaglini@arm.comclass/function/variable, and you link them together, you violate the 11313481Sgiacomo.travaglini@arm.comrule. The linker may or may not catch the error (in many cases it's 11413481Sgiacomo.travaglini@arm.comnot required by the C++ standard to catch the violation). If it 11513481Sgiacomo.travaglini@arm.comdoesn't, you get strange run-time behaviors that are unexpected and 11613481Sgiacomo.travaglini@arm.comhard to debug. 11713481Sgiacomo.travaglini@arm.com 11813481Sgiacomo.travaglini@arm.comIf you compile Google Test and your test code using different compiler 11913481Sgiacomo.travaglini@arm.comflags, they may see different definitions of the same 12013481Sgiacomo.travaglini@arm.comclass/function/variable (e.g. due to the use of `#if` in Google Test). 12113481Sgiacomo.travaglini@arm.comTherefore, for your sanity, we recommend to avoid installing pre-compiled 12213481Sgiacomo.travaglini@arm.comGoogle Test libraries. Instead, each project should compile 12313481Sgiacomo.travaglini@arm.comGoogle Test itself such that it can be sure that the same flags are 12413481Sgiacomo.travaglini@arm.comused for both Google Test and the tests. 12513481Sgiacomo.travaglini@arm.com 12613481Sgiacomo.travaglini@arm.com## How do I generate 64-bit binaries on Windows (using Visual Studio 2008)? ## 12713481Sgiacomo.travaglini@arm.com 12813481Sgiacomo.travaglini@arm.com(Answered by Trevor Robinson) 12913481Sgiacomo.travaglini@arm.com 13013481Sgiacomo.travaglini@arm.comLoad the supplied Visual Studio solution file, either `msvc\gtest-md.sln` or 13113481Sgiacomo.travaglini@arm.com`msvc\gtest.sln`. Go through the migration wizard to migrate the 13213481Sgiacomo.travaglini@arm.comsolution and project files to Visual Studio 2008. Select 13313481Sgiacomo.travaglini@arm.com`Configuration Manager...` from the `Build` menu. Select `<New...>` from 13413481Sgiacomo.travaglini@arm.comthe `Active solution platform` dropdown. Select `x64` from the new 13513481Sgiacomo.travaglini@arm.complatform dropdown, leave `Copy settings from` set to `Win32` and 13613481Sgiacomo.travaglini@arm.com`Create new project platforms` checked, then click `OK`. You now have 13713481Sgiacomo.travaglini@arm.com`Win32` and `x64` platform configurations, selectable from the 13813481Sgiacomo.travaglini@arm.com`Standard` toolbar, which allow you to toggle between building 32-bit or 13913481Sgiacomo.travaglini@arm.com64-bit binaries (or both at once using Batch Build). 14013481Sgiacomo.travaglini@arm.com 14113481Sgiacomo.travaglini@arm.comIn order to prevent build output files from overwriting one another, 14213481Sgiacomo.travaglini@arm.comyou'll need to change the `Intermediate Directory` settings for the 14313481Sgiacomo.travaglini@arm.comnewly created platform configuration across all the projects. To do 14413481Sgiacomo.travaglini@arm.comthis, multi-select (e.g. using shift-click) all projects (but not the 14513481Sgiacomo.travaglini@arm.comsolution) in the `Solution Explorer`. Right-click one of them and 14613481Sgiacomo.travaglini@arm.comselect `Properties`. In the left pane, select `Configuration Properties`, 14713481Sgiacomo.travaglini@arm.comand from the `Configuration` dropdown, select `All Configurations`. 14813481Sgiacomo.travaglini@arm.comMake sure the selected platform is `x64`. For the 14913481Sgiacomo.travaglini@arm.com`Intermediate Directory` setting, change the value from 15013481Sgiacomo.travaglini@arm.com`$(PlatformName)\$(ConfigurationName)` to 15113481Sgiacomo.travaglini@arm.com`$(OutDir)\$(ProjectName)`. Click `OK` and then build the 15213481Sgiacomo.travaglini@arm.comsolution. When the build is complete, the 64-bit binaries will be in 15313481Sgiacomo.travaglini@arm.comthe `msvc\x64\Debug` directory. 15413481Sgiacomo.travaglini@arm.com 15513481Sgiacomo.travaglini@arm.com## Can I use Google Test on MinGW? ## 15613481Sgiacomo.travaglini@arm.com 15713481Sgiacomo.travaglini@arm.comWe haven't tested this ourselves, but Per Abrahamsen reported that he 15813481Sgiacomo.travaglini@arm.comwas able to compile and install Google Test successfully when using 15913481Sgiacomo.travaglini@arm.comMinGW from Cygwin. You'll need to configure it with: 16013481Sgiacomo.travaglini@arm.com 16113481Sgiacomo.travaglini@arm.com`PATH/TO/configure CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin"` 16213481Sgiacomo.travaglini@arm.com 16313481Sgiacomo.travaglini@arm.comYou should be able to replace the `-mno-cygwin` option with direct links 16413481Sgiacomo.travaglini@arm.comto the real MinGW binaries, but we haven't tried that. 16513481Sgiacomo.travaglini@arm.com 16613481Sgiacomo.travaglini@arm.comCaveats: 16713481Sgiacomo.travaglini@arm.com 16813481Sgiacomo.travaglini@arm.com * There are many warnings when compiling. 16913481Sgiacomo.travaglini@arm.com * `make check` will produce some errors as not all tests for Google Test itself are compatible with MinGW. 17013481Sgiacomo.travaglini@arm.com 17113481Sgiacomo.travaglini@arm.comWe also have reports on successful cross compilation of Google Test 17213481Sgiacomo.travaglini@arm.comMinGW binaries on Linux using 17313481Sgiacomo.travaglini@arm.com[these instructions](http://wiki.wxwidgets.org/Cross-Compiling_Under_Linux#Cross-compiling_under_Linux_for_MS_Windows) 17413481Sgiacomo.travaglini@arm.comon the WxWidgets site. 17513481Sgiacomo.travaglini@arm.com 17613481Sgiacomo.travaglini@arm.comPlease contact `googletestframework@googlegroups.com` if you are 17713481Sgiacomo.travaglini@arm.cominterested in improving the support for MinGW. 17813481Sgiacomo.travaglini@arm.com 17913481Sgiacomo.travaglini@arm.com## Why does Google Test support EXPECT\_EQ(NULL, ptr) and ASSERT\_EQ(NULL, ptr) but not EXPECT\_NE(NULL, ptr) and ASSERT\_NE(NULL, ptr)? ## 18013481Sgiacomo.travaglini@arm.com 18113481Sgiacomo.travaglini@arm.comDue to some peculiarity of C++, it requires some non-trivial template 18213481Sgiacomo.travaglini@arm.commeta programming tricks to support using `NULL` as an argument of the 18313481Sgiacomo.travaglini@arm.com`EXPECT_XX()` and `ASSERT_XX()` macros. Therefore we only do it where 18413481Sgiacomo.travaglini@arm.comit's most needed (otherwise we make the implementation of Google Test 18513481Sgiacomo.travaglini@arm.comharder to maintain and more error-prone than necessary). 18613481Sgiacomo.travaglini@arm.com 18713481Sgiacomo.travaglini@arm.comThe `EXPECT_EQ()` macro takes the _expected_ value as its first 18813481Sgiacomo.travaglini@arm.comargument and the _actual_ value as the second. It's reasonable that 18913481Sgiacomo.travaglini@arm.comsomeone wants to write `EXPECT_EQ(NULL, some_expression)`, and this 19013481Sgiacomo.travaglini@arm.comindeed was requested several times. Therefore we implemented it. 19113481Sgiacomo.travaglini@arm.com 19213481Sgiacomo.travaglini@arm.comThe need for `EXPECT_NE(NULL, ptr)` isn't nearly as strong. When the 19313481Sgiacomo.travaglini@arm.comassertion fails, you already know that `ptr` must be `NULL`, so it 19413481Sgiacomo.travaglini@arm.comdoesn't add any information to print ptr in this case. That means 19513481Sgiacomo.travaglini@arm.com`EXPECT_TRUE(ptr ! NULL)` works just as well. 19613481Sgiacomo.travaglini@arm.com 19713481Sgiacomo.travaglini@arm.comIf we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'll 19813481Sgiacomo.travaglini@arm.comhave to support `EXPECT_NE(ptr, NULL)` as well, as unlike `EXPECT_EQ`, 19913481Sgiacomo.travaglini@arm.comwe don't have a convention on the order of the two arguments for 20013481Sgiacomo.travaglini@arm.com`EXPECT_NE`. This means using the template meta programming tricks 20113481Sgiacomo.travaglini@arm.comtwice in the implementation, making it even harder to understand and 20213481Sgiacomo.travaglini@arm.commaintain. We believe the benefit doesn't justify the cost. 20313481Sgiacomo.travaglini@arm.com 20413481Sgiacomo.travaglini@arm.comFinally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are 20513481Sgiacomo.travaglini@arm.comencouraging people to use the unified `EXPECT_THAT(value, matcher)` 20613481Sgiacomo.travaglini@arm.comsyntax more often in tests. One significant advantage of the matcher 20713481Sgiacomo.travaglini@arm.comapproach is that matchers can be easily combined to form new matchers, 20813481Sgiacomo.travaglini@arm.comwhile the `EXPECT_NE`, etc, macros cannot be easily 20913481Sgiacomo.travaglini@arm.comcombined. Therefore we want to invest more in the matchers than in the 21013481Sgiacomo.travaglini@arm.com`EXPECT_XX()` macros. 21113481Sgiacomo.travaglini@arm.com 21213481Sgiacomo.travaglini@arm.com## Does Google Test support running tests in parallel? ## 21313481Sgiacomo.travaglini@arm.com 21413481Sgiacomo.travaglini@arm.comTest runners tend to be tightly coupled with the build/test 21513481Sgiacomo.travaglini@arm.comenvironment, and Google Test doesn't try to solve the problem of 21613481Sgiacomo.travaglini@arm.comrunning tests in parallel. Instead, we tried to make Google Test work 21713481Sgiacomo.travaglini@arm.comnicely with test runners. For example, Google Test's XML report 21813481Sgiacomo.travaglini@arm.comcontains the time spent on each test, and its `gtest_list_tests` and 21913481Sgiacomo.travaglini@arm.com`gtest_filter` flags can be used for splitting the execution of test 22013481Sgiacomo.travaglini@arm.commethods into multiple processes. These functionalities can help the 22113481Sgiacomo.travaglini@arm.comtest runner run the tests in parallel. 22213481Sgiacomo.travaglini@arm.com 22313481Sgiacomo.travaglini@arm.com## Why don't Google Test run the tests in different threads to speed things up? ## 22413481Sgiacomo.travaglini@arm.com 22513481Sgiacomo.travaglini@arm.comIt's difficult to write thread-safe code. Most tests are not written 22613481Sgiacomo.travaglini@arm.comwith thread-safety in mind, and thus may not work correctly in a 22713481Sgiacomo.travaglini@arm.commulti-threaded setting. 22813481Sgiacomo.travaglini@arm.com 22913481Sgiacomo.travaglini@arm.comIf you think about it, it's already hard to make your code work when 23013481Sgiacomo.travaglini@arm.comyou know what other threads are doing. It's much harder, and 23113481Sgiacomo.travaglini@arm.comsometimes even impossible, to make your code work when you don't know 23213481Sgiacomo.travaglini@arm.comwhat other threads are doing (remember that test methods can be added, 23313481Sgiacomo.travaglini@arm.comdeleted, or modified after your test was written). If you want to run 23413481Sgiacomo.travaglini@arm.comthe tests in parallel, you'd better run them in different processes. 23513481Sgiacomo.travaglini@arm.com 23613481Sgiacomo.travaglini@arm.com## Why aren't Google Test assertions implemented using exceptions? ## 23713481Sgiacomo.travaglini@arm.com 23813481Sgiacomo.travaglini@arm.comOur original motivation was to be able to use Google Test in projects 23913481Sgiacomo.travaglini@arm.comthat disable exceptions. Later we realized some additional benefits 24013481Sgiacomo.travaglini@arm.comof this approach: 24113481Sgiacomo.travaglini@arm.com 24213481Sgiacomo.travaglini@arm.com 1. Throwing in a destructor is undefined behavior in C++. Not using exceptions means Google Test's assertions are safe to use in destructors. 24313481Sgiacomo.travaglini@arm.com 1. The `EXPECT_*` family of macros will continue even after a failure, allowing multiple failures in a `TEST` to be reported in a single run. This is a popular feature, as in C++ the edit-compile-test cycle is usually quite long and being able to fixing more than one thing at a time is a blessing. 24413481Sgiacomo.travaglini@arm.com 1. If assertions are implemented using exceptions, a test may falsely ignore a failure if it's caught by user code: 24513481Sgiacomo.travaglini@arm.com``` 24613481Sgiacomo.travaglini@arm.comtry { ... ASSERT_TRUE(...) ... } 24713481Sgiacomo.travaglini@arm.comcatch (...) { ... } 24813481Sgiacomo.travaglini@arm.com``` 24913481Sgiacomo.travaglini@arm.comThe above code will pass even if the `ASSERT_TRUE` throws. While it's unlikely for someone to write this in a test, it's possible to run into this pattern when you write assertions in callbacks that are called by the code under test. 25013481Sgiacomo.travaglini@arm.com 25113481Sgiacomo.travaglini@arm.comThe downside of not using exceptions is that `ASSERT_*` (implemented 25213481Sgiacomo.travaglini@arm.comusing `return`) will only abort the current function, not the current 25313481Sgiacomo.travaglini@arm.com`TEST`. 25413481Sgiacomo.travaglini@arm.com 25513481Sgiacomo.travaglini@arm.com## Why do we use two different macros for tests with and without fixtures? ## 25613481Sgiacomo.travaglini@arm.com 25713481Sgiacomo.travaglini@arm.comUnfortunately, C++'s macro system doesn't allow us to use the same 25813481Sgiacomo.travaglini@arm.commacro for both cases. One possibility is to provide only one macro 25913481Sgiacomo.travaglini@arm.comfor tests with fixtures, and require the user to define an empty 26013481Sgiacomo.travaglini@arm.comfixture sometimes: 26113481Sgiacomo.travaglini@arm.com 26213481Sgiacomo.travaglini@arm.com``` 26313481Sgiacomo.travaglini@arm.comclass FooTest : public ::testing::Test {}; 26413481Sgiacomo.travaglini@arm.com 26513481Sgiacomo.travaglini@arm.comTEST_F(FooTest, DoesThis) { ... } 26613481Sgiacomo.travaglini@arm.com``` 26713481Sgiacomo.travaglini@arm.comor 26813481Sgiacomo.travaglini@arm.com``` 26913481Sgiacomo.travaglini@arm.comtypedef ::testing::Test FooTest; 27013481Sgiacomo.travaglini@arm.com 27113481Sgiacomo.travaglini@arm.comTEST_F(FooTest, DoesThat) { ... } 27213481Sgiacomo.travaglini@arm.com``` 27313481Sgiacomo.travaglini@arm.com 27413481Sgiacomo.travaglini@arm.comYet, many people think this is one line too many. :-) Our goal was to 27513481Sgiacomo.travaglini@arm.commake it really easy to write tests, so we tried to make simple tests 27613481Sgiacomo.travaglini@arm.comtrivial to create. That means using a separate macro for such tests. 27713481Sgiacomo.travaglini@arm.com 27813481Sgiacomo.travaglini@arm.comWe think neither approach is ideal, yet either of them is reasonable. 27913481Sgiacomo.travaglini@arm.comIn the end, it probably doesn't matter much either way. 28013481Sgiacomo.travaglini@arm.com 28113481Sgiacomo.travaglini@arm.com## Why don't we use structs as test fixtures? ## 28213481Sgiacomo.travaglini@arm.com 28313481Sgiacomo.travaglini@arm.comWe like to use structs only when representing passive data. This 28413481Sgiacomo.travaglini@arm.comdistinction between structs and classes is good for documenting the 28513481Sgiacomo.travaglini@arm.comintent of the code's author. Since test fixtures have logic like 28613481Sgiacomo.travaglini@arm.com`SetUp()` and `TearDown()`, they are better defined as classes. 28713481Sgiacomo.travaglini@arm.com 28813481Sgiacomo.travaglini@arm.com## Why are death tests implemented as assertions instead of using a test runner? ## 28913481Sgiacomo.travaglini@arm.com 29013481Sgiacomo.travaglini@arm.comOur goal was to make death tests as convenient for a user as C++ 29113481Sgiacomo.travaglini@arm.compossibly allows. In particular: 29213481Sgiacomo.travaglini@arm.com 29313481Sgiacomo.travaglini@arm.com * The runner-style requires to split the information into two pieces: the definition of the death test itself, and the specification for the runner on how to run the death test and what to expect. The death test would be written in C++, while the runner spec may or may not be. A user needs to carefully keep the two in sync. `ASSERT_DEATH(statement, expected_message)` specifies all necessary information in one place, in one language, without boilerplate code. It is very declarative. 29413481Sgiacomo.travaglini@arm.com * `ASSERT_DEATH` has a similar syntax and error-reporting semantics as other Google Test assertions, and thus is easy to learn. 29513481Sgiacomo.travaglini@arm.com * `ASSERT_DEATH` can be mixed with other assertions and other logic at your will. You are not limited to one death test per test method. For example, you can write something like: 29613481Sgiacomo.travaglini@arm.com``` 29713481Sgiacomo.travaglini@arm.com if (FooCondition()) { 29813481Sgiacomo.travaglini@arm.com ASSERT_DEATH(Bar(), "blah"); 29913481Sgiacomo.travaglini@arm.com } else { 30013481Sgiacomo.travaglini@arm.com ASSERT_EQ(5, Bar()); 30113481Sgiacomo.travaglini@arm.com } 30213481Sgiacomo.travaglini@arm.com``` 30313481Sgiacomo.travaglini@arm.comIf you prefer one death test per test method, you can write your tests in that style too, but we don't want to impose that on the users. The fewer artificial limitations the better. 30413481Sgiacomo.travaglini@arm.com * `ASSERT_DEATH` can reference local variables in the current function, and you can decide how many death tests you want based on run-time information. For example, 30513481Sgiacomo.travaglini@arm.com``` 30613481Sgiacomo.travaglini@arm.com const int count = GetCount(); // Only known at run time. 30713481Sgiacomo.travaglini@arm.com for (int i = 1; i <= count; i++) { 30813481Sgiacomo.travaglini@arm.com ASSERT_DEATH({ 30913481Sgiacomo.travaglini@arm.com double* buffer = new double[i]; 31013481Sgiacomo.travaglini@arm.com ... initializes buffer ... 31113481Sgiacomo.travaglini@arm.com Foo(buffer, i) 31213481Sgiacomo.travaglini@arm.com }, "blah blah"); 31313481Sgiacomo.travaglini@arm.com } 31413481Sgiacomo.travaglini@arm.com``` 31513481Sgiacomo.travaglini@arm.comThe runner-based approach tends to be more static and less flexible, or requires more user effort to get this kind of flexibility. 31613481Sgiacomo.travaglini@arm.com 31713481Sgiacomo.travaglini@arm.comAnother interesting thing about `ASSERT_DEATH` is that it calls `fork()` 31813481Sgiacomo.travaglini@arm.comto create a child process to run the death test. This is lightening 31913481Sgiacomo.travaglini@arm.comfast, as `fork()` uses copy-on-write pages and incurs almost zero 32013481Sgiacomo.travaglini@arm.comoverhead, and the child process starts from the user-supplied 32113481Sgiacomo.travaglini@arm.comstatement directly, skipping all global and local initialization and 32213481Sgiacomo.travaglini@arm.comany code leading to the given statement. If you launch the child 32313481Sgiacomo.travaglini@arm.comprocess from scratch, it can take seconds just to load everything and 32413481Sgiacomo.travaglini@arm.comstart running if the test links to many libraries dynamically. 32513481Sgiacomo.travaglini@arm.com 32613481Sgiacomo.travaglini@arm.com## My death test modifies some state, but the change seems lost after the death test finishes. Why? ## 32713481Sgiacomo.travaglini@arm.com 32813481Sgiacomo.travaglini@arm.comDeath tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the 32913481Sgiacomo.travaglini@arm.comexpected crash won't kill the test program (i.e. the parent process). As a 33013481Sgiacomo.travaglini@arm.comresult, any in-memory side effects they incur are observable in their 33113481Sgiacomo.travaglini@arm.comrespective sub-processes, but not in the parent process. You can think of them 33213481Sgiacomo.travaglini@arm.comas running in a parallel universe, more or less. 33313481Sgiacomo.travaglini@arm.com 33413481Sgiacomo.travaglini@arm.com## The compiler complains about "undefined references" to some static const member variables, but I did define them in the class body. What's wrong? ## 33513481Sgiacomo.travaglini@arm.com 33613481Sgiacomo.travaglini@arm.comIf your class has a static data member: 33713481Sgiacomo.travaglini@arm.com 33813481Sgiacomo.travaglini@arm.com``` 33913481Sgiacomo.travaglini@arm.com// foo.h 34013481Sgiacomo.travaglini@arm.comclass Foo { 34113481Sgiacomo.travaglini@arm.com ... 34213481Sgiacomo.travaglini@arm.com static const int kBar = 100; 34313481Sgiacomo.travaglini@arm.com}; 34413481Sgiacomo.travaglini@arm.com``` 34513481Sgiacomo.travaglini@arm.com 34613481Sgiacomo.travaglini@arm.comYou also need to define it _outside_ of the class body in `foo.cc`: 34713481Sgiacomo.travaglini@arm.com 34813481Sgiacomo.travaglini@arm.com``` 34913481Sgiacomo.travaglini@arm.comconst int Foo::kBar; // No initializer here. 35013481Sgiacomo.travaglini@arm.com``` 35113481Sgiacomo.travaglini@arm.com 35213481Sgiacomo.travaglini@arm.comOtherwise your code is **invalid C++**, and may break in unexpected ways. In 35313481Sgiacomo.travaglini@arm.comparticular, using it in Google Test comparison assertions (`EXPECT_EQ`, etc) 35413481Sgiacomo.travaglini@arm.comwill generate an "undefined reference" linker error. 35513481Sgiacomo.travaglini@arm.com 35613481Sgiacomo.travaglini@arm.com## I have an interface that has several implementations. Can I write a set of tests once and repeat them over all the implementations? ## 35713481Sgiacomo.travaglini@arm.com 35813481Sgiacomo.travaglini@arm.comGoogle Test doesn't yet have good support for this kind of tests, or 35913481Sgiacomo.travaglini@arm.comdata-driven tests in general. We hope to be able to make improvements in this 36013481Sgiacomo.travaglini@arm.comarea soon. 36113481Sgiacomo.travaglini@arm.com 36213481Sgiacomo.travaglini@arm.com## Can I derive a test fixture from another? ## 36313481Sgiacomo.travaglini@arm.com 36413481Sgiacomo.travaglini@arm.comYes. 36513481Sgiacomo.travaglini@arm.com 36613481Sgiacomo.travaglini@arm.comEach test fixture has a corresponding and same named test case. This means only 36713481Sgiacomo.travaglini@arm.comone test case can use a particular fixture. Sometimes, however, multiple test 36813481Sgiacomo.travaglini@arm.comcases may want to use the same or slightly different fixtures. For example, you 36913481Sgiacomo.travaglini@arm.commay want to make sure that all of a GUI library's test cases don't leak 37013481Sgiacomo.travaglini@arm.comimportant system resources like fonts and brushes. 37113481Sgiacomo.travaglini@arm.com 37213481Sgiacomo.travaglini@arm.comIn Google Test, you share a fixture among test cases by putting the shared 37313481Sgiacomo.travaglini@arm.comlogic in a base test fixture, then deriving from that base a separate fixture 37413481Sgiacomo.travaglini@arm.comfor each test case that wants to use this common logic. You then use `TEST_F()` 37513481Sgiacomo.travaglini@arm.comto write tests using each derived fixture. 37613481Sgiacomo.travaglini@arm.com 37713481Sgiacomo.travaglini@arm.comTypically, your code looks like this: 37813481Sgiacomo.travaglini@arm.com 37913481Sgiacomo.travaglini@arm.com``` 38013481Sgiacomo.travaglini@arm.com// Defines a base test fixture. 38113481Sgiacomo.travaglini@arm.comclass BaseTest : public ::testing::Test { 38213481Sgiacomo.travaglini@arm.com protected: 38313481Sgiacomo.travaglini@arm.com ... 38413481Sgiacomo.travaglini@arm.com}; 38513481Sgiacomo.travaglini@arm.com 38613481Sgiacomo.travaglini@arm.com// Derives a fixture FooTest from BaseTest. 38713481Sgiacomo.travaglini@arm.comclass FooTest : public BaseTest { 38813481Sgiacomo.travaglini@arm.com protected: 38913481Sgiacomo.travaglini@arm.com virtual void SetUp() { 39013481Sgiacomo.travaglini@arm.com BaseTest::SetUp(); // Sets up the base fixture first. 39113481Sgiacomo.travaglini@arm.com ... additional set-up work ... 39213481Sgiacomo.travaglini@arm.com } 39313481Sgiacomo.travaglini@arm.com virtual void TearDown() { 39413481Sgiacomo.travaglini@arm.com ... clean-up work for FooTest ... 39513481Sgiacomo.travaglini@arm.com BaseTest::TearDown(); // Remember to tear down the base fixture 39613481Sgiacomo.travaglini@arm.com // after cleaning up FooTest! 39713481Sgiacomo.travaglini@arm.com } 39813481Sgiacomo.travaglini@arm.com ... functions and variables for FooTest ... 39913481Sgiacomo.travaglini@arm.com}; 40013481Sgiacomo.travaglini@arm.com 40113481Sgiacomo.travaglini@arm.com// Tests that use the fixture FooTest. 40213481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Bar) { ... } 40313481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Baz) { ... } 40413481Sgiacomo.travaglini@arm.com 40513481Sgiacomo.travaglini@arm.com... additional fixtures derived from BaseTest ... 40613481Sgiacomo.travaglini@arm.com``` 40713481Sgiacomo.travaglini@arm.com 40813481Sgiacomo.travaglini@arm.comIf necessary, you can continue to derive test fixtures from a derived fixture. 40913481Sgiacomo.travaglini@arm.comGoogle Test has no limit on how deep the hierarchy can be. 41013481Sgiacomo.travaglini@arm.com 41113481Sgiacomo.travaglini@arm.comFor a complete example using derived test fixtures, see 41213481Sgiacomo.travaglini@arm.com[sample5](../samples/sample5_unittest.cc). 41313481Sgiacomo.travaglini@arm.com 41413481Sgiacomo.travaglini@arm.com## My compiler complains "void value not ignored as it ought to be." What does this mean? ## 41513481Sgiacomo.travaglini@arm.com 41613481Sgiacomo.travaglini@arm.comYou're probably using an `ASSERT_*()` in a function that doesn't return `void`. 41713481Sgiacomo.travaglini@arm.com`ASSERT_*()` can only be used in `void` functions. 41813481Sgiacomo.travaglini@arm.com 41913481Sgiacomo.travaglini@arm.com## My death test hangs (or seg-faults). How do I fix it? ## 42013481Sgiacomo.travaglini@arm.com 42113481Sgiacomo.travaglini@arm.comIn Google Test, death tests are run in a child process and the way they work is 42213481Sgiacomo.travaglini@arm.comdelicate. To write death tests you really need to understand how they work. 42313481Sgiacomo.travaglini@arm.comPlease make sure you have read this. 42413481Sgiacomo.travaglini@arm.com 42513481Sgiacomo.travaglini@arm.comIn particular, death tests don't like having multiple threads in the parent 42613481Sgiacomo.travaglini@arm.comprocess. So the first thing you can try is to eliminate creating threads 42713481Sgiacomo.travaglini@arm.comoutside of `EXPECT_DEATH()`. 42813481Sgiacomo.travaglini@arm.com 42913481Sgiacomo.travaglini@arm.comSometimes this is impossible as some library you must use may be creating 43013481Sgiacomo.travaglini@arm.comthreads before `main()` is even reached. In this case, you can try to minimize 43113481Sgiacomo.travaglini@arm.comthe chance of conflicts by either moving as many activities as possible inside 43213481Sgiacomo.travaglini@arm.com`EXPECT_DEATH()` (in the extreme case, you want to move everything inside), or 43313481Sgiacomo.travaglini@arm.comleaving as few things as possible in it. Also, you can try to set the death 43413481Sgiacomo.travaglini@arm.comtest style to `"threadsafe"`, which is safer but slower, and see if it helps. 43513481Sgiacomo.travaglini@arm.com 43613481Sgiacomo.travaglini@arm.comIf you go with thread-safe death tests, remember that they rerun the test 43713481Sgiacomo.travaglini@arm.comprogram from the beginning in the child process. Therefore make sure your 43813481Sgiacomo.travaglini@arm.comprogram can run side-by-side with itself and is deterministic. 43913481Sgiacomo.travaglini@arm.com 44013481Sgiacomo.travaglini@arm.comIn the end, this boils down to good concurrent programming. You have to make 44113481Sgiacomo.travaglini@arm.comsure that there is no race conditions or dead locks in your program. No silver 44213481Sgiacomo.travaglini@arm.combullet - sorry! 44313481Sgiacomo.travaglini@arm.com 44413481Sgiacomo.travaglini@arm.com## Should I use the constructor/destructor of the test fixture or the set-up/tear-down function? ## 44513481Sgiacomo.travaglini@arm.com 44613481Sgiacomo.travaglini@arm.comThe first thing to remember is that Google Test does not reuse the 44713481Sgiacomo.travaglini@arm.comsame test fixture object across multiple tests. For each `TEST_F`, 44813481Sgiacomo.travaglini@arm.comGoogle Test will create a fresh test fixture object, _immediately_ 44913481Sgiacomo.travaglini@arm.comcall `SetUp()`, run the test, call `TearDown()`, and then 45013481Sgiacomo.travaglini@arm.com_immediately_ delete the test fixture object. Therefore, there is no 45113481Sgiacomo.travaglini@arm.comneed to write a `SetUp()` or `TearDown()` function if the constructor 45213481Sgiacomo.travaglini@arm.comor destructor already does the job. 45313481Sgiacomo.travaglini@arm.com 45413481Sgiacomo.travaglini@arm.comYou may still want to use `SetUp()/TearDown()` in the following cases: 45513481Sgiacomo.travaglini@arm.com * If the tear-down operation could throw an exception, you must use `TearDown()` as opposed to the destructor, as throwing in a destructor leads to undefined behavior and usually will kill your program right away. Note that many standard libraries (like STL) may throw when exceptions are enabled in the compiler. Therefore you should prefer `TearDown()` if you want to write portable tests that work with or without exceptions. 45613481Sgiacomo.travaglini@arm.com * The Google Test team is considering making the assertion macros throw on platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux client-side), which will eliminate the need for the user to propagate failures from a subroutine to its caller. Therefore, you shouldn't use Google Test assertions in a destructor if your code could run on such a platform. 45713481Sgiacomo.travaglini@arm.com * In a constructor or destructor, you cannot make a virtual function call on this object. (You can call a method declared as virtual, but it will be statically bound.) Therefore, if you need to call a method that will be overriden in a derived class, you have to use `SetUp()/TearDown()`. 45813481Sgiacomo.travaglini@arm.com 45913481Sgiacomo.travaglini@arm.com## The compiler complains "no matching function to call" when I use ASSERT\_PREDn. How do I fix it? ## 46013481Sgiacomo.travaglini@arm.com 46113481Sgiacomo.travaglini@arm.comIf the predicate function you use in `ASSERT_PRED*` or `EXPECT_PRED*` is 46213481Sgiacomo.travaglini@arm.comoverloaded or a template, the compiler will have trouble figuring out which 46313481Sgiacomo.travaglini@arm.comoverloaded version it should use. `ASSERT_PRED_FORMAT*` and 46413481Sgiacomo.travaglini@arm.com`EXPECT_PRED_FORMAT*` don't have this problem. 46513481Sgiacomo.travaglini@arm.com 46613481Sgiacomo.travaglini@arm.comIf you see this error, you might want to switch to 46713481Sgiacomo.travaglini@arm.com`(ASSERT|EXPECT)_PRED_FORMAT*`, which will also give you a better failure 46813481Sgiacomo.travaglini@arm.commessage. If, however, that is not an option, you can resolve the problem by 46913481Sgiacomo.travaglini@arm.comexplicitly telling the compiler which version to pick. 47013481Sgiacomo.travaglini@arm.com 47113481Sgiacomo.travaglini@arm.comFor example, suppose you have 47213481Sgiacomo.travaglini@arm.com 47313481Sgiacomo.travaglini@arm.com``` 47413481Sgiacomo.travaglini@arm.combool IsPositive(int n) { 47513481Sgiacomo.travaglini@arm.com return n > 0; 47613481Sgiacomo.travaglini@arm.com} 47713481Sgiacomo.travaglini@arm.combool IsPositive(double x) { 47813481Sgiacomo.travaglini@arm.com return x > 0; 47913481Sgiacomo.travaglini@arm.com} 48013481Sgiacomo.travaglini@arm.com``` 48113481Sgiacomo.travaglini@arm.com 48213481Sgiacomo.travaglini@arm.comyou will get a compiler error if you write 48313481Sgiacomo.travaglini@arm.com 48413481Sgiacomo.travaglini@arm.com``` 48513481Sgiacomo.travaglini@arm.comEXPECT_PRED1(IsPositive, 5); 48613481Sgiacomo.travaglini@arm.com``` 48713481Sgiacomo.travaglini@arm.com 48813481Sgiacomo.travaglini@arm.comHowever, this will work: 48913481Sgiacomo.travaglini@arm.com 49013481Sgiacomo.travaglini@arm.com``` 49113481Sgiacomo.travaglini@arm.comEXPECT_PRED1(*static_cast<bool (*)(int)>*(IsPositive), 5); 49213481Sgiacomo.travaglini@arm.com``` 49313481Sgiacomo.travaglini@arm.com 49413481Sgiacomo.travaglini@arm.com(The stuff inside the angled brackets for the `static_cast` operator is the 49513481Sgiacomo.travaglini@arm.comtype of the function pointer for the `int`-version of `IsPositive()`.) 49613481Sgiacomo.travaglini@arm.com 49713481Sgiacomo.travaglini@arm.comAs another example, when you have a template function 49813481Sgiacomo.travaglini@arm.com 49913481Sgiacomo.travaglini@arm.com``` 50013481Sgiacomo.travaglini@arm.comtemplate <typename T> 50113481Sgiacomo.travaglini@arm.combool IsNegative(T x) { 50213481Sgiacomo.travaglini@arm.com return x < 0; 50313481Sgiacomo.travaglini@arm.com} 50413481Sgiacomo.travaglini@arm.com``` 50513481Sgiacomo.travaglini@arm.com 50613481Sgiacomo.travaglini@arm.comyou can use it in a predicate assertion like this: 50713481Sgiacomo.travaglini@arm.com 50813481Sgiacomo.travaglini@arm.com``` 50913481Sgiacomo.travaglini@arm.comASSERT_PRED1(IsNegative*<int>*, -5); 51013481Sgiacomo.travaglini@arm.com``` 51113481Sgiacomo.travaglini@arm.com 51213481Sgiacomo.travaglini@arm.comThings are more interesting if your template has more than one parameters. The 51313481Sgiacomo.travaglini@arm.comfollowing won't compile: 51413481Sgiacomo.travaglini@arm.com 51513481Sgiacomo.travaglini@arm.com``` 51613481Sgiacomo.travaglini@arm.comASSERT_PRED2(*GreaterThan<int, int>*, 5, 0); 51713481Sgiacomo.travaglini@arm.com``` 51813481Sgiacomo.travaglini@arm.com 51913481Sgiacomo.travaglini@arm.com 52013481Sgiacomo.travaglini@arm.comas the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments, 52113481Sgiacomo.travaglini@arm.comwhich is one more than expected. The workaround is to wrap the predicate 52213481Sgiacomo.travaglini@arm.comfunction in parentheses: 52313481Sgiacomo.travaglini@arm.com 52413481Sgiacomo.travaglini@arm.com``` 52513481Sgiacomo.travaglini@arm.comASSERT_PRED2(*(GreaterThan<int, int>)*, 5, 0); 52613481Sgiacomo.travaglini@arm.com``` 52713481Sgiacomo.travaglini@arm.com 52813481Sgiacomo.travaglini@arm.com 52913481Sgiacomo.travaglini@arm.com## My compiler complains about "ignoring return value" when I call RUN\_ALL\_TESTS(). Why? ## 53013481Sgiacomo.travaglini@arm.com 53113481Sgiacomo.travaglini@arm.comSome people had been ignoring the return value of `RUN_ALL_TESTS()`. That is, 53213481Sgiacomo.travaglini@arm.cominstead of 53313481Sgiacomo.travaglini@arm.com 53413481Sgiacomo.travaglini@arm.com``` 53513481Sgiacomo.travaglini@arm.comreturn RUN_ALL_TESTS(); 53613481Sgiacomo.travaglini@arm.com``` 53713481Sgiacomo.travaglini@arm.com 53813481Sgiacomo.travaglini@arm.comthey write 53913481Sgiacomo.travaglini@arm.com 54013481Sgiacomo.travaglini@arm.com``` 54113481Sgiacomo.travaglini@arm.comRUN_ALL_TESTS(); 54213481Sgiacomo.travaglini@arm.com``` 54313481Sgiacomo.travaglini@arm.com 54413481Sgiacomo.travaglini@arm.comThis is wrong and dangerous. A test runner needs to see the return value of 54513481Sgiacomo.travaglini@arm.com`RUN_ALL_TESTS()` in order to determine if a test has passed. If your `main()` 54613481Sgiacomo.travaglini@arm.comfunction ignores it, your test will be considered successful even if it has a 54713481Sgiacomo.travaglini@arm.comGoogle Test assertion failure. Very bad. 54813481Sgiacomo.travaglini@arm.com 54913481Sgiacomo.travaglini@arm.comTo help the users avoid this dangerous bug, the implementation of 55013481Sgiacomo.travaglini@arm.com`RUN_ALL_TESTS()` causes gcc to raise this warning, when the return value is 55113481Sgiacomo.travaglini@arm.comignored. If you see this warning, the fix is simple: just make sure its value 55213481Sgiacomo.travaglini@arm.comis used as the return value of `main()`. 55313481Sgiacomo.travaglini@arm.com 55413481Sgiacomo.travaglini@arm.com## My compiler complains that a constructor (or destructor) cannot return a value. What's going on? ## 55513481Sgiacomo.travaglini@arm.com 55613481Sgiacomo.travaglini@arm.comDue to a peculiarity of C++, in order to support the syntax for streaming 55713481Sgiacomo.travaglini@arm.commessages to an `ASSERT_*`, e.g. 55813481Sgiacomo.travaglini@arm.com 55913481Sgiacomo.travaglini@arm.com``` 56013481Sgiacomo.travaglini@arm.comASSERT_EQ(1, Foo()) << "blah blah" << foo; 56113481Sgiacomo.travaglini@arm.com``` 56213481Sgiacomo.travaglini@arm.com 56313481Sgiacomo.travaglini@arm.comwe had to give up using `ASSERT*` and `FAIL*` (but not `EXPECT*` and 56413481Sgiacomo.travaglini@arm.com`ADD_FAILURE*`) in constructors and destructors. The workaround is to move the 56513481Sgiacomo.travaglini@arm.comcontent of your constructor/destructor to a private void member function, or 56613481Sgiacomo.travaglini@arm.comswitch to `EXPECT_*()` if that works. This section in the user's guide explains 56713481Sgiacomo.travaglini@arm.comit. 56813481Sgiacomo.travaglini@arm.com 56913481Sgiacomo.travaglini@arm.com## My set-up function is not called. Why? ## 57013481Sgiacomo.travaglini@arm.com 57113481Sgiacomo.travaglini@arm.comC++ is case-sensitive. It should be spelled as `SetUp()`. Did you 57213481Sgiacomo.travaglini@arm.comspell it as `Setup()`? 57313481Sgiacomo.travaglini@arm.com 57413481Sgiacomo.travaglini@arm.comSimilarly, sometimes people spell `SetUpTestCase()` as `SetupTestCase()` and 57513481Sgiacomo.travaglini@arm.comwonder why it's never called. 57613481Sgiacomo.travaglini@arm.com 57713481Sgiacomo.travaglini@arm.com## How do I jump to the line of a failure in Emacs directly? ## 57813481Sgiacomo.travaglini@arm.com 57913481Sgiacomo.travaglini@arm.comGoogle Test's failure message format is understood by Emacs and many other 58013481Sgiacomo.travaglini@arm.comIDEs, like acme and XCode. If a Google Test message is in a compilation buffer 58113481Sgiacomo.travaglini@arm.comin Emacs, then it's clickable. You can now hit `enter` on a message to jump to 58213481Sgiacomo.travaglini@arm.comthe corresponding source code, or use `C-x `` to jump to the next failure. 58313481Sgiacomo.travaglini@arm.com 58413481Sgiacomo.travaglini@arm.com## I have several test cases which share the same test fixture logic, do I have to define a new test fixture class for each of them? This seems pretty tedious. ## 58513481Sgiacomo.travaglini@arm.com 58613481Sgiacomo.travaglini@arm.comYou don't have to. Instead of 58713481Sgiacomo.travaglini@arm.com 58813481Sgiacomo.travaglini@arm.com``` 58913481Sgiacomo.travaglini@arm.comclass FooTest : public BaseTest {}; 59013481Sgiacomo.travaglini@arm.com 59113481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Abc) { ... } 59213481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Def) { ... } 59313481Sgiacomo.travaglini@arm.com 59413481Sgiacomo.travaglini@arm.comclass BarTest : public BaseTest {}; 59513481Sgiacomo.travaglini@arm.com 59613481Sgiacomo.travaglini@arm.comTEST_F(BarTest, Abc) { ... } 59713481Sgiacomo.travaglini@arm.comTEST_F(BarTest, Def) { ... } 59813481Sgiacomo.travaglini@arm.com``` 59913481Sgiacomo.travaglini@arm.com 60013481Sgiacomo.travaglini@arm.comyou can simply `typedef` the test fixtures: 60113481Sgiacomo.travaglini@arm.com``` 60213481Sgiacomo.travaglini@arm.comtypedef BaseTest FooTest; 60313481Sgiacomo.travaglini@arm.com 60413481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Abc) { ... } 60513481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Def) { ... } 60613481Sgiacomo.travaglini@arm.com 60713481Sgiacomo.travaglini@arm.comtypedef BaseTest BarTest; 60813481Sgiacomo.travaglini@arm.com 60913481Sgiacomo.travaglini@arm.comTEST_F(BarTest, Abc) { ... } 61013481Sgiacomo.travaglini@arm.comTEST_F(BarTest, Def) { ... } 61113481Sgiacomo.travaglini@arm.com``` 61213481Sgiacomo.travaglini@arm.com 61313481Sgiacomo.travaglini@arm.com## The Google Test output is buried in a whole bunch of log messages. What do I do? ## 61413481Sgiacomo.travaglini@arm.com 61513481Sgiacomo.travaglini@arm.comThe Google Test output is meant to be a concise and human-friendly report. If 61613481Sgiacomo.travaglini@arm.comyour test generates textual output itself, it will mix with the Google Test 61713481Sgiacomo.travaglini@arm.comoutput, making it hard to read. However, there is an easy solution to this 61813481Sgiacomo.travaglini@arm.comproblem. 61913481Sgiacomo.travaglini@arm.com 62013481Sgiacomo.travaglini@arm.comSince most log messages go to stderr, we decided to let Google Test output go 62113481Sgiacomo.travaglini@arm.comto stdout. This way, you can easily separate the two using redirection. For 62213481Sgiacomo.travaglini@arm.comexample: 62313481Sgiacomo.travaglini@arm.com``` 62413481Sgiacomo.travaglini@arm.com./my_test > googletest_output.txt 62513481Sgiacomo.travaglini@arm.com``` 62613481Sgiacomo.travaglini@arm.com 62713481Sgiacomo.travaglini@arm.com## Why should I prefer test fixtures over global variables? ## 62813481Sgiacomo.travaglini@arm.com 62913481Sgiacomo.travaglini@arm.comThere are several good reasons: 63013481Sgiacomo.travaglini@arm.com 1. It's likely your test needs to change the states of its global variables. This makes it difficult to keep side effects from escaping one test and contaminating others, making debugging difficult. By using fixtures, each test has a fresh set of variables that's different (but with the same names). Thus, tests are kept independent of each other. 63113481Sgiacomo.travaglini@arm.com 1. Global variables pollute the global namespace. 63213481Sgiacomo.travaglini@arm.com 1. Test fixtures can be reused via subclassing, which cannot be done easily with global variables. This is useful if many test cases have something in common. 63313481Sgiacomo.travaglini@arm.com 63413481Sgiacomo.travaglini@arm.com## How do I test private class members without writing FRIEND\_TEST()s? ## 63513481Sgiacomo.travaglini@arm.com 63613481Sgiacomo.travaglini@arm.comYou should try to write testable code, which means classes should be easily 63713481Sgiacomo.travaglini@arm.comtested from their public interface. One way to achieve this is the Pimpl idiom: 63813481Sgiacomo.travaglini@arm.comyou move all private members of a class into a helper class, and make all 63913481Sgiacomo.travaglini@arm.commembers of the helper class public. 64013481Sgiacomo.travaglini@arm.com 64113481Sgiacomo.travaglini@arm.comYou have several other options that don't require using `FRIEND_TEST`: 64213481Sgiacomo.travaglini@arm.com * Write the tests as members of the fixture class: 64313481Sgiacomo.travaglini@arm.com``` 64413481Sgiacomo.travaglini@arm.comclass Foo { 64513481Sgiacomo.travaglini@arm.com friend class FooTest; 64613481Sgiacomo.travaglini@arm.com ... 64713481Sgiacomo.travaglini@arm.com}; 64813481Sgiacomo.travaglini@arm.com 64913481Sgiacomo.travaglini@arm.comclass FooTest : public ::testing::Test { 65013481Sgiacomo.travaglini@arm.com protected: 65113481Sgiacomo.travaglini@arm.com ... 65213481Sgiacomo.travaglini@arm.com void Test1() {...} // This accesses private members of class Foo. 65313481Sgiacomo.travaglini@arm.com void Test2() {...} // So does this one. 65413481Sgiacomo.travaglini@arm.com}; 65513481Sgiacomo.travaglini@arm.com 65613481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Test1) { 65713481Sgiacomo.travaglini@arm.com Test1(); 65813481Sgiacomo.travaglini@arm.com} 65913481Sgiacomo.travaglini@arm.com 66013481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Test2) { 66113481Sgiacomo.travaglini@arm.com Test2(); 66213481Sgiacomo.travaglini@arm.com} 66313481Sgiacomo.travaglini@arm.com``` 66413481Sgiacomo.travaglini@arm.com * In the fixture class, write accessors for the tested class' private members, then use the accessors in your tests: 66513481Sgiacomo.travaglini@arm.com``` 66613481Sgiacomo.travaglini@arm.comclass Foo { 66713481Sgiacomo.travaglini@arm.com friend class FooTest; 66813481Sgiacomo.travaglini@arm.com ... 66913481Sgiacomo.travaglini@arm.com}; 67013481Sgiacomo.travaglini@arm.com 67113481Sgiacomo.travaglini@arm.comclass FooTest : public ::testing::Test { 67213481Sgiacomo.travaglini@arm.com protected: 67313481Sgiacomo.travaglini@arm.com ... 67413481Sgiacomo.travaglini@arm.com T1 get_private_member1(Foo* obj) { 67513481Sgiacomo.travaglini@arm.com return obj->private_member1_; 67613481Sgiacomo.travaglini@arm.com } 67713481Sgiacomo.travaglini@arm.com}; 67813481Sgiacomo.travaglini@arm.com 67913481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Test1) { 68013481Sgiacomo.travaglini@arm.com ... 68113481Sgiacomo.travaglini@arm.com get_private_member1(x) 68213481Sgiacomo.travaglini@arm.com ... 68313481Sgiacomo.travaglini@arm.com} 68413481Sgiacomo.travaglini@arm.com``` 68513481Sgiacomo.travaglini@arm.com * If the methods are declared **protected**, you can change their access level in a test-only subclass: 68613481Sgiacomo.travaglini@arm.com``` 68713481Sgiacomo.travaglini@arm.comclass YourClass { 68813481Sgiacomo.travaglini@arm.com ... 68913481Sgiacomo.travaglini@arm.com protected: // protected access for testability. 69013481Sgiacomo.travaglini@arm.com int DoSomethingReturningInt(); 69113481Sgiacomo.travaglini@arm.com ... 69213481Sgiacomo.travaglini@arm.com}; 69313481Sgiacomo.travaglini@arm.com 69413481Sgiacomo.travaglini@arm.com// in the your_class_test.cc file: 69513481Sgiacomo.travaglini@arm.comclass TestableYourClass : public YourClass { 69613481Sgiacomo.travaglini@arm.com ... 69713481Sgiacomo.travaglini@arm.com public: using YourClass::DoSomethingReturningInt; // changes access rights 69813481Sgiacomo.travaglini@arm.com ... 69913481Sgiacomo.travaglini@arm.com}; 70013481Sgiacomo.travaglini@arm.com 70113481Sgiacomo.travaglini@arm.comTEST_F(YourClassTest, DoSomethingTest) { 70213481Sgiacomo.travaglini@arm.com TestableYourClass obj; 70313481Sgiacomo.travaglini@arm.com assertEquals(expected_value, obj.DoSomethingReturningInt()); 70413481Sgiacomo.travaglini@arm.com} 70513481Sgiacomo.travaglini@arm.com``` 70613481Sgiacomo.travaglini@arm.com 70713481Sgiacomo.travaglini@arm.com## How do I test private class static members without writing FRIEND\_TEST()s? ## 70813481Sgiacomo.travaglini@arm.com 70913481Sgiacomo.travaglini@arm.comWe find private static methods clutter the header file. They are 71013481Sgiacomo.travaglini@arm.comimplementation details and ideally should be kept out of a .h. So often I make 71113481Sgiacomo.travaglini@arm.comthem free functions instead. 71213481Sgiacomo.travaglini@arm.com 71313481Sgiacomo.travaglini@arm.comInstead of: 71413481Sgiacomo.travaglini@arm.com``` 71513481Sgiacomo.travaglini@arm.com// foo.h 71613481Sgiacomo.travaglini@arm.comclass Foo { 71713481Sgiacomo.travaglini@arm.com ... 71813481Sgiacomo.travaglini@arm.com private: 71913481Sgiacomo.travaglini@arm.com static bool Func(int n); 72013481Sgiacomo.travaglini@arm.com}; 72113481Sgiacomo.travaglini@arm.com 72213481Sgiacomo.travaglini@arm.com// foo.cc 72313481Sgiacomo.travaglini@arm.combool Foo::Func(int n) { ... } 72413481Sgiacomo.travaglini@arm.com 72513481Sgiacomo.travaglini@arm.com// foo_test.cc 72613481Sgiacomo.travaglini@arm.comEXPECT_TRUE(Foo::Func(12345)); 72713481Sgiacomo.travaglini@arm.com``` 72813481Sgiacomo.travaglini@arm.com 72913481Sgiacomo.travaglini@arm.comYou probably should better write: 73013481Sgiacomo.travaglini@arm.com``` 73113481Sgiacomo.travaglini@arm.com// foo.h 73213481Sgiacomo.travaglini@arm.comclass Foo { 73313481Sgiacomo.travaglini@arm.com ... 73413481Sgiacomo.travaglini@arm.com}; 73513481Sgiacomo.travaglini@arm.com 73613481Sgiacomo.travaglini@arm.com// foo.cc 73713481Sgiacomo.travaglini@arm.comnamespace internal { 73813481Sgiacomo.travaglini@arm.com bool Func(int n) { ... } 73913481Sgiacomo.travaglini@arm.com} 74013481Sgiacomo.travaglini@arm.com 74113481Sgiacomo.travaglini@arm.com// foo_test.cc 74213481Sgiacomo.travaglini@arm.comnamespace internal { 74313481Sgiacomo.travaglini@arm.com bool Func(int n); 74413481Sgiacomo.travaglini@arm.com} 74513481Sgiacomo.travaglini@arm.com 74613481Sgiacomo.travaglini@arm.comEXPECT_TRUE(internal::Func(12345)); 74713481Sgiacomo.travaglini@arm.com``` 74813481Sgiacomo.travaglini@arm.com 74913481Sgiacomo.travaglini@arm.com## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ## 75013481Sgiacomo.travaglini@arm.com 75113481Sgiacomo.travaglini@arm.comNo. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide.md#Value_Parameterized_Tests) which 75213481Sgiacomo.travaglini@arm.comlets you repeat your tests with different parameters, without defining it more than once. 75313481Sgiacomo.travaglini@arm.com 75413481Sgiacomo.travaglini@arm.com## How do I test a file that defines main()? ## 75513481Sgiacomo.travaglini@arm.com 75613481Sgiacomo.travaglini@arm.comTo test a `foo.cc` file, you need to compile and link it into your unit test 75713481Sgiacomo.travaglini@arm.comprogram. However, when the file contains a definition for the `main()` 75813481Sgiacomo.travaglini@arm.comfunction, it will clash with the `main()` of your unit test, and will result in 75913481Sgiacomo.travaglini@arm.coma build error. 76013481Sgiacomo.travaglini@arm.com 76113481Sgiacomo.travaglini@arm.comThe right solution is to split it into three files: 76213481Sgiacomo.travaglini@arm.com 1. `foo.h` which contains the declarations, 76313481Sgiacomo.travaglini@arm.com 1. `foo.cc` which contains the definitions except `main()`, and 76413481Sgiacomo.travaglini@arm.com 1. `foo_main.cc` which contains nothing but the definition of `main()`. 76513481Sgiacomo.travaglini@arm.com 76613481Sgiacomo.travaglini@arm.comThen `foo.cc` can be easily tested. 76713481Sgiacomo.travaglini@arm.com 76813481Sgiacomo.travaglini@arm.comIf you are adding tests to an existing file and don't want an intrusive change 76913481Sgiacomo.travaglini@arm.comlike this, there is a hack: just include the entire `foo.cc` file in your unit 77013481Sgiacomo.travaglini@arm.comtest. For example: 77113481Sgiacomo.travaglini@arm.com``` 77213481Sgiacomo.travaglini@arm.com// File foo_unittest.cc 77313481Sgiacomo.travaglini@arm.com 77413481Sgiacomo.travaglini@arm.com// The headers section 77513481Sgiacomo.travaglini@arm.com... 77613481Sgiacomo.travaglini@arm.com 77713481Sgiacomo.travaglini@arm.com// Renames main() in foo.cc to make room for the unit test main() 77813481Sgiacomo.travaglini@arm.com#define main FooMain 77913481Sgiacomo.travaglini@arm.com 78013481Sgiacomo.travaglini@arm.com#include "a/b/foo.cc" 78113481Sgiacomo.travaglini@arm.com 78213481Sgiacomo.travaglini@arm.com// The tests start here. 78313481Sgiacomo.travaglini@arm.com... 78413481Sgiacomo.travaglini@arm.com``` 78513481Sgiacomo.travaglini@arm.com 78613481Sgiacomo.travaglini@arm.com 78713481Sgiacomo.travaglini@arm.comHowever, please remember this is a hack and should only be used as the last 78813481Sgiacomo.travaglini@arm.comresort. 78913481Sgiacomo.travaglini@arm.com 79013481Sgiacomo.travaglini@arm.com## What can the statement argument in ASSERT\_DEATH() be? ## 79113481Sgiacomo.travaglini@arm.com 79213481Sgiacomo.travaglini@arm.com`ASSERT_DEATH(_statement_, _regex_)` (or any death assertion macro) can be used 79313481Sgiacomo.travaglini@arm.comwherever `_statement_` is valid. So basically `_statement_` can be any C++ 79413481Sgiacomo.travaglini@arm.comstatement that makes sense in the current context. In particular, it can 79513481Sgiacomo.travaglini@arm.comreference global and/or local variables, and can be: 79613481Sgiacomo.travaglini@arm.com * a simple function call (often the case), 79713481Sgiacomo.travaglini@arm.com * a complex expression, or 79813481Sgiacomo.travaglini@arm.com * a compound statement. 79913481Sgiacomo.travaglini@arm.com 80013481Sgiacomo.travaglini@arm.com> Some examples are shown here: 80113481Sgiacomo.travaglini@arm.com 80213481Sgiacomo.travaglini@arm.com``` 80313481Sgiacomo.travaglini@arm.com// A death test can be a simple function call. 80413481Sgiacomo.travaglini@arm.comTEST(MyDeathTest, FunctionCall) { 80513481Sgiacomo.travaglini@arm.com ASSERT_DEATH(Xyz(5), "Xyz failed"); 80613481Sgiacomo.travaglini@arm.com} 80713481Sgiacomo.travaglini@arm.com 80813481Sgiacomo.travaglini@arm.com// Or a complex expression that references variables and functions. 80913481Sgiacomo.travaglini@arm.comTEST(MyDeathTest, ComplexExpression) { 81013481Sgiacomo.travaglini@arm.com const bool c = Condition(); 81113481Sgiacomo.travaglini@arm.com ASSERT_DEATH((c ? Func1(0) : object2.Method("test")), 81213481Sgiacomo.travaglini@arm.com "(Func1|Method) failed"); 81313481Sgiacomo.travaglini@arm.com} 81413481Sgiacomo.travaglini@arm.com 81513481Sgiacomo.travaglini@arm.com// Death assertions can be used any where in a function. In 81613481Sgiacomo.travaglini@arm.com// particular, they can be inside a loop. 81713481Sgiacomo.travaglini@arm.comTEST(MyDeathTest, InsideLoop) { 81813481Sgiacomo.travaglini@arm.com // Verifies that Foo(0), Foo(1), ..., and Foo(4) all die. 81913481Sgiacomo.travaglini@arm.com for (int i = 0; i < 5; i++) { 82013481Sgiacomo.travaglini@arm.com EXPECT_DEATH_M(Foo(i), "Foo has \\d+ errors", 82113481Sgiacomo.travaglini@arm.com ::testing::Message() << "where i is " << i); 82213481Sgiacomo.travaglini@arm.com } 82313481Sgiacomo.travaglini@arm.com} 82413481Sgiacomo.travaglini@arm.com 82513481Sgiacomo.travaglini@arm.com// A death assertion can contain a compound statement. 82613481Sgiacomo.travaglini@arm.comTEST(MyDeathTest, CompoundStatement) { 82713481Sgiacomo.travaglini@arm.com // Verifies that at lease one of Bar(0), Bar(1), ..., and 82813481Sgiacomo.travaglini@arm.com // Bar(4) dies. 82913481Sgiacomo.travaglini@arm.com ASSERT_DEATH({ 83013481Sgiacomo.travaglini@arm.com for (int i = 0; i < 5; i++) { 83113481Sgiacomo.travaglini@arm.com Bar(i); 83213481Sgiacomo.travaglini@arm.com } 83313481Sgiacomo.travaglini@arm.com }, 83413481Sgiacomo.travaglini@arm.com "Bar has \\d+ errors");} 83513481Sgiacomo.travaglini@arm.com``` 83613481Sgiacomo.travaglini@arm.com 83713481Sgiacomo.travaglini@arm.com`googletest_unittest.cc` contains more examples if you are interested. 83813481Sgiacomo.travaglini@arm.com 83913481Sgiacomo.travaglini@arm.com## What syntax does the regular expression in ASSERT\_DEATH use? ## 84013481Sgiacomo.travaglini@arm.com 84113481Sgiacomo.travaglini@arm.comOn POSIX systems, Google Test uses the POSIX Extended regular 84213481Sgiacomo.travaglini@arm.comexpression syntax 84313481Sgiacomo.travaglini@arm.com(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). 84413481Sgiacomo.travaglini@arm.comOn Windows, it uses a limited variant of regular expression 84513481Sgiacomo.travaglini@arm.comsyntax. For more details, see the 84613481Sgiacomo.travaglini@arm.com[regular expression syntax](V1_6_AdvancedGuide.md#Regular_Expression_Syntax). 84713481Sgiacomo.travaglini@arm.com 84813481Sgiacomo.travaglini@arm.com## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ## 84913481Sgiacomo.travaglini@arm.com 85013481Sgiacomo.travaglini@arm.comGoogle Test needs to be able to create objects of your test fixture class, so 85113481Sgiacomo.travaglini@arm.comit must have a default constructor. Normally the compiler will define one for 85213481Sgiacomo.travaglini@arm.comyou. However, there are cases where you have to define your own: 85313481Sgiacomo.travaglini@arm.com * If you explicitly declare a non-default constructor for class `Foo`, then you need to define a default constructor, even if it would be empty. 85413481Sgiacomo.travaglini@arm.com * If `Foo` has a const non-static data member, then you have to define the default constructor _and_ initialize the const member in the initializer list of the constructor. (Early versions of `gcc` doesn't force you to initialize the const member. It's a bug that has been fixed in `gcc 4`.) 85513481Sgiacomo.travaglini@arm.com 85613481Sgiacomo.travaglini@arm.com## Why does ASSERT\_DEATH complain about previous threads that were already joined? ## 85713481Sgiacomo.travaglini@arm.com 85813481Sgiacomo.travaglini@arm.comWith the Linux pthread library, there is no turning back once you cross the 85913481Sgiacomo.travaglini@arm.comline from single thread to multiple threads. The first time you create a 86013481Sgiacomo.travaglini@arm.comthread, a manager thread is created in addition, so you get 3, not 2, threads. 86113481Sgiacomo.travaglini@arm.comLater when the thread you create joins the main thread, the thread count 86213481Sgiacomo.travaglini@arm.comdecrements by 1, but the manager thread will never be killed, so you still have 86313481Sgiacomo.travaglini@arm.com2 threads, which means you cannot safely run a death test. 86413481Sgiacomo.travaglini@arm.com 86513481Sgiacomo.travaglini@arm.comThe new NPTL thread library doesn't suffer from this problem, as it doesn't 86613481Sgiacomo.travaglini@arm.comcreate a manager thread. However, if you don't control which machine your test 86713481Sgiacomo.travaglini@arm.comruns on, you shouldn't depend on this. 86813481Sgiacomo.travaglini@arm.com 86913481Sgiacomo.travaglini@arm.com## Why does Google Test require the entire test case, instead of individual tests, to be named FOODeathTest when it uses ASSERT\_DEATH? ## 87013481Sgiacomo.travaglini@arm.com 87113481Sgiacomo.travaglini@arm.comGoogle Test does not interleave tests from different test cases. That is, it 87213481Sgiacomo.travaglini@arm.comruns all tests in one test case first, and then runs all tests in the next test 87313481Sgiacomo.travaglini@arm.comcase, and so on. Google Test does this because it needs to set up a test case 87413481Sgiacomo.travaglini@arm.combefore the first test in it is run, and tear it down afterwords. Splitting up 87513481Sgiacomo.travaglini@arm.comthe test case would require multiple set-up and tear-down processes, which is 87613481Sgiacomo.travaglini@arm.cominefficient and makes the semantics unclean. 87713481Sgiacomo.travaglini@arm.com 87813481Sgiacomo.travaglini@arm.comIf we were to determine the order of tests based on test name instead of test 87913481Sgiacomo.travaglini@arm.comcase name, then we would have a problem with the following situation: 88013481Sgiacomo.travaglini@arm.com 88113481Sgiacomo.travaglini@arm.com``` 88213481Sgiacomo.travaglini@arm.comTEST_F(FooTest, AbcDeathTest) { ... } 88313481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Uvw) { ... } 88413481Sgiacomo.travaglini@arm.com 88513481Sgiacomo.travaglini@arm.comTEST_F(BarTest, DefDeathTest) { ... } 88613481Sgiacomo.travaglini@arm.comTEST_F(BarTest, Xyz) { ... } 88713481Sgiacomo.travaglini@arm.com``` 88813481Sgiacomo.travaglini@arm.com 88913481Sgiacomo.travaglini@arm.comSince `FooTest.AbcDeathTest` needs to run before `BarTest.Xyz`, and we don't 89013481Sgiacomo.travaglini@arm.cominterleave tests from different test cases, we need to run all tests in the 89113481Sgiacomo.travaglini@arm.com`FooTest` case before running any test in the `BarTest` case. This contradicts 89213481Sgiacomo.travaglini@arm.comwith the requirement to run `BarTest.DefDeathTest` before `FooTest.Uvw`. 89313481Sgiacomo.travaglini@arm.com 89413481Sgiacomo.travaglini@arm.com## But I don't like calling my entire test case FOODeathTest when it contains both death tests and non-death tests. What do I do? ## 89513481Sgiacomo.travaglini@arm.com 89613481Sgiacomo.travaglini@arm.comYou don't have to, but if you like, you may split up the test case into 89713481Sgiacomo.travaglini@arm.com`FooTest` and `FooDeathTest`, where the names make it clear that they are 89813481Sgiacomo.travaglini@arm.comrelated: 89913481Sgiacomo.travaglini@arm.com 90013481Sgiacomo.travaglini@arm.com``` 90113481Sgiacomo.travaglini@arm.comclass FooTest : public ::testing::Test { ... }; 90213481Sgiacomo.travaglini@arm.com 90313481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Abc) { ... } 90413481Sgiacomo.travaglini@arm.comTEST_F(FooTest, Def) { ... } 90513481Sgiacomo.travaglini@arm.com 90613481Sgiacomo.travaglini@arm.comtypedef FooTest FooDeathTest; 90713481Sgiacomo.travaglini@arm.com 90813481Sgiacomo.travaglini@arm.comTEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... } 90913481Sgiacomo.travaglini@arm.comTEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... } 91013481Sgiacomo.travaglini@arm.com``` 91113481Sgiacomo.travaglini@arm.com 91213481Sgiacomo.travaglini@arm.com## The compiler complains about "no match for 'operator<<'" when I use an assertion. What gives? ## 91313481Sgiacomo.travaglini@arm.com 91413481Sgiacomo.travaglini@arm.comIf you use a user-defined type `FooType` in an assertion, you must make sure 91513481Sgiacomo.travaglini@arm.comthere is an `std::ostream& operator<<(std::ostream&, const FooType&)` function 91613481Sgiacomo.travaglini@arm.comdefined such that we can print a value of `FooType`. 91713481Sgiacomo.travaglini@arm.com 91813481Sgiacomo.travaglini@arm.comIn addition, if `FooType` is declared in a name space, the `<<` operator also 91913481Sgiacomo.travaglini@arm.comneeds to be defined in the _same_ name space. 92013481Sgiacomo.travaglini@arm.com 92113481Sgiacomo.travaglini@arm.com## How do I suppress the memory leak messages on Windows? ## 92213481Sgiacomo.travaglini@arm.com 92313481Sgiacomo.travaglini@arm.comSince the statically initialized Google Test singleton requires allocations on 92413481Sgiacomo.travaglini@arm.comthe heap, the Visual C++ memory leak detector will report memory leaks at the 92513481Sgiacomo.travaglini@arm.comend of the program run. The easiest way to avoid this is to use the 92613481Sgiacomo.travaglini@arm.com`_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any 92713481Sgiacomo.travaglini@arm.comstatically initialized heap objects. See MSDN for more details and additional 92813481Sgiacomo.travaglini@arm.comheap check/debug routines. 92913481Sgiacomo.travaglini@arm.com 93013481Sgiacomo.travaglini@arm.com## I am building my project with Google Test in Visual Studio and all I'm getting is a bunch of linker errors (or warnings). Help! ## 93113481Sgiacomo.travaglini@arm.com 93213481Sgiacomo.travaglini@arm.comYou may get a number of the following linker error or warnings if you 93313481Sgiacomo.travaglini@arm.comattempt to link your test project with the Google Test library when 93413481Sgiacomo.travaglini@arm.comyour project and the are not built using the same compiler settings. 93513481Sgiacomo.travaglini@arm.com 93613481Sgiacomo.travaglini@arm.com * LNK2005: symbol already defined in object 93713481Sgiacomo.travaglini@arm.com * LNK4217: locally defined symbol 'symbol' imported in function 'function' 93813481Sgiacomo.travaglini@arm.com * LNK4049: locally defined symbol 'symbol' imported 93913481Sgiacomo.travaglini@arm.com 94013481Sgiacomo.travaglini@arm.comThe Google Test project (gtest.vcproj) has the Runtime Library option 94113481Sgiacomo.travaglini@arm.comset to /MT (use multi-threaded static libraries, /MTd for debug). If 94213481Sgiacomo.travaglini@arm.comyour project uses something else, for example /MD (use multi-threaded 94313481Sgiacomo.travaglini@arm.comDLLs, /MDd for debug), you need to change the setting in the Google 94413481Sgiacomo.travaglini@arm.comTest project to match your project's. 94513481Sgiacomo.travaglini@arm.com 94613481Sgiacomo.travaglini@arm.comTo update this setting open the project properties in the Visual 94713481Sgiacomo.travaglini@arm.comStudio IDE then select the branch Configuration Properties | C/C++ | 94813481Sgiacomo.travaglini@arm.comCode Generation and change the option "Runtime Library". You may also try 94913481Sgiacomo.travaglini@arm.comusing gtest-md.vcproj instead of gtest.vcproj. 95013481Sgiacomo.travaglini@arm.com 95113481Sgiacomo.travaglini@arm.com## I put my tests in a library and Google Test doesn't run them. What's happening? ## 95213481Sgiacomo.travaglini@arm.comHave you read a 95313481Sgiacomo.travaglini@arm.com[warning](V1_6_Primer.md#important-note-for-visual-c-users) on 95413481Sgiacomo.travaglini@arm.comthe Google Test Primer page? 95513481Sgiacomo.travaglini@arm.com 95613481Sgiacomo.travaglini@arm.com## I want to use Google Test with Visual Studio but don't know where to start. ## 95713481Sgiacomo.travaglini@arm.comMany people are in your position and one of the posted his solution to 95813481Sgiacomo.travaglini@arm.comour mailing list. Here is his link: 95913481Sgiacomo.travaglini@arm.comhttp://hassanjamilahmad.blogspot.com/2009/07/gtest-starters-help.html. 96013481Sgiacomo.travaglini@arm.com 96113481Sgiacomo.travaglini@arm.com## I am seeing compile errors mentioning std::type\_traits when I try to use Google Test on Solaris. ## 96213481Sgiacomo.travaglini@arm.comGoogle Test uses parts of the standard C++ library that SunStudio does not support. 96313481Sgiacomo.travaglini@arm.comOur users reported success using alternative implementations. Try running the build after runing this commad: 96413481Sgiacomo.travaglini@arm.com 96513481Sgiacomo.travaglini@arm.com`export CC=cc CXX=CC CXXFLAGS='-library=stlport4'` 96613481Sgiacomo.travaglini@arm.com 96713481Sgiacomo.travaglini@arm.com## How can my code detect if it is running in a test? ## 96813481Sgiacomo.travaglini@arm.com 96913481Sgiacomo.travaglini@arm.comIf you write code that sniffs whether it's running in a test and does 97013481Sgiacomo.travaglini@arm.comdifferent things accordingly, you are leaking test-only logic into 97113481Sgiacomo.travaglini@arm.comproduction code and there is no easy way to ensure that the test-only 97213481Sgiacomo.travaglini@arm.comcode paths aren't run by mistake in production. Such cleverness also 97313481Sgiacomo.travaglini@arm.comleads to 97413481Sgiacomo.travaglini@arm.com[Heisenbugs](http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug). 97513481Sgiacomo.travaglini@arm.comTherefore we strongly advise against the practice, and Google Test doesn't 97613481Sgiacomo.travaglini@arm.comprovide a way to do it. 97713481Sgiacomo.travaglini@arm.com 97813481Sgiacomo.travaglini@arm.comIn general, the recommended way to cause the code to behave 97913481Sgiacomo.travaglini@arm.comdifferently under test is [dependency injection](http://jamesshore.com/Blog/Dependency-Injection-Demystified.html). 98013481Sgiacomo.travaglini@arm.comYou can inject different functionality from the test and from the 98113481Sgiacomo.travaglini@arm.comproduction code. Since your production code doesn't link in the 98213481Sgiacomo.travaglini@arm.comfor-test logic at all, there is no danger in accidentally running it. 98313481Sgiacomo.travaglini@arm.com 98413481Sgiacomo.travaglini@arm.comHowever, if you _really_, _really_, _really_ have no choice, and if 98513481Sgiacomo.travaglini@arm.comyou follow the rule of ending your test program names with `_test`, 98613481Sgiacomo.travaglini@arm.comyou can use the _horrible_ hack of sniffing your executable name 98713481Sgiacomo.travaglini@arm.com(`argv[0]` in `main()`) to know whether the code is under test. 98813481Sgiacomo.travaglini@arm.com 98913481Sgiacomo.travaglini@arm.com## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ## 99013481Sgiacomo.travaglini@arm.com 99113481Sgiacomo.travaglini@arm.comIn C++, macros don't obey namespaces. Therefore two libraries that 99213481Sgiacomo.travaglini@arm.comboth define a macro of the same name will clash if you `#include` both 99313481Sgiacomo.travaglini@arm.comdefinitions. In case a Google Test macro clashes with another 99413481Sgiacomo.travaglini@arm.comlibrary, you can force Google Test to rename its macro to avoid the 99513481Sgiacomo.travaglini@arm.comconflict. 99613481Sgiacomo.travaglini@arm.com 99713481Sgiacomo.travaglini@arm.comSpecifically, if both Google Test and some other code define macro 99813481Sgiacomo.travaglini@arm.com`FOO`, you can add 99913481Sgiacomo.travaglini@arm.com``` 100013481Sgiacomo.travaglini@arm.com -DGTEST_DONT_DEFINE_FOO=1 100113481Sgiacomo.travaglini@arm.com``` 100213481Sgiacomo.travaglini@arm.comto the compiler flags to tell Google Test to change the macro's name 100313481Sgiacomo.travaglini@arm.comfrom `FOO` to `GTEST_FOO`. For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll need to write 100413481Sgiacomo.travaglini@arm.com``` 100513481Sgiacomo.travaglini@arm.com GTEST_TEST(SomeTest, DoesThis) { ... } 100613481Sgiacomo.travaglini@arm.com``` 100713481Sgiacomo.travaglini@arm.cominstead of 100813481Sgiacomo.travaglini@arm.com``` 100913481Sgiacomo.travaglini@arm.com TEST(SomeTest, DoesThis) { ... } 101013481Sgiacomo.travaglini@arm.com``` 101113481Sgiacomo.travaglini@arm.comin order to define a test. 101213481Sgiacomo.travaglini@arm.com 101313481Sgiacomo.travaglini@arm.comCurrently, the following `TEST`, `FAIL`, `SUCCEED`, and the basic comparison assertion macros can have alternative names. You can see the full list of covered macros [here](http://www.google.com/codesearch?q=if+!GTEST_DONT_DEFINE_\w%2B+package:http://googletest\.googlecode\.com+file:/include/gtest/gtest.h). More information can be found in the "Avoiding Macro Name Clashes" section of the README file. 101413481Sgiacomo.travaglini@arm.com 101513481Sgiacomo.travaglini@arm.com## My question is not covered in your FAQ! ## 101613481Sgiacomo.travaglini@arm.com 101713481Sgiacomo.travaglini@arm.comIf you cannot find the answer to your question in this FAQ, there are 101813481Sgiacomo.travaglini@arm.comsome other resources you can use: 101913481Sgiacomo.travaglini@arm.com 102013481Sgiacomo.travaglini@arm.com 1. read other [wiki pages](http://code.google.com/p/googletest/w/list), 102113481Sgiacomo.travaglini@arm.com 1. search the mailing list [archive](http://groups.google.com/group/googletestframework/topics), 102213481Sgiacomo.travaglini@arm.com 1. ask it on [googletestframework@googlegroups.com](mailto:googletestframework@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googletestframework) before you can post.). 102313481Sgiacomo.travaglini@arm.com 102413481Sgiacomo.travaglini@arm.comPlease note that creating an issue in the 102513481Sgiacomo.travaglini@arm.com[issue tracker](http://code.google.com/p/googletest/issues/list) is _not_ 102613481Sgiacomo.travaglini@arm.coma good way to get your answer, as it is monitored infrequently by a 102713481Sgiacomo.travaglini@arm.comvery small number of people. 102813481Sgiacomo.travaglini@arm.com 102913481Sgiacomo.travaglini@arm.comWhen asking a question, it's helpful to provide as much of the 103013481Sgiacomo.travaglini@arm.comfollowing information as possible (people cannot help you if there's 103113481Sgiacomo.travaglini@arm.comnot enough information in your question): 103213481Sgiacomo.travaglini@arm.com 103313481Sgiacomo.travaglini@arm.com * the version (or the revision number if you check out from SVN directly) of Google Test you use (Google Test is under active development, so it's possible that your problem has been solved in a later version), 103413481Sgiacomo.travaglini@arm.com * your operating system, 103513481Sgiacomo.travaglini@arm.com * the name and version of your compiler, 103613481Sgiacomo.travaglini@arm.com * the complete command line flags you give to your compiler, 103713481Sgiacomo.travaglini@arm.com * the complete compiler error messages (if the question is about compilation), 103813481Sgiacomo.travaglini@arm.com * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter. 1039