Google Test断言ASSERT_*
应该以{{1}}的形式使用,其中第一个参数是预期值,第二个参数是实际值。但是我经常在现有的代码库中看到这些参数与此代码中的相反:
ASSERT_EQ(expected, actual)
这几乎没问题,但是在测试失败的情况下会产生一些奇怪的错误消息,例如:" TEST(test, test)
{
ASSERT_EQ(foo(), 1);
}
的结果是预期的,但实际上是foo()
" 。这似乎是一个小问题,但有没有办法在编译时强制正确的预期和实际顺序?
答案 0 :(得分:1)
你可以使用谷歌模拟的Hamcrest匹配器:
ASSERT_THAT(foo(), Eq(1) );
这提高了参数的可读性和强制顺序。
答案 1 :(得分:0)
以下是两个选项:
您的预期价值仅为文字吗?如果是,您可以编写自己的宏来检查预期值是否为文字。有关如何执行此操作的建议,请参阅this question。
介绍命名约定。让团队中的每个人都将期望值放在名为expected_Foo
的变量中。像这样添加一个新的宏:
#define MyAssertion(expectedVal, actual) ASSERT_EQ(expected_##expectedVal, actual)
auto expectedFoo = foo();
MyAssertion(Foo, 1);
答案 2 :(得分:0)
对我来说,避免有线消息的最佳方法是从一开始就正确执行!
好的,这对错误编写的现有测试没有帮助,但是在我所知道的所有单元测试框架(C#,Java,C ++)中,它始终是相同的:
ASSERT(EXPECTED, ACTUAL)
如果另一个开发人员正在阅读您的测试,他应该依靠您来确保您过去做的正确。