-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🦁
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe then you nay use testify/require
instead? I think that require.NoError() terminates the execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotestyourself/gotest.tools#71 adds some more top level asserts for handling errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
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>
b144de7
to
5155cda
Compare
rebased and green |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -37,7 +38,7 @@ func TestLoadFileSyntaxError(t *testing.T) { | |||
}`) | |||
|
|||
_, 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay let’s merge what we have now, and improve in follow ups; thanks!
LGTM
We already use
gotestyourself
packages extensively indocker/cli
andtestify/assert
has many issues, so replace testify withgotestyourself/assert
(godoc).The automated migration commit was done using gty-migrate-from-testify.