Google test documentation

Question

I recently started using Google tests to help me with testing procedures. It works well, but now my test cases are growing ...

#include <gtest/gtest.h> TEST(MyTest, FirstTest) { // stuff }; TEST(MyTest, SecondTest) { // stuff }; TEST(MyTest, ThirdTest) { // stuff }; int main(int argc, char* argv[]) { ::testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS(); }; 

I would like to create good auto-generated documentation for all my tests, which will be separate from the documentation of my program. For this purpose, I usually use doxygen, but google tests use macros, and it is unclear how doxygen can handle this. More precisely, we have

 #define TEST(test_case_name, test_name)\ GTEST_TEST_(test_case_name, test_name, \ ::testing::Test, ::testing::internal::GetTestTypeId()) 

I tried

 /** * @def TEST(MyTest, FirstTest) * @brief My first test */ TEST(MyTest, FirstTest) { // stuff }; 

But it does not produce any output on doxygen ...

Answer 1

You use @def , but this command is for macro definitions. This command is not followed by the #define , so Doxygen ignores it. Doxygen command for @fn functions, so use this instead.

Also keep in mind that for a Doxygen document to document global functions, the attached file must also be documented.

Answer 2

Apparently, only Kennedy's answer answered your question. Nevertheless, I want to offer a completely different approach.

I use the gtest method for RecordProperty() to create an additional description attribute in the XML of the test log and just pass it a brief description of what the test method performs as a string literal. I created a small macro called TEST_DESCRIPTION , which should be called as the first statement in any test case:

 #define TEST_DESCRIPTION(desc) RecordProperty("description", desc) TEST(MyTest, SecondTest) { TEST_DESCRIPTION("This test does 'stuff'"); // stuff }; 

In addition, I have a simple XSLT transform that creates an HTML test report from the output of an XML test and shows this @description attribute.

The disadvantage of this method is that the description attribute will not be displayed for disabled tests, since RecordProperty() will not be executed for them.

All this was invented, since my boss asked for descriptions of unit test cases, and I didn’t want to describe them in a separate tool (for example, we have Polarion for analyzing requirements, and you can also describe test cases there), because this, likely to become inconsistent quickly.

But perhaps doxygen may provide additional benefits, as it is able to display call links from your testing methods.