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

Add additional unit-tests for Conditions #92

Merged
merged 5 commits into from
Jan 19, 2023

Conversation

tmshort
Copy link
Contributor

@tmshort tmshort commented Jan 17, 2023

Make sure each condition is defined (as best we can)
Enhancements to #91

Signed-off-by: Todd Short tshort@redhat.com

Make sure each condition is defined (as best we can)
Enhancements to operator-framework#91

Signed-off-by: Todd Short <tshort@redhat.com>
Copy link
Member

@awgreene awgreene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy with the direction of the PR, nice work @tmshort. Left a few comments.

Comment on lines 71 to 74
compareOp := reconciledOp.DeepCopy()
existingOp.Status, compareOp.Status = operatorsv1alpha1.OperatorStatus{}, operatorsv1alpha1.OperatorStatus{}
existingOp.Finalizers, compareOp.Finalizers = []string{}, []string{}
specDiffers := !equality.Semantic.DeepEqual(existingOp, compareOp)
unexpectedFieldsChanged := !equality.Semantic.DeepEqual(existingOp, compareOp)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we create a function that takes the reconciledOp and returns if an unexpected field was changed? it may make things easier and would allow us to update the block above to look like:

updateStatus := !equality.Semantic.DeepEqual(existingOp.Status, reconciledOp.Status)
updateFinalizers := !equality.Semantic.DeepEqual(existingOp.Finalizers, reconciledOp.Finalizers)
unexpectedFieldsChanged := checkForUnexpectedFieldChanges(reconciledOp) # Function name could be different.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd have to also pass existingOp in, but yeah, this seems like a good idea.

Expect(conds).To(ContainElement(HaveField("Type", t)))
}
})
It("has matching gnerations in Conditions", func() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a misspelling here, but I'm not sure if generations was the intended word to be spelt.

Suggested change
It("has matching gnerations in Conditions", func() {
It("has matching generations in Conditions", func() {

@@ -28,13 +28,20 @@ type OperatorSpec struct {
}

const (
// TODO(user): add more Types
// TODO(user): add more Types, here and into GetTypes()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this note.

Comment on lines 38 to 43
func GetTypes() []string {
// TODO(user): add Types from above
return []string{
TypeReady,
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there's a way to do this without exporting GetTypes(). This is more of an implementation detail than something that should be part of the API.

This is also only something we'd use in tests, I think?

Maybe something like:

internal/operatorutil/util.go:

// ConditionTypes is the full set of Operator condition types.
//
// NOTE: This is populated by the init function in 
//       api/v1alpha1/operator_types.go
var ConditionTypes []string

And then here:

func init() {
	operatorutil.ConditionTypes = append(operatorutil.ConditionTypes,
		// Add all Operator condition types to this list.
		TypeReady,
	)
)

WDYT? Is there another way I'm not thinking of that:

  • Keeps everything self-contained in the v1alpha1 packagae
  • Keeps the list of types internal
  • Makes the list of types available to tests, perhaps in both reconciler unit tests and e2es?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me look.

Comment on lines 71 to 74
compareOp := reconciledOp.DeepCopy()
existingOp.Status, compareOp.Status = operatorsv1alpha1.OperatorStatus{}, operatorsv1alpha1.OperatorStatus{}
existingOp.Finalizers, compareOp.Finalizers = []string{}, []string{}
specDiffers := !equality.Semantic.DeepEqual(existingOp, compareOp)
unexpectedFieldsChanged := !equality.Semantic.DeepEqual(existingOp, compareOp)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd have to also pass existingOp in, but yeah, this seems like a good idea.


// The ObservedGeneration should match the resource generation
for _, c := range getOperator.Status.Conditions {
Expect(c).To(HaveField("ObservedGeneration", getOperator.GetGeneration()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: HaveField doesn't give us compile-time checks on the field name, so its susceptible to typos, for example.

Suggested change
Expect(c).To(HaveField("ObservedGeneration", getOperator.GetGeneration()))
Expect(c.ObservedGeneration).To(Equal(getOperator.GetGeneration()))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd agree with you 100% if this were not test code. Test code, on the other hand, I could see it either way.

@awgreene
Copy link
Member

/approve

@awgreene
Copy link
Member

Nice work on this @tmshort

@tmshort
Copy link
Contributor Author

tmshort commented Jan 19, 2023

Ping @joelanford, this should address everything.

Copy link
Member

@joelanford joelanford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Looks great!

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 19, 2023
@tmshort tmshort merged commit d1b2189 into operator-framework:main Jan 19, 2023
@tmshort tmshort deleted the conditions branch January 19, 2023 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants