Would you be open to a patch or know of a tool that parses the go test output and then splits text from a failing case to the stderr output?

I was looing for such a tool and found @rakyll's comments on:
golang/go#21944
I can see that keeping output syncronised within go test while producing stderr output would be hard but in this after tool everything from the start to the end of the failure would be already correctly serlialised.

My use case is that within a CI job I would like to retail the full go test -v output so we have a record of what was run but I would rather only have the Failure cases recorded in the terminal to make them very obvious. I would pipe the passing records to a log file for storage.

Hello,

My team members and I, really like your project :-) thank you for adding colors to go test output.

We really like to keep the standard output of go test tool, the only 2 things that we would love to add were the colors (solved with this project) and a summary line counting the number of tests passed, skipped and/or failed.

We were wondering if you would consider adding this summary line at the end of the output that counts the number of tests. I'll push a PR to materialize what I mean.

The tool has only tested on dark foregrounds but it should be adaptive enough to switch to a lighter background color theme.

If the main test is PASS, SKIP appears as PASS, otherwise it appears as FAIL:

Is this intentional ?

This project hasn't been updated in ~6 months and rakyll is taking a break from open source. In the meantime, I am happy to maintain this project on my fork where I will actively review pull requests and merge changes. (And hopefully others will review my changes)

It's not my intention to use this issue as self-promotion. I use this project every day and would like to see it maintained. Either way, I'll continue to keep an eye on the issues and pull requests here.

Hi

I used gotest on goenv 1.18.
I can't run gotest command after go get -u github.com/rakyll/gotest.

If I can run gotest command, run below command.

mkdir $GOPATH/bin
cd $GOPATH/pkg/mod/github.com/rakyll/[email protected]
go build -o gotest main.go
mv gotest $GOPATH/bin

Looks as if the pre-built binary is no longer available from http://storage.googleapis.com/jbd-releases/gotest_linux.

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist.</Message>
</Error>

Hi,

Just wondering what you would say if I proposed to use ANSI colours for output instead of "github.com/fatih/color". If you used ANSI (e.g. fmt.Println("\033[1;44mSOME TEXT GOES HERE\033[0m")), output colours wouldn't be lost as opposed to the current situation. Example below won't print the colours anymore - neither in terminal nor in IDE.

Thanks

package main

import (
	"bufio"
	"fmt"
	"io"
	"log"
	"os/exec"
)

func main() {
	cmd := exec.Command("gotest", "-v", "./...")
	stdout, err := cmd.StdoutPipe()
	if err != nil {
		log.Fatal(err)
	}
	_ = cmd.Start()

	buffer := bufio.NewReader(stdout)

	for {
		line, _, err := buffer.ReadLine()

		fmt.Println(string(line))

		if err == io.EOF {
			break
		}
	}
}

$ gotest -v -skipnotest=true  github.com/rakyll/hey
?   	github.com/rakyll/gotest	[no test files]

Instead it skips all the tests.

I've used this tool https://github.com/benbjohnson/goo by @benbjohson. Copies the first "failure" to your buffer to cut/paste into your editor.

My workflow tends to always be running tests on save, and because this tool copies the first failure to the clipboard, I can quickly jump to the code in my editor (vim for me). I also use it for things like go build as well, but that may not apply to this project.

I understand this is a fairly specialized request, so feel free to close this issue if you feel it isn't worth adding.

Thank you for great tool!
Do you plan to support goapp test?

We talked about this briefly on Twitter, but I thought it would be a good idea to move the discussion to a place where messages can be a bit longer.

I did some research and found the following:
Essentially, there are 5 different types of color vision deficiencies with varying degrees of severity.

1. Red-weak/blind
2. Green-weak/blind
3. Blue-weak/blind
4. Blue Cone Monochromacy
5. Monochromacy

I found this simulator. I don't know how accurate it is, but I think (hope) that it gives us at least an idea of what the output might look like for the different types.

Type 1 and 2 obviously have the biggest issue.

Type 3 seems to be fine, although the green looses some saturation.

Type 4 losses a lot of saturation. From what I've read they only have blue cones, which led me to believe that they should see blue just fine, but in the simulator it looks like they loose saturation across all colors, which might make it tricky.

Type 5 sees no color at all, although they seem to see different shades of white/grey/black, so only coloring errors might help them, too.

All in all I think your suggested color scheme (blue for errors, standard color for the rest) is a step in the right direction. Blue seems to be working relatively well where green and red are not.

An alternative approach might be to let users pick their own colors. This way they could figure out colors that work for them, while green/red can work as the somewhat expected default.

with go version of go1.17.8 darwin/amd64 I get the following deprecation warning when running:

go get -u github.com/rakyll/gotest

go get: installing executables with 'go get' in module mode is deprecated.
	To adjust and download dependencies of the current module, use 'go get -d'.
	To install using requirements of the current module, use 'go install'.
	To install ignoring the current module, use 'go install' with a version,
	like 'go install example.com/cmd@latest'.
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

What's the suggested method of install?

In case of at least drone CI, there's no CI env variable present. While I can set CI=drone, it will not force color output as it's not listed in the switch statement.

• Can we just check for a non-empty CI env variable?
• Add on an env variable to force color output?

go get fails with the following output.

# github.com/rakyll/gotest
/go/pkg/mod/github.com/rakyll/[email protected]/main.go:105:3: undefined: c
/go/pkg/mod/github.com/rakyll/[email protected]/main.go:113:3: undefined: c
/go/pkg/mod/github.com/rakyll/[email protected]/main.go:117:3: undefined: c
/go/pkg/mod/github.com/rakyll/[email protected]/main.go:123:3: undefined: c
/go/pkg/mod/github.com/rakyll/[email protected]/main.go:155:8: cannot use c (type color.Attribute) as type *color.Color in assignment

I revert the following commit and the build was successful.

29d015f

go env

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/kei.arima/Library/Caches/go-build"
GOENV="/Users/kei.arima/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/kei.arima/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/kei.arima/.anyenv/envs/goenv/versions/1.14.1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/kei.arima/.anyenv/envs/goenv/versions/1.14.1/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/kei.arima/repos/github.com/rakyll/gotest/go.mod"
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/05/q4pw_wzx48vg9t899zwgjlyw0000gp/T/go-build433895382=/tmp/go-build -gno-recor
d-gcc-switches -fno-common"