✨ (go/v4): Add tests for the webhooks and controllers which are created so that suite_test are no longer ignored

[dashanji]

How to reproduce?

Add any valid ginkgo assert such as Expect(1).To(Equal(2)) to the BeforeSuite and AfterSuite. As a result, the test should fail, but it succeeds actually.

What do these changes do?

Add the unit test template for webhook and controllers so that suite_test are no longer ignored.

Fixes #3646

[k8s-ci-robot]

Welcome @dashanji!

It looks like this is your first PR to kubernetes-sigs/kubebuilder 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubebuilder has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @dashanji. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[camilamacedo86]

Tests should not be automatically added to the suite_test by default. Remember, the scaffold primarily sets up the suite_test, but it doesn't generate tests for individual API/controllers or webhooks.

Given this, I'm curious: under what circumstances would you add assert checks to the Before/AfterSuite without first implementing comprehensive tests for each controller and/or webhook, especially in light of the issue scenario you've described? Could you please provide more details on this?

Moreover, if we do opt to include placeholder tests to address this concern, we should:

• Scaffold a distinct test file for each controller and webhook.
• Consider including a basic test case that would universally be valid, or at the very least, include a TODO(user): note guiding users on the next steps. For reference, you might want to check out the source code—particularly the reconcile method and the accompanying TODO comments.
• Lastly, we might need to perform small changes to the implementation of the deploy image plugin since this one scaffold tests for each controller by default. See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/golang/deploy-image/v1alpha1/scaffolds/internal/templates/controllers/controller-test.go (**Probably just add m.IfExistsAction = OverwriteFile into this template is enough so that we will re-write the controller test if any be scaffolded already)

So, what do you think?
Could you change it accordingly?

[dashanji]

Given this, I'm curious: under what circumstances would you add assert checks to the Before/AfterSuite without first implementing comprehensive tests for each controller and/or webhook, especially in light of the issue scenario you've described? Could you please provide more details on this?

Hi, @camilamacedo86, thanks for the details. Actually, in ginkgo v1, the BeforeSuite and AfterSuite can run successfully, so users can test the default case(CRDs, Controllers, and Webhooks can be installed successfully, just as what BeforeSuite does) without any changes just running make test. My point is to reserve the same adaption for users in the newest kubebuilder(v4). I don't know whether it makes sense to the community.

[camilamacedo86]

Hi, @camilamacedo86, thanks for the details. Actually, in ginkgo v1, the BeforeSuite and AfterSuite can run successfully, so users can test the default case(CRDs, Controllers, and Webhooks can be installed successfully, just as what BeforeSuite does) without any changes just running make test. My point is to reserve the same adaption for users in the newest kubebuilder(v4). I don't know whether it makes sense to the community.

Can you please describe what problem and when are you facing it?
If I create a new project (kubebuilder init)
Scaffold an API (kubebuilder create api)
Run (make test)

All works fine. So, can you pelase raise an issue with:

• What are the steps that you are performing
• What would like to see
• What are you checking instead?

[dashanji]

Hi, @camilamacedo86, thanks for the details. Actually, in ginkgo v1, the BeforeSuite and AfterSuite can run successfully, so users can test the default case(CRDs, Controllers, and Webhooks can be installed successfully, just as what BeforeSuite does) without any changes just running make test. My point is to reserve the same adaption for users in the newest kubebuilder(v4). I don't know whether it makes sense to the community.

Can you please describe what problem and when are you facing it? If I create a new project (kubebuilder init) Scaffold an API (kubebuilder create api) Run (make test)

All works fine. So, can you pelase raise an issue with:

• What are the steps that you are performing
• What would like to see
• What are you checking instead?

Thanks for the advice, I just opened an issue that can reproduce the bug.
#3646, FYI.

[dashanji]

Hi, @camilamacedo86 Could you please take another review? Thanks.

[Sajiyah-Salat]

@dashanji one thing that I noticed is common that there is a func() keywork everywhere in the code. I tried to find its origin and the logic it contains. I didnt find it till now through ide. I know this is a sillly question. But can you tell me whats the logic wriiten in func() keyword. or guide me to its origin and I will find it by my own.

[camilamacedo86]

Great work 🥇
Just a few nits:

• We should not scaffold a code that is not valid. So, for the webhooks under the test add a TODO(user): Add your logic here as we do for the reconcile and it is fine
• We should not change the go/v3 since it is deprecated. Can you please revert the changes and re-run make generate?
• The title of the PR we use to generate the changelog, I will update it accordingly to try to help out but you can check more about it in the CONTRIBUTION.md guide

After the changes please ensure that we have only 1 commit as of now so that we can get this one merged. You can squash the commits.

[camilamacedo86]

/ok-to-test

[dashanji]

@dashanji one thing that I noticed is common that there is a func() keywork everywhere in the code. I tried to find its origin and the logic it contains. I didnt find it till now through ide. I know this is a sillly question. But can you tell me whats the logic wriiten in func() keyword. or guide me to its origin and I will find it by my own.

Hi, @Sajiyah-Salat. A possible way is to debugging the kubebuilder create api/webhook then you can see the complete execution order.

The webhook test is generated here and its logic code is here.

The controller test is generated here and its logic code is here. FYI.

[dashanji]

Great work 🥇 Just a few nits:

• We should not scaffold a code that is not valid. So, for the webhooks under the test add a TODO(user): Add your logic here as we do for the reconcile and it is fine
• We should not change the go/v3 since it is deprecated. Can you please revert the changes and re-run make generate?
• The title of the PR we use to generate the changelog, I will update it accordingly to try to help out but you can check more about it in the CONTRIBUTION.md guide

After the changes please ensure that we have only 1 commit as of now so that we can get this one merged. You can squash the commits.

Make sense to me.

[camilamacedo86]

It shows great for me
I am approving

But would be nice see if we get a second reviewer as well
Let's try, if nobody be able to do this review I can either lgtm after a while

[camilamacedo86]

@varshaprasad96 @everettraven @Kavinjsir

It seems OK for me.
Since it is open for a while I will /lgtm
otherwise the author might need to rebase this one

However, if you have suggestions/objections and etc we can always address in a follow up.

[camilamacedo86]

/lgtm

[Kavinjsir]

Looks good to me!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, dashanji, Kavinjsir

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:

• OWNERS [camilamacedo86]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment