Many thanks! Replying to myself as well: Build tags are still useful to separate away non unit tests that require some ad-hoc setup to be run. That way doing "go test ./..." on the project root works as expected.
On the other hand, integration or end to end tests that require some setup or external dependencies, must be run by passing the required build tags explicitly. Jose El lunes, 7 de agosto de 2023 a las 9:38:40 UTC+2, TheDiveO escribió: > https://stackoverflow.com/a/54734212 > > On Monday, August 7, 2023 at 8:48:24 AM UTC+2 josvazg wrote: > >> Interesting! Thanks! >> >> I was assuming wrongly the module was the unit of compilation. >> >> If any package not imported by production code is not included, then that >> also means that build tags are not necessary for the integration and end to >> end test folders. Correct? >> >> Any pointers on where can I read more about this? >> >> Jose >> >> El sábado, 5 de agosto de 2023 a las 4:05:52 UTC+2, Nagaev Boris escribió: >> >>> Hi, >>> >>> You can put test helpers to a separate package (directory), say >>> testhelper/ without a build tag. Code in that directory will use >>> regular code and it will have its own unit tests in testhelper/ >>> directory. When you build your production binary, it won't include >>> such code, because it is not imported by any production code (directly >>> or indirectly). At the same time, you can import the "testhelper" >>> package from your integration tests as usual. >>> >>> On Fri, Aug 4, 2023 at 11:01 AM josvazg <jos...@gmail.com> wrote: >>> > >>> > We are working on a project that requires some test helpers and mocks >>> that, ideally, should: >>> > >>> > - Helpers should be accessible by all testing code, unit tests, >>> integration or e2e. >>> > - Note unit tests live along side normal code in their *_test.go >>> files. >>> > - The rest of tests will be on a separated test/ folder using a built >>> tag to avoid to be compiled in with regular code. >>> > >>> > - Helpers should not be part of the default exported module code. >>> > >>> > - Helpers do not need to be accessible by the regular code, just the >>> test code. >>> > >>> > - Helpers might need tests themselves. >>> > >>> > How can we achieve that in the simplest or cleanest way? We do not >>> want to create yet another project for just that, as it is only to be used >>> within this project. >>> > >>> > I was thinking about a build tag for such code and just put it on a >>> regular folder, such as testsupport/. But that would break unit tests that >>> need that unless you setup the build tag, which feels weird. >>> > >>> > Another option is to place the test support and the test that use them >>> under the same build tag and folder as test/. And run them separately with >>> the build tag. That creates a special category of unit tests, when they are >>> not integration or e2e but need supporting code from those test/support/ >>> packages. >>> > >>> > Maybe use a module at testsupport/ separate from the rest of the code >>> and use it as a library from test code? >>> > >>> > Any better options? >>> > Or maybe there is a good known solution for this I should know about. >>> > >>> > Jose >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> > To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/ca983d85-b5f5-423d-b949-71fa41b414ccn%40googlegroups.com. >>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Boris Nagaev >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d5b5dcef-a8c2-4f9b-ad04-daa48423c873n%40googlegroups.com.
