Johnlon
commented
1 month ago The suggestion is one possibility, but would result in silence for protracted periods.
The reality of the situation is that folk will use things like fmt.* and even the root println fn, and unlike the JVM sadly golang doesn't provide a reliable way to intercept stdout/stderr to capture that output to defer logging. I tried it ages ago and it doesn't work and there is nothing the framework can really do to fix that.
What does work (for godog and other MT code) is to create a logger for each goroutine (eg in the before scenario), and to pass that logger to each step via the context object and then that logger can aggregate output until the after scenario where it could be logged en-masse. This is something you can do yourself.
This approach also has advantages as you can attache the captured console to the steps as you go along so that it's available in HTML report and so on.
tigh-latte
👓 What did you see?
Example output showing three different test's steps being mixed together
✅ What did you expect to see?
It would be more readable and easier to debug to hold onto a test's output until it's complete and then write it all at once.
📦 Which tool/library version are you using?
No response
🔬 How could we reproduce it?
Set
Concurrency: 2(or more) in the config📚 Any additional context?
No response