proposal: testing: consider having timeouts in test binaries be recoverable/handled

[dprotaso]

The way timeouts are thrown cause the binary to exit immediately

go/src/testing/testing.go

Lines 1740 to 1744 in 4d608eb

	m.timer = time.AfterFunc(*timeout, func() {
	m.after()
	debug.SetTraceback("all")
	panic(fmt.Sprintf("test timed out after %v", *timeout))
	})

This circumvents T.Cleanup and any cleanup logic that might have been in TestMain. In order to guarantee setup/teardown occurs it has to be done outside the go test process. Thus either a testing script or the use of go test -exec xprog

The challenge with these workarounds is you lose the simplicity of invoking go test.

Thus my ask is

1. when a timeout occurs run T.Cleanup functions
2. considering surfacing the timeout as a panic but allow the ability to handle that panic

My second point could be accomplished by having the panic be surfaced by M.Run() and could be handled in the following way

func TestMain(m *testing.M) {
   os.Exit(run(m))
}

func run(m *testing.M) (exitCode int) {
  setup()
  defer cleanup()
  exitCode = m.Run()
}

[ianlancetaylor]

Note that the t.Deadline method was introduced specifically so that tests could arrange their own, earlier, timeouts.

[dprotaso]

Yeah - I'm aware of the deadline per test.

My main concern is the setup and teardown that's called out in the TestMain docs

It is sometimes necessary for a test program to do extra setup or teardown before or after testing.