Configuring a provider for acceptance test without environment vars?

Terraform Providers
#1

I’m writing the testing framework for a new provider, but don’t want to pass required attributes with environment variables. Instead, I want to set them directly inside the test framework.

I’ve tried configuring the provider with a ResourceConfig, and I can verify that the provider’s ConfigureFunc is parsing the ResourceData as expected. For example:

func testAccPreCheck(t *testing.T) {
	testAccProviderConfigure.Do(func() {
		raw := map[string]interface{}{
			"broker_password": "pass",
			"broker_username": "user",
			"broker_url":      "http://localhost:1234/",
		}

		err := testAccProvider.Configure(context.Background(), terraform.NewResourceConfigRaw(raw))
		if err != nil {
			t.Fatal(err)
		}
	})
}

and

provider.ConfigureFunc = func(d *schema.ResourceData) (interface{}, error) {
    // broker_user prints as expected (without env vars)
    fmt.Println(d.Get("broker_user").(string))
}

Though I’m still getting “The argument FOO is required, but was not set” error when running the test. For example:

➜ TF_LOG=DEBUG TF_ACC=1 go test path/to/provider/tests -v

...

Error: Missing required argument

The argument "user" is required, but was not set.

I noticed it wasn’t the configuration that throws this error, and I’ve tentatively traced it back to github.com/hashicorp/hcl which makes me wonder:

  1. Is it even possible to configure a provider for acceptance test without providing required attributes via environment variables.
  2. What am I overlooking?
#2

Hi @walker,

I’m not an expert on the current plugin SDK so I might not have all of the details exactly right here, but I believe that the test framework is designed to create a fresh configuration of your provider for each test, so that it’s less likely for the behavior of one test to inadvertently affect another.

Specifically, I think the test function in the test API is itself calling Configure on the provider based on what it found in the test configuration you provided.

Given that, I think the only way to get the result you were hoping for here would be to include a provider block in each of your test configurations which specifies this fixed configuration. To make that less repetitive, perhaps you could write a helper function which takes a configuration string and appends this hard-coded provider block to the end of it, and then use that function in each of your tests to make sure they all run with the expected configuration.

1 Like
#3

That’s the detail I was overlooking! (that the testAPI itself configures the provider).

I’ve added the provider block to the test configuration, and everything is looking AOK.

Thanks for the quick response!