On Wed, Jan 5, 2022 at 11:32 AM Brieuc Jeunhomme <bjeunho...@gmail.com>
wrote:
> So:
> $ cat mypackage.go
> package mypackage
>
> import "something/something/foo"
>
> func MyFunction() {
> some code
> some code
> some code
> foo.Bar(make(chan foo.Baz), make(chan foo.Foobar))
> }
>
> Is the code I would really like to write.
>
> foo has build constraints. As you can see, my code doesn't, it's the
> exact thing you recommended: the common code is in mypackage.go, the
> platform specific code is in foo (which I don't control, it isn't my code,
> so I can't change it). How to unit test MyFunction to verify that it uses
> foo.Bar correctly?
>
By writing a normal test for it and running that on one of the platforms
`foo` supports. You can't run it on any other platform, because it doesn't
build on any other platform.
> Normally, I would just pass foo.Bar in argument to the function or do
> something like var fooBar = foo.Bar so I can replace it in unit tests.
>
That's certainly possible. You would declare
var fooBar func(whatever) error
And then have a file `bar_foo.go` with
//go:build amd64|…
import "something/something/foo"
func init() {
fooBar = foo.Bar
}
and a file `bar_nofoo.go` with
//go:bulid !amd64&…
func init() {
fooBar = func(whatever) error { return errors.New("not implemented") }
}
But, personally, I see very limited benefit in this. It means your package
will build, but error at runtime on platforms which are not supported by
`foo`. And your tests will not test anything relevant - you can't verify
that you are calling `foo.Bar` *correctly*, you can just verify that you
call your mock with certain arguments which you guess are right. That's a
change-detection test, it's not a good test.
Just import `foo`, call it as normal and run your tests on a platform which
is actually supported by `foo`. And/or write an implementation that works
on other platforms as well, without importing `foo`.
> But in the case of a foo package that has platform build constraints, I
> don't see how it's possible without creating a wrapper.
>
> On Wednesday, January 5, 2022 at 10:20:47 AM UTC Jan Mercl wrote:
>
>> On Wed, Jan 5, 2022 at 11:09 AM Brieuc Jeunhomme <bjeun...@gmail.com>
>> wrote:
>>
>> > But here ,since under non-windows platforms, I can't import the
>> package, it means I have to define wrappers for everything I use: types,
>> constants, functions.
>>
>> I don't get it. Put the common code in a file/in files with no build
>> constraints and the target specific bits in files with build
>> constraints for the target. What wrappers are needed and why?
>>
>> Package level declarations are visible in all files within a package -
>> meaning they have package scope. The sole exception is the package
>> qualifier explicitly or implicitly declared by an import statement.
>> Such identifier has file scope.
>>
> --
> 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/74eed2b8-9a6a-4ad1-a30a-9ceca71e5bc8n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/74eed2b8-9a6a-4ad1-a30a-9ceca71e5bc8n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfE9i-MpoAuyYO1Z1uhKdK2%3D%2Bhoo-O_nAkME1UKPHf-ASQ%40mail.gmail.com.
