[CT-3460] [unit testing] Update unique id for data tests

[emmyoop]

Housekeeping

• I am a maintainer of dbt-core

Short description

New state

With the addition of unit_tests, tests now include both unit_tests and data_tests.

Update the unique_id for data_tests to use a resource_type of data_test. The new format would be data_test.package.name

Current State

Historically, tests were exclusively data_tests so there was no need to distinguish them.

unique id for unit_tests: unit_test.package.name
unique id for data_tests: test.package.name

configs for data_tests are also defined as data_tests so it's confusing for the unique id to continue to use test.

Acceptance criteria

• unique id for data tests is in the format: data_test.package.name
• resource type for data_tests would be updated to data_test
• updated manifest json schema
• allow selection by data tests ie dbt ls resource-type data_test

Impact to Other Teams

Collaborate with CA team to determine best path.
Cloud Artifact would be affected since this would create a backwards incompatible change to the manifest

Will backports be required?

no

Context

This would make the manifest not backwards compatible. It would affect retry and defer when users upgrade. Manifest would possibly need to be rebuilt when upgrades happen.

Ensure tests for defer and state modified, don't run out of characters for test names (postgres)

Backwards compatibility

It's important that if we decide to rename these unique_ids that compatibility issues are handled. We have discussed separating out the various 'nodes' dictionary resources into separate dictionaries, and one possibility might be to rename test unique ids when we do that.

In addition, we are working on creating a cleaner separation between dbt Core and the artifacts definition, including ways to handle compatibility between different versions of artifacts. When that work is in place, it could be used to mitigate the compatibility issues by enabling conversions or by setting feature flags or using whatever mechanisms are developed.

[dbeatty10]

open question

• allow selection by data tests ie dbt ls resource-type data_test

The impact of inconsistencies is that it makes the various commands harder to document, reason about, and use.

So for consistency, then it seems like we should allow all resource types here with dbt ls --resource-type unless we have a really good reason to exclude a particular resource type.

[emmyoop]

@dbeatty10 your comment may be a bigger, but related, ticket. Right now these are the allowed resource-types. Definitively a subset of what you linked above. I do agree and am of the opinion data_test, unit_test and test should allow be allowed as resource-types if we change the resource_type of from test -> data_tests as part of this ticket.

[graciegoheen]

https://getdbt.slack.com/archives/CMZ2V0X8V/p1701820009435659?thread_ts=1701787446.634629&cid=CMZ2V0X8V

For deferral to work, sounds like we'd want to recommend folks run a dbt parse with the new version to defer to.