Why advanced testing catches subtle data issues in dbt - Visual Breakdown

Concept Flow - Why advanced testing catches subtle data issues

Start: Data Load

↓

Basic Tests Run

↓

Detect Obvious Errors?

No→Proceed

|Yes↓

Fix Errors

↓

Advanced Tests Run

↓

Detect Subtle Issues?

No→Data Ready

|Yes↓

Investigate & Fix

↓

Repeat Advanced Tests

Data first passes basic tests to catch clear errors, then advanced tests find subtle issues before data is ready.

Execution Sample

dbt

select * from users where email is null;
-- Basic test: check missing emails

select count(distinct user_id) from orders;
-- Advanced test: check unique user orders count

select count(*) from orders where order_amount < 0;
-- Advanced test: check for negative amounts

This code runs basic and advanced tests to find missing emails and subtle data problems like duplicates or negative values.

Execution Table

Step	Test Description	Query Result	Issue Detected	Action Taken
1	Basic test: missing emails	3 rows found	Yes - missing emails	Flag and fix missing emails
2	Advanced test: unique user orders count	Count matches expected	No	No action needed
3	Advanced test: negative order amounts	2 rows found	Yes - negative amounts	Investigate and correct data
4	Re-run advanced tests after fixes	No issues found	No	Data ready for use

💡 All tests passed after fixes, data is clean and ready

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
missing_emails_count	unknown	3	3	0	0
unique_user_orders_count	unknown	unknown	expected count	expected count	expected count
negative_order_amounts_count	unknown	unknown	unknown	2	0

Key Moments - 2 Insights

Why do basic tests not catch negative order amounts?

Basic tests check obvious errors like missing values (see Step 1 in execution_table), but negative amounts are subtle and require advanced tests (Step 3).

Why run advanced tests after fixing basic errors?

Fixing basic errors can reveal or affect subtle issues, so advanced tests are repeated to ensure all problems are caught (Step 4).

Visual Quiz - 3 Questions

Look at the execution table, how many missing emails were found in the basic test?

A 3

B 2

C 0

D 5

💡 Hint

Check Step 1 under 'Query Result' in the execution_table

At which step were negative order amounts detected?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look for 'negative order amounts' in the 'Test Description' column

If the advanced test for unique user orders count failed, what would change in the execution table?

A Step 2 would show 'No' under 'Issue Detected'

B Step 2 would show 'Yes' under 'Issue Detected'

C Step 1 would show 'Yes' under 'Issue Detected'

D Step 4 would be skipped

💡 Hint

Check how 'Issue Detected' is marked for each step in the execution_table

Concept Snapshot

Advanced testing in dbt:
- Runs after basic tests catch obvious errors
- Finds subtle data issues like duplicates or invalid values
- Helps ensure data quality before use
- Requires writing specific SQL tests
- Repeat tests after fixes to confirm data is clean

Full Transcript

In dbt, data quality is checked first by basic tests that catch clear errors like missing values. Then, advanced tests run to find subtle problems such as duplicates or negative amounts. The process starts with loading data, running basic tests, fixing any found errors, then running advanced tests. If advanced tests find issues, those are investigated and fixed, and tests are repeated until no issues remain. This layered testing ensures data is reliable and ready for analysis or reporting.

Practice

1. Why is advanced testing important in dbt for data quality?

easy

A. It makes the data load faster.

B. It reduces the size of the database.

C. It finds subtle data issues that simple tests might miss.

D. It automatically fixes all data errors.

Solution

1. Step 1: Understand the role of advanced testing

   Advanced testing is designed to catch hidden or subtle data problems that basic tests do not detect.

2. Step 2: Compare with other options

   The other options describe unrelated or incorrect effects of advanced testing.

3. Final Answer:

   It finds subtle data issues that simple tests might miss. -> Option C

4. Quick Check:

   Advanced testing = finds subtle issues [OK]

Hint: Advanced tests catch hidden problems, not speed or size [OK]

Common Mistakes:

• Thinking advanced tests speed up data loading
• Assuming advanced tests reduce database size
• Believing advanced tests fix errors automatically

2. Which of the following is the correct syntax to define a custom test in dbt?

easy

A. tests:
unique_test:
test: unique
column_name: id

B. tests:
- unique_test:
column_name: id

C. tests:
- name: unique_test
test: unique
column_name: id

D. tests:
- name: unique_test
test: unique
column_name: id
severity: error

Solution

1. Step 1: Review dbt test YAML syntax

   Custom tests in dbt are defined with a name, test type, column, and optional severity in a list format.

2. Step 2: Identify correct structure

   tests: - name: unique_test test: unique column_name: id severity: error correctly uses a list item with name, test, column_name, and severity keys.

3. Final Answer:

   tests:\n - name: unique_test\n test: unique\n column_name: id\n severity: error -> Option D

4. Quick Check:

   Correct YAML list with keys = tests: - name: unique_test test: unique column_name: id severity: error [OK]

Hint: Custom tests need name, test, column, and optional severity [OK]

Common Mistakes:

• Using incorrect YAML indentation
• Missing the 'name' key for the test
• Not using a list for multiple tests

3. Given this dbt test SQL snippet, what will be the output if the table has duplicate user_ids?

SELECT user_id, COUNT(*)
FROM {{ ref('users') }}
GROUP BY user_id
HAVING COUNT(*) > 1

medium

A. A list of user_ids that appear more than once

B. An error because COUNT(*) cannot be used with GROUP BY

C. An empty result if no duplicates exist

D. A count of all user_ids in the table

Solution

1. Step 1: Understand the SQL query

   The query groups rows by user_id and selects those with count greater than 1, meaning duplicates.

2. Step 2: Determine output when duplicates exist

   If duplicates exist, the query returns user_ids with more than one occurrence.

3. Final Answer:

   A list of user_ids that appear more than once -> Option A

4. Quick Check:

   GROUP BY + HAVING COUNT(*) > 1 = duplicates list [OK]

Hint: HAVING COUNT(*) > 1 finds duplicates [OK]

Common Mistakes:

• Thinking COUNT(*) can't be used with GROUP BY
• Expecting total count instead of filtered duplicates
• Confusing empty result with error

4. You wrote a dbt test to check for nulls in the email column, but it always passes even when nulls exist. What is the likely issue?

medium

A. The test is running on the wrong model reference.

B. The test is using COUNT(email) instead of COUNT(*)

C. The test is written as a schema test instead of data test.

D. The test SQL is missing a WHERE clause to filter nulls.

Solution

1. Step 1: Analyze why nulls are not detected

   COUNT(email) only counts non-null values, so tests relying on it will miss nulls and pass incorrectly.

2. Step 2: Check other options

   The other options cause different issues, like running on wrong data or incorrect test type.

3. Final Answer:

   The test is using COUNT(email) instead of COUNT(*) -> Option B

4. Quick Check:

   COUNT(email) ignores nulls [OK]

Hint: COUNT(column) ignores nulls [OK]

Common Mistakes:

• Using COUNT(column) which ignores nulls
• Confusing schema and data tests
• Referencing wrong model in test

5. You want to create an advanced dbt test that checks if the order_date is always before the ship_date. Which approach best catches subtle data issues?

hard

A. Write a SQL test that selects rows where order_date >= ship_date.

B. Use a built-in unique test on order_date.

C. Create a schema test to check order_date is not null.

D. Add a test that counts total rows in the orders table.

Solution

1. Step 1: Define the data rule to test

   The rule is order_date must be before ship_date, so invalid rows have order_date >= ship_date.

2. Step 2: Choose the test that finds violations

   A SQL test selecting rows where order_date >= ship_date will catch subtle errors where dates are reversed or equal.

3. Final Answer:

   Write a SQL test that selects rows where order_date >= ship_date. -> Option A

4. Quick Check:

   Test selects invalid date order rows [OK]

Hint: Test selects rows violating the date order rule [OK]

Common Mistakes:

• Using unique test which doesn't check date order
• Checking only for nulls misses order errors
• Counting rows doesn't validate date logic