Add unit tests to azuremanagedcontrolplane reconciler

[troy0820]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:

This will increase coverage around the controller/reconciler code.
 
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #4290

Special notes for your reviewer:
This test is marked as an error happening for the following reasons. When it hits the path to StoreClusterInfo it cannot create a remote client because that call is trying to reach out to do this. This is expected and not meant to derail the effort around coverage. However, this doesn't show the successful path around the reconcileNormal. There are many functions/methods that I had to extract and refactor to become testable to reduce the level of abstraction around how nested the New funcs are within certain places where I can't inject but patch as done in a previous PR and as well as done here.

I did create new mocks to test the clients that we export in the services package AzureClient which held azure-sdk-for-go clients and added coverage around this as well.
I left the commits as a single point of reference if you want to review this within the context of the commits, however I can squash if this meets the satisfaction of the maintainers.

Also, the test for CreateOrUpdateAsync end in error (not failing) because the poller that is returned is something that I cannot inject to EXPECT on the return value. The call cannot be done because the return value for runtime.Poller[] is not something that the azure-sdk-defined and cannot make that interface return value a thing to utilize in the test.

• cherry-pick candidate

TODOs:

• squashed commits
• includes documentation
• adds unit tests

Release note:

None

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6102da4) 59.73% compared to head (2c6ae38) 60.45%.
Report is 46 commits behind head on main.

Files	Patch %	Lines
azure/scope/managedcontrolplane.go	50.00%	1 Missing ⚠️
controllers/azuremanagedcontrolplane_controller.go	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4303      +/-   ##
==========================================
+ Coverage   59.73%   60.45%   +0.71%     
==========================================
  Files         192      191       -1     
  Lines       19303    19201     -102     
==========================================
+ Hits        11531    11608      +77     
+ Misses       7142     6949     -193     
- Partials      630      644      +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[troy0820]

/ok-to-test

[troy0820]

/retest

[willie-yao]

Thanks for your great work on this @troy0820! This is some really good stuff, but I might have a comment on the approach to this PR. This PR modifies many of the Azure services, which are in the middle of being refactored to use ASO in #3402 rather than the Azure SDK for Go. I'm not entirely sure if the same logic would translate to the new way of structuring services, as services will no longer have their own CreateOrUpdate functions.

Also, I'm not sure if those changes are entirely necessary. If the goal is to pass in scopes to reconcileNormal, you can create them manually like how the azuremachine reconciler test does it: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/main/controllers/azuremachine_controller_test.go#L338

This is definitely my bad as I misunderstood your proposal to use mocks, so I'm super sorry for misleading you! Do you think the approach used in the azuremachine_controller_test.go would work for your case?

[troy0820]

Thanks for your great work on this @troy0820! This is some really good stuff, but I might have a comment on the approach to this PR. This PR modifies many of the Azure services, which are in the middle of being refactored to use ASO in #3402 rather than the Azure SDK for Go. I'm not entirely sure if the same logic would translate to the new way of structuring services, as services will no longer have their own CreateOrUpdate functions.

Also, I'm not sure if those changes are entirely necessary. If the goal is to pass in scopes to reconcileNormal, you can create them manually like how the azuremachine reconciler test does it: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/main/controllers/azuremachine_controller_test.go#L338

This is definitely my bad as I misunderstood your proposal to use mocks, so I'm super sorry for misleading you! Do you think the approach used in the azuremachine_controller_test.go would work for your case?

This doesn't change any of the logic that exists but makes the azure-sdk-for-go clients an interface to allow this to be tested and not reach out to azure to do things. Because this is migrating to ASO, it may not make sense to change this while allowing that other work to continue. This doesn't offer any benefit besides covering some lines and allowing to utilize these methods (the top level of abstraction) within the codebase to test. I can remove them, including the mocks.

As far as the test in question, I would really only need to do the patch method for the new.... function that I already have there.

I didn't want to use the mock for the type so I can follow the path in the method r.reconcileKubeconfig. It only gets stuck because the scopes has to call the r.StoreClusterInfo() and not being able to get around the newRemote method inside that function without patching makes the test fail/error (which is supposed to). Which is fine unless I used the mock and using the mock removes the setup for the test I'm doing.

TLDR; I will remove the client mocks and test for the azure/services/<service_name>/client_test.go and go as far down the code path as I can with the mocks I have in place.

[troy0820]

/hold

[troy0820]

/hold cancel

[willie-yao]

Looks good pending a few nits! Thanks for your patience here and I apologize again that the mocks didn't work out. I think we can still use them as a reference though in the future once ASO is implemented!

[willie-yao]

/lgtm

Great work @troy0820! 🚀

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 4f52c269e6df7b61755a4a4a20ef8153edd697cf

[nojnhuh]

/lgtm

Thanks @troy0820!

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 5d5d8f46ee6fa7a668fc489c3f47ff9628861960

[willie-yao]

/lgtm

[nojnhuh]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nojnhuh

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 [nojnhuh]

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

[willie-yao]

/retest