Return a bool from assertions

[goodevilgenius]

Testify's library comes with two flavors: assert and require. be is essentially just assert, which is reasonable given the design goal of having a low footprint.

But, if we need to require, you could return a bool from each method to indicate success/failure, and then we could do:

if !be.Err(t, err, nil) {
  t.FailNow()
}

In this case, we can ignore the return if we don't need it, or check it if we do.

[nalgeon]

Be is mostly assert, with one exception:

Be doesn't fail the test when an assertion fails, so you can see all the errors at once instead of hunting them one by one. The only exception is when the be.Err(err, nil) assertion fails — this means there was an unexpected error. In this case, the test terminates immediately because any following assertions probably won't make sense and could cause panics.

This covers exactly the use case that you mentioned.

[goodevilgenius]

The nil error was the most obvious use case, but not the only one.

For example, I have a test that looks like this (I'm in the process of refactoring to use be instead of testify):

valT, ok := val.(time.Time)
if assert.True(t, ok) {
    assert.WithinRange(t, valT, exp.Add(-time.Second), exp.Time(time.Second)
}

If the val which is an any, isn't a time.Time, then it doesn't make sense to compare it to the expected time, because it won't be. So, by skipping that test, I eliminate unnecessary noise.

So, with be, I have to do:

valT, ok := val.(time.Time)
be.True(t, ok)
if !ok {
    be.True(t, valT.After(exp.Add(-time.Second)) && valtT.Before(exp.Add(time.Second)))
}

It's a very small convenience

[nalgeon]

So, with this change, the code will be as follows, correct?

valT, ok := val.(time.Time)
if be.True(t, ok) {
    be.True(t, valT.After(exp.Add(-time.Second)))
	be.True(t, valT.Before(exp.Add(time.Second)))
}

And you also expect the test to fail if valT is not time.Time, correct?

[goodevilgenius]

So, with this change, the code will be as follows, correct?

valT, ok := val.(time.Time)
if be.True(t, ok) {
    be.True(t, valT.After(exp.Add(-time.Second)))
	be.True(t, valT.Before(exp.Add(time.Second)))
}

And you also expect the test to fail if valT is not time.Time, correct?

Yeah, that's the idea. Like I said, it's a minor convenience, and maybe not worth it for such a small benefit. Just an idea I had while doing this refactor.

[nalgeon]

I like this change. It makes the API more flexible without making it more complicated. The only problem is that it's a breaking change, since function signatures would change from returning nothing to returning bool. On the other hand, it’s unlikely to cause any problems in practice.

I'll think about it some more and get back to you.

[nalgeon]

Please install the package from the main branch and try it out. If everything works well, I'll release the next version.