Pass stdin to go test #234
Conversation
There was a problem hiding this comment.
Thank you for the PR! I think it would be good to allow some way to read from stdin.
I thought this had come up before, but I was not able to find the discussion, so I'll need to think some more about any potential complications. One thing that comes to mind is that --watch changes the terminal mode to accept keystrokes. I'm not sure if that will cause any problems with passing os.Stdin to the command being run. You can see that in internal/filewatcher/term_unix.go.
cmd/main_test.go
Outdated
| {Action: "fail", Package: "pkg", Test: "TestOne"}, | ||
| {Action: "fail", Package: "pkg"}, | ||
| } { | ||
| assert.NilError(t, e.Encode(event)) |
There was a problem hiding this comment.
I think t.Fatal (and anything that results in t.FailNow) is only supposed to be called from the main test goroutine. Here assert.NilError will call t.FailNow. One way to work around this is to use t.Error (t.Fail) instead, which can be done with assert.Check(t, e.Encode(event)).
|
Thank you again for the PR! I had a chance to test it out and everything seems to work as expected. I made a couple small changes to the test to ensure that it would fail when the code change it is testing is removed. Also added another example to the docs to show how it works. If CI is happy I will merge. |
The test would not fail without the change because it was not making any assertions about the input. Adding a check for "DONE 1" causes it to fail properly when the support is removed. Also add an example to the docs of how to use stdin.
|
Thanks! Happy to help. 🙂 |
It may be useful to pipe the
go testJSON togotestsum. There are a few ways in which this could be achieved:Passing stdin to
testjson.ScanConfigseems the most sensible, but it may be complicated and may cause unintended side effects. For instance, assuminggotestsumwere to contextually switch between using stdin andgo test, existing invocations ofgotestsumwhere data is being piped would no longer work. Providing a new flag to opt-in may be helpful? Maybe a sub-command?(This PR) Passing stdin to
--raw-commandallows stdin to be piped to stdout via use of a tool likecat.Given the changes included in this PR,
gotestsumcan readgo testJSON via stdin with:cat out.json | gotestsum --raw-command -- catThis may be useful when the JSON is generated via other tools (i.e Bazel). For example:
What do you think?