-
Notifications
You must be signed in to change notification settings - Fork 32
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] Improve test coverage and performance in apimachinery_status_conditions #172
[test] Improve test coverage and performance in apimachinery_status_conditions #172
Conversation
- Refactored CopyConditions function to avoid unnecessary appends and allocate slice with exact length - Reused CopyConditions in ConditionMarshal instead of using append for performance improvement and null safety
a08e581
to
379dcdc
Compare
Message: "Object validation failed", | ||
}, | ||
}, | ||
expectedJSONOutput: `[{"type":"Installed","status":"True","observedGeneration":1,"lastTransitionTime":"` + nowUTC + `","reason":"InstallSuccessful","message":"Object successfully installed"},{"type":"Ready","status":"False","observedGeneration":2,"lastTransitionTime":"` + nowUTC + `","reason":"ComponentsNotReady","message":"Object components are not ready"},{"type":"Validated","status":"Unknown","observedGeneration":3,"lastTransitionTime":"` + nowUTC + `","reason":"ValidationError","message":"Object validation failed"}]`, |
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.
what? Order does not keep consistent?? First Ready, then Installed and lastly Validated. And for the serialized string: Installed, Ready, Validated. Weird.
HAve you run the test multiple times? if order is not maintained, on multiple runs, some of them could fail
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.
Thanks for the concern! Conditions are sorted based on their Condition.Type
field in the ConditionMarshal
function before they're serialized. So, the order is consistent and not random. To answer your question, running the test multiple times should not result in any failures due to the consistent ordering provided by the sorting mechanism. Heer is ConditionMarhsal implementation, pay attention to the sorting part:
func ConditionMarshal(conditions []metav1.Condition) ([]byte, error) {
condCopy := CopyConditions(conditions)
sort.Slice(condCopy, func(a, b int) bool {
return condCopy[a].Type < condCopy[b].Type
})
return json.Marshal(condCopy)
}
Let me know if you have any other questions! 👼
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.
🤦 Sorry for that. Once again I took some assumptions that are wrong.
Looking good
This pull request adds unit tests to verify the correctness of the CopyConditions and ConditionMarshal functions in the 'common' package's apimachinery_status_conditions.go file.
It also refactors the CopyConditions function to avoid unnecessary appends and allocate a slice with the exact length.
Finally, it reuses the CopyConditions function in ConditionMarshal instead of using append for performance improvement and null safety. This work partly addresses issue #167, and more work is still in progress.