testCheckResourceAttrSet() is broken for all but TypeString attributes

[justinTM]

I recently spent about 12 hours trying to find a bug in my code which would result in the testing function testCheckResourceAttrSet() reporting a certain resource attribute was not set.

In fact, the attribute WAS set, and the function contains a bug; when you try to check a key-value pair from Attributes which is not a simple map[string]string and instead, eg. []map[string]interface{}, the function will fail.

The proposal here is to add a comment to the function so anyone using autocomplete in the future is aware this function should be used for string attributes only.

To verify this is the case, I wrote a simple panic() test inside my resource code:

if dashs, ok := d.GetOk("dashboards"); ok {
  panic(fmt.Errorf("dashboards attr = %#v", dashs))
}

this guaranteed the test would exit with a stack trace if the resource attribute dashboards was set; it did. Removing this small bit of code resulted in the test framework error:

?       github.com/grafana/terraform-provider-grafana   [no test files]
=== RUN   TestAccDataSourceDashboardsAllAndByFolderID
    data_source_dashboards_test.go:38: Step 1/1 error: Check failed: Check 5/9 error: data.grafana_dashboards.all: Attribute 'dashboards' expected to be set
--- FAIL: TestAccDataSourceDashboardsAllAndByFolderID (3.46s)

[justinTM]

func DatasourceDashboards() *schema.Resource {
  return &schema.Resource{
    ReadContext: dataSourceReadDashboards,
    Schema: map[string]*schema.Schema{
      "dashboards": {
        Type:     schema.TypeList,
        Computed: true,
        Elem: &schema.Resource{
          Schema: map[string]*schema.Schema{
            "title": {
              Type:     schema.TypeString,
              Computed: true,
            },
            "uid": {
              Type:     schema.TypeString,
              Computed: true,
            },
            "folder_title": {
              Type:     schema.TypeString,
              Computed: true,
            },
          },
        },
      },
    },
  }
}

func dataSourceReadDashboards(ctx context.Context, d *schema.ResourceData, meta interface{}) diag.Diagnostics {
  dashboards := make([]map[string]interface{}, len(results))
  for i, result := range results {
    dashboards[i] = map[string]interface{}{
      "title":        result.Title,
      "uid":          result.UID,
      "folder_title": result.FolderTitle,
    }
  }

  if err := d.Set("dashboards", dashboards); err != nil {
    return diag.Errorf("error setting dashboards attribute: %s", err)
  }
}

[justinTM]

func TestAccDataSourceDashboardsAllAndByFolderID(t *testing.T) {
  CheckCloudTestsEnabled(t)

  checks := []resource.TestCheckFunc{
    resource.TestCheckResourceAttrSet("data.grafana_dashboards.general_folder", "dashboards"),
  }

  resource.UnitTest(t, resource.TestCase{
    PreCheck:          func() { testAccPreCheck(t) },
    ProviderFactories: testAccProviderFactories,
    Steps: []resource.TestStep{
      {
        Config: testAccExample(t, "data-sources/grafana_dashboards/data-source.tf"),
        Check:  resource.ComposeTestCheckFunc(checks...),
      },
    },
  })
}

[bflad]

Hi @justinTM 👋 Thank you for raising this and sorry you ran into trouble here.

The current Go documentation around this was certainly lacking the necessary context to help you figure out the correct solution. To that end, I've submitted #911 to better document the name and key expectations for the various helper/resource package TestCheck and TestMatch functions.

To check for existence of the TypeList attribute itself, there is a non-intuitive (unless you understand the internals of the older Terraform state storage mechanisms used in the test framework) solution required for this situation: using TestCheckResourceAttr/TestMatchResourceAttr against the expected element count for the list, which uses the special .# key. For example:

resource.TestCheckResourceAttr("data.grafana_dashboards.general_folder", "dashboards.#", "1"),

Hope this helps.

[bflad]

As a followup, #920 will add explicit error messaging for this particular situation with information how to resolve it.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.