What’s google test

Google's framework for writing C++ tests on a

variety of platforms (Linux, Mac OS X, Windows,
Cygwin, Windows CE, and Symbian). Based on
the xUnit architecture. Supports automatic test
discovery, a rich set of assertions, user-defined
assertions, death tests, fatal and non-fatal
failures, value- and type-parameterized tests,
various options for running the tests, and XML
test report generation.
 Why Google C++ Testing Framework?

• A Google C++ Testing Framework helps you

write better C++ tests. No matter whether you
work on Linux, Windows, or a Mac, if you
write C++ code, Google Test can help you
 how does Google C++ Testing Framework fit
in?
• 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.
• 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.
 how does Google C++ Testing Framework fit
in? (Cont.)
• 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.)
• 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.
 how does Google C++ Testing Framework fit
in? (Cont.)
• 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.
• 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.
• Since Google C++ Testing Framework is based on the popular xUnit
architecture, you'll feel right at home if you've used JUnit or
PyUnit before. If not, it will take you about 10 minutes to learn the
basics and get started. 
 Setting up a New Test Project

• To write a test program using Google Test, you need to

compile Google Test into a library and link your test with
it.
IMPORTANT NOTE: Please do link your project to its
library not archive all object files as a binary, otherwise
your program would be crashed.
• Once you are able to compile the Google Test library, you
should create a project or build target for your test
program. Make sure you have GTEST_ROOT/include in the
header search path so that the compiler can
find "gtest/gtest.h" when compiling your test.
 Basic Concepts

• When using Google Test, you start by writing assertions, which

are statements that check whether a condition is true. An
assertion's result can besuccess, nonfatal failure, or fatal failure.
If a fatal failure occurs, it aborts the current function; otherwise
the program continues normally.
• Tests use assertions to verify the tested code's behavior. If a test
crashes or has a failed assertion, then it fails; otherwise
it succeeds.
• A test case contains one or many tests. You should group your
tests into test cases that reflect the structure of the tested code.
When multiple tests in a test case need to share common objects
and subroutines, you can put them into a test fixture class.
 Assertions

• Google Test assertions are macros that resemble function calls. You
test a class or function by making assertions about its behavior.
When an assertion fails, Google Test prints the assertion's source file
and line number location, along with a failure message. You may
also supply a custom failure message which will be appended to
Google Test's message.
• We have pairs of assertion. ASSERT_* versions generate fatal failures
when they fail, and abort the current function. EXPECT_* versions
generate nonfatal failures, which don't abort the current function.
UsuallyEXPECT_* are preferred, as they allow more than one
failures to be reported in a test. However, you should
use ASSERT_* if it doesn't make sense to continue when the
assertion in question fails.
 Basic Assertions

• These assertions do basic true/false condition

testing.

Fatal assertion Nonfatal assertion Verifies

ASSERT_TRUE(condition EXPECT_TRUE(condition
condition is true
); );

ASSERT_FALSE(conditio EXPECT_FALSE(conditio
condition is false
n); n);
 Binary Comparison
• This section describes assertions that compare
two values.
Fatal assertion Nonfatal assertion Verifies
ASSERT_EQ(expecte
EXPECT_EQ(expected, actual); expected == actual
d, actual);
ASSERT_NE(val1, va EXPECT_NE(val1, val2); val1 != val2
l2);
ASSERT_LT(val1, val
EXPECT_LT(val1, val2); val1 < val2
2);
ASSERT_LE(val1, val EXPECT_LE(val1, val2); val1 <= val2
2);
ASSERT_GT(val1, va EXPECT_GT(val1, val2); val1 > val2
l2);
ASSERT_GE(val1, va
EXPECT_GE(val1, val2); val1 >= val2
l2);
ASSERT_GE(val1, val
2); EXPECT_GE(val1, val2); val1 >= val2
 String Comparison

• The assertions in this group compare two C

strings. If you want to compare
two string objects,
use EXPECT_EQ, EXPECT_NE,
Fatal assertion Nonfatal assertion
and
Verifies
etc instead.
ASSERT_STREQ(expected_ EXPECT_STREQ(expectedthe two C strings have
str, actual_str); _str, actual_str); the same content
ASSERT_STRNE(str1, str2) EXPECT_STRNE(str1, str2)
the two C strings have
; ; different content
ASSERT_STRCASEEQ(expe EXPECT_STRCASEEQ(expe the two C strings have
the same content,
cted_str, actual_str); cted_str, actual_str);
ignoring case
the two C strings have
ASSERT_STRCASENE(str1,  EXPECT_STRCASENE(str1, 
different content,
str2); str2); ignoring case
 Simple Tests

• To create a test:
• Use the TEST() macro to define and name a test
function, These are ordinary C++ functions that
don't return a value.
• In this function, along with any valid C++
statements you want to include, use the various
Google Test assertions to check values.
• 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.
 An example
• For example, let's take a simple integer function:
• int Factorial(int n); // Returns the factorial of nA test case for this function might
look like:
• // Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
  EXPECT_EQ(1, Factorial(0));
}

// Tests factorial of positive numbers.

TEST(FactorialTest, HandlesPositiveInput) {
  EXPECT_EQ(1, Factorial(1));
  EXPECT_EQ(2, Factorial(2));
  EXPECT_EQ(6, Factorial(3));
  EXPECT_EQ(40320, Factorial(8));
}
 Test Fixtures: Using the Same Data Configuration for Multiple Tests

• If you find yourself writing two or more tests that operate on similar data, you can
use a test fixture. It allows you to reuse the same configuration of objects for
several different tests.
• To create a fixture, just:
• Derive a class from ::testing::Test . Start its body with protected: or public: as we'll
want to access fixture members from sub-classes.
• Inside the class, declare any objects you plan to use.
• 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.
• 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.
• If needed, define subroutines for your tests to share.
 Invoking the Tests

• 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.
After defining your tests, you can run them with RUN_ALL_TESTS() , which returns 0 if
all the tests are successful, or 1 otherwise. Note thatRUN_ALL_TESTS() runs all tests in
your link unit -- they can be from different test cases, or even different source files.
When invoked, the RUN_ALL_TESTS() macro:
• Saves the state of all Google Test flags.
• Creates a test fixture object for the first test.
• Initializes it via SetUp().
• Runs the test on the fixture object.
• Cleans up the fixture via TearDown().
• Deletes the fixture.
• Restores the state of all Google Test flags.
• Repeats the above steps for the next test, until all tests have run.
 Writing the main() Function

• Example:
int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}
• The ::testing::InitGoogleTest() function parses the command
line for Google Test flags, and removes all recognized flags.
This allows the user to control a test program's behavior via
various flags, which we'll cover in AdvancedGuide. You must
call this function before callingRUN_ALL_TESTS(), or the
flags won't be properly initialized.
 Known Limitations

• Google Test is designed to be thread-safe. The

implementation is thread-safe on systems where
the pthreads library is available. It is currently
unsafe to use Google Test assertions from two
threads concurrently on other systems (e.g.
Windows). In most tests this is not an issue as
usually the assertions are done in the main thread.
If you want to help, you can volunteer to implement
the necessary synchronization primitives in gtest-
port.h for your platform.
 Want to learn more?
• Advanced guide of google test:
http://
code.google.com/p/googletest/wiki/AdvancedG
uide#Teaching_Google_Test_How_to_Print_You
r_Values
• Google mock cookbook. A good friend of goolge
test which customers your mock object’s
behavior:
http://code.google.com/p/googlemock/wiki/Co
okBook
• Google C++ Mocking Framework Cheat Sheet: