-
Notifications
You must be signed in to change notification settings - Fork 46
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
Check if workerGroupSpec is not empty before accessing it #549
Check if workerGroupSpec is not empty before accessing it #549
Conversation
@ChristianZaccaria Can you please provide a unit test verifying the changes? |
@sutaakar I added unit tests covering these changes. Please let me know if there are other test cases I should be covering here. Also, I am thinking of adding a RayCluster template in the test support file and perhaps append items to it in the tests to reduce the amount of code in the test file. Is this a good approach or what is the best practices on this? Thank you! :) |
@ChristianZaccaria Creating one valid RayCluster CR and then modify it is a possible approach, may increase test readability. |
258d3a4
to
89d0450
Compare
warnings, err := rcWebhook.ValidateCreate(test.Ctx(), runtime.Object(validRayCluster)) | ||
t.Run("Expected no warnings or errors on call to ValidateCreate function", func(t *testing.T) { | ||
g := gomega.NewWithT(t) | ||
g.Expect(warnings).To(gomega.BeNil()) | ||
g.Expect(err).To(gomega.BeNil()) | ||
}) |
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.
@sutaakar I only then realised that this basically covers all test cases as it will fail if the elements to be validated are not in the defined RayCluster in the test. Perhaps the tests after this one are not needed?
Also, If I do the same for the Default function, would all the other tests/assertions not be required too?
Open to thoughts on this before continuing, thanks!
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.
Thinking perhaps the assertions made for the Default
(mutating) function is required to compare outputs.
For the validating functions such as ValidateCreate
, as long as no errors are returned (meaning all elements exist in the defined RayCluster), the validation should succeed. - Making any other assertion tests not necessary. Correct me if I'm wrong
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.
For ValidateCreate
and ValidateUpdate
it is enough to have one positive test, providing negative tests to validate incorrect modification and its detection.
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.
Or possibly to have several tests, providing valid RayClusters, i.e. more elements in workerGroupSpecs and such.
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.
Hopefully, latest changes in this PR reflects the above. - One positive test case, providing negative tests for manipulated fields. Thanks!
b80e2bd
to
ecafab2
Compare
t.Run("Expected no errors on call to Default function", func(t *testing.T) { | ||
g := gomega.NewWithT(t) | ||
g.Expect(err).To(gomega.BeNil()) | ||
}) | ||
|
||
t.Run("Expected required OAuth proxy container for the head group", func(t *testing.T) { | ||
g := gomega.NewWithT(t) | ||
g.Expect(func() bool { | ||
for _, container := range validRayCluster.Spec.HeadGroupSpec.Template.Spec.Containers { | ||
if container.Name == oauthProxyContainerName { | ||
return true | ||
} | ||
} | ||
return false | ||
}()).To(gomega.BeTrue(), "Expected the OAuth proxy container to be present in the list of head group containers") | ||
}) |
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.
This boilerplate isn't needed, you can leverage test
directly as it embeds gomega:
test.Expect(err).NotTo(HaveOccurred(), "Expected no errors on call to Default function")
test.Expect(validRayCluster.Spec.HeadGroupSpec.Template.Spec.Containers).
To(ContainElement(WithTransform(ContainerName, Equal(oauthProxyContainerName))), "Expected the OAuth proxy container to be present in the list of head group containers")
With helper functions in the bottom (to be relocated into codeflare-common):
func ContainerName(container corev1.Container) string {
return container.Name
}
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.
Also this approach avoids BeTrue()
checks for element with specific value, which often don't provide meaningful context.
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.
Test can also check number of elements, making the assertion more structured:
test.Expect(validRayCluster.Spec.HeadGroupSpec.Template.Spec.Containers).
To(
And(
HaveLen(1),
ContainElement(WithTransform(ContainerName, Equal(oauthProxyContainerName))),
),
"Expected the OAuth proxy container to be present in the list of head group containers",
)
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.
That was very enlightening, thanks Karel for sharing such great expertise!
@sutaakar latest changes include one positive test for each "main" function, and several negative tests to cover the full functionality of the raycluster_webhook.go file. |
invalidRayCluster := validRayCluster.DeepCopy() | ||
|
||
t.Run("Negative: Expected errors on call to ValidateUpdate function due to EnableIngress set to True", func(t *testing.T) { | ||
invalidRayCluster.Spec.HeadGroupSpec.EnableIngress = &trueBool |
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.
Nitpick, there is a dedicate funtion to create pointer for values:
invalidRayCluster.Spec.HeadGroupSpec.EnableIngress = &trueBool | |
invalidRayCluster.Spec.HeadGroupSpec.EnableIngress = support.Ptr(true) |
@ChristianZaccaria Can you also adjust Otherwise this PR looks great, good job. |
6423b3b
to
21ef9ac
Compare
@sutaakar I made the last few changes, tests are now running as part of this PR check in the |
I made a PR to move the core functions used here to the codeflare-common repository. Should we merge that and then make the changes here or what is the appropriate approach? Thanks @sutaakar |
/lgtm
That is up to you, can be merged now and refactored later or it can wait. |
21ef9ac
to
f4bb394
Compare
f4bb394
to
954fa07
Compare
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sutaakar 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 |
4ba15ae
into
project-codeflare:main
Issue link
Jira: https://issues.redhat.com/browse/RHOAIENG-6614
What changes have been made
index out of range
error in the webhook logic. TheworkerGroupSpec
was attempted to be accessed when it doesn't exist.Verification steps
default-dsci
go test -timeout 30m -v ./test/e2e/rayjob_lightweight_test.go ./test/e2e/support.go
Checks