Go to Google open-source C ++ Unit Test Framework Six-running parameters of the Google test series (gtest)

I. Preface

A test case written using gtest is usually an executable file, so it is very convenient to run. Gtest also provides a series of running parameters (environment variables, command line parameters, orCodeSo that we can effectively control the execution of the case.

Ii. Basic Introduction

As mentioned above, gtest provides three ways to set the running parameters:

1. System Environment Variables

2. Command Line Parameters

3. Specify the flag in the code

There will be a priority issue because three approaches are provided. One principle is that the last one will take effect. However, in general, the ideal priority is:

Command line parameters> flag in code> system environment variables

Why can we write test cases to process these command line parameters? This is because the command line parameters are handed over to gtest in the main function, and gtest is used to solve the problem of command line parameters.

Int _ Tmain ( Int Argc, _ tchar * Argv [])
{
Testing: initgoogletest ( & Argc, argv );
Return Run_all_tests ();
}

 

In this way, we have the ability to receive and respond to gtest command line parameters. If you need to specify the flag in the code, you can use the macro testing: gtest_flag to set the flag. For example, you can use testing: gtest_flag (output) = "XML:"; to set it relative to the command line parameter -- gtest_output. Note that the -- gtest prefix is not required. At the same time, it is recommended to place this sentence before initgoogletest, so that for the same parameter, the command line parameter priority is higher than the specified in the Code.

Int _ Tmain ( Int Argc, _ tchar * Argv [])
{
Testing: gtest_flag (output) =   " XML: " ;
Testing: initgoogletest ( & Argc, argv );
Return Run_all_tests ();
}

 

Finally, let's talk about the first setting method-system environment variables. If you need gtest to set system environment variables, note the following:

1. All system environment variables are in uppercase. For example, for -- gtest_output, the system environment variable in the response is: gtest_output.

2. There is a command line parameter exception, that is, -- gtest_list_tests, which does not accept system environment variables. (Only used to list test case names)

Iii. Parameter List

After learning about the above content, I will summarize and list all the command line parameters here. If you want to obtain detailed command line instructions and run your case directly, enter the command line parameter :/? Or -- help or-help

1. Test Case set

Command Line Parameters	Description
-- Gtest_list_tests	When this parameter is used, the test cases in it will not be executed, but a list of cases will be output.
-- Gtest_filter	Filters test cases and supports wildcard characters. ? Single Character * Any character -Exclude, for example,-A indicates that apart from : Take or. For example, A: B indicates A or B. For example: ./Foo_test: no filtering conditions are specified and all cases are run. ./Foo_test -- gtest_filter = * use wildcard * to run all cases ./Foo_test -- gtest_filter = footest. * run all the "test case name (testcase_name)" footest cases. ./Foo_test -- gtest_filter = * null *: * constructor * Run all cases where "Test Case name (testcase_name)" or "test name (test_name)" contains null or constructor. ./Foo_test -- gtest_filter =-* deathtest. * Run all non-dead test cases. ./Foo_test -- gtest_filter = footest. *-footest. Bar run all the "test case name (testcase_name)" footest cases, except for footest. Bar.
-- Gtest_also_run_disabled_tests	When executing the case, the test case that is set to invalid is also executed. The method for setting an invalid test case is as follows: Add the disabled prefix to the test case name or test name, for example: // Tests that Foo does ABC. Test (footest, disabled_doesabc ){} ClassDisabled_bartest:PublicTesting: test {}; //Tests that bar does XYZ. Test_f (disabled_bartest, doesxyz ){}
-- Gtest_repeat = [count]	Set the number of repeated cases. This is a great feature! For example: -- Gtest_repeat = 1000 execute 1000 times repeatedly, even if an error occurs in the middle. -- Gtest_repeat =-1 unlimited execution times .... -- Gtest_repeat = 1000 -- gtest_break_on_failure repeats 1000 times and stops immediately when the first error occurs. This function is very useful for debugging. -- Gtest_repeat = 1000 -- gtest_filter = foobar repeated execution of 1000 test cases named foobar.

 

2. Test Case output

command line parameters	description
-- gtest_color = (Yes | no | auto)	use colorful colors when outputting command lines. The default value is auto.
-- gtest_print_time	whether to print the execution time of each test case in the output command line. It is not printed by default.
-- gtest_output = xml [: directory_path \ |: file_path]	output the test result to an XML file. 1. -- gtest_output = xml: when no output path is specified, the current path of the case is used by default. 2. -- gtest_output = xml: D: \ specifies the output to a directory 3. -- gtest_output = xml: D: \ Foo. XML specifies the output to D: \ Foo. XML if a specific file path is not specified, gtest does not overwrite the output report each time, but is created with a digital suffix. The output content of XML is described later.

 

3. Handling case exceptions

Command Line Parameters	Description
-- Gtest_break_on_failure	In debug mode, the system stops when the case fails to facilitate debugging.
-- Gtest_throw_on_failure	When the case fails, it is thrown as a C ++ exception.
-- Gtest_catch_exceptions	Whether to capture exceptions. Gtest does not capture exceptions by default. Therefore, if an exception is thrown in your test case, a dialog box may pop up, which is unfriendly, it also hinders the operation of test cases. If you want to skip this box, you can set this parameter. For example, set -- gtest_catch_exceptions to a non-zero number. Note: this parameter is only valid in windows.

Iv. xml report output format <? XML version = "1.0" encoding = "UTF-8" ?>
< Testsuites Tests = "3" Failures = "1" Errors = "0" Time = "35" Name = "Alltests" >
< Testsuite Name = "Mathtest" Tests = "2" Failures = "1" * Errors = "0" Time = "15" >
< Testcase Name = "Addition" Status = "Run" Time = "7" Classname = "" >
< Failure Message = "Value of: add (1, 1)
Actual: 3
Expected: 2" Type = "" />
< Failure Message = "Value of: add (1,-1)
Actual: 1
Expected: 0" Type = "" />
</ Testcase >
< Testcase Name = "Subtraction" Status = "Run" Time = "5" Classname = "" >
</ Testcase >
</ Testsuite >
< Testsuite Name = "Logictest" Tests = "1" Failures = "0" Errors = "0" Time = "5" >
< Testcase Name = "Noncontradiction" Status = "Run" Time = "5" Classname = "" >
</ Testcase >
</ Testsuite >
</ Testsuites >

We can see from the report that the test case name (testcase_name) We previously defined in macros such as test is actually a testsuite name in the XML test report, and the test name (test_name) in the macro) in the XML test report, it is a testcase name, which seems a bit confusing in concept. Let's take a look at it.

