Six tutorials in the Google C ++ unit test series-FAQ excerpt

In this section, let's take a look at the gtest FAQ (frequently-asked questions ).

Why should the names of test cases and test instances not contain underscores?

In C ++, the corresponding identifier may be used by the compiler or standard library in the following cases:

1. The identifier that begins with an underscore and follows an upper-case letter.
2. An identifier that contains two consecutive underlines

To avoid identifier conflictsCodeThe IDS of the above two conditions should not be customized. If you use test () or test_f (), the name conflict may occur if you misuse the underline.

When we define the following test instance and perform the testProgramGtest generates a class named testcasename_testname_test for us.

 
Test (testcasename, testname)
 

What if testcasename or testname contains underscores?

• Testcasename starts with "_" (for example, _ Foo). We get _ foo_testname_test
• Testcasename ends with "_" (for example, foo _). We get Foo _ testname_test.
• Testname starts with "_" (for example, _ BAR). We get testcasename _ bar_test
• Testname ends with "_" (for example, BAR _). We get testcasename_bar _ test.

The above naming methods may cause naming conflicts. Therefore, testcasename and testname cannot start or end.

What if the name of testcasename or testname contains underscores?

 
Test (time, flies_like_an_arrow ){...}
Test (time_flies, like_an_arrow ){...}
 

Suppose we have defined two test instances at the same time, oops! In this case, gtest will generate the same class: time_flies_like_an_arrow.

Therefore, to avoid naming conflicts (whether it is a system sign conflict or a custom sign conflict), we recommend that the names of our test cases or test instances do not contain underscores. Of course, this is a suggestion rather than a necessity.

In the firmware test, why do we use the set-up/tear-down function instead of the constructor/destructor?

Do you still remember to test the effect of firmware? By testing the firmware, gtest generates a firmware test object for each test instance. This object provides independent data configuration for each test instance. By writing the setup ()/teardown () function, we can initialize and destroy the data.

For a class, isn't constructor and destructor equally capable of initializing/destroying data? Is it true that gtest provides setup () and teardown? No, no, no. You must use setup ()/teardown () in the following cases:

If an exception is thrown in the destruction operation, teardown () is required because the C ++ destructor cannot throw an exception () call (for the introduction of C ++ destructor throwing an exception, please refer to here ).

Why does the compiler throw an "ignoring return value" warning when I call the run_all_tests () function?

Some gtest users ignore the return value of run_all_tests () and should call it like this:

 
ReturnRun_all_tests ();
 

Instead:

 
Run_all_tests ();
 

The test program checks whether the test instance contained by run_all_tests () is successful Based on the return value of run_all_tests. If the return value is ignored in the main () function, even if a test instance fails to detect, the entire test program is considered to be successfully executed without detection failure.

To avoid misuse of run_all_tests (), GCC will throw a warning for calls that are not returned as main () values. To eliminate this warning, run_all_tests () will be used as main () the Return Value of the function.

How to define multiple test cases for a test firmware

I want to write multiple test instances that correspond to the same test firmware. Do I need to write a new test firmware class for each test instance? Like this:

 
ClassFootest:PublicBasetest {};

Test_f (footest, ABC ){...}
Test_f (footest, DEF ){...}

ClassBartest:PublicBasetest {};

Test_f (bartest, ABC ){...}
Test_f (bartest, DEF ){...}
 

Here, classes footest and bartest do not do anything. We define this only to generate two different test case names.

In fact, typedef can be used more easily to achieve the goal:

 
Typedef basetest footest;

Test_f (footest, ABC ){...}
Test_f (footest, DEF ){...}

Typedef basetest bartest;

Test_f (bartest, ABC ){...}
Test_f (bartest, DEF ){...}
 

For more FAQs about gtest, see here.