proposal: cross package test imports #44086
Occasionally two related packages have some overlap in their test code. A common example would be a package defining a complex core data type and the manipulation of that data, and the consumer of that data type which may exist in many other packages.
The core data type may have extensive tests to verify the different ways it can be manipulated and ensure that it contains the correct values.
Consumers of that data type may want to make use of those test objects rather than go through the same process of recreating them.
Currently the recommendation is the put this common test code in a common non _test package, so that it can be used in multiple places. This works but breaks the namespacing. What if there are only certain parts of the core data type which should be public? Or if the tests require private access? What used to be a single
Put test code in an implicit
The text was updated successfully, but these errors were encountered:
You could make an internal package, like
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.
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 :)
This is really the heart of the issue for me. What if this
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.