When the check point passes, no checkpoint information is output. When the checkpoint fails, detailed Failure Information is output to the failure node.

I found a problem during usage. When I set the -- gtest_filter parameter at the same time, the output XML report still contains information about all test cases, however, the status value of the test cases that are not executed is "notrun ". I previously thought that the output XML report should only contain information about the test cases that I need to run. I wonder whether an XML report can be provided to output only the test cases to be executed. Because when I need to execute one of the 1000 cases, it is difficult to find the case I run in the report. Although I can find it, it is still very troublesome.

V. Summary

This article describes how to use some parameters provided during gtest execution. These parameters are very useful. When writing gtest cases, you must use them. At least what I usually use now is:

1. -- gtest_filter

2. -- gtest_output = xml [: directory_path \ |: file_path]

3. -- gtest_catch_exceptions

Finally, I will summarize several problems I encountered during usage:

1. If -- gtest_filter and -- gtest_output = xml: are used simultaneously, can the XML test report contain only the filtered test case information.

2. sometimes, when I set testing: gtest_flag (catch_exceptions) = 1 in the Code, the results of using -- gtest_catch_exceptions in the command line are slightly different, sometimes some exceptions cannot be caught when the flag method is set in the code, but the command line parameter method is generally not a problem. This is a problem I have encountered. My final solution is to set flag in the Code and input -- gtest_catch_exceptions in the command line parameters. I don't know whether gtest is not stable enough in catch_exceptions, or whether it is my own test case.

Series links:

1. Go to Google's open-source C ++ unit testing framework, one of the Google test series (gtest)-First known as gtest

2. Go to Google open-source C ++ unit test framework Google test series (gtest) 2-Assertions

3. Go to Google open-source C ++ unit test framework Google test series (gtest) 3-event mechanism

4. Go to Google's open-source C ++ unit test framework: four parameters of the Google test series (gtest)

5. go to Google open-source C ++ unit testing framework Google test series (gtest) 5-death Testing

6. go to Google open-source C ++ unit testing framework-Google test series (gtest)-running parameters

7. Go to Google open-source C ++ unit test framework Google test series (gtest) 7-in-depth analysis of gtest

8. go to Google open-source C ++ unit testing framework Google test series (gtest)-build your own unit testing framework