Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
testing: shutdown hook? #8159
Could we add a shutdown/cleanup mechanism to the testing package? Background: some tests (notably: integration-style tests) require heavy setup, compiling things, setting up things on disk, running child processes wired together, etc. If you just do this once and share it per test, it's unclear when to clean up the /tmp folder and shut down the processes. People have resorted to things like TestZZZ for cleanup (which doesn't work well with -test.run), or z_last_test.go (as seen in net/http), or the hoops jumped through here: https://github.com/bradfitz/docker/blob/fuse/vfuse/all_test.go (Look at release and testsToRun and how it's calculated.) And also hacks in Google's code, even people so far as to fork the testing package. Or people run a child process that is responsible for cleanup, once it notices its parent has died. But that's a lot of work and there are portability concerns. I know a test could still crash mid-way through, so cleanup on shutdown is still best effort, but when it's a bunch of big processes and big files in /tmp, that's better than nothing most the time. With regard to atexit-ish concerns, I'd propose the shutdown mechanism itself be subject to the same timeout concerns. If the shutdown doesn't finish in N seconds, the test exits with failure.
We could add some more conventions: If a function called SetUp exists then it runs before any of the tests. If a function called TearDown exists then it runs after all the tests have run. More generally, we could have: If a function starts with SetUp(.*) and takes *testing.T then it will be run before any of the tests that start with Test\1 are run. If a function starts with TearDown(.*) and takes a *testing.T then it will be run after all of the tests that start with Test\1 are run. This can lead me to write something like: func SetupCaseFoo(t... func TestCaseFooBar(t... func TestCaseFooBlee(t.. func TearDownCase(t.. etc. If the concern is that there might already be functions with such names and argument types then a new type could be introduced that must be the argument that is an alias for testing.T (or that is more specifically suitable for setup and teardown functions).