code review 13729043: testing: add Atexit

testing: add Atexit

[chai2010, 2013-12-10 00:38:16]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[minux1, 2013-12-10 00:40:36]

has this api addition been discussed on golang-nuts? i don't like it.

[rsc, 2013-12-10 00:54:13]

not lgtm

Atexit is a way to make your program wedge instead of exiting. It's too
easy to misuse, even limited to package testing.

[chai2010, 2013-12-10 01:13:08]

On 2013/12/10 00:40:36, minux wrote:
> has this api addition been discussed on golang-nuts? i don't like it.

The atexit has been discussed on golang-nuts,
but it is not for testing package.

is there an atexit?
https://groups.google.com/forum/#!topic/golang-nuts/qBQ0bK2zvQA

Is there atexit?
https://groups.google.com/forum/#!msg/golang-nuts/PCVy2dGGai0/CKF38-nH96MJ

[chai2010, 2013-12-10 01:13:26]

On 2013/12/10 00:54:13, rsc wrote:
> not lgtm
> 
> Atexit is a way to make your program wedge instead of exiting. It's too
> easy to misuse, even limited to package testing.

I read your reply on "is there an atexit?" topic:
https://groups.google.com/forum/#!msg/golang-nuts/qBQ0bK2zvQA/vmOu9uhkYH0J

I agree with your opinion: "Atexit may make sense in single-threaded,
short-lived programs".

And the testing.Main run in single-threaded, it is a short-lived programs.
And we often need do some clean work when test exit.

For a normal test example:
1. once.Do(createTempDatebase())
2. multi client goutines connect to TempDatebase.
3. test exit, need delete the TempDatebase!

But how to delete the TempDatebase(without atexit) in the sense?

[rsc, 2013-12-10 01:18:29]

What do you do if the test crashes?

[chai2010, 2013-12-10 01:22:32]

On 2013/12/10 01:18:29, rsc wrote:
> What do you do if the test crashes?

If the test crashes, i will fix the test BUG.
The good `go test` will print PASS.

[minux1, 2013-12-10 01:22:44]

On Dec 9, 2013 8:13 PM, <chaishushan@gmail.com> wrote:
> I read your reply on "is there an atexit?" topic:
> https://groups.google.com/forum/#!msg/golang-nuts/qBQ0bK2zvQA/vmOu9uhkYH0J
>
> I agree with your opinion: "Atexit may make sense in single-threaded,
> short-lived programs".
>
> And the testing.Main run in single-threaded, it is a short-lived
> programs.
> And we often need do some clean work when test exit.
>
> For a normal test example:
> 1. once.Do(createTempDatebase())
> 2. multi client goutines connect to TempDatebase.
> 3. test exit, need delete the TempDatebase!
>
> But how to delete the TempDatebase(without atexit) in the sense?
even if we have testing.Atexit, what if the test dereference a nil pointer?
it will exit immediately without running your atexit handler.

a much more reliable way is to start the real tests as a subprocess in
init(), and do clean up once the child exits.

[chai2010, 2013-12-10 01:25:17]

On 2013/12/10 01:22:44, minux wrote:
> On Dec 9, 2013 8:13 PM, <mailto:chaishushan@gmail.com> wrote:
> > I read your reply on "is there an atexit?" topic:
> > https://groups.google.com/forum/#%21msg/golang-nuts/qBQ0bK2zvQA/vmOu9uhkYH0J
> >
> > I agree with your opinion: "Atexit may make sense in single-threaded,
> > short-lived programs".
> >
> > And the testing.Main run in single-threaded, it is a short-lived
> > programs.
> > And we often need do some clean work when test exit.
> >
> > For a normal test example:
> > 1. once.Do(createTempDatebase())
> > 2. multi client goutines connect to TempDatebase.
> > 3. test exit, need delete the TempDatebase!
> >
> > But how to delete the TempDatebase(without atexit) in the sense?
> even if we have testing.Atexit, what if the test dereference a nil pointer?
> it will exit immediately without running your atexit handler.
> 
> a much more reliable way is to start the real tests as a subprocess in
> init(), and do clean up once the child exits.

The testing.Atexit is just for the good test(do clean work).
If the test crashes, we need to fix the BUG.

[minux1, 2013-12-10 01:26:36]

On Dec 9, 2013 8:22 PM, <chaishushan@gmail.com> wrote:
> On 2013/12/10 01:18:29, rsc wrote:
>> What do you do if the test crashes?
> If the test crashes, i will fix the test BUG.
> The good `go test` will print PASS.
then why do we introduce an unreliable atexit mechanism that doesn't work
when tests crash?

as a develeper you might remember to do clean up manually in those cases,
but what about other users of your package?

[dfc, 2013-12-10 01:26:43]

not lgtm.

If you need this higher level funcationality, look at gocheck or one
of the other suite based testing tools.

