2011年1月11日 Joey Oravec <joeyoravec@gmail.com>:
> Sure, I agree it would be way more useful to print that way. I can work on
> it, but I wonder if you could explain how to get from a TestInfo to the
> corresponding Test*. In file gtest-param-util.h in
> ParameterizedTestCaseInfo::RegisterTests() we see:
>
>  std::string comment = "GetParam() = " + PrintToString(*param_it);
>
> which generates the string, then calls MakeAndRegisterTestInfo which records
> the comment string. Similarly in file gtest-internal.h in
> TypeParameterizedTest::Register() we see:
>
>  String::Format("TypeParam = %s", GetTypeName<Type>().c_str())
>
> where it's also recording a comment string. Much later when gtest is
> printing results, it's operating on a TestInfo object which contains these
> strings. Of course I printed these in this first draft because they're
> readily accessible.
>
> Regarding your proposal, for a given TestInfo we'd want to know if it was
> value-parameterized or type-parameterized and print the parameter.
Yes.
> I was
> assuming I could follow some pointer from the TestInfo to the Test* since
> the (derived) Test object records the parameter as a member. But I only saw
> the factory... Isn't there some chain of pointers that I could follow to get
> from a TestInfo to the corresponding Test* object?
No. To isolate the tests, gtest only creates a Test object after the
previous test method has finished and the previous Test object has
been deleted. At any time, there is at most one Test object alive.
Since the XML report is generated at the end of the test run, all Test
objects have been deleted by that time, so you cannot get a pointer to
any of them, regardless of where you look.
> My alternative is to record the parameter information as a string in
> TestInfo when MakeAndRegisterTestInfo is called. This would probably work,
Sounds good.
> but seems preferable for the function that's doing the printing (like
> OutputXmlTestInfo or the pretty result printer) to access the member
> directly so it can render the string exactly how it wants.
Even if the printer function has access to the Test object, how can it
extract the value parameter or type parameter from the object? The
only way to get that information is to ask the Test object to provide
it in an untyped format (i.e. the Test object must do the rendering),
as types are not first-class values in C++. So I don't think it's
possible to do what you want.
> -joey
>
> 2011年1月10日 Zhanyong Wan (λx.x x) <wan@google.com>
>>
>> I would like to distinguish between value- and type- parameterized
>> tests. For the former, I want an attribute like
>>
>> value_param="&quot;meeny&quot;"
>>
>> (note the '&quot;' and the lack of "GetParam() = ").
>>
>> For the latter, I want the attribute to look like:
>>
>> type_param="int"
>>
>> Would you like to implement that? Thanks,
>>
>> 2010年12月28日 Zhanyong Wan (λx.x x) <wan@google.com>:
>> > 2010年12月28日 Joey Oravec <joeyoravec@gmail.com>:
>> >> No idea since I've never used Hudson. I wouldn't expect trouble since
>> >> gtest
>> >> already has ReportProperty() which writes attributes in the same place.
>> >> As I
>> >
>> > Actually I have no idea whether ReportProperty() works with Hudson. ;)
>> >
>> >> got deeper into this I noticed:
>> >>
>> >> - the XML doesn't describe the relation among value-parameterized
>> >> tests.
>> >> Without hierarchy you have to parse strings to understand which tests
>> >> are
>> >> related (like FooTest/0 .. FooTest/N).
>> >
>> > But these tests will be nested in the same parent testcase element, no?
>> >
>> >> - the <failure> tag returns the block of text, but could return finer
>> >> grained details like filename, line number, and the type (like
>> >> kNonFatalFailure)
>> >>
>> >> ...and there's probably more. An alternate proposal is that we maintain
>> >> an
>> >> xml-junitreport logger that writes the format strictly, plus an
>> >> xml-gtest
>> >> logger that is flexible to log every detail that gtest collects. This
>> >> seems
>> >> manageable now that there's an event listener API.
>> >
>> > I'd prefer not to create another XML format if we could avoid it. If
>> > you really care about this, I'd suggest to lobby the jUnit people to
>> > extend the format such that we don't diverge.
>> >
>> >>
>> >> -joey
>> >>
>> >> 2010年12月28日 Zhanyong Wan (λx.x x) <wan@google.com>
>> >>>
>> >>> Hi Joey,
>> >>>
>> >>> Thanks for contributing. Do you know if this works with popular
>> >>> continuous build systems like Hudson?
>> >>>
>> >>> I'm discussing this with our internal teams to make sure it doesn't
>> >>> break existing tools that consume the XML.
>> >>>
>> >>> On Mon, Dec 27, 2010 at 12:49 PM,  <joeyoravec@gmail.com> wrote:
>> >>> > Reviewers: ,
>> >>> >
>> >>> > Description:
>> >>> > Please consider this change which improves gtest's XML output to
>> >>> > include
>> >>> > the value for value-parameterized tests.
>> >>> >
>> >>> > Value-parameterized tests have somewhat opaque names like:
>> >>> >
>> >>> > InstantiationName/FooTest.DoesBlah/0 for "meeny"
>> >>> > InstantiationName/FooTest.DoesBlah/1 for "miny"
>> >>> > InstantiationName/FooTest.DoesBlah/2 for "moe"
>> >>> >
>> >>> > The existing pretty result printer prints the value, using
>> >>> > operator<<,
>> >>> > for any failed test like:
>> >>> >
>> >>> > [ FAILED ] InstantiationName/FooTest.DoesBlah/0, where GetParam()
>> >>> > =
>> >>> > meeny
>> >>> >
>> >>> > This proposal prints the same information in the XML output. The
>> >>> > value
>> >>> > is printed as an attribute "param" of the testcase like:
>> >>> >
>> >>> > <testcase
>> >>> > name="DoesBlah/0"
>> >>> > status="run"
>> >>> > time="x.xxx"
>> >>> > classname="InstantiationName/FooTest"
>> >>> > param="GetParam() = meeny" />
>> >>>
>> >>> Hmm, we probably want to get rid of the "GetParam() = " prefix from
>> >>> the
>> >>> value.
>> >>>
>> >>> >
>> >>> > There's another TestInfo member test_case_comment(). It's unclear if
>> >>> > that member ever contains useful information. It's also unclear if
>> >>> > that
>> >>> > would be associated with the <testsuite /> or something else.
>> >>>
>> >>> This is used for type-parameterized tests and typed tests.
>> >>>
>> >>> > Please review this at http://codereview.appspot.com/3773042/
>> >>> >
>> >>> > Affected files:
>> >>> > gtest.cc
>> >>> >
>> >>> >
>> >>> > Index: gtest.cc
>> >>> > ===================================================================
>> >>> > --- gtest.cc  (revision 528)
>> >>> > +++ gtest.cc  (working copy)
>> >>> > @@ -3210,6 +3210,23 @@
>> >>> >      << "\" classname=\"" <<
>> >>> > EscapeXmlAttribute(test_case_name).c_str()
>> >>> >      << "\"" << TestPropertiesAsXmlAttributes(result).c_str();
>> >>> >
>> >>> > + // Value-parameterized tests have opaque names like
>> >>> > + // InstantiationName/FooTest.DoesBlah/0 for "meeny"
>> >>> > + // InstantiationName/FooTest.DoesBlah/1 for "miny"
>> >>> > + // InstantiationName/FooTest.DoesBlah/2 for "moe"
>> >>> > + //
>> >>> > + // Print the value. This will look like
>> >>> > + // GetParam() = "meeny"
>> >>> > + // The string is generated by operator<< for the parameter's type
>> >>> > + //
>> >>> > + if (test_info.comment()[0] == '0円') {
>> >>> > +  // no comment, do nothing
>> >>> > + } else {
>> >>> > +  *stream << " param=\""
>> >>> > +      << EscapeXmlAttribute(test_info.comment()).c_str()
>> >>> > +      << "\"";
>> >>> > + }
>> >>> > +
>> >>> >  int failures = 0;
>> >>> >  for (int i = 0; i < result.total_part_count(); ++i) {
>> >>> >   const TestPartResult& part = result.GetTestPartResult(i);
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Zhanyong
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Zhanyong
>> >
>>
>>
>>
>> --
>> Zhanyong
>
>
-- 
Zhanyong