I am not sure what happened, but the tests worked when I pushed them to our repository, now when I try to run go test I get these errors (changed directory names):

$ go test
# ~/git/repo
package ~/git/repo (test)
	imports gotest.tools/assert
	imports gotest.tools/v3/assert/cmp: code in directory ~/go/src/gotest.tools/assert/cmp expects import "gotest.tools/assert/cmp"
FAIL	~/git/repo [setup failed]

This is how I import gotest.tools:

import (
	"gotest.tools/assert"
	"net/http"
	"testing"
)

How does this happen all of a sudden? I tried reinstalling everything, even cleared my GOPATH completely, but the error remains.

Passing -test.update-golden to update the golden files works well, but if you're not already familiar with the library, then it's not especially discoverable.

Could the assertion failure include some help text which tells the user that this flag exists?

gotest.tools 2.3.0 w/ Go 1.12.2 on Fedora Rawhide, x86_64:

Testing    in: /builddir/build/BUILD/gotest.tools-2.3.0/_build/src
         PATH: /builddir/build/BUILD/gotest.tools-2.3.0/_build/bin:/builddir/.local/bin:/builddir/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin
       GOPATH: /builddir/build/BUILD/gotest.tools-2.3.0/_build:/usr/share/gocode
  GO111MODULE: off
      command: go test -buildmode pie -compiler gc -ldflags "-X gotest.tools/version=2.3.0 -extldflags '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '"
      testing: gotest.tools
gotest.tools/assert
--- FAIL: TestDeepEqualFailure (0.00s)
    assert_test.go:305: should have failure message "assertion failed: \n--- actual\n+++ expected\n{assert.stub}.b:\n\t-: 1\n\t+: 2\n", got "assertion failed: \n--- actual\n+++ expected\n\u00a0\u00a0assert.stub{\n\u00a0\u00a0\ta: \"ok\",\n-\u00a0\tb: 1,\n+\u00a0\tb: 2,\n\u00a0\u00a0}\n"
FAIL
exit status 1
FAIL	gotest.tools/assert	0.028s

This PR adds MatchExtraFilesGlob PathOp. As discuss in #133, this is a starting point.

@dnephin regarding the function

 func MatchExtraFilesGlob(glob string, ops ...PathOp) PathOp 

What should I do with the ops parameter? should I apply it to the directoryPath in the AddGlob function (as it is done for other directoryPath functions)?

Signed-off-by: glefloch [email protected]

and adjust assert/cmp/compare_test.go accordingly.

In go-cmp v0.4.0, for user convenience, full name of the type is printed in the panic message when accessing an unexported field, see google/go-cmp#171

Many thanks!

Anthony

this is a follow-up to https://github.com/gotestyourself/gotest.tools/pull/217, opening as draft because the first 3 commits are from that pull request; I thought it was good to open this change as a separate PR for visibility.

go.mod: golang.org/x/tools v0.1.0

Project now started to do releases; this one was related to a security issue on Windows, replacing all usages of os/exec with golang.org/x/sys/execabs.

icmd: replace all usages of os/exec with golang.org/x/sys/execabs

Following the changes in Go, and golang.org/x/tools themselves, this change ensures that packages using exec.LookPath or exec.Command to find or run binaries do not accidentally run programs from the current directory when they mean to run programs from the system PATH instead.

go.mod: github.com/pkg/errors v0.9.1

This version provides compatibility with Go 1.3+ native error wrapping

go.mod: github.com/google/go-cmp v0.5.5

Version v0.5.x provides various improvements to the reporter output; https://github.com/google/go-cmp/releases

full diff: https://github.com/google/go-cmp/compare/v0.4.0...v0.5.5

I don't think the fix for #167 (#171) was entirely correct. A typed nil error is not a nil error when compared against nil in a normal context.

package baderr

import (
	"testing"

	"gotest.tools/v3/assert"
)

type myEvilError struct{}

func (m *myEvilError) Error() string {
	return "this is an error"
}

func doSomething() error {
	var err *myEvilError
	return err // NOT nil, this has a type.
}

// Should not pass.
func TestErrorNil(t *testing.T) {
	assert.NilError(t, doSomething()) // This says it's nil.
}

func TestErrorNotNil(t *testing.T) {
	assert.Assert(t, doSomething() != nil) // An actual comparison says it's not nil.
}

In order to make vendoring work with go modules we need the alias to be as the major version, otherwise, the vendor files are in gotest.tools/v3/assert but the import says gotest.tools/assert which makes go fail to build without go modules.

Takes over #162 Closes #162

Signed-off-by: Vincent Demeester [email protected]

Create a custom error by implementing the error interface (e.g. Error() function)

type MyCustomError struct {
    msg string
}
func (ce *MyCustomError) Error() string {
    return ce.string
}

In a test, checking for a nil MyCustomError reference using the NilError function will lead to unexpected behavior, such as:

var myErr *MyCustomError 
assert.NilError(t, myErr)

in this case, you receive a memory address error, because the above custom Error() function will get invoked, even though ce is nil.

If you "fix" your Error() function, such as:

func (ce *MyCustomError) Error() string {
    if ce != nil {
        return ce.string
    }
    return ""
}

then you get rid of the null pointer memory error, but the assertion will fail.

This happens because, in the assert.go file, at the type switch switch check := comparison.(type), it resolves to case error branch.

Workaround: use Assert(t, myErr == nil) instead.

The poll_test unit test is calling a broken example file

+ LDFLAGS='-X gotest.tools/version=2.1.0'
+ GO_TEST_FLAGS='-buildmode pie -compiler gc'
+ GO_TEST_EXT_LD_FLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '
+ go-rpm-integration check -i gotest.tools -b /builddir/build/BUILD/gotest.tools-2.1.0/_build/bin -s /builddir/build/BUILD/gotest.tools-2.1.0/_build -V 2.1.0-1.0.fc30.llt -p /builddir/build/BUILDROOT/golang-gotest-tools-2.1.0-1.0.fc30.llt.x86_64 -g /usr/share/gocode -r '.*example.*'
Testing in: /builddir/build/BUILD/gotest.tools-2.1.0/_build/src
      PATH: /builddir/build/BUILD/gotest.tools-2.1.0/_build/bin:/builddir/.local/bin:/builddir/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin
    GOPATH: /builddir/build/BUILD/gotest.tools-2.1.0/_build:/usr/share/gocode
   command: go test -buildmode pie -compiler gc -ldflags "-X gotest.tools/version=2.1.0 -extldflags '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '"
   testing: gotest.tools
gotest.tools/assert
PASS
ok  	gotest.tools/assert	0.028s
gotest.tools/assert/cmd/gty-migrate-from-testify
PASS
ok  	gotest.tools/assert/cmd/gty-migrate-from-testify	5.330s
gotest.tools/assert/cmp
PASS
ok  	gotest.tools/assert/cmp	0.009s
gotest.tools/assert/opt
PASS
ok  	gotest.tools/assert/opt	0.008s
gotest.tools/env
PASS
ok  	gotest.tools/env	0.008s
gotest.tools/fs
PASS
ok  	gotest.tools/fs	0.014s
gotest.tools/golden
PASS
ok  	gotest.tools/golden	0.009s
gotest.tools/icmd
PASS
ok  	gotest.tools/icmd	0.369s
gotest.tools/poll
# gotest.tools/poll_test
./example_test.go:22: Wrapf format %s reads arg #1, but call has 0 args
FAIL	gotest.tools/poll [build failed]

Hello!

I was wondering if you'd considered whether it's worth it to use generics in the comparison functions, and what a migration path to that model might look like?

It would be nice if there was a way to run the tests, and for each one that fails, prompt the user to decide whether to update the diff or not. Think a UX similar to git add -p

I found DurationWithThreshold returns false if both of the values are zero.

https://github.com/gotestyourself/gotest.tools/pull/62/files#diff-d952cf5be65334da619358823c8ff4669961b0d9a30e85d542caad125beac4c6R20

I guess if both of them are zero, we should return true to compare all test cases in the consistent way.

What do you think?

Originally we thought there might be more stuff to include in the skip package. It has been a few years, and we haven't added anything.

This PR deprecates the skip package, and moves the one function to assert.SkipIf. Instead of a very small page it should be fine to move this one exported function to the assert package.

Also improves the godoc a bit, and documents msgAndArgs on assert.Assert as well.

I've run across a few cases recently where I've wanted to set a deadline on a test running. Generally when doing potentially complicated things that could deadlock, and as mistake could accidentally leave the test hanging.

Would you be interesting in accepting a new function/package for this functionality?

There's some related disucssion in https://github.com/golang/go/issues/10529 where it was deemed not suitable for core.

I originally tried pitching this to go-cmp, and they said no because they quite resonably want all comparison to be stateless.

https://github.com/google/go-cmp/issues/241#issue-736205887

The context from that issue is:

After upgrading to the most recent version of protobuf, we are finding all of our comparisons are failing due to some new unexported fields.

There is a cmp.Option implementation provided by the protobuf module in godoc.org/google.golang.org/protobuf/testing/protocmp#Transform - but I now need to go and add this option to every single compare.

This particular check is generic and safe to add on every compare - would it be reasonable to provide a way to install such global comparison options?

This feels like it might be slightly safer for a test assertion tool, as each "global" would be scoped to the test binary.