TEST_P / INSTANTIATE_TEST_CASE_P don't play kindly with macro expansion

666 views
Skip to first unread message

Ryan Sleevi

unread,
Oct 31, 2011, 11:59:14 PM10/31/11
to Google C++ Testing Framework
I recently ran into this issue while writing a Chromium unit test and
it seemed trivial enough to fix. I'm reporting this here as
http://code.google.com/p/googletest/issues/entry notes to report bugs
here instead of via the bugtracker.

Currently TEST() / TEST_F() expand macro tokens in parameters due to
the fact that TEST() / TEST_F() invoke further macros (specifically,
GTEST_TEST_). This allows code like Chromium to selectively enable/
disable/annotate tests with the following pattern:

#if defined(OS_WIN)
#define MAYBE_SomeTest DISABLED_SomeTest
#else
#define MAYBE_SomeTest SomeTest
#endif

TEST(MyTestClass, MAYBE_SomeTest) {
}

However, TEST_P() / INSTANTIATE_TEST_CASE_P() don't support this
pattern, because the macro is only expanded once before concatenation/
stringizing. Thus, if an argument to these macros is itself a macro,
it won't be expanded by the preprocessor. For example,
TEST_P(MyTestCase, MAYBE_MyTest), the test name is literally
"MAYBE_MyTest", instead of "MyTest" / "DISABLED_MyTest".

This is easily worked around downstream by:
#define WRAPPED_TEST_P(test_case_name, test_name) \
TEST_P(test_case_name, test_name)
#define WRAPPED_INSTANTIATE_TEST_CASE_P(prefix, test_case_name,
generator) \
INSTANTIATE_TEST_CASE_P(prefix, test_case_name, generator)

However, this could easily be fixed upstream by renaming the existing
TEST_P to TEST_P_ / INSTANTIATE_TEST_CASE_P to
INSTANTIATE_TEST_CASE_P_, and then having TEST_P/
INSTANTIATE_TEST_CASE_P refer to those macros.

With this, I can easily use TEST_P(MyTestCase, MAYBE_MyTest) { } as I
can with TEST/TEST_F.

Please let me know if this sounds reasonable. Thanks.

Vlad Losev

unread,
Nov 8, 2011, 12:14:27 PM11/8/11
to Google C++ Testing Framework
This indeed looks reasonable. I've logged this as issue 389.
Reply all
Reply to author
Forward
0 new messages