Custom singular tests help you check specific rules or conditions in your data. They make sure your data is correct and clean.
Custom singular tests in dbt
Start learning this pattern below
Jump into concepts and practice - no test required
version: 2 models: - name: your_model_name tests: - your_custom_test_name: arg1: value1 arg2: value2 # In tests/your_custom_test_name.sql SELECT * FROM {{ model }} WHERE NOT (your_condition_here)
Custom singular tests are SQL queries that return zero rows if the test passes.
Place your test SQL files inside the tests/ folder in your dbt project.
customer_id column.version: 2
models:
- name: customers
tests:
- unique_customer_idcustomer_id has no nulls.# tests/not_null_customer_id.sql
SELECT * FROM {{ model }}
WHERE customer_id IS NULLpositive_order_amount with an argument column_name.version: 2
models:
- name: orders
tests:
- positive_order_amount:
column_name: order_amount# tests/positive_order_amount.sql SELECT * FROM {{ model }} WHERE {{ column_name }} <= 0
This example shows a custom singular test not_null_customer_id that checks for nulls in customer_id. The test query returns rows where customer_id is null, so the test fails if any such rows exist.
# dbt_project.yml name: 'my_project' version: '1.0' # models/customers.yml version: 2 models: - name: customers tests: - not_null_customer_id # tests/not_null_customer_id.sql SELECT * FROM {{ model }} WHERE customer_id IS NULL # Sample data in customers model: # customer_id | name # 1 | Alice # 2 | Bob # NULL | Eve # Running dbt test will run the custom test and find the NULL customer_id.
Custom singular tests must return zero rows to pass.
You can pass arguments to your tests via the YAML file.
Use Jinja templating to make your tests dynamic and reusable.
Custom singular tests are SQL queries that check specific data conditions.
They return zero rows if data passes the test, otherwise they fail.
You define them in tests/ and call them in your model YAML files.
Practice
Solution
Step 1: Understand the role of custom singular tests
Custom singular tests are SQL queries that check data quality by returning rows only when problems exist.Step 2: Compare options with this definition
Only To write your own SQL query that checks data quality and returns rows only if there are issues describes writing a SQL query that returns rows if there are data issues, matching the purpose of custom singular tests.Final Answer:
To write your own SQL query that checks data quality and returns rows only if there are issues -> Option BQuick Check:
Custom singular test = SQL check returning problem rows [OK]
- Confusing tests with documentation generation
- Thinking tests create tables
- Assuming tests schedule runs
schema.yml file?Solution
Step 1: Recall the schema.yml syntax for custom singular tests
Custom singular tests are referenced by their filename (without .sql) in the tests list of schema.yml.Step 2: Match options to this syntax
tests: - my_custom_test correctly references the test file tests/my_custom_test.sql. Other options use incorrect structure, extra keys, or include .sql.Final Answer:
tests: - my_custom_test -> Option DQuick Check:
schema.yml test syntax = - test_filename_without_sql [OK]
- Using 'name' or 'test' keys
- Including .sql extension
- Using map/dict structure
tests/check_positive_values.sql:
SELECT * FROM {{ ref('orders') }} WHERE amount <= 0
What will be the output if all amounts in the orders table are positive?Solution
Step 1: Understand the test SQL logic
The test selects rows where amount is less than or equal to zero.Step 2: Analyze the data condition
If all amounts are positive, no rows satisfy the condition, so the query returns zero rows.Final Answer:
An empty result with zero rows -> Option AQuick Check:
All positive amounts means zero rows returned [OK]
- Expecting a count instead of rows
- Thinking it returns all rows
- Assuming SQL syntax error
Solution
Step 1: Identify causes of SQL syntax errors
Syntax errors happen when SQL is malformed, such as missing SELECT statements.Step 2: Evaluate options for syntax error causes
The SQL file is missing the requiredSELECTstatement directly relates to SQL syntax. Other options cause runtime or configuration errors, not syntax errors.Final Answer:
The SQL file is missing the requiredSELECTstatement -> Option CQuick Check:
Syntax error = malformed SQL like missing SELECT [OK]
- Confusing missing test listing with syntax error
- Assuming zero rows cause syntax errors
- Ignoring missing model references
users table. Which SQL query should you write in your test file?Solution
Step 1: Understand the test goal
The test should return rows where email is NULL to detect missing emails.Step 2: Choose the SQL that returns rows with NULL emails
SELECT * FROM {{ ref('users') }} WHERE email IS NULL returns rows only when there are NULL emails (0 rows = pass). COUNT(*) always returns one row, failing even with zero NULLs. IS NOT NULL selects good rows (opposite). = '' checks empty strings, not NULLs.Final Answer:
SELECT * FROM {{ ref('users') }} WHERE email IS NULL -> Option AQuick Check:
Return rows with NULL email = SELECT * FROM {{ ref('users') }} WHERE email IS NULL [OK]
- Using COUNT(*) instead of returning rows
- Checking for empty string instead of NULL
- Selecting non-NULL emails
