ワンクリックで
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").