Go tests: does using the same package pollute the compiled binary? : ###TL;DR:

Do test written within a package end up in the final exported package? Do they add any garbage or weight to a compiled binary?

###Longer version:

Let's say that I have a `foo` Go package:

```
pkg/
  foo/
    bar.go
    bar_test.go
```

I'm aware of the [black box vs white box](https://stackoverflow.com/questions/19998250/proper-package-naming-for-testing-with-the-go-language/31443271#31443271) approaches to testing in go. A short recap is that I can either:

1. have `bar_test.go` declare a `foo_test` package, or
2. have it part of the main `foo` package.

Approach 1 is considered better because I get to focus on the public API of the package, as I can only access the exported identifiers of `foo`. Also, when application code imports the `foo` package with `import "pkg/foo"`, only the files containing the main `foo` package are compiled. That's nice.

However, there are cases where putting the tests in `foo` is a convenient compromise. I don't particularly like it myself, but I can see it in several codebases and I understand why at times it's necessary.

My question is about what happens to these tests. Since they're part of the package `foo`, when `foo` is imported somewhere, I'd expect the tests to be brought along. Or is the compiler smart enough to strip them?
