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/95c10c49-762f-4f98-93d7-4b8c076a6024n%40googlegroups.com.
