/cc @bcmills @rsc

In-package tests are always at risk of unrealism. For example, what if broken_test.go provided an init function rather than a type declaration? Then the breakage would not be caught until run-time in some other test.

In contrast, a package-external test (package broken_test instead of package broken) would have caught this example right from the start.

Instead of adding a “clean package build” step where it isn't otherwise needed, I'd rather we encourage users to use external tests instead of in-package ones.

See also #29258.

But everybody has tons of tests that use unexported functions. That all will break and the export_test.go trick is quite inconvenient to use and in end it's again in-package _test.go file. For these reasons we always recommended the opposite. What am I missing/what has changed?

But everybody has tons of tests that use unexported functions.

I said “encourage”, not “require”. If you want to catch subtle variations between the test package and the real one, test against the real one: that's something you can do today, without any extra support from the go command.

we always recommended the opposite. What am I missing/what has changed?

internal packages make it possible to define (and test against) exported APIs without exposing them to the outside world. I don't know about official recommendations, but at least for me that nullifies the strongest argument for package-internal testing.

This seems like a reasonable thing to try to help users notice.

I strongly disagree about suggesting use of external tests by default. Quite the opposite: I think external tests should be reserved for cases where an internal test would hit an import cycle.

I would like to understand how much it would cost in a typical go test cycle to build the package both with and without its internal tests. My guess is that it would not cost much - most of the cost of go test is in linking the binary, not the incremental build of the package itself.