Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Possible future work:
Allow
ExUnit.start(capture_io: true)
to mimiccapture_log: true
?Add api to programmatically append to the StringIO input buffer, right now it's only possible on creation:
The idea is something like this:
And so we could replace the usage of:
too.
Maybe instead of calling it
StringIO.buffer
it could be calledStringIO.input_write
andStringIO.input_puts
to mimicIO.write
andIO.puts
. Not sure if we'd need.input_binwrite
too.@tag capture_io: :standard_error
?I think we could do this as long as the test is running in
async: false
which we'd know and then we can raise otherwise. This is as opposed tocapture_io(:standard_error, ...)
where ExUnit does not know if it's sync or async.If we do this, do we want to capture both? I guess we could accept a list of devices and set it in context:
Not sure if
:stdio
is even semantically correct, my understanding is it's not stdio per se but the group leader. So yeah, it's probably a pass, and a reason to usecapture_io
in this case, but I thought I'd mention this for completeness.Make the StringIO available to
@tag :capture_log
tests in context as%{capture_log: io}
. This could be considered a breaking change since today the context is usually set as%{capture_log: true}
or%{capture_log: options}
but I can't think of a reason to read them back in a test.