Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecation of Built-In TestCheckFunc Implementations for Checking Pairs of Values #282

Open
bendbennett opened this issue Jan 25, 2024 · 3 comments
Labels
design Design research, documents, and prototyping

Comments

@bendbennett
Copy link
Contributor

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.

TestCheckFunc State Check
TestCheckResourceAttrPair Deprecated without replacement
TestCheckTypeSetElemAttrPair 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/or TestCheckTypeSetElemAttrPair.

References

@bflad
Copy link
Contributor

bflad commented Jan 29, 2024

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 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.

@bflad
Copy link
Contributor

bflad commented Feb 25, 2024

The proposed ValueComparer interface in #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design research, documents, and prototyping
Projects
None yet
Development

No branches or pull requests

2 participants