severity

Changelog

Tests return a number of failures—most often, this is the count of rows returned by the test query, but it could be a custom calculation. Generally, if the number of failures is nonzero, the test returns an error. This makes sense, as test queries are designed to return all the rows you don't want: duplicate records, null values, etc.

It's possible to configure tests to return warnings instead of errors, or to make the test status conditional on the number of failures returned. Maybe 1 duplicate record can count as a warning, but 10 duplicate records should count as an error.

The relevant configs are:

  • severity: error or warn (default: error)
  • error_if: conditional expression (default: !=0)
  • warn_if: conditional expression (default: !=0)

Conditional expressions can be any comparison logic that is supported by your SQL syntax with an integer number of failures: > 5, = 0, between 5 and 10, and so on.

Here's how those play in practice:

  • If severity: error, dbt will check the error_if condition first. If the error condition is met, the test returns an error. If it's not met, dbt will then check the warn_if condition. If the warn condition is met, the test warns; if it's not met, the test passes.
  • If severity: warn, dbt will skip the error_if condition entirely and jump straight to the warn_if condition. If the warn condition is met, the test warns; if it's not met, the test passes.

Note that test warn statuses will return errors instead if the --warn-error flag is passed. Unless dbt is told to treat warnings as errors, a test with warn severity will never return an error.

Configure a specific instance of a generic (schema) test:

models/<filename>.yml
version: 2
models:
- name: large_table
columns:
- name: slightly_unreliable_column
tests:
- unique:
severity: error
error_if: ">1000"
warn_if: ">10"