Skip to content
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

Merged
merged 3 commits into from
Dec 12, 2023
Merged

Randomize Unit Tests #108

merged 3 commits into from
Dec 12, 2023

Conversation

razo7
Copy link
Member

@razo7 razo7 commented Nov 26, 2023

  1. Randomize unit tests
  2. Ensure unit tests are independent for randomly running the specs

Copy link
Contributor

openshift-ci bot commented Nov 26, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@mshitrit
Copy link
Member

/test ?

Copy link
Contributor

openshift-ci bot commented Nov 26, 2023

@mshitrit: The following commands are available to trigger required jobs:

  • /test 4.12-ci-bundle-my-bundle
  • /test 4.12-images
  • /test 4.12-openshift-e2e
  • /test 4.12-test
  • /test 4.13-ci-bundle-my-bundle
  • /test 4.13-images
  • /test 4.13-openshift-e2e
  • /test 4.13-test
  • /test 4.14-ci-bundle-my-bundle
  • /test 4.14-images
  • /test 4.14-openshift-e2e
  • /test 4.14-test
  • /test 4.15-ci-bundle-my-bundle
  • /test 4.15-images
  • /test 4.15-openshift-e2e
  • /test 4.15-test

Use /test all to run all jobs.

In response to this:

/test ?

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.

@mshitrit
Copy link
Member

/test 4.12-openshift-e2e

@razo7 razo7 marked this pull request as ready for review November 29, 2023 00:29
@razo7 razo7 changed the title Randomize Unit Tests and Run them Twice Randomize Unit Tests Nov 29, 2023
@@ -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())
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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) {
Copy link
Member

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

Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

@clobrano clobrano Dec 11, 2023

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))
}

Copy link
Member Author

@razo7 razo7 Dec 11, 2023

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.

Copy link
Contributor

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 😅

@slintes
Copy link
Member

slintes commented Dec 7, 2023

lgtm

but did we actually agree that we want to have this? I remember some discussion in chat... 🤔

@razo7
Copy link
Member Author

razo7 commented Dec 7, 2023

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
Copy link
Contributor

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}

Copy link
Member Author

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
Copy link
Contributor

openshift-ci bot commented Dec 12, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@razo7
Copy link
Member Author

razo7 commented Dec 12, 2023

/retest

1 similar comment
@razo7
Copy link
Member Author

razo7 commented Dec 12, 2023

/retest

@openshift-merge-bot openshift-merge-bot bot merged commit b404e39 into medik8s:main Dec 12, 2023
18 checks passed
@razo7 razo7 deleted the randomize-ut branch January 7, 2024 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants