proposal: add a build tag "test" #21360
Comments
Isn't this the same as #14668, which you didn't like? |
This also looks like a duplicate of/related to #12120 (/cc @slimsag), which is even older. I'll paste a point I made there, since it's relevant:
|
Yes, I didn't like it then, but today I encountered an actual instance where I wanted it. My arguments before still stand, but I did find a new argument in favor. It's not quite a duplicate of #14668, and that's closed anyway, so I'll leave this for now. |
... sentiment about my proposal being closed as working-as-intended and later reopened two years later aside.. I've had a desire for this functionality multiple times. Most recently, I've had to exclude certain code from a test invocation inside a package-level
This led me to use an atrocious concoction like this, which relies on initialization order to function correctly:
var isTest bool
If a |
I haven't made up my mind quite yet, just musing aloud: Assuming a This suggests an alternative, such as a (And pushing this a bit further: Instead of build tags, one could encode the file build properties in the file name: imagine |
I'll be that guy, what's wrong with You are in control of the tests, you can easily add that without changing the testing logic. |
@OneOfOne That is something extra I have to explain to every contributor who wishes to run the tests of my project, and it's the kind of command that makes people go |
@slimsag while that's a valid point, it's easily worked around, for example just add an extra test file to notify the users:
|
I admit, that is a pretty decent workaround I had not thought of. Thanks @OneOfOne I think I'll start using that for now! It'd still be nice to have real support for this, though. |
I think it's worth noting that this would require us to potentially rebuild every dependency of the package being tested. This is somewhat problematic when using a build system other than |
I'll expand on @ianlancetaylor's point to say that it'd affect not only the build system, but the experience of Go users. If this is adopted, it could mean that a dependency of a dependency of a dependency (any one of them) can in theory change its behavior when you do Imagine running into an issue in production, then trying to reproduce it by writing a test and running it with Right now, that is not possible, so a Go user is safe knowing their dependencies will behave identically for However, I'll note that the original proposal doesn't necessarily mean the |
Is there any other real-world example where we could benefit from having this build tag, or is it really just about constants? If it's just about constants, maybe we can find a better solution. |
This could be useful, but the build system complications probably outweigh the utility. |
To have code be compiled only during tests, it's easy: just put the code in a file suffixed _test.go. However, there is no mechanism for the complement: to have code that is excluded when testing. I propose we set the tag "test" when the build is being run under "go test".
The desire for this came up for me recently when I wanted to test some code's behavior given a value I wanted to be constant. The only way to do this now is to make it a variable that the test modifies, but a variable is not a constant. There are things you can do with a constant, such as declare array types, that are illegal with a variable.
It was necessary to change the semantics of the code to make it testable. That bothers me.
This is a small problem, I admit, but the proposed solution is also small.
The text was updated successfully, but these errors were encountered: