Tf test 1.8.3 - Cannot resolve properly provider definition "Provider type mismatch"

[seblatre]

Terraform Version

$ terraform version
Terraform v1.8.3
on windows_amd64

### Terraform Configuration Files

`module_to_test/main.tf`
```terraform
terraform {
  required_providers {
    restapi = {
      source  = "Mastercard/restapi"
      version = "~> 1.18.2"
    }
  }
}

module_to_test/tests/unit.tftest.hcl

provider "restapi" {
  [...]
}
provider "azuredevops" {
  org_service_url = "https://dev.azure.com/foobar"
}

run "setup_azdevops" {
  command = apply

  providers = {
    azuredevops = azuredevops
  }

  variables {
    [...]
  }

  module {
    source = "../azdevops"
  }
}

# Passing test
run "azdevops_test" {
  [...]
}

azdevops/main.tf

terraform {
  required_providers {
    azuredevops = {
      source  = "microsoft/azuredevops"
      version = "~> 1.0.1"
    }
  }
}
[...]

Debug Output

Not relevant for this use case as we have a clear error message shown

Expected Behavior

The terraform init should work for the above context summed up like this:
A side module azdevops is requiring the microsoft/azuredevops provider to run and output some data. These data are then used as input to the tested module but this tested module has no knowledge about this azuredevops provider (and we don't want to have coupling with it)

Actual Behavior

The following errors are raised when doing terraform init & terraform providers:

$ terraform init

Initializing the backend...
Initializing modules...

Initializing provider plugins...
- Finding microsoft/azuredevops versions matching "~> 1.0.1"...
- Finding mastercard/restapi versions matching "~> 1.18.2"...
- Finding latest version of hashicorp/azuredevops...
- Installing microsoft/azuredevops v1.0.1...
- Installed microsoft/azuredevops v1.0.1 (signed by a HashiCorp partner, key ID 6F0B91BDE98478CF)
- Installing mastercard/restapi v1.18.2...
- Installed mastercard/restapi v1.18.2 (self-signed, key ID DCB8C431D71C30AB)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/azuredevops: provider registry registry.terraform.io does not have a provider named
│ registry.terraform.io/hashicorp/azuredevops
│
│ Did you intend to use microsoft/azuredevops? If so, you must specify that source address in each module which requires that provider. To see which modules are currently
│ depending on hashicorp/azuredevops, run the following command:
│     terraform providers

$ terraform providers

Providers required by configuration:
.
├── provider[registry.terraform.io/mastercard/restapi] ~> 1.18.2
└── test.tests\unit
    ├── provider[registry.terraform.io/hashicorp/azuredevops]
    └── run.setup_azdevops
        └── provider[registry.terraform.io/microsoft/azuredevops] ~> 1.0.1

Steps to Reproduce

1. terraform init

Additional Context

N/A

References

Already opened as discussion in the forum:
https://discuss.hashicorp.com/t/tf-1-8-3-test-im-not-able-to-select-the-right-provider-for-sub-module/67016

[liamcervante]

Hi @seblatre, thanks for filing this!

As discussed in the forum post, the test command isn't checking the testing modules for provider definitions when working out which type to assign providers defined directly within the testing file. This means it isn't finding the provider type for azuredevops, and attempts to load it from hashicorp as a fallback.

For others viewing this, there is a workaround. If you add the required_provider definition for azuredevops into your main configuration under test, then the test command does discover the definition and downloads the correct provider.

We'll need to update the init command so that it does a bit analysis of the configuration to work out the relevant required provider blocks for each defined provider.

Thanks for filing the issue!

[liamcervante]

This will be fixed in the upcoming v1.9 release series. In the meantime the recommended workaround is to specify any problematic providers within the required_providers block within the main configuration under test.