Hi, let me first say that the library is great, thank you for creating it!

I find myself repeating few checks for errors that could be made into assertation. It would be my pleasure to contribute this upgrades if we agree on their form.

1. is.NoErr(err) is great but in lots of situations I need to check the opposite, that error is present. Using is.True(err != nil) works but does not have the same approach to assertation. I suggest adding is.Err(err) that would assert err is not nil.

2. Usually, I add context to errors but I do not use custom error types as there is no behavior associated with this errors. When I have this situation, I would like to check that error contains a particular substring. I suggest adding is.ErrContains(err, "part of error message") that would assert if error contains given substring.

What do you think about this two additions?

With the commit https://github.com/matryer/is/commit/46663c17c43e9963aa1aae09e7bbdbb35d7b9dda the parsing of the flags has changed to the use of flag.Parse(). Because flag.Parse() is called in init(), it prevents the source package (the one, that uses github.com/matryer/is) from defining and using it's own flags, because the calls to e.g. flag.Bool(...) will be after the execution of flag.Parse() and therefore these flags are not considered and the execution of go test fails with flag provided but not defined: ....

This leaves us with two options:

1. Revert the above mentioned commit
2. Under the assumption, that this package is mainly (only) used for testing with go test, then it would also be save to remove the call to flag.Parse() in init(), because go test will execute flag.Parse()

This changes the comment color to from green to red. Green implies success, whereas red stands out.

There's no related issue (I can create one, if needed).

Hi Mat!

Big fan (of Go of course 😏), long time listener of GoTime and working with Go full time for 4 years next month!

So... I just tried this nice little assert library and the first thing I notice is that my editor thinks I shouldn't do this:

is := is.New(t)

It says: Variable 'is' collides with imported package name (And I hate to disappoint my editor!)

What is your defence? (Trying to be funny 😂)

Helper marks the calling function as a test helper function. When printing file and line information, that function will be skipped.

Adopted from testings.Helper from the stdlib.

Related: #30

go test without -nocolor works:

sam@macbook:~/go/src/github.com/sbward/s (master)
$ go test ./model/
	permissions_test.go:11: model.Permission(2) != int(1)
--- FAIL: TestPermissionBits (0.00s)
FAIL
FAIL	github.com/sbward/s/model	0.009s

But go test with -nocolor gives an error:

sam@macbook:~/go/src/github.com/sbward/s (master)
$ go test ./model/ -nocolor
flag provided but not defined: -nocolor
...

Is there a specific reason why this project uses the restrictive GPL 3 license? I for one would be able to use it in a much more relaxed way if it used a more open license like MIT.

@matryer, would you consider switching?

Why

There is no need to depend on testing package in the "production" code.

What

• New and NewRelaxed methods accept t T instead of t *t.testing.

Traffic from godoc.org redirects to the corresponding page on pkg.go.dev.

P.S. Thank you for talking about this package on the Go Time podcast. Always enjoy hearing from you.

Reference: https://blog.golang.org/godoc.org-redirect

Hi! Watched the talk you gave on The Art of Testing and really liked it. That's why I'm trying out this package, and I really like its simplicity.

One thing though that I'm missing is a Contains method (basically this).

As there is none so far, I guess there is some other way to do it? For example, I have a function that returns [][]string, and I wanna check if some []string are in that slice, but do not wanna specify the order.

Thanks!

The current v1.0.0 release still contains the old GPL license. Could we create a new release with the new MIT license or move the existing release tag to include it?

Instead of hardcoding the colour for file and types, use the dim escape code to let the terminal decide the colour. Specifically this makes it more readable if your terminal happens to be slightly gray.

Also includes some gofmt edits of package comment.

I sometimes have cases, where I would like to alter or extend the way is.Equal is deciding, if the values are considered equal. After trying several approaches, I came up with the following solution, which does not extend the current API surface, but adds a maximum of flexibility and freedom to the user in regards to how is.Equal decides if two inputs are equal.

The proposal is to value a newly defined matcher interface, which is defined as follows (the matcher interface does not need to become part of the public API of github.com/matryer/is, in fact it can just be defined inline where needed):

type matcher interface{
	Match(interface{}) bool
}

The actual change, that I am proposing is, to extend the existing areEqual function like this (lines 9-11):

// areEqual gets whether a equals b or not.
func areEqual(a, b interface{}) bool {
	if isNil(a) && isNil(b) {
		return true
	}
	if isNil(a) || isNil(b) {
		return false
	}
	if matcher, ok := a.(interface{ Match(interface{}) bool }); ok {
		return matcher.Match(b)
	}
	if reflect.DeepEqual(a, b) {
		return true
	}
	aValue := reflect.ValueOf(a)
	bValue := reflect.ValueOf(b)
	return aValue == bValue
}

In theory, this change does alter the working of is.Equal. In practice, I assume the chances of this change having negative side effects for users of this package to be extremely low. Only users, that use this package to compare types, that implement this exact interface would be affected. I rate the profit of this change to be way higher than the risk of negative side effects. If you think, that the current signature (Match(interface{}) bool) is too likely to cause problems, the name of the method can easily be altered such that the chance of a collision become negligible (e.g. MatRyerIsMatch(interface{}) bool 😜).

If I find acceptance for this proposal, I am happy to provide the necessary PR to update the code, the tests and the documentation.

As a side note, the areEqual function could be minimally simplified by replacing:

	if isNil(a) && isNil(b) {
		return true
	}
	if isNil(a) || isNil(b) {
		return false
	}

with

	if isNil(a) || isNil(b) {
		return isNil(a) && isNil(b)
	}

Hey Mat, long time. Ran into a curious issue worth filing.

Summary

Running go test -json ... and using this package reports incorrect test names in JSON events. This could very well be a bug in Go (test2json), but figured I'd start here because if I remove is and use regular std. lib primitives it reports the correct thing.

Reproducible example

I noticed this happening in https://github.com/pressly/goose and put together a PR to showcase the problem.

In this commit I purposefully changed a test to trigger a failure. Note the name of the test is TestNotAllowMissing.

https://github.com/pressly/goose/pull/353/commits/9b7c7321bdbabb8307e71a40e0601d86b222d6ce#diff-080f0d7ba408eaf6181e1f61388995ebcd57fdd1468ffafffbf789176531418fR30

When I run go test -v -json -count=1 ./tests/e2e -dialect=postgres I happily get JSON output. But, the test name in the JSON event doesn't line up with the Output.

I was expecting Output that is prints to be associated with test named TestNotAllowMissing, but instead it was associated with another test named TestMigrateFull. (the name is non-deterministic, it changes between runs).

The raw output can be found here. But I've copied and trimmed the relevant bits:

{"Test":"TestMigrateFull","Output":"\t\u001b[90mallow_missing_test.go:30: \u001b[39m7 != 8\n"}
{"Test":"TestNotAllowMissing","Output":"--- FAIL: TestNotAllowMissing (3.73s)\n"}

The first JSON event refers to allow_missing_test.go:30, in the code base the call site on line 30 is located within the test named: TestNotAllowMissing, but the test name is TestMigrateFull.

The second JSON event correctly outputs the failure under the test named TestNotAllowMissing.

This could very well be a bug in how go test prints JSON events, but I suspect it may be something within this library. I say this because if I remove is from that specific test (TestNotAllowMissing) I see the expected output associated with the correct Test name:

Raw output can be found here

{"Test":"TestNotAllowMissing","Output":"    allow_missing_test.go:35: got 7: want: 8\n"}
{"Test":"TestNotAllowMissing","Output":"--- FAIL: TestNotAllowMissing (2.81s)\n"}

The following code

	if isNil(a) || isNil(b) {
		is.logf("%s != %s", is.valWithType(a), is.valWithType(b))
	} else if reflect.ValueOf(a).Type() == reflect.ValueOf(b).Type() {
		is.logf("%v != %v", a, b)
	} else {
		is.logf("%s != %s", is.valWithType(a), is.valWithType(b))
	}

can be simplified to

        if isNil(a) || isNil(b) || reflect.ValueOf(a).Type() != reflect.ValueOf(b).Type() {
		is.logf("%s != %s", is.valWithType(a), is.valWithType(b))
	} else {
		is.logf("%v != %v", a, b)
	}

I find it useful to be able to control the flow of execution in my tests depending on the outcome of previous tests. This PR adds a bool return value from test test functions.