Open bendbennett opened 10 months ago
I spent some time this morning checking out GitHub source available usage of TestCheckTypeSetElemAttrPair
and from this sample set, I would venture its usage is actually beneficial in certain scenarios where it would otherwise not be easy/possible. I would recommend a similar exercise with TestCheckResourceAttrPair
, although it has a much broader usage base. There might be a lot of TestCheckResourceAttrPair
usage for resource <> data source 1:1 attribute value checking to avoid hardcoding the values for all assertions.
Valid: Test assertions that seem meaningful to verify and otherwise difficult or not possible (e.g. validating API via data source picks up expected resource indirectly)
Extraneous via direct configuration: Test assertions against configuration attribute value references. While extraneous, these seem to be implemented for full(er) coverage.
Extraneous via computed configuration: Test assertions using computed attribute, but due to configuration attribute value reference. While extraneous, these seem to be implemented for full(er) coverage.
Extraneous and errant: Test assertions using invalid attribute paths (e.g. not sets) and against configuration attribute value references. While extraneous, these seem to be implemented for full(er) coverage.
The proposed ValueComparer
interface in https://github.com/hashicorp/terraform-plugin-testing/issues/295 could be something that helps with a re-implementation of TestCheckResourceAttrPair()
for state checks. In this model, the pair check could be tailored towards adding both resource attribute values at the same time and not requiring a separate initialization of the check itself like the multiple step checks.
Following are some example usages of TestCheckResourceAttrPair
.
resource - data source 1:1 comparisons - avoiding hardcoding of values Vast majority of results appear to be from AWS provider or forks of the AWS provider.
Background
As part of the implementation of state checks which leverage tfjson.State, built-in state checks, which are implementations of TestCheckFunc (e.g., TestCheckResourceAttr) are being deprecated in favour of state checks that are based on interrogating tfjson.State.
All of the implementations of TestCheckFunc which handle checking individual values, will have an equivalent state check implemented with the new state checks that leverage tfjson.State. However, the built-in implementations of TestCheckFunc which deal with pairs of values will be deprecated without replacement.
Purpose of this Issue
The purpose of this issue is to provide a placeholder for signalling use-cases and interest in having built-in state checks which operate on tfjson.State that replicate the behaviour of
TestCheckResourceAttrPair
and/orTestCheckTypeSetElemAttrPair
.References
266
276