Google Test / Mock personal cheat sheet

Overview

Last time, I made a Google Mock environment for C that I use for my work, so I decided to study a little more. There is something like "Google C ++ Mocking Framework cheat sheet", but it's hard to understand and it doesn't come to my mind just by looking at it. While reading, I decided to make something like a cheat sheet for myself. We will update it one by one.

Summary of macros

TEST(), TEST_F(), TEST_P() https://github.com/google/googletest/blob/master/googletest/docs/primer.md#simple-tests

TEST(TestSuiteName, TestName) {
  ... test body ...
}

• Enter the major and minor names of the test case.

• It seems that it is not good to use underscore. I can use something.
• If there are multiple tests, a build error will occur unless the combination of the major item name and the minor item name is duplicated.

• In TEST_F, the first argument is the class name defined as the test fixture.
• TEST_P is an advanced technique that allows you to run one test many times with different parameters.
  • http://opencv.jp/googletestdocs/advancedguide.html#adv-how-to-write-value-parameterized-tests

ASSERT_EQ, EXPECT_EQ http://opencv.jp/googletestdocs/primer.html#primer-binary-comparison

• The first argument is the expected value and the second argument is the actual value. It can be used to check the return value when the function is executed.
• There are also relatives such as ʻEXPECT_NE and ʻEXPECT_TRUE
• ʻASSERT_ * will immediately terminate the test when the situation is not what you expected, and ʻEXPECT_ * will continue.

MOCK_METHOD*, MOCK_CONST_METHOD*

• Used to define mock methods. The * part is the number of arguments.
• If the number of arguments exceeds 10, it will die. Measures are required for unfortunate projects that have functions with many arguments.

EXPECT_CALL

• Declare that Mock methods will be called. The first argument is an instance of the Mocked class (the entity, not the pointer), and the second argument is the method name.
• The method name specifies a set of arguments. If a call is made that does not match the arguments, it means that it was not called.
• You can omit the argument check by using :: testing :: _ described later.
• If it is not the NiceMock described below, a non-EXPECTed Mock method call will be warned. (The test will succeed). The test will fail if there are no EXPECTed calls.

::testing::_ https://github.com/google/googletest/blob/master/googlemock/docs/cheat_sheet.md#wildcard

• The exact definition is Matcher's wildcard, which, as the name implies, allows arbitrary arguments.
• There are various Matchers on the above page, so if you look at them, there may be something you can use.
• There seems to be logical operation.

Times http://opencv.jp/googlemockdocs/fordummies.html#cardinalities

• You can specify the number of calls by using it like a member of ʻEXPECT_CALL`. It's called cardinality.
• You can loosen the number check with :: testing :: AtLeast (n) (n is an integer greater than or equal to 0)
• The test will fail if not called the specified number of times
• You can declare that the method will not be called by setting it to Times (0)
• Times (1) can be omitted.

WillOnce, WillRepeatedly http://opencv.jp/googlemockdocs/fordummies.html#fordummies-general-syntax

• Can be used like a member of ʻEXPECT_CALL` to define the action when called
• I think that action mainly specifies the return value. You can't do that with a method that has no return value.
• Will ** must be written after Times.
• You can use multiple WillOnces, and you can change the action for each return value.

using ::testing::Return;...
EXPECT_CALL(turtle, GetX())
    .Times(5)
    .WillOnce(Return(100))
    .WillOnce(Return(150))
    .WillRepeatedly(Return(200));

::testing::Return https://github.com/google/googletest/blob/master/googlemock/docs/cheat_sheet.md#actions-actionlist

• It works to return the value as the action of Will ** mentioned above.
• It seems that there are several types of actions as shown on the above page. I'm not sure where to use it ...

RetiresOnSaturation http://opencv.jp/googlemockdocs/fordummies.html#expectation-sticky

• You can use it like a member of ʻEXPECT_CALL` to specify that you should not look at EXPECT_CALL anymore when the role of EXPECT_CALL is over.

Google Mock Expectation indicates "sticky" by default

• I think that you have to make various tests and learn with your skin what exactly sticky is.

::testing::Invoke http://opencv.jp/googlemockdocs/cheatsheet.html#cheatsheet-using-afunction-or-functor

• You can define a function as an action as shown below. It will be used like a fake instead of a mock.

double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
...
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));

• The function registered in action with Invoke must be in the same function form (or compatible form such as void *) as the Mock method.
• Unused arguments can be Unused. It is also used in the above example.
• There seems to be ʻInvokeWithoutArgs` etc. It seems that you can ignore any arguments instead of taking no arguments.
• There is also Define Action, but ...

NiceMock<> http://opencv.jp/googlemockdocs/cookbook.html#nice-strict

• The Mock declared with this will not issue an Assert etc. even if the method of the Mock is called before it is set with ʻEXPECT_CALL`.
• "First, let's specify EXPECT_CALL and specify the behavior of the mock."
• "Use very carefully" "Bugs may be overlooked without warning"
• I also recommend using it only for classes that don't matter
• I also have a relative, Strict Mock.

Grammatic

Test fixture

https://github.com/google/googletest/blob/master/googletest/docs/primer.md#test-fixtures-using-the-same-data-configuration-for-multiple-tests

• You can define a class derived from :: testing :: Test to create a fixture (there is no valid Japanese, but I think it is a nuance such as a standard or basic concept).
• Specifically, you can share the instance created by the fixture between test cases. ,

RUN_ALL_TESTS and main function

http://opencv.jp/googletestdocs/primer.html#primer-invoking-the-tests http://opencv.jp/googlemockdocs/fordummies.html#fordummies-using-mocks-in-tests

• When using fixtures and mock, it seems that main () is required to initialize them.
• If main () is prepared, it seems better to execute RUN_ALL_TESTS () with the return of main ().

• Run all tests with RUN_ALL_TESTS. Note that Setup () and TearDown () are run for each test at this time.

::testing::InitGoogleMock

• It seems to initialize when using Mock. I'm not sure about the details ... It's a magical state.

Multiple Exceptions (ʻEXPECT_CALL`)

http://opencv.jp/googlemockdocs/fordummies.html#fordummies-using-multiple-expectations

• EXPECT_CALL for multiple matchers (match conditions) can be written in advance.

EXPECT_CALL(turtle, Forward(_));  // #1
EXPECT_CALL(turtle, Forward(10))  // #2
    .Times(2);

• However, multiple Exceptions behave uniquely and can be difficult to test:
• Match judgment seems to be in order from the last defined one
• If you write multiple EXPECT_CALL for the same matcher, it will be overwritten by the last declared one.
• If you want to have multiple actions under the same Match condition, add multiple Will Once or use :: testing :: Invoke.

InSequence http://opencv.jp/googlemockdocs/fordummies.html#fordummies-ordered-vs-unordered

• You can check the method call order
• I don't use it so much, so I can't explain it in detail. The situation where you have to test the calling order is already over ... but if you use it well, will the test code be easier to see?
• It feels like an intermediate technique when it comes to this area.
• Another example also describes how to define a sequence by attaching it to EXPECT_CALL.
• There is After related to the order.

ʻON_CALL` and default action

http://opencv.jp/googlemockdocs/cheatsheet.html#action

• ʻON_CALL` seems to specify the default action of the method
• You can do the same with Will Repeatedly without Times, but using ON_CALL may be the original procedure.
• There seems to be DefaultValue <T> :: Set (value).

The one I didn't understand

• MOCK_METHOD_1_WITH_CALLTYPE
• :: testing :: Mock :: VerifyAndClearExpectations + its companion
• Can you verify destruction?