Expose internal SDKv2 Diff cross-test interface

[VenelinMartinov]

This is a test-only change. It exposes an internal Diff cross-test interface for the SDKv2 bridge. It currently just calls the runDiffCheck function.

[VenelinMartinov]

This change is part of the following stack:

• Expose internal SDKv2 Diff cross-test interface #2720 ◀
  • Refactor SDKv2 set detailed diff tests #2721
    • Ensure all sdkv2 test providers have an id and an update method #2723
      • Add SDKv2 detailed diff set tests for top-level ForceNew #2724
        • Refactor SDKv2 non-set detailed diff tests #2725
          • Add SDKv2 Detailed Diff tests for list replacements #2735
            • Add SDKv2 Detailed Diff tests for lists with many elements #2736
              • Add SDKv2 Detailed Diff tests for Computed properties in sets #2740
                • Refactor SDKv2 set detailed diff tests to correct files #2741

_{Change managed by git-spice.}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.64%. Comparing base (7b3ace6) to head (5fec1c6).
Report is 7 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2720   +/-   ##
=======================================
  Coverage   69.63%   69.64%           
=======================================
  Files         301      301           
  Lines       38725    38725           
=======================================
+ Hits        26967    26970    +3     
+ Misses      10240    10238    -2     
+ Partials     1518     1517    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iwahbe]

Create and Configure both take a map[string]*schema.Schema instead of a *schema.Resource. This is to intentionally constrain the inputs to Diff to only options that can be exercised in Diff based tests.

We will probably want an option for schema.Resource.CustomizeDiff. We don't want users to be able to set schema.Resource.Importer.

[VenelinMartinov]

Yeah, this unfortunately limits the expressiveness of the test too - for example custom Create and Update methods might be required in a Diff test for implementing Computed properties. Instead of re-implementing the API with options we should have a simple check for the banned inputs. In the case of Diff tests, I don't think there are any schema inputs which should be banned - this only applies to, for example, custom Create in Create cross-tests.

[VenelinMartinov]

I don't see what Resource.Importer has to do with Diff test

[VenelinMartinov]

I don't see a good reason why we would choose to add a new interface there for specifying schemas instead of reusing the default TF SDK one - it works well enough and allows us to copy-paste provider examples and avoids unnecessary complexity.

I can add refactoring the other cross-test interfaces to my TODO list

[t0yv0]

I'm on the side of being more permissive here in the internal test code.

[iwahbe]

I don't see a good reason why we would choose to add a new interface there for specifying schemas instead of reusing the default TF SDK one

Because it keeps the tests intentional. We only add properties that can actually be tested.

it works well enough and allows us to copy-paste provider examples and avoids unnecessary complexity.

I'd rather we didn't copy-paste whole resources to test only a small part of them.

I don't see what Resource.Importer has to do with Diff test

Nothing at all, but I can set .Importer on a *schema.Resource and pass that to crosstests.Diff with this design. I'd rather that was a compiler error. I use that example because I remember someone setting .Importer for a create and asserting that the .Importer didn't panic.

I won't block the PR on this, but IMO passing *schema.Resource directly makes the tests easier to write but harder to read.

[VenelinMartinov]

passing *schema.Resource directly makes the tests easier to write but harder to read.

I don't agree about readability either. I think the benefit of options is that it is harder to get the Schema wrong. Given that there's very few people who actually write these type of tests, I think it's worth keeping it simple for now and evolving the interface once we find a need to.

Let's revisit once we have a concrete problem we are solving with the extra interface.

[pulumi-bot]

This PR has been shipped in release v3.98.0.