What if there are only certain parts of the core data type which should be public?

You could make an internal package, like internal/testcommon - but with a better name.

Or if the tests require private access?

How would you share code that requires private access to multiple packages to begin with?

Personally, what I do is keep some helper test code in an internal package, then use it from each test package with whatever access to private code is necessary.

What if there are only certain parts of the core data type which should be public?

You could make an internal package, like internal/testcommon - but with a better name.

Thanks for the suggestion, my understanding is that this is currently the idiomatic way to deal with shared test logic. I think it can be improved :)

Or if the tests require private access?

How would you share code that requires private access to multiple packages to begin with?

This is really the heart of the issue for me. What if this core object requires many state transitions to reach the interesting test cases? It may be easier and less error-prone to set a private type directly rather than trying to carefully recreate the chain of events that lead to the state (carefully re-creating the state would be a different test).

I don't want the consumer to know about this detail, but a helper function that is part of the test package should be able to set it directly. Today that sort of thing isn't possible without making that helper function part of the public package interface.

You could instead put everything in internal/ packages and use a public package to export only the parts of your API that you want your users to have access to.

also duplicate of #31135 #39565

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group