In dbt, tests can have different severity levels that affect how failures are handled during runs. Which severity level causes dbt to fail the entire run if the test fails?
Think about which severity level means the test failure is critical enough to stop the process.
The error severity level causes dbt to fail the entire run if the test fails. The warn level only logs a warning but continues the run.
Given a dbt test configured with severity: warn and the test fails, what is the expected behavior in the dbt run output?
version: 2
models:
- name: customers
tests:
- unique:
column_name: id
config:
severity: warnSeverity 'warn' means the test failure is noted but does not stop the run.
When a test has severity 'warn' and fails, dbt logs a warning message but continues running other models and tests.
After running dbt tests, you get a summary table with test results and their severity levels. How many tests with severity 'error' failed if the table below is given?
test_name | severity | status unique_id | error | fail not_null_email | warn | pass unique_email | error | fail accepted_values | warn | fail
Count only tests with severity 'error' and status 'fail'.
There are two tests with severity 'error' that failed: unique_id and unique_email.
A dbt test is configured as follows but the run fails unexpectedly when the test fails. Identify the misconfiguration.
tests:
- not_null:
column_name: user_id
severity: warnHowever, the run fails on this test failure.
Check where severity is placed in the test configuration.
Severity must be set inside a config block for the test, not directly under the test name. Placing it incorrectly causes dbt to ignore it and default to 'error'.
You manage a dbt project with critical and non-critical data quality tests. Which severity level should you assign to tests that must never fail without stopping the pipeline, and which to tests that should only log issues but allow the pipeline to continue?
Think about which severity stops the pipeline and which only logs warnings.
Critical tests should have severity 'error' to stop the pipeline on failure. Non-critical tests should have severity 'warn' to log issues but continue.