Using an extra mock simply to take advantage of the behaviour observation tooling

Question

I'm writing integration for a project, but our framework doesn't provide any ability to inject dependencies, so I've written tests with a unit testing framework (GTest) and used a mock (GMock) in an odd way simply to leverage its behaviour obverving functions. I have a python script to run it, it all works, but, is there a better approach I should be taking?

/** Class that exists simply to provide stubs for callbacks */
class Monitor
{
 public:
  virtual auto subscribe() -> void {}
};

/** Mocking the ClientMonitor in order to leverage the Mocking tools, i.e.
 * EXPECT_CALL.Times, etc. */
class MockMonitor
{
 public:
  MOCK_METHOD1(subscribe, void());
};

TEST_F(Test, RECEIVE_PROXY_STATUS_EVENT_AVAILABLE)
{
  using ::testing::_;
  MockMonitor cm;

  // Listen for when the service event changes.
  auto const subscription_status = proxy_->getPayloadEvent().subscribe(
    [&cm](int64_t id, std::string const& payload) {
      cm.subscribe();
    });

  EXPECT_CALL(cm, subscribe());

  std::cout << "Waiting " << response_window_.count() << " ms for event..." << std::endl;
  std::this_thread::sleep_for(response_window_);
  std::cout << "Done waiting\n";
  return;
}

This is an integration test so I actually want the communication to work, and there's no way I can see when I go through the code to actually mock it "normally", i.e.

if I derive proxy_ and override getProxyStatusEvent(), I could return a mock (in this case it would be something complex like CommonAPI::FNV::FNVEvent<PayloadEvent, CommonAPI::Deployable< int32_t, CommonAPI::FNV::IntegerDeployment >, CommonAPI::Deployable< std::string, CommonAPI::FNV::StringDeployment >>, but then that class has its own private signal handler, etc..

So, basically, because the lack of injection, I'd have to create some complex mocks based on internal code that could change at any time.. not a good solution even if possible.

Thus, the solution I wrote above seems to acheive my goals quite simply

• It only tests public api methods
• It's small
• It's flexible

It does seem odd however to create a mock of a dummy class simply to get functions like EXPECT_CALL. Is there a better approach I could be taking?

Also, for context, I'm using GTest again simply for the tools it provides, i.e. test fixtures, command line parsing of test naems, the asserts, etc. This could easily work without GTest.