-
Notifications
You must be signed in to change notification settings - Fork 8
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
Randomize Unit Tests #108
Randomize Unit Tests #108
Conversation
razo7
commented
Nov 26, 2023
•
edited
Loading
edited
- Randomize unit tests
- Ensure unit tests are independent for randomly running the specs
Skipping CI for Draft Pull Request. |
/test ? |
@mshitrit: 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. |
/test 4.12-openshift-e2e |
@@ -285,7 +286,7 @@ func cleanupTestedResources(va1, va2 *storagev1.VolumeAttachment, pod *corev1.Po | |||
podTest := &corev1.Pod{} | |||
if err := k8sClient.Get(context.Background(), client.ObjectKeyFromObject(pod), podTest); err == nil { | |||
log.Info("Cleanup: clean pod", "pod name", podTest.Name) | |||
Expect(k8sClient.Delete(context.Background(), podTest)).To(Succeed()) | |||
Expect(k8sClient.Delete(context.Background(), podTest, forced)).To(Succeed()) |
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.
Would you do the same for "test-pod" in e2e 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.
Yes, and thanks for pointing this out.
But I prefer to do that in a follow-up PR as this one is more about running unit tests in a randomized way.
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.
So, maybe doing both in the next PR? Using this one only for randomization?
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.
SGTM :D #110
@@ -312,22 +315,21 @@ func cliCommandsEquality(far *v1alpha1.FenceAgentsRemediation) (bool, error) { | |||
|
|||
// testPodDeletion tests whether the pod no longer exist for successful FAR CR | |||
// and consistently check if the pod exist and was not deleted | |||
func testPodDeletion(podName string, resourceDeletionWasTriggered bool) { | |||
func testPodDeletion(podName string, wasDeleted bool) { |
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.
The func name with the wasDeleted arg is confusing. I'd prefer 2 functions for clarity. E.g. verifyPodExists
and verifyPodDeleted
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.
In my other PR, I opted for checkPodIsNotFound(podname, boolean)
.
I think this might improve readability
- checkPodIsNotFound
somePod
true, if pod was deleted - checkPodIsNotFound
somePod
false, if pod was not deleted
wdyt?
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 Marc's suggestion for two different functions seems more readable
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.
eventually, the two functions can simply call this one, since the code is basically the same
func verifyPodDeleted(podname string) {
checkPodIsNotFound(podname, true)
}
func checkPodIsNotFound(podName string, expected bool) {
podKey := client.ObjectKey{
Namespace: defaultNamespace,
Name: podName,
}
ConsistentlyWithOffset(1, func() bool {
pod := &corev1.Pod{}
err := k8sClient.Get(context.Background(), podKey, pod)
return apierrors.IsNotFound(err)
}, timeoutDeletion, pollInterval).Should(Equal(expected))
}
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.
the same
They are close to being the same. One function uses ConsistentlyWithOffset
and the other uses EventuallyWithOffset
. But they can both use ConsistentlyWithOffset
. SGTM
Edit: I will stick with the current functions.
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.
oh, I missed that. Maybe that's why I got that problem in my e2e 😅
lgtm but did we actually agree that we want to have this? I remember some discussion in chat... 🤔 |
IIRC we agreed not to do a repetition, but the concept of randomization was accepted. |
}) | ||
It("should have finalizer, taint, while the two VAs and one pod will be deleted", func() { | ||
By("Searching for remediation taint") | ||
nodeKey.Name = workerNode |
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.
Modifying variables on the fly is confusing when reading the test
Why not using directly the client.ObjectKey
?
client.ObjectKey{Name: workerNode, Namespace: defaultNamespace}
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 have no strong preference, I thought it looked easier this way, but I will change it.
Randomize all the specs per suite to test them in diffetnet orders of specs.
Needed for randomly running the specs. Set nodeKey and farNamespacedName using client.ObjectKey for better understanding the tests
Split testPodDeletion into two functions - verifyPodExists and verifyPodDeleted
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: clobrano, razo7 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 |
/retest |
1 similar comment
/retest |