This is a mirror of official site: http://jasper-net.blogspot.com/

A quick introduction to the Google C++ Testing Framework

| Thursday, May 13, 2010
Why use the Google C++ Testing Framework?

There are many good reasons for you to use this framework. This section describes several of them.
Some categories of tests have bad memory problems that surface only during certain runs. Google's test framework provides excellent support for handling such situations. You can repeat the same test a thousand times using the Google framework. At the first sign of a failure, the debugger is automatically invoked. In addition, all of this is done with just two switches passed from command line: --gtest_repeat=1000 --gtest_break_on_failure.
Contrary to a lot of other testing frameworks, Google's test framework has built-in assertions that are deployable in software where exception handling is disabled (typically for performance reasons). Thus, the assertions can be used safely in destructors, too.
Running the tests is simple. Just making a call to the predefined RUN_ALL_TESTS macro does the trick, as opposed to creating or deriving a separate runner class for test execution. This is in sharp contrast to frameworks such as CppUnit.
Generating an Extensible Markup Language (XML) report is as easy as passing a switch: --gtest_output="xml:<file name>". In frameworks such as CppUnit and CppTest, you need to write substantially more code to generate XML output.

Creating a basic test

Consider the prototype for a simple square root function shown in Listing 1.

Listing 1. Prototype of the square root function

double square_root (const double);

For negative numbers, this routine returns -1. It's useful to have both positive and negative tests here, so you do both. Listing 2 shows that test case.

Listing 2. Unit test for the square root function

#include "gtest/gtest.h"

TEST (SquareRootTest, PositiveNos) {
   EXPECT_EQ (18.0, square-root (324.0));
   EXPECT_EQ (25.4, square-root (645.16));
   EXPECT_EQ (50.3321, square-root (2533.310224));
}

TEST (SquareRootTest, ZeroAndNegativeNos) {
   ASSERT_EQ (0.0, square-root (0.0));
   ASSERT_EQ (-1, square-root (-22.0));
}

Listing 2 creates a test hierarchy named SquareRootTest and then adds two unit tests, PositiveNos and ZeroAndNegativeNos, to that hierarchy. TEST is a predefined macro defined in gtest.h (available with the downloaded sources) that helps define this hierarchy. EXPECT_EQ and ASSERT_EQ are also macros—in the former case test execution continues even if there is a failure while in the latter case test execution aborts. Clearly, if the square root of 0 is anything but 0, there isn't much left to test anyway. That's why the ZeroAndNegativeNos test uses only ASSERT_EQ while the PositiveNos test uses EXPECT_EQ to tell you how many cases there are where the square root function fails without aborting the test.

Running the first test

Now that you've created your first basic test, it is time to run it. Listing 3 is the code for the main routine that runs the test.

Listing 3. Running the square root test

#include "gtest/gtest.h"

TEST(SquareRootTest, PositiveNos) {
   EXPECT_EQ (18.0, square-root (324.0));
   EXPECT_EQ (25.4, square-root (645.16));
   EXPECT_EQ (50.3321, square-root (2533.310224));
}

TEST (SquareRootTest, ZeroAndNegativeNos) {
   ASSERT_EQ (0.0, square-root (0.0));
   ASSERT_EQ (-1, square-root (-22.0));
}

int main(int argc, char **argv) {
 ::testing::InitGoogleTest(&argc, argv);
 return RUN_ALL_TESTS();
}

The ::testing::InitGoogleTest method does what the name suggests—it initializes the framework and must be called before RUN_ALL_TESTS. RUN_ALL_TESTS must be called only once in the code because multiple calls to it conflict with some of the advanced features of the framework and, therefore, are not supported. Note that RUN_ALL_TESTS automatically detects and runs all the tests defined using the TEST macro. By default, the results are printed to standard output. Listing 4 shows the output.

Read more: IBM

Posted via email from jasper22's posterous

0 comments: