[CT-1395] [Feature] Make tests fail if model is not found

[pevidex]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

Currently, tests for tables that are not materialized and are not being referenced by other tables are skipped.
Let's say we have a table called table_1 and a developer changes its name to table_2 and runs dbt test. The tests for table_2 will be skipped with following warning:

The selection criterion 'source:source_name.table_2' does not match any nodes

It would be nice if we could configure the tests to fail instead so we get visibility on possible typos/mistakes.

Describe alternatives you've considered

I'm aware we can use --warn-errors to convert warnings to errors. However, this will be applied to all the warnings in the project which means non-related warnings will start to be thrown as errors when we want to keep them as warnings.

Who will this benefit?

We had an issue where a developer, by mistake, changed the name of one model and the tests started being skipped for that specific model. This will benefit users who need to be notified of this kind of mistakes.

Are you interested in contributing this feature?

Yes

Anything else?

No response

[lostmygithubaccount]

hi @pevidex, thanks for opening this! if you're willing to contribute this PR we can help you through it

[pevidex]

@lostmygithubaccount I intend to contribute and I'll do so in the following days!

[jtcohen6]

@lostmygithubaccount @pevidex My inclination is to treat this as a specific use case, that would be best solved by the general-purpose approach proposed in #6165

[jtcohen6]

Going to close this in favor of solving in a more general-purpose way!

[pevidex]

My inclination is to treat this as a specific use case, that would be best solved by the general-purpose approach proposed in #6165

Makes sense, if we're adding a new flag for every use case of this kind, we'll end up bloating the tool. A more generic approach sounds better 👍