On Thu, Sep 18, 2014 at 8:01 PM, <r@golang.org> wrote: > > https://codereview.appspot.com/148770043/diff/40001/src/testing/testing.go > File ...
9 years, 7 months ago
(2014-09-19 00:21:16 UTC)
#3
On Thu, Sep 18, 2014 at 8:01 PM, <r@golang.org> wrote:
>
> https://codereview.appspot.com/148770043/diff/40001/src/testing/testing.go
> File src/testing/testing.go (right):
>
> https://codereview.appspot.com/148770043/diff/40001/src/
> testing/testing.go#newcode137
> src/testing/testing.go:137: // func TestMain(m *testing.M) {
> os.Exit(m.Run()) }
> i don't see how this helps much. the fields of m are private so i can't,
> for instance, loop over the tests doing setup and teardown for each
> test.
>
Setup and teardown for each test can be inside the test.
What people have been asking for is setup and teardown for the whole
executable run:
func TestMain(m *testing.M) {
initDBServer()
code := m.Run()
cleanupDBServer()
os.Exit(code)
}
The other thing that has come up repeatedly is being able to go back and
run something on the main thread, because some bad C libraries need that.
This lets them move the test loop off the main thread:
func init() { runtime.LockOSThread() } // locks main goroutine to main
thread
func TestMain(m *testing.M) {
// on main thread. run testing elsewhere
go func() {
os.Exit(m.Run())
}()
// do whatever it is that has to be available on the main thread during
the tests...
...
}
LGTM i don't like it but during several hours of comcast outage i couldn't think ...
9 years, 7 months ago
(2014-09-19 03:16:45 UTC)
#8
LGTM
i don't like it but during several hours of comcast outage i couldn't think of a
better approach.
i expect pressure to add features to testing.M. i will push back on them very
hard.
also go1.4.txt On Thu, Sep 18, 2014 at 8:16 PM, <r@golang.org> wrote: > LGTM > ...
9 years, 7 months ago
(2014-09-19 03:17:40 UTC)
#9
also go1.4.txt
On Thu, Sep 18, 2014 at 8:16 PM, <r@golang.org> wrote:
> LGTM
>
> i don't like it but during several hours of comcast outage i couldn't
> think of a better approach.
>
> i expect pressure to add features to testing.M. i will push back on them
> very hard.
>
> https://codereview.appspot.com/148770043/
On 2014/09/19 17:51:13, rsc wrote: > *** Submitted as https://code.google.com/p/go/source/detail?r=804cc55d6b47 *** > > cmd/go, testing: ...
9 years, 5 months ago
(2014-11-06 16:01:11 UTC)
#12
Message was sent while issue was closed.
On 2014/09/19 17:51:13, rsc wrote:
> *** Submitted as https://code.google.com/p/go/source/detail?r=804cc55d6b47 ***
>
> cmd/go, testing: add TestMain support
>
> Fixes issue 8202.
>
> LGTM=r, bradfitz
> R=r, josharian, bradfitz
> CC=golang-codereviews
> https://codereview.appspot.com/148770043
This broke "go test -compiler gccgo" with llgo (and presumably gccgo):
[...]/_test/_testmain.go:52:7: MainStart not declared by package testing
Could we perhaps add some version checks to this code for compatibility with
go1.3 compilers?
Over in https://code.google.com/p/go/issues/detail?id=8851 we were discussing
how "go" should learn the compiler's Go release tags, which may be useful for
this.
I'm sorry about the breakage, but llgo and gccgo should use a go command built ...
9 years, 5 months ago
(2014-11-06 17:29:01 UTC)
#13
I'm sorry about the breakage, but llgo and gccgo should use a go command
built for the same version of Go that they support.
This is the Go 1.4 go command. It expects Go 1.4 underneath it. I don't
want to start supporting all older versions in each go command.
Russ
Issue 148770043: code review 148770043: cmd/go, testing: add TestMain support
(Closed)
Created 9 years, 7 months ago by rsc
Modified 9 years, 5 months ago
Reviewers: pcc
Base URL:
Comments: 6