HippoMocks是线程安全的吗?

时间:2016-07-29 08:48:00

标签: multithreading unit-testing mocking hippomocks

HippoMocks可以在并发测试用例中使用,如下所示:

  1. 同步启动阶段

    • 创建模拟
    • 注册期望等。
  2. 并行测试阶段

    • 在模拟
    • 上调用方法
  3. 同步拆解阶段

    • 验证模拟
  4. 我没有找到关于这个问题的明确声明。在这里和那里提到,模拟非虚方法会破坏线程安全(HippoMocks: is it possible to mock non-virtual methods?)的可能性,或者线程安全可以很容易地添加(遗憾的是没有实际揭示如何)。 GoogleMock非常清楚地回答了这个问题(https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#using-google-mock-and-threads),这样的信息在这里也会有所帮助。

1 个答案:

答案 0 :(得分:2)

不,HippoMocks不是设计为线程安全的。

但是,如果您遵循一些简单的规则,您应该能够在多线程环境中使用模拟:

  1. 在一个线程中按顺序执行设置并使用一个MockRepository。
  2. 在不同的线程中使用不同的模拟应该是安全的。
  3. 当您仅使用OnCall()设置时,在不同线程中使用一个模拟是安全的。将它与OnCall()。Do()结合使用,您应该可以通过这种方式进行大量测试。
  4. 不要使用ExpectCall - 它不安全。
  5. 更新:好的,我做到了。我为多线程编写了一个小测试

    class IMulti
    {
    public:
        virtual void A() =0;
        virtual int B(int a) = 0;
    };
    
    const int THREAD_ITERATIONS = 1000;
    
    static DWORD WINAPI run_thread(LPVOID args)
    {
        IMulti* im = static_cast<IMulti*>(args);
        for (int i=0; i<THREAD_ITERATIONS; i++)
        {
            im->A();
            int result = im->B(22);
            std::cout << "task says: " << i <<" result:" << result <<"\n";
        }
    
        std:: cout << "finished";
    
        return 0;
    }
    
    TEST(check_HippoMocksCanMultiThreadedConcurrentReadingViaOnCall)
    {
        MockRepository mocks;
    
        IMulti* im = mocks.Mock<IMulti>();
    
        mocks.OnCall(im, IMulti::A);
        mocks.OnCall(im, IMulti::B).Return(4711);
    
        HANDLE handles[2];
    
        handles[0] = CreateThread(NULL, 0, &run_thread, im, 0, NULL);
        handles[1] = CreateThread(NULL, 0, &run_thread, im, 0, NULL);
    
        WaitForMultipleObjects(2, handles, TRUE, INFINITE);
    }
    

    结果是,它工作正常。 现在我做了一点点努力,用以下内容替换了第二个OnCall:

    for (int i = 0; i< THREAD_ITERATIONS*2; i++)
    {
        mocks.ExpectCall(im, IMulti::B).Return(i);
    }
    

    在这里,您将随机崩溃(只需使用THREAD_ITERATIONS计数器)。原因是,匹配的期望以某种方式计入Mockrepository。

    正如预期的那样,设置会崩溃崩溃。