An option to disable "TEST START" println?

[aldanor]

An option to disable "TEST START" println?

[aldanor]

@la10736 Thanks for replying so fast!

Change it today means introduce a breaking change.

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.

Remove it when there isn't any trace attribute

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.

Use a feature flag to enable it

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]

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: ***@***.***>

[aldanor]

@la10736 Wonder if there's any further thoughts on this? Or is any help with PR needed?

[la10736]

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: ***@***.***>

[la10736]

Ok, you've convinced me. I'll just remove it if there isn't any trace.

[la10736]

Done.

[aldanor]

Done.

Thanks! 👍

[Mart-Bogdan]

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?

[Mart-Bogdan]

Oh it is unreleased yet. I see. So can live with this output for now, and wait for release.

Thanks!