Gmock integration
Comments
-
From my experience I haven't heard of anyone trying to use GMock or any other Mocking framework with C/C++test. I wasn't able to find information on this in our documentation so I do not see this as a supported feature right now in the tool.
I do see that the use of Mocking is supported in our other tool, Jtest.
0 -
1) Support for gmock is provided by allowing usage of any external libraries to be used. Search "Linker Options" in our documentation. You might need to provide additional include paths in compiler options to satisfy the compiler (if the header files for the gmock are not in the same directory).
2) Using gmock with C++Test is redundant a bit. C++Test has Stubs API that can be used in the same way that mocks are used: We support both life cycles:Test lifecycle with stubs
// supported with Stubs out of the box
Setup - Prepare object that is being tested and its stubs collaborators.
Exercise - Test the functionality.
Verify state - Use asserts to check object's state.
Teardown - Clean up resources.Test lifecycle with mocks: - supported with Dynamic Stubs API - search the doc
Setup data - Prepare object that is being tested.
Setup expectations - Prepare expectations in mock that is being used by primary object.
Exercise - Test the functionality.
Verify expectations - Verify that correct methods has been invoked in mock.
Verify state - Use asserts to check object's state.
Teardown - Clean up resources.1 -
I've just tried a simple example with recent C++test and latest gmock. It seems to be working fine. I'm talking about a simple use cases where gmock asserts/expectations messages go to console only (not visible in C++test reports), but full gmock power is available.
For a simple scenario please follow the steps:
Build gmock and gtest
Configuration with no pthreads mode is recommended
(./configure --with-pthreads=no)Add include paths to the compiler flags:
Project Properties->Parasoft->C++test->Build Settings->Compiler options
[append:] -Igmock_dir/include -Igtest_dir/includeDisable Parasoft Dynamic Stubs API
(temporarily it conflicts with gtest, this will be addressed in near future)
Project Properties->Parasoft->C++test->Build Settings->Compiler options
[append:] -DCPPTEST_TRIGGER_ENABLED=0Append gmock and gtest libs to the linker flags:
Project Properties->Parasoft->C++test->Build Settings->Linker options
[append:] gmock_dir/lib/.libs/libgmock.a gtest_dir/lib/.libs/libgtest.aAdd gmock framework initialization
In your project create folder named factory or stubs (if not yet exists)
Inside "factory" or “stubs” create a file init.cpp with the following content:
include "gmock\gmock.h"
void CppTest_Initialize(void)
{
static int argc = 1;
static char * argv = {"fake cmd"};
testing::InitGoogleMock( &argc, &argv );
}
This is to inject gmock initialization at the test harness startup.
Currently there is no easy way to pass a real command line args (from main) to the InitGoogleMock.
If needed, hardcode parameters via static argc and argv inside CppTest_Initialize.Use Gmock inside the test suite:
Snippet from my test suite:
…
include "gmock/gmock.h"
...
using ::testing::AtLeast;
using ::testing::Return;
...
class TestMock : public Test {
public:
MOCK_METHOD0( getValue, int() );
};
...
void TestSuite_my_class_cpp_4e0526f9::test_case_fuu()
{
TestMock test1;
EXPECT_CALL(test1, getValue()).Times(AtLeast(2)).WillOnce(Return(33));
int _ret = fuu(test1);
CPPTEST_ASSERT_INTEGER_EQUAL(_ret, 33);
}Run prepared test cases
Created mock objects will behave as expected (here return value from Test::getValue forced to 33)
GMock expectations/asserts will be shown on the console:
Expected to be called at least twice, but has only 1 WillOnce().C:\Users\mirek\parasoft\workspace_gmock\GMockTest\tests\autogenerated\TestSuite_my_class_cpp.cpp:58: Failure
Actual function call count doesn't match EXPECT_CALL(test1, getValue())...
Expected: to be called at least twice
Actual: called once - unsatisfied and active
All above was verified with Cygwin GNU GCC 5.3 (Windows 10)
4 -
Awwww!!!! that's great Mirek.
0 -
@Mirek - Does any of the above changes dramatically with introduction of awesome Proxy Stubs in 10.4.3?
0 -
I find that the Proxy Stubs provided in 10.4.3 do not replace what I'm accustomed to using with Mock objects. Injecting faults at the C++ interface level is more powerful with Mocks than Stubs, IMHO.
I explored using GMock but I don't want to pull in the GoogleTest to my testing framework. I want something simpler and limited in scope. I looked into Turtle and it requires Boost. Then I found FakeIt which provides Mock capabilities in a single header and testing framework independent. With some (a lot) of tweaking, I have FakeIt running on a Parasoft project which uses a BDF for an IAR Arm compiler with CSpy executing the tests.
For those that are interested, I've created a Pull-Request for the FakeIt project that you can use to access the modifications:
https://github.com/eranpeer/FakeIt/pull/203Here's my description of the Pull-Request for reference:
Add a single header to support Parasoft unit test tool. This implementation specifically supports Parasoft building IAR Arm projects and executing tests on the IAR CSpy Arm Simulator.
Parasoft is a unit testing tool that supports testing C/C++ applications. Parasoft is well suited for embedded and safety-critical applications. Since Parasoft is aimed at supporting light-weight C applications, it provides a stubbing framework to eliminate dependencies with low-level library calls in C. Stubbing is a critical component for testing embedded applications but Mocking is a preferred approach for dependency injection when testing C++ code. This is the motivation for adding FakeIt support to Parasoft. FakeIt was selected over open source projects (GoogleMock, Boost/Turtle) because it has no dependency on other test frameworks.
Note: this implementation does not support exceptions. The samples/fakeit_with_parasoft directory has a TestSuite that documents the FakeIt features that have been validated with the Parasoft / IAR configuration.
0 -
Hi @wbschiller,
Thank you for sharing it.
We will review/research it internally. Maybe we can move some concepts into our stubbing framework.0