#1 .NET BDD Framework. SpecFlow automates your testing & works with your existing code. Find Bugs before they happen. Behavior Driven Development helps developers, testers, and business representatives to get a better understanding of their collaboration
The matter I'm trying to address is how to completely suppress the trace output of succeeding scenarios, while at the same time preserving it for failing ones.
The idea is to have a new configuration option, which causes trace messages to be buffered until an error happens. If an error happens, all buffered messages are flushed, and following messages go through without buffering until the start of the next scenario. If the scenario finishes with status OK, the buffered messages are discarded.
I'm posting this as a starting point for discussion, rather than anything like a for-sure final draft, because I think I need the maintainers' opinions on:
Is this approach a good idea at all?
Where exactly things should go? Are the changes to the internal interfaces okay? Is that an okay place to keep state, such as the buffer, in AsyncTraceListener? Would this even work correctly with parallel executions? I'm probably not putting some things in the right place.
I'll try to add an integration test later to more explicitly show the expected behaviour.
I'll hold off on unit tests until it more clear where the implementation will go.
Types of changes
[ ] Bug fix (non-breaking change which fixes an issue).
[x] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[ ] Performance improvement
[ ] Refactoring (so no functional change)
[ ] Other (docs, build config, etc)
Checklist:
[ ] I've added tests for my code. (most of the time mandatory)
[x] I have added an entry to the changelog. (mandatory)
[x] My change requires a change to the documentation.
An attempt to address #2708
The matter I'm trying to address is how to completely suppress the trace output of succeeding scenarios, while at the same time preserving it for failing ones.
The idea is to have a new configuration option, which causes trace messages to be buffered until an error happens. If an error happens, all buffered messages are flushed, and following messages go through without buffering until the start of the next scenario. If the scenario finishes with status OK, the buffered messages are discarded.
I'm posting this as a starting point for discussion, rather than anything like a for-sure final draft, because I think I need the maintainers' opinions on:
AsyncTraceListener? Would this even work correctly with parallel executions? I'm probably not putting some things in the right place.I'll try to add an integration test later to more explicitly show the expected behaviour. I'll hold off on unit tests until it more clear where the implementation will go.
Types of changes
Checklist: