-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Logging macros scoped to test case instead of current scope #983
Comments
There are couple requests for the old |
If I'm using latest on master as of today, does your recommendation still stand? I noticed commit 7e4038d which is similar to the |
Also is it intended that I implement |
Yes, current master properly redirects IIRC you need to implement |
So all I need to do is implement |
Actually I think all you need to do is to take your favourite reporter and enable iostream redirection if it isn't (so if you are using compact reporter, you need to enable it, if you are using xml reporter, it already is) and make your logging adapter write to |
Can you give me an example? I started implementing
And to set it up I'm trying:
But it looks like you don't add reporters this way. You have to use the
It's not clear to me how to do what you're saying. I'm not that familiar with the internals of Catch and most of this doesn't seem documented in the reference document. |
Ok |
I can't get access to the reporter object that Catch seems to be creating internally, so I can't connect it to my Sink. Not sure how to do this. |
Ok, consider the following test file as an example
And this modified console reporter
when I compile the test file against my modified catch and run it, I get the following output
Note that the writes for the passing test case is not written out, only for the failing one. If you have Obviously this isn't complete solution, for example it has only test case level granularity, instead of assertion level granularity, but it should be a good enough starting point. You could further improve it by abusing Listeners, by storing the logs instead of printing them, and use your own listener to tell your sink to either send the output to standard stream, or dump it entirely. |
I'll try your example. How does |
What reporter are you using? |
I normally do not mess with reporters explicitly. Based on the code this means "console" becomes the default if the reporters list is empty. I'm asking on a more general level though (basically, ignore any customization). I just want to know about how the console reporter normally handles stdout & stderr, and how your changes impact/supplement that behavior. |
How can I implement assertion-level granularity with your solution? |
This is getting too complicated, so I'm going to go ahead and implement |
Normally console reporter ignores std streams and lets them go straight to output. My change makes console reporter ask Catch to redirect std streams during test case and then handle them at the end of a test case, specifically don't use them if the whole test case passed and print them if it didnt. As mentioned, it doesn't provide assertion level granularity, but it is a start. Assertion level granularity should be possible by abusing Listener interface. I might be able to provide a small example in the evening. |
Ok I got
Based on this I think I want to try the reporter again. However, I want to meet the following requirements:
I'm still not sure how to do this on the assertion begin/end macros, since the |
So after struggling with Catch code even more, I decided it's much simpler to bypass Catch completely. Basically, I implement a custom reporter that manages printing its own log buffer separate from Catch:
My So far this is working nicely and it's simple. If there's anything Catch could benefit from after my struggles, is better documentation for the reporters. Explain the inputs to each reporter member function. Explain the base reporters and their purpose, as well as potential use cases for overriding them. Hopefully that gets more flushed out over time. |
Hi there! I also needed scoped info messages in a way I can use them to report stuff from my own helper functions in case of a failure. Currently, calling INFO() from my helper functions doesn't help me since they are scoped to the my helper functions. So, they are created in the helper function scope and destroyed while returning from there, before they had a chance to get reported when an assertion fails. I'd like implement this functionality if nobody is working on that. I have a couple of questions. Let me describe my understanding first: Currently, INFO() is an alias for this internal macro: Catch2/include/internal/catch_capture.hpp Lines 130 to 131 in 67308bb
It creates this object: Catch2/include/internal/catch_message.cpp Lines 49 to 60 in 67308bb
I assume these two are not overridden in somewhere else, are they? Catch2/include/internal/catch_run_context.cpp Lines 237 to 243 in 63d1a96
I'm thinking of adding some message vectors to Eventually these functionalities can be exposed with some macros, e.g. @horenmar I'd appreciate if you could provide me feedback before I start implementation. Is this right approach? Do you have any objections or suggestions? |
cc #415 @philsquared |
@ozars In general, I think that providing full granularity (e.g. separate macros for test case scope, section scope, assertion scope) is not a good idea -- I think that we should just bring back
and then they are removed. For implementation details, you want to rope in @JoeyGrajciar, because I am taking 2 weeks break. |
Fair enough.
If I understood you correctly, this is actually how assertion info (#1522) behaves since ps. Nope, messages are currently cleared when
Have a nice break! @JoeyGrajciar: I'd appreciate if you could provide some feedback on #1522. |
|
So I'm familiar with the
INFO
macro for logging. However, these logs get lost once the enclosing scope ends. I'd instead like logs to be scoped to aTEST_CASE
orSECTION
. I have a logging system (basically a singleton) that I can register logging sinks to. For only catch tests, I override the logger to sink all logs toINFO
. My hope was, that for failed test cases, it would dump logs that occurred within its own test case across our whole code base (since they all use this logger). But this doesn't work since it's nested so deep, outside of actual test case scope (but still inside; just not explicitly).Is there some way I can make all logs in the code base funnel into Catch? Maybe an INFO_WITHIN_TESTCASE macro could be added or something? It would basically keep a list of all logs created, until the test case or section ends and then it is erased.
ideas?
The text was updated successfully, but these errors were encountered: