1 Introduction
Use gtest written test case itself is usually an executable file, so running very convenient. At the same time, gtest also provides us with a range of operating parameters (environment variables, command-line parameters or code specified), so that we can perform some of the cases of effective control. For operating parameters, gtest provides a way of three settings:
1) system environment variables
2) command line parameters
3) designated FLAG tag
Because there are three kinds of ways, so there exists a priority issue. Principle is: the last set that will take effect . Ideally priorities are: command line arguments> tag specifies the FLAG> system environment variable .
The reason line parameters to write test cases are able to deal with these commands: In the main function, the command-line arguments to the gtest, by the gtest to get the command-line parameters of the problem . That is: testing :: InitGoogleTest (& argc, argv); this has the ability to receive and respond gtest command line parameters.
If you need to specify FLAG in your code, you can use this macro to testing :: GTEST_FLAG set. For example with respect to the command line parameters --gtest_output, use testing :: GTEST_FLAG (output) = " xml:"; set. This eliminates the need plus --gtest prefix. Also, before the sentence is preferably placed InitGoogleTest, so that for the same parameters can be, higher priority than the command-line parameters specified in the code.
2, the system environment variable settings
2.1 Notes
1) system environment variables in all caps, such as for --gtest_output, system environment variable response is: GTEST_OUTPUT
2) has a command-line argument exception, that is --gtest_list_tests, it is not accepted by the system environment variables. (Just to name a list of test cases)
3, the parameter list
Want to get a detailed explanation of the command line, run directly your case, enter the command line parameters:? / Or --help or -help.
3.1 test case set
Description command-line parameters
when --gtest_list_tests use this parameter will not be performed inside the test case, but a case of the output list.
--gtest_filter execution of test cases to filter support wildcard
? single character
* any character
- excluded, except as -a represents a
: or, as a: b represents a or b
Example:
./foo_test not specified filter criteria, running all the cases
./foo_test --gtest_filter = * use the wildcard * indicates running all the cases
./foo_test --gtest_filter = FooTest * Run all "test case name (testcase_name)" is. FooTest case
./foo_test --gtest_filter = * Null *: * Constructor * run all "test case name (testcase_name)" or "test name (test_name)" contains Null or Constructor's case.
./foo_test --gtest_filter = - * DeathTest * All non-fatal run test cases.
./foo_test --gtest_filter = FooTest * -. FooTest.Bar run all "test case name (testcase_name)" as a case FooTest, but in addition to this case FooTest.Bar
When --gtest_also_run_disabled_tests execution cases, as well as execution is invalidated test case. About setting up test cases ineffective methods are:
add DISABLED prefix in the name of the test case or test name, such as:
// Tests that Foo does Abc.
TEST(FooTest, DISABLED_DoesAbc) { }
class DISABLED_BarTest : public testing::Test { };
// Tests that Bar does Xyz.
TEST_F(DISABLED_BarTest, DoesXyz) { }
--gtest_repeat = [COUNT] Set the number of such cases repeat run:.
--gtest_repeat 1000 = Repeat 1000, even though the middle of error.
--gtest_repeat = -1 Unlimited performed
--gtest_repeat = 1000 --gtest_break_on_failure repeatedly performed 1,000 times, and stop immediately when the first error occurs. This function is very useful for debugging.
--gtest_repeat = 1000 --gtest_filter = FooBar repeat the 1000 test case for the name of the case FooBar.
3.2 test case output
命令行参数 说明
--gtest_color=(yes|no|auto) 输出命令行时是否使用一些五颜六色的颜色。默认是auto。
--gtest_print_time 输出命令行时是否打印每个测试案例的执行时间。默认是不打印的。
--gtest_output=xml[:DIRECTORY_PATH\|:FILE_PATH] 将测试结果输出到一个xml中。
1.--gtest_output=xml: 不指定输出路径时，默认为案例当前路径。
2.--gtest_output=xml:d:\ 指定输出到某个目录
3.--gtest_output=xml:d:\foo.xml 指定输出到d:\foo.xml
如果不是指定了特定的文件路径，gtest每次输出的报告不会覆盖，而会以数字后缀的方式创建。xml的输出内容后面介绍吧。
3.3 对案例的异常处理
命令行参数 说明
--gtest_break_on_failure 调试模式下，当案例失败时停止，方便调试
--gtest_throw_on_failure 当案例失败时以C++异常的方式抛出
--gtest_catch_exceptions 只在Windows下有效。是否捕捉异常。gtest默认是不捕捉异常的，因此假如你的测试案例抛了一个异常，很可能会弹出一个对话框，这非常的不友好，同时也阻碍了测试案例的运行。如果想不弹这个框，可以通过设置这个参数来实现。如将--gtest_catch_exceptions设置为一个非零的数。
3.4 XML报告输出格式
<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="17" failures="4" disabled="0" errors="0" time="0.575" name="AllTests">
<testsuite name="CTest" tests="1" failures="0" disabled="0" errors="0" time="0.012">
<testcase name="Init" status="run" time="0.011" classname="CTgPluginManager" />
</testsuite>
<testsuite name="CGtestFile" tests="5" failures="1" disabled="0" errors="0" time="0.016">
<testcase name="UnInit" status="run" time="0" classname="CGtestFile" />
<testcase name="Start" status="run" time="0" classname="CGtestFile" />
<testcase name="Stop" status="run" time="0" classname="CGtestFile" />
<testcase name="GetVersion" status="run" time="0" classname="CGtestFile" />
<testcase name="QueryClientObject" status="run" time="0.009" classname="CGtestFile">
<failure message="Value of: nRet
 Actual: false
Expected: true" type=""><![CDATA[e:\xxx\cglobalevent.cpp:51
Value of: nRet
Actual: false
Expected: true]]></failure>
</testcase>
</testsuite>
</testsuites>
从报告里可以看出，我们之前在TEST等宏中定义的测试案例名称(testcase_name)在xml测试报告中其实是一个testsuite name，而宏中的测试名称(test_name)在xml测试报告中是一个testcase name。
当检查点通过时，不会输出任何检查点的信息。当检查点失败时，会有详细的失败信息输出来failure节点。当同时设置了--gtest_filter参数时，输出的xml报告中还是会包含所有测试案例的信息，只不过那些不被执行的测试案例的status值为“notrun”。
4、总结
1）比较常用的运行参数是
--gtest_filter
--gtest_output=xml[:DIRECTORY_PATH\|:FILE_PATH]
--gtest_catch_exceptions
能通过命令行参数的方式设置最好使用命令行参数设置，可以避免一些使用代码设置的问题。