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
Increase test coverage for groups/ #2873
Increase test coverage for groups/ #2873
Conversation
Skipping CI for Draft Pull Request. |
/test all |
/assign @spiffxp |
6b8a5ce
to
94abbfe
Compare
@spiffxp @dims while writing tests - I'm a little confused regarding the logic around creating/updating groups: Lines 187 to 209 in 75c0411
Here, in the top most if condition itself it is checked that Name and Description are non-empty and then again in the if condition it is checked. Is the intent of the top most if condition, i.e.:Line 187 in 75c0411
to make sure that updates do not clear names and descriptions of the google groups? If that is the intent then, the code above this will also need to be changed: Lines 168 to 181 in 75c0411
since there is a possibility of groups with empty names and descriptions being created. |
/test all |
3a13fe9
to
aa5a6f3
Compare
/test ? |
@MadhavJivrajani: The following commands are available to trigger required jobs:
Use
In response to this:
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. |
aa5a6f3
to
9e96b96
Compare
@spiffxp the PR's ready for review, I've added the required tests, PTAL :) |
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
- Stub out clientErrCheckFunc for testing so that returned errors from fake client can be checked easily. - Add methods to create admin and group services by taking in custom clients and clientErrCheckFunc Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
9e96b96
to
9db32f0
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.
I've got some style / corner-case nits. Overall though I think this is great coverage.
// Groups is a mapping from groupKey to *admin.Group | ||
Groups map[string]*admin.Group | ||
// Members is a mapping from groupKey -> members of that group | ||
// Members of a group are a mapping from memberKey -> *admin.Member | ||
Members map[string]map[string]*admin.Member |
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.
map[string]map[string]
feels off. Makes me wonder if we're missing a type that holds both the Group and its Members
"ReconcileMembers": "true", | ||
}, | ||
Members: []string{}, // member removed |
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.
Do we have a test case that confirms ReconcileMembers: false
behavior for a member? Like proof that attempting to remove a member won't work if this setting is false
groups/service_test.go
Outdated
"k8s.io/k8s.io/groups/fake" | ||
) | ||
|
||
func augmentAdminServiceFakeClient(fakeClient *fake.FakeAdminServiceClient) *fake.FakeAdminServiceClient { |
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.
Ah, here's where the fixtures are hidden. I feel like it would be better to put these closer to the reconcile tests so I don't have to keep bouncing back and forth here. I don't have a suggestion off the top of my head though.
FWIW I also wonder if it'd be better to pass this data in via the constructor, then less code needs to be aware it's dealing with / mutating a fake
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.
How about providing a constructor that returns an augmented fake client?
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
// desired state is not nescessarily the same as expected state. | ||
// We might need the two of them to differ in cases where we want | ||
// to test out functionality where our desired state warrants for | ||
// a change but in actuality this change should not occur - which | ||
// is signified via expected state. shouldConsiderExpectedState is | ||
// what differentiates what we should consider when comparing results. | ||
// If false - desired is same as expected. This is done because in | ||
// most cases these two are same and we can avoid clutter. | ||
shouldConsiderExpectedState bool | ||
desiredState []GoogleGroup | ||
expectedState []GoogleGroup |
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.
@spiffxp I've added a test for testing out reconciliation for ReconcileMembers
setting set to "false"
. In order to do so, we would need another dimension called expectedState
to verify if things worked correctly for such a case. However, adding expectedState
to all test cases resulted in a lot of bloat - which is why I went with this approach. Let me know if this is okay or if I should change it.
@spiffxp I've addressed most comments, PTAL |
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 the test data could be pruned down a bit still but this has been hanging out enough, improvements can be done as followup
/approve
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: MadhavJivrajani, spiffxp 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 |
This PR adds fake clients to test out code in groups/
TODO:
Fixes #420
/area groups