On Tue, Dec 10, 2013 at 12:25 PM,  <chaishushan@gmail.com> wrote:
> On 2013/12/10 01:22:44, minux wrote:
>
>> On Dec 9, 2013 8:13 PM, <mailto:chaishushan@gmail.com> wrote:
>> > I read your reply on "is there an atexit?" topic:
>> >
>
> https://groups.google.com/forum/#%21msg/golang-nuts/qBQ0bK2zvQA/vmOu9uhkYH0J
>
>> >
>> > I agree with your opinion: "Atexit may make sense in
>
> single-threaded,
>>
>> > short-lived programs".
>> >
>> > And the testing.Main run in single-threaded, it is a short-lived
>> > programs.
>> > And we often need do some clean work when test exit.
>> >
>> > For a normal test example:
>> > 1. once.Do(createTempDatebase())
>> > 2. multi client goutines connect to TempDatebase.
>> > 3. test exit, need delete the TempDatebase!
>> >
>> > But how to delete the TempDatebase(without atexit) in the sense?
>> even if we have testing.Atexit, what if the test dereference a nil
>
> pointer?
>>
>> it will exit immediately without running your atexit handler.
>
>
>> a much more reliable way is to start the real tests as a subprocess in
>> init(), and do clean up once the child exits.
>
>
> The testing.Atexit is just for the good test(do clean work).
> If the test crashes, we need to fix the BUG.
>
>
> https://codereview.appspot.com/13729043/
>
> --
>
> ---You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[chai2010, 2013-12-10 02:18:40]

On 2013/12/10 01:26:36, minux wrote:
> On Dec 9, 2013 8:22 PM, <mailto:chaishushan@gmail.com> wrote:
> > On 2013/12/10 01:18:29, rsc wrote:
> >> What do you do if the test crashes?
> > If the test crashes, i will fix the test BUG.
> > The good `go test` will print PASS.
> then why do we introduce an unreliable atexit mechanism that doesn't work
> when tests crash?
> 
> as a develeper you might remember to do clean up manually in those cases,
> but what about other users of your package?

As a develeper, i agree with i need to do clean work.
But i don't know how to do the clean work in some special scene.

For examle:
I need create a temp file in init func.
The TestA/TestB use the temp file in different goroutines.
How to remove the temp file when the test exit?
Do we need write lots of refuse code just for testing.Atexit work?

// foo_test.go

var testfile *os.File

func init() {
	var err error
	if testfile, err = os.Create("foo"); err != nil {
		log.Fatal(err)
	}
	testing.Atexit(func(){
		testfile.Close()
		os.RemoveAll()
	})
}

func TestA(t *testing.T) {
	// do something with testfile
}
func TestB(t *testing.T) {
	// do something with testfile
}

[chai2010, 2013-12-10 02:19:02]

On 2013/12/10 01:26:43, dfc wrote:
> not lgtm.
> 
> If you need this higher level funcationality, look at gocheck or one
> of the other suite based testing tools.
> 
> On Tue, Dec 10, 2013 at 12:25 PM,  <mailto:chaishushan@gmail.com> wrote:
> > On 2013/12/10 01:22:44, minux wrote:
> >
> >> On Dec 9, 2013 8:13 PM, <mailto:chaishushan@gmail.com> wrote:
> >> > I read your reply on "is there an atexit?" topic:
> >> >
> >
> >
https://groups.google.com/forum/#%2521msg/golang-nuts/qBQ0bK2zvQA/vmOu9uhkYH0J
> >
> >> >
> >> > I agree with your opinion: "Atexit may make sense in
> >
> > single-threaded,
> >>
> >> > short-lived programs".
> >> >
> >> > And the testing.Main run in single-threaded, it is a short-lived
> >> > programs.
> >> > And we often need do some clean work when test exit.
> >> >
> >> > For a normal test example:
> >> > 1. once.Do(createTempDatebase())
> >> > 2. multi client goutines connect to TempDatebase.
> >> > 3. test exit, need delete the TempDatebase!
> >> >
> >> > But how to delete the TempDatebase(without atexit) in the sense?
> >> even if we have testing.Atexit, what if the test dereference a nil
> >
> > pointer?
> >>
> >> it will exit immediately without running your atexit handler.
> >
> >
> >> a much more reliable way is to start the real tests as a subprocess in
> >> init(), and do clean up once the child exits.
> >
> >
> > The testing.Atexit is just for the good test(do clean work).
> > If the test crashes, we need to fix the BUG.
> >
> >
> > https://codereview.appspot.com/13729043/
> >
> > --
> >
> > ---You received this message because you are subscribed to the Google Groups
> > "golang-dev" group.
> >
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to mailto:golang-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.

I hope the std testing pkg is the best.
I don't like use non-std pkg, especially the std pkg has the same feature.

I just need a way to create my own exit, but i have no choise in `go test` scene
(i can't write the main.main in test).

I create a tipoc for this:
https://groups.google.com/forum/#!msg/golang-nuts/1mnGkkfzosY/ajSlAeIbF9YJ

[chai2010, 2013-12-17 02:33:45]

*** Abandoned ***