원클릭으로
lookml-tests
Standards and best practices for writing LookML tests to ensure data integrity, accuracy, and logic validation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Standards and best practices for writing LookML tests to ensure data integrity, accuracy, and logic validation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Looker Developer Onboarding: Step 3. Authenticates the Looker CLI using OAuth. Only execute this after Step 2 (CLI Verification using `installing-looker-cli`).
Looker Developer Onboarding: Step 4. Creates a database connection in Looker to Google BigQuery. Only execute this after Step 3 (CLI Authentication using `authenticating-looker-cli`).
Looker Developer Onboarding: Step 7 (Final Step). Creates a LookML dashboard in the project, imports it as a user-defined dashboard (UDD) in Looker, and iteratively refines it based on user feedback by syncing changes. Only execute this after Step 6 (Model Setup using `creating-lookml-model`).
Looker Developer Onboarding: Step 6. Creates LookML views and models based on the user's goals, maps model connections, validates LookML, and runs verification queries. Only execute this after Step 5 (Project Setup using `setting-up-looker-project`).
Looker Developer Onboarding: Step 1. Guides the agent to explore BigQuery data and define the onboarding goal. This is the first active step, to be executed immediately after reading the parent orchestrator `looker-developer-onboarding`.
Looker Developer Onboarding: Step 2. Verifies that the Looker CLI is available in the PATH, or installs it from GitHub Releases if missing. Only execute this after Step 1 (Data Discovery using `exploring-data-for-looker`).
| name | lookml-tests |
| description | Standards and best practices for writing LookML tests to ensure data integrity, accuracy, and logic validation. |
| license | Apache-2.0 |
| metadata | {"publisher":"google","version":"v1"} |
Testing is critical for maintaining trust in data. LookML tests allow us to verify that our semantic model behaves as expected and that the underlying data conforms to our assumptions.
tests/[explore_name].test.lkml.[explore_name].test.lkml (e.g., orders.test.lkml).Each test consists of an explore_source query and an assert statement.
test: [test_name] {
explore_source: [explore_name] {
column: [column_name] { field: [view_name].[field_name] }
filters: {
field: [view_name].[field_name]
value: "[value]"
}
}
assert: [assertion_name] {
expression: ${[view_name].[field_name]} [operator] [value] ;;
}
}
Verify that Primary Keys remain unique after joins. This is the best defense against "fanout" errors caused by incorrect one_to_many join definitions.
Example: Primary Key Uniqueness
test: orders_pk_is_unique {
explore_source: orders {
column: order_id {}
column: count {}
# Limit to recent data to save costs/time if table is large
filters: {
field: orders.created_date
value: "last 7 days"
}
}
assert: order_id_is_unique {
expression: ${orders.count} = 1 ;;
}
}
Validate specific measure values against known constants or expectations.
Example: Revenue is Positive
test: revenue_is_positive {
explore_source: orders {
column: total_revenue {}
filters: {
field: orders.created_date
value: "yesterday"
}
}
assert: revenue_greater_than_zero {
expression: ${orders.total_revenue} >= 0 ;;
}
}
Ensure calculations behave as expected. For example, checking that gross_margin is never greater than revenue or that lifetime_orders is never NULL for an active user.
Example: Logic Check
test: margin_less_than_revenue {
explore_source: orders {
column: total_revenue {}
column: total_margin {}
}
assert: margin_is_valid {
expression: ${orders.total_margin} <= ${orders.total_revenue} ;;
}
}
orders_pk_is_unique) and assertions (order_id_is_unique).last 7 days) to limit the scan size for large tables, unless verifying full history is required.test files are included in the model file (e.g., include: "/tests/*.test.lkml").