lookml-tests について
lookml-tests は、LookML モデルとデータの前提を検証する開発スキルです。キーの整合性、指標の正確性、業務ロジックの確認に加え、テスト構成やスキャン範囲の抑制方法を扱います。
主な機能
- 01Explore ごとのテストファイル構成
- 02クエリとアサーションによるテスト
- 03主キーの一意性確認
- 04指標と業務ルールの検証
- 05フィルターによるスキャン範囲の制限
活用シーン
- 01結合によるキー重複の検出
- 02売上などの指標値の期待値確認
- 03計算ルールや NULL 制約のテスト
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ looker-open-source/ looker-skills --skill lookml-testsインストール後、Claude Code で/lookml-testsを入力して読み込まれたか確認します。
詳細
LookML テスト標準
データへの信頼を維持するうえで、テストは非常に重要です。LookML テストを使うと、セマンティックモデルが想定どおりに動作すること、および基盤となるデータが前提に適合していることを確認できます。
1. ファイル構成
- 配置場所:テストは
tests/[explore_name].test.lkmlに定義します。 - Explore ごとに 1 つのテストスイート:各ファイルには、特定の Explore に関するすべてのテスト定義を含めます。
- 命名規則:
[explore_name].test.lkml(例:orders.test.lkml)。
2. テスト構造
各テストは、explore_source クエリと assert ステートメントで構成されます。
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] ;;
}
}
3. テストの種類
A. 整合性チェック(重要)
結合後も主キーが一意であることを確認します。これは、誤った one_to_many 結合定義によって発生する「ファンアウト」エラーを防ぐ最善の方法です。
例:主キーの一意性
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 ;;
}
}
B. 正確性テスト
特定のメジャー値を既知の定数または想定値と照合して検証します。
例:売上が正であること
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 ;;
}
}
C. ビジネスロジックの検証
計算が想定どおりに動作することを確認します。たとえば、gross_margin が revenue を超えないことや、アクティブユーザーの lifetime_orders が NULL にならないことを確認します。
例:ロジックチェック
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} ;;
}
}
4. ベストプラクティス
- 説明的な名前:テスト(
orders_pk_is_unique)とアサーション(order_id_is_unique)には、内容がわかる名前を使用します。 - パフォーマンス:全期間の確認が必要な場合を除き、大きなテーブルではフィルター(例:
last 7 days)を使用してスキャン対象のサイズを抑えます。 - モデルへのインクルード:テストファイルがモデルファイルに含まれていることを確認します(例:
include: "/tests/*.test.lkml")。
コメント
Markdown 対応