Thanks. It does work. I suppose I had wrong assumptions on how the
'internal' package works. I thought it is usable only by its immediate
parent package. It turns out it is usable by any other packages that share
the same parent as the internal package.
Thanks again, everyone! :)
Henry
On Mo
What Dave suggested should work, in your example package1, package2,
package3 and package4 should be able to import testhelpers with `import
"project/internal/testhelpers"`
On Sunday, December 18, 2016 at 2:48:41 PM UTC+1, Henry wrote:
>
> Where do you put this internal package in relation to th
The problem with putting my test utilities under a single file, lets say
util_test.go, is that the utilities are not usable across different packages
within the same project. As far as I know, you cannot import test packages (eg.
mypackage_test).
--
You received this message because you are s
Any reason not to have a `utils_test.go` file - and puts your utilities in
there? Seems like the simplest solution.
Then they only get included for your tests.
Using /internal for testing tools feels a bit strange to me IMHO.
Mark
On 18 December 2016 at 11:13, Matt Harden wrote:
> An import o
An import of a path containing the element “internal” is disallowed if the
importing code is outside the tree rooted at the parent of the “internal”
directory.
Note the use of the word "tree" in that sentence, as opposed to "directory".
On Sun, Dec 18, 2016 at 5:48 AM Henry wrote:
> Where do yo
Where do you put this internal package in relation to the rest of the packages?
Is it something like this:
project/
package1/
package2/
package3/package4/
internal/testhelpers/
I thought internal package would only be visible to its immediate parent? I
want it to be usable across th
Like Nigel suggested
project/
internal/
testhelper
On Sunday, 18 December 2016 21:45:25 UTC+11, Henry wrote:
>
> No. I meant something like this:
>
> project/
> -- package1
> -- package2
> -- package3
>
> Now there is a reusable test utility that is used by the tests in
> package1, pack
No. I meant something like this:
project/
-- package1
-- package2
-- package3
Now there is a reusable test utility that is used by the tests in package1,
package2, and package3. So the question is where do I put the test utility
without exposing them as a part of the project's API? I don't want
On Sun, Dec 18, 2016 at 1:51 PM, Henry wrote:
> I have reusable test utilities in a project. They are used by various
> packages in the project for testing purposes, and at the same time I don't
> want to expose these utilities as public APIs. Since it is impossible to
> import another test packag
Hi,
I have reusable test utilities in a project. They are used by various
packages in the project for testing purposes, and at the same time I don't
want to expose these utilities as public APIs. Since it is impossible to
import another test package in Go, I wonder what would be the best way to
10 matches
Mail list logo
