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

test: generate gcgort #25310

Open
pciet opened this issue May 9, 2018 · 2 comments

Comments

@pciet
Copy link
Contributor

commented May 9, 2018

In e0adc35 test/gcgort.go is added. This test may benefit from being generated instead of hand-written to increase maintainability by reducing repeating and narrow test coverage by removing extraneous setup code like the modifier struct.

This change would be after 1.11 and my opinion is it should only be done if the test strategy is also updated for the stated garbage collector, types, and concurrency interactions coverage. Currently the test failure relies on the runtime implementation causing a panic.

From https://go-review.googlesource.com/c/go/+/93715 discussion with @aclements.

@bradfitz bradfitz added this to the Unplanned milestone May 9, 2018

@burakguven

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2018

I made a first attempt at removing some of the duplication here. The output is identical to the original file except for a few irrelevant differences like variable names and comments. Is something like this what you had in mind?

@pciet

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2018

@burakguven The way to generate is new to me and looks like a good step forward. Even so there’s still a lot of code for the generate program because of the templates.

A reason type modifier is there is to be sure missing field mistakes is caught by the compiler, but if we’re generating then maybe it can be removed from the output (this isn’t to test following func pointers).

Ideally the test would catch issues without the runtime having to panic. I was thinking something like verifying that the memory of var x is the right value after x+1 is executed and a goroutine switch happens to maybe find memory corruption because of an incorrect garbage collection. Thanks for taking a look at this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.