Go: TestMain: fmt.Print and variants do not display output when not in package directory

[nullbio]

What version of Go are you using (go version)?

go version go1.8 linux/amd64

What operating system and processor architecture are you using (go env)?

Ubuntu 16.04.1 LTS

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

Using fish for my terminal.

What did you do?

project structure looks like:

main.go
package/package.go
package/package_test.go

When running go test ./package any fmt.Printf (or Printf variants like Fprint on os.Stderr or os.Stdout, fmt.Println, etc) calls do not display anything to stdout. The terminal only shows:

~/x $ go test ./package
ok      github.com/x/x/package  0.476s

However, if I cd into the directory first and run go test I get the fmt output from my TestMain function:

func TestMain(m *testing.M) {
    fmt.Printf("test!")
    os.Exit(m.Run())
}

~/x $ cd package
~/x/package $ go test
test!
PASS
ok      github.com/nullbio/lolwtf/controllers   0.460s

What did you expect to see?

Expected to see fmt.Print output.

[ianlancetaylor]

It's a bit odd, yes, but that is how it works. To always see the output, use -test.v. Basically, tests are not expected to write to standard output. For simplicity, when go test is invoked with no arguments, it lets the test's standard output flow through to the program's standard output. But in more complex situations, such as when invoked with arguments or when using -test.parallel to run tests in parallel, go test captures standard output and displays it only for failing tests or when using -test.v.

Closing because this is working as designed.

[nullbio]

@ianlancetaylor Sure, but that doesn't explain why it would be different depending on the directory you're in. I understand that you're saying it's treated differently if it's invoked with arguments (in this case a path), however that logic should only apply to arguments other than a path. Why is there no conditional logic in there to exclude paths from that rule? To me this still classifies as a bug due to its inconsistent nature. Anyway, obviously a low priority, but I still think this should be noted somewhere and not closed unless there is a reason for why path arguments cannot be treated differently.

[ianlancetaylor]

What you are calling a "path" is what go test calls a "package". If go test is invoked with any package arguments (you can use more than one), it behaves one way. If it is invoked with no package arguments, it behaves a different way. It doesn't really have anything to do with what directory you are in when you run go test, except that the directory determines which package is tested if you don't use any package arguments.

The current go test behavior makes sense if you use multiple package arguments, and it makes sense if you use an argument like p/.... I suppose one could argue that if go test is used with a single package argument that expands to a single package, then it could behave the same as go test invoked with no package arguments. But that is more confusing to describe than the current behavior, so it's not clearly better.

[nullbio]

Thanks for the explanation, appreciate it.