Google Test (gtest) Notes
A good unit test:
- Is able to be fully automated
- has full control over all the pieces running(Uses mocks or fakes to achieve this isolation when needed
- Can run in any order
- Runs fast
- Test a single logical concepts in system
- Is readable
- is maintainable
- Runs in memory(no DB or File access )
How to run it ?
- ccmake
- localmake
- /sdev/user/bin/run_ut
Mock Objects
- Each unit test case test a single logical solution
- That is, test the behavior of a single function in a single scenario
- But many functions call other functions with their own complex behavior
- The complex behavior make it hard to test a single logical solution
- It is also difficult to get the called function to exhibit bad whether behavior
- So instead of calling the actual calling those other functions we call test doubles
- One particular kind of test double is mock
What is Mock ?
A Mock check that the double is called as expected
It substitutes a behavior for the function that would be called
EXPECT_CALL Macro
EXPECT_CALL(mock_object, method(matchers)).Times(cardinality).WillOnce(action)
What is Test Fixture?
Test Fixtures:
- Using the Same Data Configuration for Multiple Tests.
- Derive a class from ::testing::Test. Start its body with protected:, as we will want to access fixture members from sub-classes.
- If necessary, write a default constructor or SetUp().
- If necessary, write a default destructor or TearDown().
- Use TEST_F(), instead of TEST().
TEST_F(TestFixtureName, TestName) {
... test body ...
}
What is EXPECT_CALL and ON_CALL in gtest?
There are subtle but significant differences between the two statements. EXPECT_CALL sets expectation on a mock calls. Writing
EXPECT_CALL(mock, methodX(_)).WillRepeatedly(do_action);
tells gMock that methodX may be called on mock any number of times with any arguments, and when it is, mock will perform do_action. On the other hand,
ON_CALL(mock, methodX(_)).WillByDefault(do_action);
tells gMock that whenever methodX is invoked on mock, it should perform do_action. That feature is helpful in a scenario where you have to write many expectations on your mock, and most/all of them have to specify the same action -- especially if it's complex. You can specify that action in ON_CALL, and then write EXPECT_CALLs without specifying the action explicitly. E.g.,
ON_CALL(mock, Sign(Eq(0), _))
.WillByDefault(DoAll(SetArgPointee<1>("argument is zero"), Return(0)));
ON_CALL(mock, Sign(Gt(0), _))
.WillByDefault(DoAll(SetArgPointee<1>("argument is positive"), Return(1)));
ON_CALL(mock, Sign(Lt(0), _))
.WillByDefault(DoAll(SetArgPointee<1>("argument is negative"), Return(-1)));
Now, if you have to write a lot of EXPECT_CALLs, you don't have to mock's specify the behavior every time:
EXPECT_CALL(mock, Sign(-4, _));
EXPECT_CALL(mock, Sign(0, _));
EXPECT_CALL(mock, Sign(1, _)).Times(2);
EXPECT_CALL(mock, Sign(2, _));
EXPECT_CALL(mock, Sign(3, _));
EXPECT_CALL(mock, Sign(5, _));
In another example, assuming Sign returns int, if you write
ON_CALL(mock, Sign(Gt(0), _)).WillByDefault(Return(1));
EXPECT_CALL(mock, Sign(10, _));
the call mock.Sign(10) will return 1 as ON_CALL provides default behavior for a call specified by EXPECT_CALL. But if you write
EXPECT_CALL(mock, Sign(Gt(0), _).WillRepeatedly(Return(1));
EXPECT_CALL(mock, Sign(10, _));
the invocation of mock.Sign(10, p) will return 0. It will be matched against the second expectation. That expectation specifies no explicit action and gMock will generate a default action for it. That default action is to return a default value of the return type, which is 0 for int. The first expectation will be totally ignored in this case.
Q. What is exact difference between ON_CALL and EXPECT_CALL ?
ON_CALL defines what happens when a mock method is called, but doesn't imply any expectation on the method being called.
EXPECT_CALL not only defines the behavior, but also sets an expectation that the method must be called with the given arguments, for the given number of times (and in the given order when you specify the order too).
Keep in mind that one doesn't have to verify more than one property in one test. In fact, it's a good style to verify only one thing in one test. If you do that, a bug will likely break only one or two tests instead of dozens (which case would you rather debug?). If you are also in the habit of giving tests descriptive names that tell what they verify, you can often easily guess what's wrong just from the test log itself.
So use ON_CALL by default, and only use EXPECT_CALL when you actually intend to verify that the call is made.
Example Code for gtest:-
#include<gtest/gtest.h>
using namespace std;
Test(TestName, Subtest_1)
{
ASSERT_FALSE(1 == 2)
}
Test(TestName, Subtest_2)
{
ASSERT_FALSE(1 == 2)
}
//To add New testName2 as separate test, after that we can multiple test cases
Test(TestName, Subtest_1)
{
ASSERT_FALSE(1 == 2)
}
int main()
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS()
}
To compile gtest:
g++ Test.cpp -lgtest -lgtest_main -pthread
./a.out
Types of Assertions
1. Success
EXPECT_EQ()
ASSERT_EQ()
2. Non fatal failure
Equal: EXPECT_EQ()
Not Equal: EXPECT_NE()
Less than: EXPECT_LT()
LessThanEqual: EXPECT_LE()
Greater than: EXPECT_GT()
GreaterThanEqual: EXPECT_GE()
3. Fatal failure
Equal: ASSERT_EQ()
Not Equal: ASSERT_NE()
Less than: ASSERT_LT()
LessThanEqual: ASSERT_LE()
Greater than: ASSERT_GT()
GreaterThanEqual: ASSERT_GE()
Comments
Post a Comment