-
Notifications
You must be signed in to change notification settings - Fork 764
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
src/goTestExplorer: explain benchmark output
- Add test_events.md to detail what go test -json looks like - Add comments - Also, address gerrit comments
- Loading branch information
1 parent
1ee5851
commit 77f3623
Showing
2 changed files
with
61 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# Go test events | ||
|
||
Running tests with the `-json` flag or passing test output through `go tool | ||
test2json1` will produce a stream of JSON events. Each event specifies an | ||
action, such as `run`, `pass`, `output`, etc. An event *may* specify what test | ||
it belongs to. The VSCode Go test controller must capture these events in order | ||
to notify VSCode of test output and lifecycle events. | ||
|
||
## Tests | ||
|
||
Processing test events generated by `TestXxx(*testing.T)` functions is easy. | ||
Events with an empty `Test` field can be ignored, and all other events have a | ||
meaningful `Action` field. Output is recorded, and run/pass/fail/skip events are | ||
converted to VSCode test API events. | ||
|
||
[go#37555](https://github.com/golang/go/issues/37555) did require special | ||
handling, but that only appeared in Go 1.14 and was backported to 1.14.1. | ||
|
||
## Benchmarks | ||
|
||
Test events generated by `BenchmarkXxx(*testing.B)` functions require | ||
significantly more processing. If a benchmark fails or is skipped, the `Test` | ||
and `Action` fields are populated appropriately. Otherwise, `Test` is empty and | ||
`Action` is always `output`. Thus, nominal lifecycle events (run/pass) must be | ||
deduced purely from test output. When a benchmark begins, an output such as | ||
`BenchmarkFooBar\n` is produced. When a benchmark completes, an output such as | ||
`BencmarkFooBar-4 123456 123.4 ns/op 123 B/op 12 allocs/op` is produced. No | ||
explicit `run` or `pass` events are generated. Thus: | ||
|
||
- When `BenchmarkFooBar\n` is seen, the benchmark will be marked as running | ||
- When an explicit fail/skip is seen, the benchmark will be marked as failed/skipped | ||
- When benchmark results are seen, the benchmark will be marked as passed | ||
|
||
Thus, a benchmark that does not produce results (and does not fail or skip) will | ||
never produce an event indicating that it has completed. Benchmarks that call | ||
`(*testing.B).Run` will not produce results. In practice, this means that any | ||
incomplete benchmarks must be explicitly marked as passed once `go test` | ||
returns. |