Expecting googlemock calls from another thread
Asked Answered
E

5

14

What will be the best way to write (google) test cases using a google mock object and expect the EXPECT_CALL() definitions being called from another thread controlled by the class in test? Simply calling sleep() or alike after triggering the call sequences doesn't feel appropriate since it may slow down testing unnecessary and may not really hit the timing conditions. But finishing the test case somehow has to wait until the mock methods have been called. Ideas anyone?

Here's some code to illustrate the situation:

Bar.hpp (the class under test)

class Bar
{
public:

Bar(IFooInterface* argFooInterface);
virtual ~Bar();

void triggerDoSomething();
void start();
void stop();

private:
void* barThreadMethod(void* userArgs);
void endThread();
void doSomething();

ClassMethodThread<Bar> thread; // A simple class method thread implementation using boost::thread
IFooInterface* fooInterface;
boost::interprocess::interprocess_semaphore semActionTrigger;
boost::interprocess::interprocess_semaphore semEndThread;
bool stopped;
bool endThreadRequested;
};

Bar.cpp (excerpt):

void Bar::triggerDoSomething()
{
    semActionTrigger.post();
}

void* Bar::barThreadMethod(void* userArgs)
{
    (void)userArgs;
    stopped = false;
    do
    {
        semActionTrigger.wait();
        if(!endThreadRequested && !semActionTrigger.try_wait())
        {
            doSomething();
        }
    } while(!endThreadRequested && !semEndThread.try_wait());
    stopped = true;
    return NULL;
}

void Bar::doSomething()
{
    if(fooInterface)
    {
        fooInterface->func1();
        if(fooInterface->func2() > 0)
        {
            return;
        }
        fooInterface->func3(5);
    }
}

The testing code (excerpt, nothing special in the definition of FooInterfaceMock so far):

class BarTest : public ::testing::Test
{
public:

    BarTest()
    : fooInterfaceMock()
    , bar(&fooInterfaceMock)
    {
    }

protected:
    FooInterfaceMock fooInterfaceMock;
    Bar bar;
};

TEST_F(BarTest, DoSomethingWhenFunc2Gt0)
{
    EXPECT_CALL(fooInterfaceMock,func1())
        .Times(1);
    EXPECT_CALL(fooInterfaceMock,func2())
        .Times(1)
        .WillOnce(Return(1));

    bar.start();
    bar.triggerDoSomething();
    //sleep(1);
    bar.stop();
}

Test results without sleep():

[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from BarTest
[ RUN      ] BarTest.DoSomethingWhenFunc2Gt0
../test/BarTest.cpp:39: Failure
Actual function call count doesn't match EXPECT_CALL(fooInterfaceMock, func2())...
         Expected: to be called once
           Actual: never called - unsatisfied and active
../test/BarTest.cpp:37: Failure
Actual function call count doesn't match EXPECT_CALL(fooInterfaceMock, func1())...
         Expected: to be called once
           Actual: never called - unsatisfied and active
[  FAILED  ] BarTest.DoSomethingWhenFunc2Gt0 (1 ms)
[----------] 1 test from BarTest (1 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BarTest.DoSomethingWhenFunc2Gt0

 1 FAILED TEST
terminate called after throwing an instance of         'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
Aborted

Test results with sleep() enabled:

[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from BarTest
[ RUN      ] BarTest.DoSomethingWhenFunc2Gt0
[       OK ] BarTest.DoSomethingWhenFunc2Gt0 (1000 ms)
[----------] 1 test from BarTest (1000 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1000 ms total)
[  PASSED  ] 1 test.

I want to avoid the sleep(), in best case without need to change the Bar class at all.

Ellipsoid answered 26/5, 2012 at 14:36 Comment(0)
E
16

Fraser's answer inspired me for a simple solution using a GMock specialized Action. GMock makes it very easy to quickly write such Actions.

Here's the code (excerpt from BarTest.cpp):

// Specialize an action that synchronizes with the calling thread
ACTION_P2(ReturnFromAsyncCall,RetVal,SemDone)
{
    SemDone->post();
    return RetVal;
}

TEST_F(BarTest, DoSomethingWhenFunc2Gt0)
{
    boost::interprocess::interprocess_semaphore semDone(0);
    EXPECT_CALL(fooInterfaceMock,func1())
        .Times(1);
    EXPECT_CALL(fooInterfaceMock,func2())
        .Times(1)
        // Note that the return type doesn't need to be explicitly specialized
        .WillOnce(ReturnFromAsyncCall(1,&semDone));

    bar.start();
    bar.triggerDoSomething();
    boost::posix_time::ptime until = boost::posix_time::second_clock::universal_time() +
            boost::posix_time::seconds(1);
    EXPECT_TRUE(semDone.timed_wait(until));
    bar.stop();
}

TEST_F(BarTest, DoSomethingWhenFunc2Eq0)
{
    boost::interprocess::interprocess_semaphore semDone(0);
    EXPECT_CALL(fooInterfaceMock,func1())
        .Times(1);
    EXPECT_CALL(fooInterfaceMock,func2())
        .Times(1)
        .WillOnce(Return(0));
    EXPECT_CALL(fooInterfaceMock,func3(Eq(5)))
        .Times(1)
        // Note that the return type doesn't need to be explicitly specialized
        .WillOnce(ReturnFromAsyncCall(true,&semDone));

    bar.start();
    bar.triggerDoSomething();
    boost::posix_time::ptime until = boost::posix_time::second_clock::universal_time() +
            boost::posix_time::seconds(1);
    EXPECT_TRUE(semDone.timed_wait(until));
    bar.stop();
}

Note the same principle will work well for any other kind of semaphore implementation as boost::interprocess::interprocess_semaphore. I'm using it for testing with our production code that uses it's own OS abstraction layer and semaphore implementation.

Ellipsoid answered 28/5, 2012 at 10:36 Comment(2)
The timed_wait() will not work properly if you use local_time() when calculating until. You should use universal_time() instead.Philhellene
@Philhellene THX for the hint. The real example I have uses our own OSAL, I put the boost functions here as a concise surrogate.Alcaic
S
7

Using lambdas, you could do something like (I have put boost equivalents in comments):

TEST_F(BarTest, DoSomethingWhenFunc2Gt0)
{
    std::mutex mutex;                  // boost::mutex mutex;
    std::condition_variable cond_var;  // boost::condition_variable cond_var;
    bool done(false);

    EXPECT_CALL(fooInterfaceMock, func1())
        .Times(1);
    EXPECT_CALL(fooInterfaceMock, func2())
        .Times(1)
        .WillOnce(testing::Invoke([&]()->int {
            std::lock_guard<std::mutex> lock(mutex);  // boost::mutex::scoped_lock lock(mutex);
            done = true;
            cond_var.notify_one();
            return 1; }));

    bar.start();
    bar.triggerDoSomething();
    {
      std::unique_lock<std::mutex> lock(mutex);               // boost::mutex::scoped_lock lock(mutex);
      EXPECT_TRUE(cond_var.wait_for(lock,                     // cond_var.timed_wait
                                    std::chrono::seconds(1),  // boost::posix_time::seconds(1),
                                    [&done] { return done; }));
    }
    bar.stop();
}

If you can't use lambdas, I imagine you could use boost::bind instead.

Sinnard answered 27/5, 2012 at 19:23 Comment(1)
Hi Fraser, Thanks a lot for your answer. Unfortunately in the environment where I want to write the tests finally I have neither lambdas, nor boost available (I've been using boost only for quickly writing a demo of the problem). Nevertheless your answer inspired me for a simple solution using a specialized GMock Action (kind of surrogate for a lambda).Alcaic
M
4

So I liked these solutions, but thought it might be easier with a promise, I had to wait for my test to startup:

std::promise<void> started;
EXPECT_CALL(mock, start_test())
    .Times(1)
    .WillOnce(testing::Invoke([&started]() {
        started.set_value();
    }));
system_->start();
EXPECT_EQ(std::future_status::ready, started.get_future().wait_for(std::chrono::seconds(3)));
Mooney answered 9/7, 2019 at 11:26 Comment(0)
V
0

Fraser's answer inspired me also. I used his suggestion, and it worked, but then I found another way to accomplish the same without the condition variable. You'll need to add a method to check some condition, and you'll need an infinite loop. This is also assuming that you have a separate thread that will update the condition.

TEST_F(BarTest, DoSomethingWhenFunc2Gt0)
{
    EXPECT_CALL(fooInterfaceMock,func1()).Times(1);
    EXPECT_CALL(fooInterfaceMock,func2()).Times(1).WillOnce(Return(1));

    bar.start();
    bar.triggerDoSomething();

    // How long of a wait is too long?
    auto now = chrono::system_clock::now();
    auto tooLong = now + std::chrono::milliseconds(50); 

    /* Expect your thread to update this condition, so execution will continue
     * as soon as the condition is updated and you won't have to sleep
     * for the remainder of the time
     */
    while (!bar.condition() && (now = chrono::system_clock::now()) < tooLong) 
    {
        /* Not necessary in all cases, but some compilers may optimize out
         * the while loop if there's no loop body.
         */
        this_thread::sleep_for(chrono::milliseconds(1));
    }

    // If the assertion fails, then time ran out.  
    ASSERT_LT(now, tooLong);

    bar.stop();
}
Vick answered 27/10, 2016 at 14:30 Comment(1)
I don't think that replacing the condition variable by active waiting (i.e. the infinite loop) is a good tradeoff. I usually believe it is the opposite: removing active waiting by using a condition variable is a good idea. What is your opinion on that?Galbreath
G
0

I've managed to solve the issue after proposed by πάντα ῥεῖ solution, but with std::condition_variable. The solution become a bit different than Fraser proposed and also may be improved with lambdas.

ACTION_P(ReturnFromAsyncCall, cv)
{
    cv->notify_all();
}

...

TEST_F(..,..)
{

   std::condition_variable cv;
   ...
   EXPECT_CALL(...).WillRepeatedly(ReturnFromAsyncCall(&cv));

   
   std::mutex mx;
   std::unique_lock<std::mutex> lock(mx);
   cv.wait_for(lock, std::chrono::seconds(1));
   
 }

Seems mutex here just to sutisfy condition variable.

Giorgione answered 31/7, 2020 at 15:33 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.