Possible to run tests against a specific Go binary?

[st ov]

As part of a build pipeline, I want to initially artifact the Go binary to send through all the stages from development to production.

How can I run a set of tests (*_test.go) against this one binary? Can I only have blackbox tests or is whitebox possible?

Or will the approach need to be, to run 'go test' against the package code at every step and rebuild?

How do you handle delivering and deploying your builds?

[st ov]

Is it not possible? The doc seems to say that 'go test' recompiles each package tested

https://golang.org/cmd/go/#hdr-Test_packages

[Ian Lance Taylor]

On Fri, Apr 21, 2017 at 9:30 AM, st ov <so.q...@gmail.com> wrote:
> Is it not possible? The doc seems to say that 'go test' recompiles each
> package tested
> https://golang.org/cmd/go/#hdr-Test_packages

`go test` is for testing packages separately. I don't really know
what you mean by "run tests against a specific Go binary."

Ian

> On Thursday, April 20, 2017 at 10:00:24 AM UTC-7, st ov wrote:
>>
>> As part of a build pipeline, I want to initially artifact the Go binary to
>> send through all the stages from development to production.
>>
>> How can I run a set of tests (*_test.go) against this one binary? Can I
>> only have blackbox tests or is whitebox possible?
>>
>> Or will the approach need to be, to run 'go test' against the package code
>> at every step and rebuild?
>>
>> How do you handle delivering and deploying your builds?
>>
>>

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[st ov]

So lets say I have a package that relies on a configuration.

In my dev environment I run 'go test' against the package and the configurations for dev.

It passes the tests so I build out this package and artifact the resulting binary.

This artifact then continues to a staging environment that has its own configurations.

I was wondering if its possible to run those same tests against the binary instead of having the source rebuild?

This is to verify that the binary works across different environments.

Or am I approaching this incorrectly? 

[Ian Lance Taylor]

On Fri, Apr 21, 2017 at 12:37 PM, st ov <so.q...@gmail.com> wrote:
>
> So lets say I have a package that relies on a configuration.
> In my dev environment I run 'go test' against the package and the
> configurations for dev.
> It passes the tests so I build out this package and artifact the resulting
> binary.
>
> This artifact then continues to a staging environment that has its own
> configurations.
> I was wondering if its possible to run those same tests against the binary
> instead of having the source rebuild?
> This is to verify that the binary works across different environments.
>
> Or am I approaching this incorrectly?

I see. No, `go test` doesn't work that way. `go test` builds a
testing version of the package, and tests that. There is no way to
run the same tests from a normal non-testing version of the package.
It's a perfectly reasonable request, it's just not what `go test`
does. Given an external program, you will have to write tests that
test that program, which is not the usual way that `go test` works.

That said, it is possible to use `go test` and have the tests build
and test the program. Then you could use a flag to specify which
program to test, use `go test -c` to build a test binary, and run that
test binary with the flag. You would only be able to test external
behavior, things you can do by running the program, rather than
testing internals as you can normally do with `go test`. In the
standard repository, some of the cmd/go tests are written this way;
see src/cmd/go/go_test.go. It doesn't have the flag to choose the
binary to test, but that would be a minor addition.

Ian

[st ov]

Thank you Ian for providing those details and for pointing me to the code in the source to reference. I'll have a look and respond back if I have any questions.