Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build failure in tests are not reported #145

Closed
tzachshabtay opened this issue Sep 16, 2022 · 1 comment
Closed

Build failure in tests are not reported #145

tzachshabtay opened this issue Sep 16, 2022 · 1 comment
Milestone

Comments

@tzachshabtay
Copy link

tzachshabtay commented Sep 16, 2022

Description

We're running go test -coverprofile=coverage.out -v ./... 2>&1 | go-junit-report -iocopy -set-exit-code -out junit.xml, and even though we had tests that failed to build, we got an exit code of 0 and the failures were not in the report.

Note that the problem is in specific tests (more on that later in the analysis part), some types of tests do report when they have build failures.

In go test output, the failures were reported like this:

# our.company.name/some/path/parser_test [our.company.name/some/path/parser.test]
compiler error description here

...
later on
...

FAIL	our.company.name/some/path/parser [build failed]

In the xml output I see this:

<testsuite name="our.company.name/some/path/parser" tests="0" failures="0" errors="0" id="292" hostname="5e7b50c95ee9" time="0.000" timestamp="2022-09-16T18:48:08Z"></testsuite>

Analysis

As far as I can tell, for tests that have the same package name as the packages they're testing, this works fine.
For tests that have a _test suffix, this works fine if there were no sub-tests, but in this case the compilation error was in a sub-test which resulting in the output above, i.e # test_package_name [package_name.test] and not # package_name like the other examples.

In the code (I looked at the code, I didn't debug it so I can be wrong) I see it's setting the package name to the first token, and ignoring the second one:

return p.buildOutput(fields[0])

So it's using the test package name and not the package name when recording the build error.

When processing the summary event, it tries to compare the package name in the summary event (i.e parser) with the test package name in the build error (i.e parser_test), which means it misses out on the build failure:

if buildErr.Name == newPackageName {

It then checks if the package "is empty" before even looking at the summary result:

So even though the result states "FAIL", because we have no output for the package and no known tests it completely ignores the "FAIL" status and continues.

So in short, I think there are 2 issues here:

  1. Package name is parsed wrong for this scenario (or alternatively the comparison should also match with _test suffix)
  2. A "FAIL" status for a package is ignored if it's empty

I think the second issue is even more critical then the first as it safe-proofs future incidents of parsing errors like this, i.e not having the build failures in the output is annoying, but having the "FAIL" status ignored means exit code is 0 and we can unknowingly ship untested code to production

jstemmer added a commit that referenced this issue Sep 17, 2022
The ReportBuilder ignores summary results if we never collected any
events for that package. While under normal circumstances we wouldn't
expect this to happen (unless some output was lost or due to a bug in
go-junit-report), we should at the very least make sure that failed
results are not ignored.

Refs #145
jstemmer added a commit that referenced this issue Sep 17, 2022
Make sure we don't ignore any build error that did not belong to a
package. This isn't expected to normally happen, but we need to handle
it anyway to prevent accidentally ignoring potential errors.

Refs #145
jstemmer added a commit that referenced this issue Sep 17, 2022
It's possible for test files to declare a package with the "_test"
suffix. If these packages contain build errors, they were not correctly
matched to the package without the "_test" suffix.

Refs #145
@jstemmer
Copy link
Owner

jstemmer commented Sep 17, 2022

Thanks for the excellent report.

I agree that the second issue is the most important, we should never exit with code 0 if there was any failure or error. I've made some changes to make sure we catch some unusual cases where this could happen.

I've also implemented your first suggestion to make sure build errors in test packages with the _test suffix are correctly matched to the package under test.

I'll close this as fixed, but feel free to reopen if you think I've missed any other cases.

@jstemmer jstemmer added this to the Version 2.1.0 milestone Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants