-
Notifications
You must be signed in to change notification settings - Fork 52
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
add unit tests for createHeadlessSvcIfNecessary #526
add unit tests for createHeadlessSvcIfNecessary #526
Conversation
Hi @dejanzele. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
✅ Deploy Preview for kubernetes-sigs-jobset canceled.
|
/cc @danielvegamyhre |
6d92e4e
to
b53124e
Compare
/ok-to-test |
b53124e
to
d53c8cc
Compare
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
/assign @danielvegamyhre @ahg-g
} | ||
fakeClientBuilder.WithObjects(svc) | ||
} | ||
fakeClient := fakeClientBuilder.Build() |
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 think we should use an interceptorFunc in the fake client (as described here) in order to validate the actual r.Create(svc)
calls done in the function.
d53c8cc
to
bbc5bb1
Compare
thanks for the review @danielvegamyhre, I have addressed your comments |
bbc5bb1
to
7e6e6f5
Compare
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 after 2 minor comments.
return errors.New("unexpected error") | ||
} | ||
if !tc.expectServiceCreate { | ||
t.Fatal("unexpected service creation") |
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.
Why not t.Error() here? Don't we want to continue running the rest of the tests?
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 am not sure, it is an error if an unexpected service creation happens, but does it make sense to do further assertion on that service, if we didn't expect service creation in the first place?
At the end we also have assertions how many services we expected to be created (1 if we expect, 0 if we don't) which would also get skipped.
I don't have a strong opinion, you can make the decision.
7e6e6f5
to
8526b6a
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danielvegamyhre, dejanzele, kannon92 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 |
Add unit tests for createHeadlessSvcIfNecessary