Having multiple benchmarks for a single name is something specific to
the gotest output, so grouping benchmarks by name is not something that
belongs in the junit package.
This function was used in the past to perform some operations on the
individual output lines before joining them together. However, now it's
only used to combine the collection of lines into a single output
string.
The consequence of this is that any output emitted after the test or
benchmark result, will no longer belong to the last test. Instead it
will be appended to the global log. This is necessary to correctly
attribute output to the correct test or benchmark, for example in cases
where both tests and benchmarks appear.
In the past, Go test output printed test logs after the test result.
However, from Go 1.14 this behaviour was changed and test logs are now
printed before the test result.
With this commit, we effectively no longer support the old behaviour in
Go1.13 and earlier. The output will still appear in the generated
report, however it will no longer belong to the correct test.
Many of the testdata files were generated a long time ago with very old
versions of Go. The Go test output has changed over time, and these test
inputs no longer reflect the current state. The intention is to fully
support the test output of the most recent Go versions.
This commit also includes the source used to generate the test output,
so the output can be more easily updated in the future.
Whitespace prefix of output lines was carried over from the old v1
version, but in some cases it removes too much whitespace. Ideally it
would detect the common prefix of all output lines for a given text and
only trim that. Until that's fixed, let's just stop removing the
whitespace.
Fixes#131
There was some code duplication between the go-junit-report binary, its
tests and the testdata/generate-golden script. This has been moved into
an internal package. The go-junit-report binary can now just focus on
flag parsing and validation, and it should be less likely that the
binary, tests and golden report generator behave differently.
The two parsers that are supported are `gotest` (default), and `gojson`.
They handle the standard `go test -v` and `go test -json` output
respectively.
For most testcases we shouldn't need to specify the input and report
files, instead just look at the testdata/ dir and process each input
file. For the few testcases that need a non-standard config, an entry
can be added to `testConfigs` map (indexed by the test number).
The testdata files must follow a certain naming pattern to be valid.
They should start with a number, followed by a dash, then any text
describing the test and finally end with `.txt`. The corresponding
report file must start with the same number, a dash, followed by
`report.xml`.
The ReportBuilder was made specifically for building a gtr.Report from
parsed go test output. At this point it's unclear whether this will be
reusable if we ever introduce other parser. For now let's move it closer
to where it's used and let's not make it part of the public API yet.
In cases where a test result is not found, for example when a panic
happened, a dummy failing test is added to the report. Since we don't
know exactly what failed, its error message was simply "Run error". This
has been renamed to "Runtime error".
