1 2 3# Introduction: Why Google C++ Testing Framework? # 4 5_Google C++ Testing Framework_ helps you write better C++ tests. 6 7No matter whether you work on Linux, Windows, or a Mac, if you write C++ code, 8Google Test can help you. 9 10So what makes a good test, and how does Google C++ Testing Framework fit in? We believe: 11 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. 12 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. 13 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.) 14 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. 15 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. 16 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. 17 18Since Google C++ Testing Framework is based on the popular xUnit 19architecture, you'll feel right at home if you've used JUnit or PyUnit before. 20If not, it will take you about 10 minutes to learn the basics and get started. 21So let's go! 22 23_Note:_ We sometimes refer to Google C++ Testing Framework informally 24as _Google Test_. 25 26# Beware of the nomenclature # 27 28_Note:_ There might be some confusion of idea due to different 29definitions of the terms _Test_, _Test Case_ and _Test Suite_, so beware 30of misunderstanding these. 31 32Historically, the Google C++ Testing Framework started to use the term 33_Test Case_ for grouping related tests, whereas current publications 34including the International Software Testing Qualifications Board 35([ISTQB](http://www.istqb.org/)) and various textbooks on Software 36Quality use the term _[Test 37Suite](http://glossary.istqb.org/search/test%20suite)_ for this. 38 39The related term _Test_, as it is used in the Google C++ Testing 40Framework, is corresponding to the term _[Test 41Case](http://glossary.istqb.org/search/test%20case)_ of ISTQB and 42others. 43 44The term _Test_ is commonly of broad enough sense, including ISTQB's 45definition of _Test Case_, so it's not much of a problem here. But the 46term _Test Case_ as used in Google Test is of contradictory sense and thus confusing. 47 48Unfortunately replacing the term _Test Case_ by _Test Suite_ throughout 49the Google C++ Testing Framework is not easy without breaking dependent 50projects, as `TestCase` is part of the public API at various places. 51 52So for the time being, please be aware of the different definitions of 53the terms: 54 55Meaning | Google Test Term | [ISTQB](http://www.istqb.org/) Term 56------- | ---------------- | ----------------------------------- 57Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case](http://glossary.istqb.org/search/test%20case) 58A set of several tests related to one component | [Test Case](#basic-concepts) | [Test Suite](http://glossary.istqb.org/search/test%20suite) 59 60# Setting up a New Test Project # 61 62To write a test program using Google Test, you need to compile Google 63Test into a library and link your test with it. We provide build 64files for some popular build systems: `msvc/` for Visual Studio, 65`xcode/` for Mac Xcode, `make/` for GNU make, `codegear/` for Borland 66C++ Builder, and the autotools script (deprecated) and 67`CMakeLists.txt` for CMake (recommended) in the Google Test root 68directory. If your build system is not on this list, you can take a 69look at `make/Makefile` to learn how Google Test should be compiled 70(basically you want to compile `src/gtest-all.cc` with `GTEST_ROOT` 71and `GTEST_ROOT/include` in the header search path, where `GTEST_ROOT` 72is the Google Test root directory). 73 74Once you are able to compile the Google Test library, you should 75create a project or build target for your test program. Make sure you 76have `GTEST_ROOT/include` in the header search path so that the 77compiler can find `"gtest/gtest.h"` when compiling your test. Set up 78your test project to link with the Google Test library (for example, 79in Visual Studio, this is done by adding a dependency on 80`gtest.vcproj`). 81 82If you still have questions, take a look at how Google Test's own 83tests are built and use them as examples. 84 85# Basic Concepts # 86 87When using Google Test, you start by writing _assertions_, which are statements 88that check whether a condition is true. An assertion's result can be _success_, 89_nonfatal failure_, or _fatal failure_. If a fatal failure occurs, it aborts 90the current function; otherwise the program continues normally. 91 92_Tests_ use assertions to verify the tested code's behavior. If a test crashes 93or has a failed assertion, then it _fails_; otherwise it _succeeds_. 94 95A _test case_ contains one or many tests. You should group your tests into test 96cases that reflect the structure of the tested code. When multiple tests in a 97test case need to share common objects and subroutines, you can put them into a 98_test fixture_ class. 99 100A _test program_ can contain multiple test cases. 101 102We'll now explain how to write a test program, starting at the individual 103assertion level and building up to tests and test cases. 104 105# Assertions # 106 107Google Test assertions are macros that resemble function calls. You test a 108class or function by making assertions about its behavior. When an assertion 109fails, Google Test prints the assertion's source file and line number location, 110along with a failure message. You may also supply a custom failure message 111which will be appended to Google Test's message. 112 113The assertions come in pairs that test the same thing but have different 114effects on the current function. `ASSERT_*` versions generate fatal failures 115when they fail, and **abort the current function**. `EXPECT_*` versions generate 116nonfatal failures, which don't abort the current function. Usually `EXPECT_*` 117are preferred, as they allow more than one failures to be reported in a test. 118However, you should use `ASSERT_*` if it doesn't make sense to continue when 119the assertion in question fails. 120 121Since a failed `ASSERT_*` returns from the current function immediately, 122possibly skipping clean-up code that comes after it, it may cause a space leak. 123Depending on the nature of the leak, it may or may not be worth fixing - so 124keep this in mind if you get a heap checker error in addition to assertion 125errors. 126 127To provide a custom failure message, simply stream it into the macro using the 128`<<` operator, or a sequence of such operators. An example: 129``` 130ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length"; 131 132for (int i = 0; i < x.size(); ++i) { 133 EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i; 134} 135``` 136 137Anything that can be streamed to an `ostream` can be streamed to an assertion 138macro--in particular, C strings and `string` objects. If a wide string 139(`wchar_t*`, `TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is 140streamed to an assertion, it will be translated to UTF-8 when printed. 141 142## Basic Assertions ## 143 144These assertions do basic true/false condition testing. 145 146| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 147|:--------------------|:-----------------------|:-------------| 148| `ASSERT_TRUE(`_condition_`)`; | `EXPECT_TRUE(`_condition_`)`; | _condition_ is true | 149| `ASSERT_FALSE(`_condition_`)`; | `EXPECT_FALSE(`_condition_`)`; | _condition_ is false | 150 151Remember, when they fail, `ASSERT_*` yields a fatal failure and 152returns from the current function, while `EXPECT_*` yields a nonfatal 153failure, allowing the function to continue running. In either case, an 154assertion failure means its containing test fails. 155 156_Availability_: Linux, Windows, Mac. 157 158## Binary Comparison ## 159 160This section describes assertions that compare two values. 161 162| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 163|:--------------------|:-----------------------|:-------------| 164|`ASSERT_EQ(`_val1_`, `_val2_`);`|`EXPECT_EQ(`_val1_`, `_val2_`);`| _val1_ `==` _val2_ | 165|`ASSERT_NE(`_val1_`, `_val2_`);`|`EXPECT_NE(`_val1_`, `_val2_`);`| _val1_ `!=` _val2_ | 166|`ASSERT_LT(`_val1_`, `_val2_`);`|`EXPECT_LT(`_val1_`, `_val2_`);`| _val1_ `<` _val2_ | 167|`ASSERT_LE(`_val1_`, `_val2_`);`|`EXPECT_LE(`_val1_`, `_val2_`);`| _val1_ `<=` _val2_ | 168|`ASSERT_GT(`_val1_`, `_val2_`);`|`EXPECT_GT(`_val1_`, `_val2_`);`| _val1_ `>` _val2_ | 169|`ASSERT_GE(`_val1_`, `_val2_`);`|`EXPECT_GE(`_val1_`, `_val2_`);`| _val1_ `>=` _val2_ | 170 171In the event of a failure, Google Test prints both _val1_ and _val2_. 172 173Value arguments must be comparable by the assertion's comparison 174operator or you'll get a compiler error. We used to require the 175arguments to support the `<<` operator for streaming to an `ostream`, 176but it's no longer necessary since v1.6.0 (if `<<` is supported, it 177will be called to print the arguments when the assertion fails; 178otherwise Google Test will attempt to print them in the best way it 179can. For more details and how to customize the printing of the 180arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).). 181 182These assertions can work with a user-defined type, but only if you define the 183corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding 184operator is defined, prefer using the `ASSERT_*()` macros because they will 185print out not only the result of the comparison, but the two operands as well. 186 187Arguments are always evaluated exactly once. Therefore, it's OK for the 188arguments to have side effects. However, as with any ordinary C/C++ function, 189the arguments' evaluation order is undefined (i.e. the compiler is free to 190choose any order) and your code should not depend on any particular argument 191evaluation order. 192 193`ASSERT_EQ()` does pointer equality on pointers. If used on two C strings, it 194tests if they are in the same memory location, not if they have the same value. 195Therefore, if you want to compare C strings (e.g. `const char*`) by value, use 196`ASSERT_STREQ()` , which will be described later on. In particular, to assert 197that a C string is `NULL`, use `ASSERT_STREQ(NULL, c_string)` . However, to 198compare two `string` objects, you should use `ASSERT_EQ`. 199 200Macros in this section work with both narrow and wide string objects (`string` 201and `wstring`). 202 203_Availability_: Linux, Windows, Mac. 204 205_Historical note_: Before February 2016 `*_EQ` had a convention of calling it as 206`ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. 207Now `*_EQ` treats both parameters in the same way. 208 209## String Comparison ## 210 211The assertions in this group compare two **C strings**. If you want to compare 212two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead. 213 214| **Fatal assertion** | **Nonfatal assertion** | **Verifies** | 215|:--------------------|:-----------------------|:-------------| 216| `ASSERT_STREQ(`_str1_`, `_str2_`);` | `EXPECT_STREQ(`_str1_`, `_str2_`);` | the two C strings have the same content | 217| `ASSERT_STRNE(`_str1_`, `_str2_`);` | `EXPECT_STRNE(`_str1_`, `_str2_`);` | the two C strings have different content | 218| `ASSERT_STRCASEEQ(`_str1_`, `_str2_`);`| `EXPECT_STRCASEEQ(`_str1_`, `_str2_`);` | the two C strings have the same content, ignoring case | 219| `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case | 220 221Note that "CASE" in an assertion name means that case is ignored. 222 223`*STREQ*` and `*STRNE*` also accept wide C strings (`wchar_t*`). If a 224comparison of two wide strings fails, their values will be printed as UTF-8 225narrow strings. 226 227A `NULL` pointer and an empty string are considered _different_. 228 229_Availability_: Linux, Windows, Mac. 230 231See also: For more string comparison tricks (substring, prefix, suffix, and 232regular expression matching, for example), see the [Advanced Google Test Guide](AdvancedGuide.md). 233 234# Simple Tests # 235 236To create a test: 237 1. Use the `TEST()` macro to define and name a test function, These are ordinary C++ functions that don't return a value. 238 1. In this function, along with any valid C++ statements you want to include, use the various Google Test assertions to check values. 239 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. 240 241``` 242TEST(test_case_name, test_name) { 243 ... test body ... 244} 245``` 246 247 248`TEST()` arguments go from general to specific. The _first_ argument is the 249name of the test case, and the _second_ argument is the test's name within the 250test 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 251individual name. Tests from different test cases can have the same individual 252name. 253 254For example, let's take a simple integer function: 255``` 256int Factorial(int n); // Returns the factorial of n 257``` 258 259A test case for this function might look like: 260``` 261// Tests factorial of 0. 262TEST(FactorialTest, HandlesZeroInput) { 263 EXPECT_EQ(1, Factorial(0)); 264} 265 266// Tests factorial of positive numbers. 267TEST(FactorialTest, HandlesPositiveInput) { 268 EXPECT_EQ(1, Factorial(1)); 269 EXPECT_EQ(2, Factorial(2)); 270 EXPECT_EQ(6, Factorial(3)); 271 EXPECT_EQ(40320, Factorial(8)); 272} 273``` 274 275Google Test groups the test results by test cases, so logically-related tests 276should be in the same test case; in other words, the first argument to their 277`TEST()` should be the same. In the above example, we have two tests, 278`HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test 279case `FactorialTest`. 280 281_Availability_: Linux, Windows, Mac. 282 283# Test Fixtures: Using the Same Data Configuration for Multiple Tests # 284 285If you find yourself writing two or more tests that operate on similar data, 286you can use a _test fixture_. It allows you to reuse the same configuration of 287objects for several different tests. 288 289To create a fixture, just: 290 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. 291 1. Inside the class, declare any objects you plan to use. 292 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. 293 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). 294 1. If needed, define subroutines for your tests to share. 295 296When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to 297access objects and subroutines in the test fixture: 298``` 299TEST_F(test_case_name, test_name) { 300 ... test body ... 301} 302``` 303 304Like `TEST()`, the first argument is the test case name, but for `TEST_F()` 305this must be the name of the test fixture class. You've probably guessed: `_F` 306is for fixture. 307 308Unfortunately, the C++ macro system does not allow us to create a single macro 309that can handle both types of tests. Using the wrong macro causes a compiler 310error. 311 312Also, you must first define a test fixture class before using it in a 313`TEST_F()`, or you'll get the compiler error "`virtual outside class 314declaration`". 315 316For each test defined with `TEST_F()`, Google Test will: 317 1. Create a _fresh_ test fixture at runtime 318 1. Immediately initialize it via `SetUp()` 319 1. Run the test 320 1. Clean up by calling `TearDown()` 321 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. 322 323As an example, let's write tests for a FIFO queue class named `Queue`, which 324has the following interface: 325``` 326template <typename E> // E is the element type. 327class Queue { 328 public: 329 Queue(); 330 void Enqueue(const E& element); 331 E* Dequeue(); // Returns NULL if the queue is empty. 332 size_t size() const; 333 ... 334}; 335``` 336 337First, define a fixture class. By convention, you should give it the name 338`FooTest` where `Foo` is the class being tested. 339``` 340class QueueTest : public ::testing::Test { 341 protected: 342 virtual void SetUp() { 343 q1_.Enqueue(1); 344 q2_.Enqueue(2); 345 q2_.Enqueue(3); 346 } 347 348 // virtual void TearDown() {} 349 350 Queue<int> q0_; 351 Queue<int> q1_; 352 Queue<int> q2_; 353}; 354``` 355 356In this case, `TearDown()` is not needed since we don't have to clean up after 357each test, other than what's already done by the destructor. 358 359Now we'll write tests using `TEST_F()` and this fixture. 360``` 361TEST_F(QueueTest, IsEmptyInitially) { 362 EXPECT_EQ(0, q0_.size()); 363} 364 365TEST_F(QueueTest, DequeueWorks) { 366 int* n = q0_.Dequeue(); 367 EXPECT_EQ(NULL, n); 368 369 n = q1_.Dequeue(); 370 ASSERT_TRUE(n != NULL); 371 EXPECT_EQ(1, *n); 372 EXPECT_EQ(0, q1_.size()); 373 delete n; 374 375 n = q2_.Dequeue(); 376 ASSERT_TRUE(n != NULL); 377 EXPECT_EQ(2, *n); 378 EXPECT_EQ(1, q2_.size()); 379 delete n; 380} 381``` 382 383The above uses both `ASSERT_*` and `EXPECT_*` assertions. The rule of thumb is 384to use `EXPECT_*` when you want the test to continue to reveal more errors 385after the assertion failure, and use `ASSERT_*` when continuing after failure 386doesn't make sense. For example, the second assertion in the `Dequeue` test is 387`ASSERT_TRUE(n != NULL)`, as we need to dereference the pointer `n` later, 388which would lead to a segfault when `n` is `NULL`. 389 390When these tests run, the following happens: 391 1. Google Test constructs a `QueueTest` object (let's call it `t1` ). 392 1. `t1.SetUp()` initializes `t1` . 393 1. The first test ( `IsEmptyInitially` ) runs on `t1` . 394 1. `t1.TearDown()` cleans up after the test finishes. 395 1. `t1` is destructed. 396 1. The above steps are repeated on another `QueueTest` object, this time running the `DequeueWorks` test. 397 398_Availability_: Linux, Windows, Mac. 399 400_Note_: Google Test automatically saves all _Google Test_ flags when a test 401object is constructed, and restores them when it is destructed. 402 403# Invoking the Tests # 404 405`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. 406 407After 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. 408 409When invoked, the `RUN_ALL_TESTS()` macro: 410 1. Saves the state of all Google Test flags. 411 1. Creates a test fixture object for the first test. 412 1. Initializes it via `SetUp()`. 413 1. Runs the test on the fixture object. 414 1. Cleans up the fixture via `TearDown()`. 415 1. Deletes the fixture. 416 1. Restores the state of all Google Test flags. 417 1. Repeats the above steps for the next test, until all tests have run. 418 419In addition, if the test fixture's constructor generates a fatal failure in 420step 2, there is no point for step 3 - 5 and they are thus skipped. Similarly, 421if step 3 generates a fatal failure, step 4 will be skipped. 422 423_Important_: You must not ignore the return value of `RUN_ALL_TESTS()`, or `gcc` 424will give you a compiler error. The rationale for this design is that the 425automated testing service determines whether a test has passed based on its 426exit code, not on its stdout/stderr output; thus your `main()` function must 427return the value of `RUN_ALL_TESTS()`. 428 429Also, you should call `RUN_ALL_TESTS()` only **once**. Calling it more than once 430conflicts with some advanced Google Test features (e.g. thread-safe death 431tests) and thus is not supported. 432 433_Availability_: Linux, Windows, Mac. 434 435# Writing the main() Function # 436 437You can start from this boilerplate: 438``` 439#include "this/package/foo.h" 440#include "gtest/gtest.h" 441 442namespace { 443 444// The fixture for testing class Foo. 445class FooTest : public ::testing::Test { 446 protected: 447 // You can remove any or all of the following functions if its body 448 // is empty. 449 450 FooTest() { 451 // You can do set-up work for each test here. 452 } 453 454 virtual ~FooTest() { 455 // You can do clean-up work that doesn't throw exceptions here. 456 } 457 458 // If the constructor and destructor are not enough for setting up 459 // and cleaning up each test, you can define the following methods: 460 461 virtual void SetUp() { 462 // Code here will be called immediately after the constructor (right 463 // before each test). 464 } 465 466 virtual void TearDown() { 467 // Code here will be called immediately after each test (right 468 // before the destructor). 469 } 470 471 // Objects declared here can be used by all tests in the test case for Foo. 472}; 473 474// Tests that the Foo::Bar() method does Abc. 475TEST_F(FooTest, MethodBarDoesAbc) { 476 const string input_filepath = "this/package/testdata/myinputfile.dat"; 477 const string output_filepath = "this/package/testdata/myoutputfile.dat"; 478 Foo f; 479 EXPECT_EQ(0, f.Bar(input_filepath, output_filepath)); 480} 481 482// Tests that Foo does Xyz. 483TEST_F(FooTest, DoesXyz) { 484 // Exercises the Xyz feature of Foo. 485} 486 487} // namespace 488 489int main(int argc, char **argv) { 490 ::testing::InitGoogleTest(&argc, argv); 491 return RUN_ALL_TESTS(); 492} 493``` 494 495The `::testing::InitGoogleTest()` function parses the command line for Google 496Test flags, and removes all recognized flags. This allows the user to control a 497test program's behavior via various flags, which we'll cover in [AdvancedGuide](AdvancedGuide.md). 498You must call this function before calling `RUN_ALL_TESTS()`, or the flags 499won't be properly initialized. 500 501On Windows, `InitGoogleTest()` also works with wide strings, so it can be used 502in programs compiled in `UNICODE` mode as well. 503 504But 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. 505 506## Important note for Visual C++ users ## 507If 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: 508``` 509__declspec(dllexport) int PullInMyLibrary() { return 0; } 510``` 511If 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: 512``` 513int PullInMyLibrary(); 514static int dummy = PullInMyLibrary(); 515``` 516This will keep your tests referenced and will make them register themselves at startup. 517 518In 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. 519 520There 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! 521 522# Where to Go from Here # 523 524Congratulations! You've learned the Google Test basics. You can start writing 525and running Google Test tests, read some [samples](Samples.md), or continue with 526[AdvancedGuide](AdvancedGuide.md), which describes many more useful Google Test features. 527 528# Known Limitations # 529 530Google Test is designed to be thread-safe. The implementation is 531thread-safe on systems where the `pthreads` library is available. It 532is currently _unsafe_ to use Google Test assertions from two threads 533concurrently on other systems (e.g. Windows). In most tests this is 534not an issue as usually the assertions are done in the main thread. If 535you want to help, you can volunteer to implement the necessary 536synchronization primitives in `gtest-port.h` for your platform. 537