jeudi 17 janvier 2019

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 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?

Aucun commentaire:

Enregistrer un commentaire