Update state:modified caveat re: testing

[jtcohen6]

Description & motivation

Based on this Slack thread

Previously, I was recommending selection criteria like:

dbt run -m state:modified 1+state:modified,1+test_type:data
dbt test -m state:modified

This works if the data test itself is modified, and we need to ensure that its parent models will exist when it comes time to execute that test.

If you have a multi-pronged test (e.g. relationships or a data test with 2+ parents), however, and only one of the parents is modified, then this selection criteria isn't going to cut it—the missing prong is not included in 1+state:modified.

By contrast, it is included within the criteria of @state:modified, because it's the parent of a shared child: the data test. (The fact that @ now works for tests was something of a revelation earlier today, and enabled me to close dbt-labs/dbt-core#1827.)

There's greater risk of extra baggage with this approach, since @state:modified,1+test_type:data is a more expansive set of criteria, but I think it's a small price to pay.

Pre-release docs

Is this change related to an unreleased version of dbt?

• Yes: please
  • update the base branch to next
  • add Changelog components: <Changelog>[New/Changed] in v0.x.0</Changelog>
  • add links to the "New and changed documentation" section of the latest Migration Guide
• No: please ensure the base branch is current
• Unsure: we'll let you know!

[clrcrl]

This makes sense to me