You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a Go package has both an internal test (package example) and an external test (package example_test), the resulting test binary runs the Test, Fuzz, Example, and Benchmark functions from both packages.
If a TestMain function is defined in both packages, test setup fails with multiple definitions of TestMain.
However, if other testing functions are defined in both packages, they are both run. That leads to a number of confusing effects:
The same test name can be shown with two different results (say, PASS and SKIP, or PASS and FAIL), even if the test flags only request to run each package once. That may confuse tools that ingest test results.
If the tests run in parallel, logs and JSON events for the two tests may be interleaved, with no way to distinguish the two. (t.Log messages will list the correct file and line number, but log messages originating in helper functions may be completely ambiguous.)
It is impossible to use the -run flag to run only one of the two tests but not the other.
For the above reasons, I propose that a test binary that defines two different Test, Fuzz, Example, or Benchmark functions with the same name should fail at run-time.
(A GODEBUG setting should be used to restrict this failure to only tests whose go version is at least the release in which this change is introduced.)
The text was updated successfully, but these errors were encountered:
Alternately, this could be implemented as a vet check, included in the subset of vet checks run by default during go test.
However, I prefer the testing approach: the cmd/vet alternative seems more difficult to implement (especially in a way that complies with #56986), and either way it would cause go test of the package to fail.
changed the title
proposal: testing: fail the test if a test function is defined in both the _test and non-_test package with the same nameJun 23, 2023
Failing at run time allows a user to revert to the prior behavior easily using a //go:debug directive. Failing at generation time would make it a hard break for any existing duplicated tests when updating the go version.