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

proposal: cross package test imports #44086

Open
winder opened this issue Feb 3, 2021 · 4 comments
Open

proposal: cross package test imports #44086

winder opened this issue Feb 3, 2021 · 4 comments
Labels
Projects
Milestone

Comments

@winder
Copy link

@winder winder commented Feb 3, 2021

Problem

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 core_test.go file is now split across multiple packages instead of using the same idioms we use when writing non-test code.

Proposal

Put test code in an implicit _test package which can be imported to other _test packages.

Using the core and consumer examples, perhaps we have core_test.go which is part of the core package. It defines several useful functions that consumer_test.go would like to use. So we simply add core_test to get them.

@gopherbot gopherbot added this to the Proposal milestone Feb 3, 2021
@mvdan
Copy link
Member

@mvdan mvdan commented Feb 3, 2021

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.

@winder
Copy link
Author

@winder winder commented Feb 3, 2021

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.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Feb 3, 2021

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.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Feb 3, 2021

also duplicate of #31135 #39565

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Feb 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants