Invalid test config: accepted_values" dbt test failure

TL;DR

The accepted_values test definition has a wrong key or shape. The correct form nests a values list under accepted_values. Fix the YAML, reparse, and rerun the test.

Error

"Invalid test config: accepted_values" dbt test failure

Steps

1. Open the schema YAML file where the test is defined and find the accepted_values entry. Expected: you see the current (broken) key structure.
2. Rewrite it in the valid form:

tests:
  - accepted_values:
      values: ['placed', 'shipped', 'returned']

Expected: the only key under accepted_values is values, holding a list.

1. Check indentation: tests is a list under the column, and accepted_values is a list item. Expected: YAML parses cleanly (validate with a YAML linter if unsure).
2. Run dbt parse. Expected: no invalid-test-config error.
3. Run dbt test --select [MODEL NAME]. Expected: the test executes instead of failing at config time.

When to use

• dbt reports "Invalid test config" naming accepted_values.
• You just added or edited a generic test in a schema YAML file.

When not to use

• The test runs and fails on data (a data-quality fix, not a config fix).
• The error names a different test type (check that test's documented keys).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Generic test schemas are adapter-independent.

Variant phrasings

Invalid test config: not_null / unique / relationships

Same class of error: each generic test has required keys, and a typo or wrong nesting fails validation.

Test not found after defining in YAML

Often the same root cause: the YAML did not parse into a valid test definition.

Why it happens

dbt validates generic test definitions against a schema at parse time. A misspelled key, a scalar where a list belongs, or wrong nesting fails validation before the test ever runs.

Edge cases

• quote: true is a valid sibling key when values need quoting; it goes beside values, not inside it.
• Severity and tags are configured via config: inside the test definition, not as top-level keys.
• Defining the same test twice on one column with different configs can produce confusing validation errors.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7PHun5mdyrqs-GA2PJj-zQ