Skip to content

Simplify AzureProvisioner and make it testable #8752

@davidfowl

Description

@davidfowl

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:

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.

Metadata

Metadata

Assignees

Labels

area-integrationsIssues pertaining to Aspire Integrations packagesazureIssues associated specifically with scenarios tied to using Azure

Type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions