[英]Expecting googlemock calls from another thread
使用谷歌模擬對象編寫(谷歌)測試用例並期望從測試中的類控制的另一個線程調用 EXPECT_CALL() 定義的最佳方法是什么? 在觸發調用序列后簡單地調用 sleep() 或類似方法並不合適,因為它可能會減慢不必要的測試,並且可能不會真正達到計時條件。 但是以某種方式完成測試用例必須等到模擬方法被調用。 任何人的想法?
下面是一些代碼來說明這種情況:
Bar.hpp(被測類)
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(摘錄):
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);
}
}
測試代碼(摘錄,到目前為止 FooInterfaceMock 的定義沒有什么特別之處):
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();
}
沒有 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
啟用 sleep() 的測試結果:
[==========] 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.
我想避免使用 sleep(),最好的情況是根本不需要更改 Bar 類。
Fraser 的回答激發了我使用 GMock 專用 Action 的簡單解決方案。 GMock 使快速編寫此類操作變得非常容易。
這是代碼(摘自 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();
}
請注意,相同的原則適用於任何其他類型的信號量實現,如boost::interprocess::interprocess_semaphore
。 我用它來測試我們的生產代碼,這些代碼使用它自己的操作系統抽象層和信號量實現。
使用 lambdas,你可以做一些類似的事情(我在評論中加入了 boost 等價物):
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();
}
如果您不能使用 lambda,我想您可以改用boost::bind
。
所以我喜歡這些解決方案,但認為有一個承諾可能會更容易,我不得不等待我的測試啟動:
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)));
弗雷澤的回答也啟發了我。 我使用了他的建議,它奏效了,但后來我找到了另一種沒有條件變量的方法來完成同樣的工作。 您需要添加一個方法來檢查某些條件,並且需要一個無限循環。 這也假設您有一個單獨的線程來更新條件。
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();
}
在 πάντα ῥεῖ 解決方案提出后,我設法解決了這個問題,但使用 std::condition_variable。 該解決方案與 Fraser 提出的方案略有不同,也可以使用 lambda 進行改進。
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));
}
這里似乎互斥鎖只是為了滿足條件變量。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.