Replace testify assertions with gotestyourself/assert#879
Conversation
Codecov Report
@@ Coverage Diff @@
## master #879 +/- ##
=========================================
+ Coverage 53.19% 53.2% +0.01%
=========================================
Files 246 246
Lines 16021 16021
=========================================
+ Hits 8522 8524 +2
+ Misses 6929 6927 -2
Partials 570 570 |
|
Are there any plans on picking up the effort to merge these projects? test-go/testify#13 (comment) |
|
At this point, I don't think so. At the time |
| assert.Equal(t, "foo", options.Filters.Get("name")[0]) | ||
| assert.Equal(t, "lbl1=Label-bar", options.Filters.Get("label")[0]) | ||
| assert.Check(t, is.Equal("foo", options.Filters.Get("name")[0])) | ||
| assert.Check(t, is.Equal("lbl1=Label-bar", options.Filters.Get("label")[0])) |
There was a problem hiding this comment.
Hm, I find assert.NoError(...) more easy on the eye than assert.Check(....); same as assert.Equal(..); for example:
assert.Equal(t, "lbl1=Label-bar", options.Filters.Get("label")[0])vs
assert.Check(t, is.Equal("lbl1=Label-bar", options.Filters.Get("label")[0]))The last one I have to read until position 20 (with indentation, position 32) to see what kind of check is done, and the is.Equal() add another level of nesting, which makes it quite a bit harder to read.
Basically assert.Something( enables me to "scan" the code, and at a glance grasp what steps are taken.
Was this a deliberate design choice in gotestyourself?
There was a problem hiding this comment.
I find assert.NoError(...) more easy on the eye than assert.Check(....)
assert.NoError() (in testify) is almost always wrong because it only fails the test, but doesn't end execution immediately. If you don't end execution immediately on an error you will likely hit a panic on a following line. This is one of the many issues that should be fixed.
gotestyourself does have assert.NilError(). The automated migration tool preserves the existing behaviour so we ended up with a few assert.Check(t, err), but these should likely be converted to assert.NilError(t, err) in a follow up.
Was this a deliberate design choice in gotestyourself?
Yes, gotestyourself/gotest.tools#49 (comment).
I think we should add more assert.Something(), but I want to make sure we add the right ones and don't clutter the interface with infrequently used, or weak assertions.
assert.Check(t, is.Equal()) is an interesting case. We need a way to support assertions that use both T.Fail and T.FailNow. There are only so many ways this can be done. testify solved it with code generation and using a separate package. gotestyourself solves it by splitting the failure (assert.Check vs assert.Assert) from the comparison.
The convenience assertions added to the assert package all use FailNow because that should be the more common case. We could add a assert.CheckEqual() but I don't really see that as an improvement over assert.Check(t, isEqual()). Using assert.Equal() (which already exists) should be correct in most cases.
There was a problem hiding this comment.
Maybe then you nay use testify/require instead? I think that require.NoError() terminates the execution.
There was a problem hiding this comment.
Yes, you could use require.NoError(), but this PR should make it clear that it's too easy to do the wrong thing with testify. It is just one of the many problems with testify. require should be called assert, and assert should be something like "check".
gotestyourself makes it a lot easier to do the right thing by making it the most convenient and fixing the terminology.
There was a problem hiding this comment.
gotestyourself/gotest.tools#71 adds some more top level asserts for handling errors.
There was a problem hiding this comment.
@dnephin looking good! I think we should move this forward (sorry for stalling this). Looks like this'll need a massive rebase (or was it all done automated?)
There was a problem hiding this comment.
It was mostly automated, so it should be easy to just re-run that automation.
and fix some tests Signed-off-by: Daniel Nephin <dnephin@docker.com>
dnephin
force-pushed
the
update-assertions
branch
from
9157aa4 to
b144de7
Compare
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Fix tests that failed when using cmp.Compare() internal/test/testutil/assert InDelta Fix DeepEqual with kube metav1.Time Convert some ErrorContains to assert Signed-off-by: Daniel Nephin <dnephin@docker.com>
dnephin
force-pushed
the
update-assertions
branch
from
b144de7 to
5155cda
Compare
|
rebased and green |
|
|
||
| _, err := LoadFile(reader) | ||
| assert.EqualError(t, err, "JSON syntax error at byte 37: invalid character 'u' looking for beginning of value") | ||
| assert.Check(t, is.Error(err, "JSON syntax error at byte 37: invalid character 'u' looking for beginning of value")) |
There was a problem hiding this comment.
Is it possible to automate changing these to assert.Error() (gotestyourself/gotest.tools#71), or do you want to keep that for a follow-up ?
There was a problem hiding this comment.
It's possible to automate the change, but it's not the same as gotestyourself/gotest.tools#71.
The current automated migration preserves behaviour, so testify/require -> Assert, testify/assert -> Check.
I can write another migration that converts specific checks to the canonical Assert, but that is a change in behaviour (Fail -> FailNow), so I'd like to do that in a separate PR so that we can more carefully review the change.
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
okay let’s merge what we have now, and improve in follow ups; thanks!
LGTM
6 participants
We already use
gotestyourselfpackages extensively indocker/cliandtestify/asserthas many issues, so replace testify withgotestyourself/assert(godoc).The automated migration commit was done using gty-migrate-from-testify.