-
Notifications
You must be signed in to change notification settings - Fork 669
Description
Originally the AzureProvisioner
was tied to the azure management plane libraries in a way that made them unique per resource type and pretty much untestable. We used AddAzureProvisioner to add a TProvisioner with a specific resource type.
We no longer need IAzureResourceProvisioner
or AzureResourceProvisioner<TResource>
.
The only implementation is the BicepProvisioner
so all of this abstraction is wasted.
We can remove all of the layers of abstraction in the AzureProvisioner
around selecting a provisioner for a resource since it's always the BicepProvisioner
at play here.
One that is done, we want to introduce internal interfaces that we can use to decouple calling into azure, making a webrequest or hitting the disk so that we can write tests. We need to abstracts anything that interacts with:
- ArmClient
- The SecretClient
- The bicep cli - This is logic that compiles the bicep template to an ARM template.
- ProvisioningContext - The ProvisioningContext has a set of properties and concepts that need to be mockable.
- User secrets management is hard coded.
When building abstractions, do not mock the client libraries directly, mock the minimal set of functionalities needed by the AzureProvisioner and BicepProvisioner. Introduce these as internal interfaces for testing purposes.
Write tests that capture the basic functionality of the code in Aspire.Hosting.Azure.Tests in a new test class.