Skip to content

testing: testing a list of packages blocks the real-time output #27826

Open
@mwf

Description

@mwf

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

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yes, reproduced on tip - go version devel +ce58a39fca Thu Sep 20 22:52:44 2018 +0000 darwin/amd64

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/ikorolev/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ikorolev/.gvm/pkgsets/go1.11/global:/Users/ikorolev/dev/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/ikorolev/.gvm/gos/go1.11"
GOTMPDIR=""
GOTOOLDIR="/Users/ikorolev/.gvm/gos/go1.11/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/go-build880489854=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go test -v -count=1 ./... doesn't print real-time test output if you got subpackages.

cd `mktemp -d`
go mod init example.com/test
cat <<EOD > main_test.go
package main

import (
	"fmt"
	"testing"
	"time"
)

func TestLong(t *testing.T) {
	fmt.Println("running")
	time.Sleep(2 * time.Second)
	fmt.Println("2 second later")
}
EOD
mkdir subpkg
cat <<EOD > subpkg/main_test.go
package subpkg
EOD
go test -v -count=1 ./...

What did you expect to see?

I expect to see the output successively as the test is running.
And I will see it if run go test -v -count=1 . instead.

What did you see instead?

Using ./... doesn't produce real-time output.
The output is produced only when all the tests are finished.

It's not convenient when you run tests on a CI and see only "go test -v ./..." line for several minutes.
You don't have any idea if the tests have stuck somewhere or they are just too slow.

I understand that such behaviour may be connected with running the tests in parallel, but maybe we could do anything about it?

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.TestingAn issue that has been verified to require only test changes, not just a test failure.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions