[Feature] add generic config for generic tests

[McKnight-42]

resolves #10197

Problem

We would like to update our TestBuilder class for generic tests to be able to accept any config that the user can think of needing.

examples.

models:
  - name: my_model
    columns:
      - name: colour
        tests:
          - accepted_values:
              values: ['blue', 'red']
              severity: warn
              config:
                custom_config: custom_value

Solution

in the Testbuilder class we first setup a variable with a ll defined accepted configs we can keep this a little further down we can add a if condition to process the config beyond the original of searching for the CONFIG_ARGS variable.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
• This PR includes type annotations for new and modified functions

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.70%. Comparing base (3e37d77) to head (8c2ad87).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10245      +/-   ##
==========================================
- Coverage   88.72%   88.70%   -0.02%     
==========================================
  Files         180      180              
  Lines       22476    22474       -2     
==========================================
- Hits        19942    19936       -6     
- Misses       2534     2538       +4     

Flag	Coverage Δ
integration	85.96% <100.00%> (-0.11%)	⬇️
unit	63.25% <80.00%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[mikealfare]

I like the approach of breaking out the logic into separate methods for readability. And I provided comments that align with that approach as you've implemented it.

However, I also think this could be done even better by dispatching to methods that correspond to stage instead of legacy/preferred. There's a lot of duplication in the two methods, which suggests that pivoting how it's split could be useful.

To make sure I completely understand the context, here's how I understand the intent and constraints:

• there is a legacy method of specifying config at the root, these expected config keys are captured in self.CONFIG_ARGS
• there is a preferred method of specifying config which will show up as self.args["config"] (as a result of processing data_test via self.extract_test_args())
• the same key should not show up in both methods, otherwise raise SameKeyNestedError()
• we need to render str entries, and fail on a missing macro
• we need to filter None entries

Assuming the above is correct, this could be done by translating the above steps into the below pseudo-code:

def __init__(...)
    ...
    raw_config = self._raw_config()
    self.config = self._rendered_config(raw_config)
    ...

def _raw_config(self) -> Dict[str, Optional[str]]:
    legacy_config = ...
    config = ...
    # identify issue where key is present in both
    raw_config = ...
    return raw_config

def _rendered_config(
    self,
    raw_config: Dict[str, Optional[str]],
    render_ctx: Dict[str, Any],
    column_name: Optional[str]
) -> Dict[str, Any]:
    rendered_config = {}
    for key, value in raw_config.items():
        # try to render, raising an error if the macro is missing
        # filter for `None` here since you're already looping, and you could make the argument that removing `None` values is a form of rendering
    return rendered_config

[McKnight-42]

running command

dbt list --quiet --output json --select accepted_values_table_color__blue__red

in a local project after getting models/seeds ran

shows a json object with a config of

"config": {"enabled": true, "alias": null, "schema": "dbt_test__audit", "database": null, "tags": [], "meta": {}, "group": null, "materialized": "test", "severity": "warn", "store_failures": null, "store_failures_as": null, "where": null, "limit": null, "fail_calc": "count(*)", "warn_if": "!= 0", "error_if": "!= 0", "custom_config_key": "some_value"}

[McKnight-42]

I like the approach of breaking out the logic into separate methods for readability. And I provided comments that align with that approach as you've implemented it.

However, I also think this could be done even better by dispatching to methods that correspond to stage instead of legacy/preferred. There's a lot of duplication in the two methods, which suggests that pivoting how it's split could be useful.

To make sure I completely understand the context, here's how I understand the intent and constraints:

• there is a legacy method of specifying config at the root, these expected config keys are captured in self.CONFIG_ARGS
• there is a preferred method of specifying config which will show up as self.args["config"] (as a result of processing data_test via self.extract_test_args())
• the same key should not show up in both methods, otherwise raise SameKeyNestedError()
• we need to render str entries, and fail on a missing macro
• we need to filter None entries

Assuming the above is correct, this could be done by translating the above steps into the below pseudo-code:

def __init__(...)
    ...
    raw_config = self._raw_config()
    self.config = self._rendered_config(raw_config)
    ...

def _raw_config(self) -> Dict[str, Optional[str]]:
    legacy_config = ...
    config = ...
    # identify issue where key is present in both
    raw_config = ...
    return raw_config

def _rendered_config(
    self,
    raw_config: Dict[str, Optional[str]],
    render_ctx: Dict[str, Any],
    column_name: Optional[str]
) -> Dict[str, Any]:
    rendered_config = {}
    for key, value in raw_config.items():
        # try to render, raising an error if the macro is missing
        # filter for `None` here since you're already looping, and you could make the argument that removing `None` values is a form of rendering
    return rendered_config

When I tried to combine the levels/ or hit its version of code more it would hit macro errors in dbt-adapters to augment to that style seems like it would require a higher lift to supply more configs to other existing macros.

[mikealfare]

I have some small nits that would make the code a bit more succinct, but nothing that's worth stopping from moving forward. If you have the time, take a look, otherwise merge and move on.