Question

我在我继承的项目中进行了测试，看起来与此类似

std::string value("test string");
const char * buffer = value.c_str();
EXPECT_CALL(object, foo(_,_,buffer, buffer.size(), _)).WillOnce(Return(0));
bar(value);

缓冲区是指向一串数据的char *。我已经插入了像对象这样的虚拟值，只是为了关注使用EXPECT_CALL的问题。在此EXPECT_CALL之后，调用一个方法栏，它将原始字符串值作为参数，然后在方法中使用从原始字符串值构建的缓冲区调用foo。

此测试正在处理此项目的Mac版本，但在Windows版本上失败。它似乎是比较两个char指针的指针地址，预期和实际，然后因为它们不同而失败。方法foo肯定在bar中调用。

如果此测试方法（EXPECT_CALL）比较指针地址而不是该指针处的数据，那么Mac上的测试也不应该失败吗？

在使用EXPECT_CALL和指针时，是否有人熟悉Mac和Windows之间的明显区别？

我看到的错误

unknown file: error:
Unexpected mock function call - returning default value.
    Function call: foo(NULL, 1, 0000000001CAAE78 pointing to "test string", 11,_)
           Returns: 0
Google Mock tried the following 1 expectation, but it didn't match:

test.cpp(235): EXPECT_CALL(object, foo(_,_,buffer,buffer.size(),_)...
  Expected arg #2: is equal to 0000000001CAAF78 pointing to "test string"
           Actual: 0000000001CAAE78 pointing to "test string"
         Expected: to be called once
           Actual: never called - unsatisfied and active
   test.cpp(235): error: Actual function call count doesn't match EXPECT_CALL(object, foo(_,_,buffer, buffer.size(), _)...
     Expected: to be called once

我修改此错误只是为了反映我的例子。

提前感谢您的帮助。

Answer 1

Mac和Mac之间似乎没有任何明显的差异。关于EXPECT_CALL的Windows。我想在string实现之间可能存在差异，以及编译器如何处理常量字符串，这可以解释行为的差异。

但是，我希望通过地址比较来匹配指针参数。要比较值，您应该使用特定的Matchers。特别是对于您的情况，有多种String Matchers可供选择，包括StrEq用于字符串相等，您可以将其用作：

EXPECT_CALL(object, foo(_,_,testing::StrEq(buffer),value.size(),_))
  .WillOnce(Return(0));

Answer 2

这在Windows中有效的原因是因为MSVC实现了字符串池（/GF）。见这里：

http://msdn.microsoft.com/en-us/library/s0s0asdt.aspx

那为什么这会让它发挥作用呢？因为gmock正在比较指针地址，并且当你有2个相同的常量字符串时，字符串池将使它们具有相同的值。关闭此编译器选项并观察它失败。

GTest和GoogleMock EXPECT_CALL在Windows中失败，使用char * param在Mac上传递

2 个答案: