How strict is the rule of no-underscores in TEST() names?

Question

The document of Google Test says:

TEST() arguments go from general to specific. The first argument is the name of the test case, and the second argument is the test's name within the test case. Both names must be valid C++ identifiers, and they should not contain underscore (_).

It surprises me because I usually name the tests with underscores (instead of CamelCase), e.g:

TEST(foo_test, should_fail_if_either_arg_negative) {

It seems that the tests are doing well.

My question is, how strict is this no-underscore rule? What could happen if I break it?

Answer 1

From one Vlad Losev (see this discussion) when he was actually working at Google on the Test product:

This restriction was put in place to afford us some flexibility in implementing tests. One day we may decide to change the implementation and rely on this assumption. [Then] the user code that doesn't conform to it may end up broken. So please try keeping your test case names free of underscores.

So, even if you take the standards-language approach where rules are indicated by must and shall while guidelines are indicated by should, you'd be advised to follow said guidelines just to be more certain that your code won't break in future.

Later on in that discussion, it's also made clear that certain arguments with underscores may result in names beginning with an underscore or containing two or more consecutive underscores, both of which are technically "invalid" in user code (they're reserved for the implementation).

Answer 2

Google Test answers this question in its FAQ. In short,

• Test names starts or ends with _ could easily generate invalid identifiers.

• Test names that have _ in the middle are fine in most cases. However,

  TEST(Time, Flies_Like_An_Arrow) { ... }
  TEST(Time_Flies, Like_An_Arrow) { ... }
  

  will generate the same names.

For simplicity, the rule is set more constraining than necessary, and it also gives Google Test some room in case its implementation needs to change in the future.

So, in conclusion:

If you violate the rule, there may not be immediately consequences, but your test may (just may) break with a new compiler (or a new version of the compiler you are using) or with a new version of Google Test. Therefore it's best to follow the rule.