Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-07 Thread josvazg
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 ext

Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-07 Thread TheDiveO
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 a

Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-06 Thread josvazg
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

Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-04 Thread Nagaev Boris
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 impor

[go-nuts] Bets approach for test helper packages within same project

2023-08-04 Thread josvazg
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