Data test configurations
Related documentation
Data tests can be configured in a few different ways:
- Properties within
.yml
definition (generic tests only, see test properties for full syntax) - A
config()
block within the test's SQL definition - In
dbt_project.yml
Data test configs are applied hierarchically, in the order of specificity outlined above. In the case of a singular test, the config()
block within the SQL definition takes precedence over configs in the project file. In the case of a specific instance of a generic test, the test's .yml
properties would take precedence over any values set in its generic SQL definition's config()
, which in turn would take precedence over values set in dbt_project.yml
.
Available configurations
Click the link on each configuration option to read more about what it can do.
Data test-specific configurations
Resource-specific configurations are applicable to only one dbt resource type rather than multiple resource types. You can define these settings in the project file (dbt_project.yml
), a property file (models/properties.yml
for models, similarly for other resources), or within the resource’s file using the {{ config() }}
macro.
The following resource-specific configurations are only available to Data tests:
- Project file
- Config block
- Property file
version: 2
<resource_type>:
- name: <resource_name>
tests:
- <test_name>: # # Actual name of the test. For example, dbt_utils.equality
name: # Human friendly name for the test. For example, equality_fct_test_coverage
<argument_name>: <argument_value>
config:
fail_calc: <string>
limit: <integer>
severity: error | warn
error_if: <string>
warn_if: <string>
store_failures: true | false
where: <string>
columns:
- name: <column_name>
tests:
- <test_name>:
name:
<argument_name>: <argument_value>
config:
fail_calc: <string>
limit: <integer>
severity: error | warn
error_if: <string>
warn_if: <string>
store_failures: true | false
where: <string>
This configuration mechanism is supported for specific instances of generic tests only. To configure a specific singular test, you should use the config()
macro in its SQL definition.
General configurations
General configurations provide broader operational settings applicable across multiple resource types. Like resource-specific configurations, these can also be set in the project file, property files, or within resource-specific files.
- Project file
- Config block
- Property file
version: 2
<resource_type>:
- name: <resource_name>
tests:
- <test_name>: # Actual name of the test. For example, dbt_utils.equality
name: # Human friendly name for the test. For example, equality_fct_test_coverage
<argument_name>: <argument_value>
config:
enabled: true | false
tags: <string> | [<string>]
meta: {dictionary}
# relevant for store_failures only
database: <string>
schema: <string>
alias: <string>
columns:
- name: <column_name>
tests:
- <test_name>:
name:
<argument_name>: <argument_value>
config:
enabled: true | false
tags: <string> | [<string>]
meta: {dictionary}
# relevant for store_failures only
database: <string>
schema: <string>
alias: <string>
This configuration mechanism is supported for specific instances of generic data tests only. To configure a specific singular test, you should use the config()
macro in its SQL definition.
Examples
Add a tag to one test
If a specific instance of a generic data test:
models:
- name: my_model
columns:
- name: id
tests:
- unique:
tags: ['my_tag']
If a singular data test:
{{ config(tags = ['my_tag']) }}
select ...
Set the default severity for all instances of a generic data test
{% test my_test() %}
{{ config(severity = 'warn') }}
select ...
{% endtest %}
Disable all data tests from a package
tests:
package_name:
+enabled: false