Skip to content
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: allow tests to control main execution #8202

Closed
rsc opened this issue Jun 13, 2014 · 7 comments
Closed

testing: allow tests to control main execution #8202

rsc opened this issue Jun 13, 2014 · 7 comments

Comments

@rsc
Copy link
Contributor

rsc commented Jun 13, 2014

A few things have come up recently that could be solved by giving tests a bit more
control over func main.

Suppose we define a type testing.Main analogous to testing.T or testing.PB - it's there
just to have methods to call - with one method Run() (exitcode int). Then the default
test main.main would refactor to:

func main() {
    // various registration
    // create m
    os.Exit(m.Run())
}

But if a test package contains a func TestMain(m *testing.Main), then the main.main
becomes:

func main() {
    // various registration
    // create m
    pkg.TestMain(m.Run())
}

The minimal TestMain is

func TestMain(m *testing.Main) { os.Exit(m.Run()) }

but giving people the ability to write this solves a few problems that have been asked
for.

issue #7905: need to run graphics on main thread

func TestMain(m *testing.Main) {
    go func() {
        os.Exit(m.Run())
    }()
    runGraphics()
}

issue #8159: testing setup/shutdown hook:

func TestMain(m *testing.Main) {
    setup()
    exitCode := m.Run()
    shutdown()
    os.Exit(exitCode)
}
@rsc
Copy link
Contributor Author

rsc commented Jun 13, 2014

Comment 1:

FWIW, the snippet for issue #7905 would also need 'func init() { runtime.LockOSThread() }'

@minux
Copy link
Member

minux commented Jul 8, 2014

Comment 2:

Issue #8340 has been merged into this issue.

@rsc
Copy link
Contributor Author

rsc commented Sep 18, 2014

Comment 3:

Issue #7905 has been merged into this issue.

@rsc
Copy link
Contributor Author

rsc commented Sep 18, 2014

Comment 4:

Issue #8159 has been merged into this issue.

@gopherbot
Copy link
Contributor

Comment 5:

CL https://golang.org/cl/148770043 mentions this issue.

@rsc
Copy link
Contributor Author

rsc commented Sep 19, 2014

Comment 6:

This issue was closed by revision 182d131.

Status changed to Fixed.

@niemeyer
Copy link
Contributor

Comment 7:

Looks great, thank you.

@rsc rsc added the fixed label Sep 20, 2014
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
Fixes golang#8202.

LGTM=r, bradfitz
R=r, josharian, bradfitz
CC=golang-codereviews
https://golang.org/cl/148770043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
Fixes golang#8202.

LGTM=r, bradfitz
R=r, josharian, bradfitz
CC=golang-codereviews
https://golang.org/cl/148770043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
Fixes golang#8202.

LGTM=r, bradfitz
R=r, josharian, bradfitz
CC=golang-codereviews
https://golang.org/cl/148770043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants