runtime: clean up export_test.go #55108
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
@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: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.runtime
instead ofruntime_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 importtesting
, so we would copy thetesting.TB
interface into runtime, write the tests to take this interface, and autogenerate trivialTestX(*testing.T)
functions intoruntime_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.testing
fromruntime
. Thetesting
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 importtesting
today. The advantage of this is that we wouldn't need to generateTestX
wrappers because we could usetesting.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.The text was updated successfully, but these errors were encountered: