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

runtime: clean up export_test.go #55108

Open
aclements opened this issue Sep 16, 2022 · 1 comment
Open

runtime: clean up export_test.go #55108

aclements opened this issue Sep 16, 2022 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Thinking
Milestone

Comments

@aclements
Copy link
Member

aclements commented Sep 16, 2022

@mknyszek, @cherrymui, @rsc, and I were discussing how to simplify runtime/export_test.go. It's become quite ungainly, and the difficulty of re-exporting runtime internals (especially data structures) I believe actively discourages us from writing unit tests. There are a few things we could do:

  1. Generate export_test.go. Have some way of describing what runtime internals we want and just code generate the bulk of the wrappers. This is easy for functions, and remains messy for data structures, but at least a tool would be handling the mess.
  2. Flip things around. Put (most) runtime unit tests in package runtime instead of runtime_test, so they can directly access runtime internals. Now because of layering we have the reverse problem we do today. These test functions can't import testing, so we would copy the testing.TB interface into runtime, write the tests to take this interface, and autogenerate trivial TestX(*testing.T) functions into runtime_test that would just call the real tests. We would also need access to some of the standard library (e.g., sync.WaitGroup, reflect.DeepEqual), and for that we can inject closures into the runtime test. The key advantage of this approach is that rather than trying to access unexported things across packages, we're accessing exported things across packages.
  3. Make it possible to import testing from runtime. The testing package already widely uses the sort of cross-DAG injection I described above to minimize its dependencies, but it could go even further. This would benefit a couple dozen packages that can't import testing today. The advantage of this is that we wouldn't need to generate TestX wrappers because we could use testing.T directly. However, we would still need to inject other library dependencies as in option 2. Since it's easy to write a tool to generate the wrappers and this tool could be shared, it's not clear this is much of an advantage.

Overall, it seems like option 2 is the best balance. We can also migrate toward it incrementally, perhaps writing new tests in this style, or moving particularly onerous export_test tests over.

@aclements aclements added Thinking compiler/runtime Issues related to the Go compiler and/or runtime. labels Sep 16, 2022
@aclements aclements added this to the Backlog milestone Sep 16, 2022
@aclements
Copy link
Member Author

aclements commented Sep 16, 2022

cc @golang/runtime

@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Thinking
Projects
Status: No status
Development

No branches or pull requests

2 participants