-
Notifications
You must be signed in to change notification settings - Fork 811
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
test-e2e - Added several Fatal calls #1629
test-e2e - Added several Fatal calls #1629
Conversation
Build Failed 😱 Build Id: 3a0cdc27-aa72-4d91-8ccd-9c6e1f74dcd9 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
871960d
to
99f9ffe
Compare
Build Succeeded 👏 Build Id: 286498f2-7a32-410a-ba75-ddd479f5b360 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
99f9ffe
to
d04393f
Compare
Build Failed 😱 Build Id: 647b924e-e574-461e-a2e0-79a4b6082ddd To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
d04393f
to
a1ea40c
Compare
Build Succeeded 👏 Build Id: 84f66a8f-816d-471c-8958-843dc5d0a698 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
test/e2e/gameserver_test.go
Outdated
assert.Equal(t, "3\n", reply) | ||
|
||
err = wait.Poll(time.Second, time.Minute, func() (bool, error) { | ||
gs, err = framework.AgonesClient.AgonesV1().GameServers(framework.Namespace).Get(gs.ObjectMeta.Name, metav1.GetOptions{}) | ||
if err != nil { | ||
if !assert.NoError(t, err) { |
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.
Same as all the above - I don't think these are providing any kind of extra value, and could be confusing.
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.
There are places where we check errors with assert library in tests, that is why I decided to do the same:
https://github.com/googleforgames/agones/blob/master/pkg/util/apiserver/apiserver_test.go#L100
https://github.com/googleforgames/agones/blob/master/test/e2e/fleetautoscaler_test.go#L358
https://github.com/googleforgames/agones/blob/master/test/e2e/gameserverallocation_test.go#L356
As I see, currently there is no single approach and we use both options across the project. You are right, there is no big difference, but as far as this is a test file I decided to use a testing library here.
In which cases do you think we should use err != nil or assert.NoError() ?
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 don't know if I have strong opinions on either one. @roberthbailey I feel like you had opinions on this at one stage.
I feel like consolidating to:
if !assert.NoError(t, err) {
assert.FailNow(t, "the is my message for why this failed")
}
Feels like the solution that best takes advantage of the test libraries we use, but that I think Robbie has preferred if err != nil
more?
Thoughts?
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 redundant to both assert.NoError and then call Fail, since the former calls fail already: https://github.com/stretchr/testify/blob/master/assert/assertions.go#L1327
The one place where I don't recommend using the assert calls in tests is in goroutines, since calling asserts there don't necessarily bubble up nicely back to the main testing thread and give you a good idea of why a test failed. In those cases, doing "normal" error checking (if err != nil
) and returning regular errors from the goroutines and then doing the asserts when they come back to the main routine is generally nicer. This is where I generally add comments about doing the normal error checking.
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 redundant to both assert.NoError and then call Fail, since the former calls fail already:
But FailNow
will stop the test at that specific moment, which I think is the point. Or am I missing the point of your comment?
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, aborting the test in case of an error is an idea, because if we go further nil value will be used. As a result, I’ve noticed nil pointer exceptions in some tests along with assert-fail messages in case if test fails.
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.
If we assert twice then we will duplicate error logs in the test output. So if we need to fail now I'm in favor of doing a regular if err != nil
check to reduce noise in the test logs.
a1ea40c
to
a748bd0
Compare
@markmandel I've updated PR taking into account your comments. Please check. |
Build Succeeded 👏 Build Id: 7f2a3504-c85b-41c2-b52f-f308c72ae174 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
We need them in order to avoid nil pointer exceptions in some places fix
5b25a6f
to
e7f1605
Compare
Build Failed 😱 Build Id: f3858f7b-07a0-4f42-9b66-5e2e38839185 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Build Succeeded 👏 Build Id: ac3bdf3e-b580-4b66-8d2a-ae5a05c1e443 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
e7f1605
to
a2e2b68
Compare
a2e2b68
to
e461950
Compare
Build Succeeded 👏 Build Id: a190d042-4f3e-4782-b178-b9210305dd31 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Build Failed 😱 Build Id: c5f3c455-c01e-437e-bdc0-775ace4557c3 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Build Succeeded 👏 Build Id: 123eb4f7-fdf5-4c83-9f71-c03d63d75321 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Updated again. I've replaced |
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 like it! LGTM!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akremsa, markmandel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* test-e2e - Added several Fatal calls We need them in order to avoid nil pointer exceptions in some places
What type of PR is this?
What this PR does / Why we need it:
Added those additional Fatal calls in order to avoid nil pointer exceptions in some places.