How to test SetupWithManager?

[pbxqdown]

When trying to test default generated controller code, I found that test doesn't cover SetupWithManager function. I tried to create/update resource, but CreateFunc/UpdateFunc defined in Predicates of SetupWithManager is not called.
Is it because envtest package doesn't emit event when there is change? Wondering how should we test CreateFunc/UpdateFunc in this case.
not sure whether this question is more appropriate here or in the kubebuilder repo.

[troy0820]

It's difficult to see where your test are failing to pick up the changes. If you are using the default kubebuilder scaffold for env test, you may need to modify what you wish to test. In envtest you can

Expect(<name of controller>.SetupWithManager(ctx, mgr)).ToNot(HaveOccurred()) 

during your set up (BeforeSuite) in your suite_test.go and assert on the things that your SetUpWithManager does with predicates in your test file.

Test setup help with KubeBuilder

[pbxqdown]

Thanks for response @troy0820. I already called SetUpWithManager function in test, would like to test following code inside SetUpWithManager.

nodePredicates := predicate.Funcs{
		CreateFunc: func(e event.CreateEvent) bool {
			return true
		},
		DeleteFunc: func(e event.DeleteEvent) bool {
			// if node is deleted we don't care if we should cordon it.
			return true
		},
                ...

In practice I found that no matter how I create/update nodes in envtest environment, above code is not executed. I suspect it is because envtest doesn't emit event such as node create/delete/update, so controller can not watch predicates, but not very confirmed.
This the code coverage, most uncovered code are in predicate.Funcs: SetupWithManager 11.8%

[troy0820]

Unless you’re using an existing cluster, keep in mind that no built-in controllers are running in the test context. In some ways, the test control plane will behave differently from “real” clusters, and that might have an impact on how you write tests. One common example is garbage collection; because there are no controllers monitoring built-in resources, objects do not get deleted, even if an OwnerReference is set up.

If you need to see node events, it may make sense to try this on an existing cluster where you can see the events trigger when nodes get updated. If you are just trying to vet the functionality, you could unit test the predicates to see if what changes creates true/false which would trigger the parent object of your reconciler.

[pbxqdown]

Yes. I updated my test config and it can execute CreateFunc/DeleteFunc now. still not able to execute UpdateFunc, may need to further tweak the test.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.