-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add public interface for XmlUnitTestResultPrinter #4402
base: main
Are you sure you want to change the base?
Add public interface for XmlUnitTestResultPrinter #4402
Conversation
Allowing custom gtest_main implementations to instantiate the XmlUnitTestResultPrinter with either a given file path or any other kind of std::ostream to write to. This is useful for e.g. embedded cases where an XML report is still wanted, but not file system is available, by instantiating with a std::stringstream and delivering the data via any custom mean. Related to google#1930
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Make XmlUnitTestResultPrinter usable when GTEST_HAS_FILE_SYSTEM=0, though this should probably be another class extending XmlUnitTestResultPrinter instead - but feels like the preprocessor feature flag logic matches the existing code base.
For some context, this is an example how that might be used: (this is not merged to my main yet, so I hope that commit hash stays non-GC'd long enough to be useful ^^') |
Making this a public interface generally sounds good to me. |
void ListTestsMatchingFilter(const std::vector<TestSuite*>& test_suites); | ||
|
||
private: | ||
#if GTEST_HAS_FILE_SYSTEM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we could have a separate interface for "output sink"?
Perhaps we could even turn XmlUnitTestResultPrinter
into an abstract class, and have a FileXmlUnitTestResultPrinter
vs. a StreamXmlUnitTestResultPrinter
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think about having XmlUnitTestResultPrinter
be the one that prints to a stream and FileXmlUnitTestResultPrinter
inheriting from that, opening a file stream to give to the base?
I don't think the additional abstract base, from which both Stream..
and File..
inherit is useful here
thank you for that feedback - sorry for getting back here this late, will look into tidying this up, hopefully soon :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just want to see (XmlUnitTestResultPrinter)
Allowing custom gtest_main implementations to instantiate the XmlUnitTestResultPrinter with either a given file path or any other kind of std::ostream to write to.
This is useful for e.g. embedded cases where an XML report is still wanted, but not file system is available, by instantiating with a std::stringstream and delivering the data via any custom mean.
Related to #1930
This clearly needs some more polishing (e.g. docs in the header), but before I'll do the chores, I'd like some feedback :)