Store test failures for analysis in dbt - Step-by-Step Execution

Concept Flow - Store test failures for analysis

Run dbt tests

↓

Check test results

↓

Identify failures?

No→End

Yes↓

Extract failure details

↓

Store failures in table

↓

Use stored data for analysis

This flow shows how dbt test failures are detected, extracted, and stored for later analysis.

Execution Sample

dbt

select * from dbt_test_results
where status = 'fail';

insert into failure_analysis
select * from dbt_test_results
where status = 'fail';

This code selects failed test results and inserts them into a failure analysis table.

Execution Table

Step	Action	Query Executed	Result	Next Step
1	Run dbt tests	dbt test	Tests run, results stored in dbt_test_results	Check test results
2	Check test results	select count(*) from dbt_test_results where status = 'fail'	3 failures found	Identify failures?
3	Identify failures?	Condition: failures > 0	True	Extract failure details
4	Extract failure details	select * from dbt_test_results where status = 'fail'	3 rows of failure details	Store failures in table
5	Store failures in table	insert into failure_analysis select * from dbt_test_results where status = 'fail'	3 rows inserted	Use stored data for analysis
6	Use stored data for analysis	select * from failure_analysis	3 failure records ready for analysis	End

💡 All failures extracted and stored; analysis can proceed.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
failures_count	0	3	3	3
failure_details_rows	empty	empty	3 rows	3 rows
failure_analysis_table	empty	empty	empty	3 rows inserted

Key Moments - 2 Insights

Why do we check if failures exist before storing them?

Checking failures_count > 0 (see execution_table step 3) avoids unnecessary inserts when no failures occurred.

What happens if we skip extracting failure details before inserting?

Without extracting (step 4), we cannot insert correct failure rows; the insert would fail or be empty.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, how many failures were found?

A 0

B 3

C 1

D 5

💡 Hint

Check the 'Result' column in execution_table row 2.

At which step are failure details extracted from the test results?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for 'Extract failure details' in the 'Action' column.

If no failures were found, what would happen at step 3?

A Proceed to extract failure details

B Insert empty rows into failure_analysis

C Skip storing failures and end

D Run tests again

💡 Hint

Refer to the 'Identify failures?' condition and next step in execution_table step 3.

Concept Snapshot

Store test failures for analysis in dbt:
1. Run dbt tests to get results.
2. Check if any tests failed.
3. Extract failure details only if failures exist.
4. Insert failure details into a dedicated table.
5. Use stored failures for further analysis.

Full Transcript

This visual execution trace shows how to store dbt test failures for analysis. First, dbt tests run and results are saved. Next, we count how many tests failed. If failures exist, we extract their details and insert them into a failure_analysis table. This stored data can then be used for deeper analysis. Key points include checking for failures before inserting and extracting failure details properly. The execution table and variable tracker show each step and how variables change. This helps beginners see exactly how failure data flows from test run to storage.

Practice

1. What does setting store_failures = true in a dbt test configuration do?

easy

A. It sends an email notification when a test fails.

B. It skips the test execution entirely.

C. It deletes the rows that fail the test from the source table.

D. It saves the rows that fail the test for later analysis.

Solution

1. Step 1: Understand the purpose of store_failures

   This setting controls whether dbt saves the rows that fail a test.

2. Step 2: Identify the effect of setting it to true

   When set to true, dbt stores failing rows in a table for analysis.

3. Final Answer:

   It saves the rows that fail the test for later analysis. -> Option D

4. Quick Check:

   store_failures = true means save failing rows [OK]

Hint: Remember: store_failures saves failing rows for review [OK]

Common Mistakes:

• Thinking it skips tests instead of saving failures
• Assuming it deletes data on failure
• Confusing it with notification settings

2. Which of the following is the correct way to enable storing failures in a dbt test config?

easy

A. config(store_failures == true)

B. config(store_failures: true)

C. config(store_failures = true)

D. config(store_failures = "true")

Solution

1. Step 1: Recall dbt config syntax

   dbt uses Python-like syntax with keyword arguments inside config().

2. Step 2: Identify the correct assignment

   The correct syntax uses equals sign and boolean true without quotes.

3. Final Answer:

   config(store_failures = true) -> Option C

4. Quick Check:

   Use equals and boolean true without quotes [OK]

Hint: Use equals sign and true without quotes in config() [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using double equals (==) instead of single equals
• Putting true in quotes making it a string

3. After running a dbt test with store_failures = true, which SQL query will show the failing rows for a model named orders and test unique?

medium

A. SELECT * FROM dbt_test__orders__unique

B. SELECT * FROM orders WHERE test = 'unique' AND status = 'fail'

C. SELECT * FROM dbt_failures.orders_unique

D. SELECT * FROM test_failures.orders_unique

Solution

1. Step 1: Recall naming convention for failure tables

   dbt stores failures in tables named dbt_test__model__test.

2. Step 2: Apply model and test names

   For model 'orders' and test 'unique', the table is dbt_test__orders__unique.

3. Final Answer:

   SELECT * FROM dbt_test__orders__unique -> Option A

4. Quick Check:

   Failure table = dbt_test__model__test [OK]

Hint: Use dbt_test__model__test naming to find failure tables [OK]

Common Mistakes:

• Assuming failure data is in original model table
• Using incorrect table prefixes
• Trying to filter failures in source tables

4. You set store_failures = true in your test config, but after running tests, no failure tables appear. What is the most likely cause?

medium

A. The test did not find any failing rows, so no failure table was created.

B. You must manually create failure tables before running tests.

C. The store_failures setting only works for schema tests, not data tests.

D. Failure tables are stored in a different schema and need to be queried there.

Solution

1. Step 1: Understand when failure tables are created

   Failure tables are only created if the test finds failing rows.

2. Step 2: Check if test found failures

   If no failures, no failure table is generated.

3. Final Answer:

   The test did not find any failing rows, so no failure table was created. -> Option A

4. Quick Check:

   No failures means no failure table [OK]

Hint: No failure rows means no failure table created [OK]

Common Mistakes:

• Thinking failure tables must be pre-created
• Assuming store_failures only works for some test types
• Looking in wrong schema without verifying failures

5. You want to analyze failing rows from multiple tests on the customers model. Which approach best helps you combine all failure data for analysis?

hard

A. Manually export failure tables and merge them outside the database.

B. Create a union query combining all dbt_test__customers__* failure tables.

C. Run each test again with store_failures = false to avoid duplicates.

D. Use the original customers table and filter rows with errors.

Solution

1. Step 1: Identify failure tables for each test

   Each test creates a failure table named dbt_test__customers__testname.

2. Step 2: Combine failure tables using SQL UNION

   Use a UNION query to combine all failure rows from these tables into one result set.

3. Final Answer:

   Create a union query combining all dbt_test__customers__* failure tables. -> Option B

4. Quick Check:

   Union failure tables to analyze all failures together [OK]

Hint: Use UNION on all failure tables for combined analysis [OK]

Common Mistakes:

• Disabling store_failures loses failure data
• Merging outside database is inefficient
• Filtering original table misses failure details