testing: TestMain should not require os.Exit #34129
Let's say you start here:
Subtle bug #1: your teardown isn't running; you're making a mess of your test environment. Try this:
Oops, setup has a
Uh, headscratch. "Why isn't go running my tests?", you ask. Oh,
Let's save people some headscratching (and time and effort and silly wrapper code). The testing framework probably has enough information to call
TestMain is really useful for writing end-to-end tests, where a single setup/teardown for all the tests is important. If I break those tests into packages for organization, it would be nice not to copy that
The text was updated successfully, but these errors were encountered:
One possibility, that I thought was discussed before but I can't find an issue, is to change the behavior depending on the result of
This mistake does happen a lot, and the testing package that called TestMain and prepared the m can certainly record the result of m.Run for use in its own outer os.Exit.
Letting TestMain simply call m.Run instead of calling os.Exit(m.Run) seems OK and makes defer more useful.
I'm not as confident about alternate TestMain signatures; that seems unnecessary to solve this specific problem.
It seems like if we do the "automatic os.Exit" that will fix quite a few buggy tests, and it basically eliminates the need for a TestMain that returns int. We could always revisit that and add it later, if needed, but let's start with the automatic os.Exit.
To be clear, the proposal is this. Right now, the overall test func main calls TestMain(m), and the TestMain function is expected to do two things:
The proposal is that:
This would mean that implementations of TestMain that forget to call os.Exit will have it called for them. And implementations that want to explicitly avoid os.Exit in order to make defer useful can do that.
If TestMain does not call m.Run (presumably for a good reason) and returns, then the outer func main should os.Exit(0) as it does today.
Does anyone object to this plan or think it would not address the necessary use cases?
In CL 219639 the generated testing package gets a dependency on reflect. Trim that dependency in the go/packages tests, just as we trim other dependencies of the generated testing package. Updates golang/go#34129 Change-Id: I5e2578fc61cafb4d524d0a58525cf78a402c1143 Reviewed-on: https://go-review.googlesource.com/c/tools/+/221477 Run-TryBot: Ian Lance Taylor <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Michael Matloob <email@example.com>
Explicitly listing the pruned packages ties the test to the details of how the testing package is implemented. That shouldn't matter, and it changes in CL 219639. This change makes it possible to work whether or not CL 219639 is committed. Updates golang/go#34129 Change-Id: I45875dadeaac42a1002e1329a1a762e340c5352c Reviewed-on: https://go-review.googlesource.com/c/tools/+/221657 Run-TryBot: Ian Lance Taylor <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Changkun Ou <firstname.lastname@example.org> Reviewed-by: Michael Matloob <email@example.com>