The reportBuilder assumed we were always processing events for a single
package at a time. This is not true however when running `go test -json
-race` for example. In order to properly support processing events from
different packages we now have packageBuilders per package name.
Fixes#134
The only reason groupBenchmarksByName needed the reportBuilder receiver
was to access its output collector. By passing the output explicitly to
the groupBenchmarksByName function we can remove the reportBuilder
dependency.
We specify 1.13 in go.mod, so we should make sure it can be built and
tested on that version. Let's keep using the ioutil package for now,
since it was only deprecated from 1.16.
The gotest parser used a bufio.Scanner to read its input, which
prevented us from reading lines larger than 64K.
In order to support reading larger lines, bufio.Scanner has been
replaced with bufio.Reader. The maximum line size has been increased to
4MiB and instead of returning an error when reading lines that exceed
the maximum size, we truncate that line and continue parsing.
Fixes#135
In some cases we may have captured some output for a package that didn't
have any tests. We should include it in the generated report as it may
contain useful information.
The junit package shouldn't need to know anything about benchmarks and
gtr.Benchmark will be removed in a future commit. Instead, it will be
the responsibility of the gotest parser to represent benchmarks using
gtr.Test.
When we encounter a failure but there was not failing test, we create a
failing dummy test in the report. This is to prevent the failure from
being overlooked.
The case where the output contained a failing benchmark was not handled
correctly, resulting in a dummy test failure being added to the report
unnecessarily.
Benchmark durations were originally formatted with higher precision
because they contained just the NsPerOp field. Now that we're
approximating the total duration they are more accurate and don't need
as many decimals.
The NsPerOp was previously casted to a time.Duration (int64) before
multiplying it with the number of iterations. This has been fixed by
doing the casting after the multiplication. The resulting duration
should be a bit more accurate.
