[CT-1264] [Feature] Support "debugging columns" across multiple tests

[elyobo]

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

Some tests, including not_null and (soon) dbt_utils.expression_is_true use the store_failures configuration to decide which columns to select. This improves performance and controls costs in some engines (notably BigQuery).

This still leaves us with expensive queries when store failures is turned on, however, and leaves us with no debugging information when it's turned off. As discussed in dbt-labs/dbt-utils#683 (comment) I think it would be useful to allow tests to configure a set of columns to select which would then be used instead of * for storing tests and 1 when not storing tests. The existing tests mentioned above are obvious candidates for this functionality; there may be others as well.

@joellabes appears to have a pretty good handle on how this would work (I don't!) and has provided some example code there that I'm happy to look at integrating if there's interest in this idea.

Describe alternatives you've considered

Leave as is; developers when debugging can manually add the columns they need, and can eat the additional costs if storing failures.

Who will this benefit?

Improves DX when debugging test failures, both interactively (copying the compiled test code will include appropriate columns) and when reviewing stored failures (as an already-appropriate-for-this-test-failure subset of columns will be included instead of everything).

Reduces costs for stored test failures on engines where this matters (BigQuery) which still use select *.

Are you interested in contributing this feature?

Happy to help; minimal understanding of dbt internals, beginner dbt user. I had managed to contribute very simple changes to dbt utils with some assistance though!

Anything else?

No.

[lostmygithubaccount]

hi @elyobo, thanks for opening! we'd be happy to help you work through issues if you or somebody else from the community can develop a working proof-of-concept with macro code, then proceed to build into dbt-utils or dbt-core as it makes sense

as-is, I think this issue needs a bit more refinement and engagement on what the solution would look like. some initial documentation that might help in getting started: https://docs.getdbt.com/docs/building-a-dbt-project/tests#more-generic-tests

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

[github-actions]

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers.