-
Notifications
You must be signed in to change notification settings - Fork 54
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
An option to disable "TEST START" println? #158
Comments
The original idea was to make an explicit output to enclose variable
tracing.
Maybe make this the default behavior was not the best choice. Change it
today means introduce a breaking change.
What I can do is
1. Remove it when there isn't any trace attribute
2. Use a feature flag to enable it
One is always a breaking change but I guess that I can live with it.
For two my taste is add this flag as default ... I'm not so sure.
Il dom 17 lug 2022, 01:22 Ivan Smirnov ***@***.***> ha
scritto:
…
https://github.com/la10736/rstest/blob/4e1069b7468d0d49a5d78c47f1336fd88d41e472/rstest_macros/src/render/mod.rs#L268
When running in IDEs (like CLion) that automatically capture output in the
test runner, there's tons of --- TEST START --- printlns.
Looking at the code, wonder why are they needed at all? I found one place
where this is checked, in rstest's tests:
https://github.com/la10736/rstest/blob/e12494bf082ef2c82353e4e88ba74c2c30d1addd/rstest/tests/rstest/mod.rs#L259
But then again, I guess there's other ways to check this, without having
to dump this to stdout on every test? (Or as another option, if it's really
required, could make it a non-default crate feature; or yet another
proc-macro attr, although that's an overkill)
—
Reply to this email directly, view it on GitHub
<#158>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5Y34LHYBLA3PDDLWHWBF3VUM74FANCNFSM53YZUDEQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@la10736 Thanks for replying so fast!
Technically - yes, agreed (however, you're not 1.0 yet, so breaking changes are kind of expected?). However, to be honest I can't picture a real situation where this change would be actually breaking anything - except for a single test in rstest's test suite itself.
That sounds like the best way to do it, I think. If you're tracing things - you're going to be looking at stdout capture anyway. If you're not tracing anything - there's no reason to write anything to stdout.
You mean enable printlns if tracing is disabled? I think it's a bit of an overkill to be honest - can you imaging anyone having this flag turned on in their dev-dependencies? Why would they? If you want those printlns for whatever reason, it's a temporary thing and not a permanent one. Temporary things are usually enabled either at runtime or via env vars; permanent ones via cargo manifests. Maybe more suitable is an environment variable then instead of a feature flag? |
@la10736 Wonder if there's any further thoughts on this? Or is any help with PR needed? |
Sorry, I'm very busy in this period.
If you provide a PR I'll really appreciate it.
Il mer 14 set 2022, 13:52 Ivan Smirnov ***@***.***> ha
scritto:
… @la10736 <https://github.com/la10736> Wonder if there's any further
thoughts on this? Or is any help with PR needed?
—
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5Y34OMW2WHEWLHGP5MSRTV6G4AVANCNFSM53YZUDEQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Ok, you've convinced me. I'll just remove it if there isn't any trace. |
Done. |
Thanks! 👍 |
It still shows to me. No trace flags was provided. or #[case] is trace, and I didn't understand correctly what it meant by it? |
Oh it is unreleased yet. I see. So can live with this output for now, and wait for release. Thanks! |
rstest/rstest_macros/src/render/mod.rs
Line 268 in 4e1069b
When running in IDEs (like CLion) that automatically capture output in the test runner, there's tons of
--- TEST START ---
printlns. It's not mission-critical, but very annoying 😢Looking at the code, wonder why are they needed at all? I found one place where this is checked, in rstest's tests:
rstest/rstest/tests/rstest/mod.rs
Line 259 in e12494b
But then again, I guess there's other ways to check this, without having to dump this to stdout on every test? (Or as another option, if it's really required, could make it a non-default crate feature; or yet another proc-macro attr, although that's an overkill)
If these printlns could be removed, conditionally or unconditionally, would be much appreciated.
The text was updated successfully, but these errors were encountered: