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

testing: shutdown hook? #8159

Closed
bradfitz opened this Issue Jun 6, 2014 · 4 comments

Comments

Projects
None yet
5 participants
@bradfitz
Member

bradfitz commented Jun 6, 2014

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.
@chai2010

This comment has been minimized.

Show comment
Hide comment
@chai2010

chai2010 Jun 18, 2014

Contributor

Comment 1:

I think we need a testing.Atexit to do the clean work.
CL13729043 has some discuss about the testing.Atexit.
https://golang.org/cl/13729043/
Contributor

chai2010 commented Jun 18, 2014

Comment 1:

I think we need a testing.Atexit to do the clean work.
CL13729043 has some discuss about the testing.Atexit.
https://golang.org/cl/13729043/
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Jun 18, 2014

Contributor

Comment 2:

I don't see Atexit happening. It's too awful.
issue #8202 describes an alternative.
Contributor

rsc commented Jun 18, 2014

Comment 2:

I don't see Atexit happening. It's too awful.
issue #8202 describes an alternative.
@balshetzer

This comment has been minimized.

Show comment
Hide comment
@balshetzer

balshetzer Sep 12, 2014

Comment 3:

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).

balshetzer commented Sep 12, 2014

Comment 3:

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).
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Sep 18, 2014

Contributor

Comment 4:

Status changed to Duplicate.

Merged into issue #8202.

Contributor

rsc commented Sep 18, 2014

Comment 4:

Status changed to Duplicate.

Merged into issue #8202.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015

@rsc rsc removed the release-go1.4 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.