Lookerテスト機能の基本と注意点

こんにちは、株式会社ゼストでインターンをしている榎橘（東京大学3年）です。

現在はLookerを使ったZEST BOARDというダッシュボード開発に参加しています。
その中でLookerのテスト機能を使うことがあったのですが、調べてもあまり情報がなく困ったことがあったので、今回は備忘録的な意味も込めてテストの基本的な書き方や注意点などについてまとめようと思います！

基本的な書き方

まず基本的なテストの書き方について簡単にまとめます。

test: historic_revenue_is_accurate {
  explore_source:  orders {
    column:  total_revenue {
      field:  orders.total_revenue 
    }
    filters: [orders.created_date:  "2017"]
  }
  assert:  revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

• explore_source: テスト対象のExploreを指定します。
• column: テストに必要なカラムを定義します。
• filters: 特定の期間や条件でデータを絞り込みます。
• assert: 検証ロジック（Looker式）を記述します。結果が yes になればテスト通過です。

基本は上記の通りですがいくつか注意点があります。

explore_sourceで指定したexploreの元になっているviewの値をテストするときは以下のようにfieldを省略することができますが、joinしたviewの値もテストしたいという場合は以下のようにfieldで指定する必要があります。

explore_source:  orders {
  column:  total_revenue {}
  column:  client_name {
    field:  clients.client_name
  }
}

assertは1つのtestブロック内に幾つでも書くことができるので同じフィルタ条件であれば1つのテストで検証することが可能です。
testブロックごとにクエリが実行されるため一つにまとめられるテストは可能な限りまとめた方が実行時間もコード量も少なくて済みます。

test: historic_revenue_is_accurate {
  explore_source:  orders {
    column:  total_revenue {}
    column:  count {}
    filters: [orders.created_date:  "2017"]
  }
  assert:  revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
  assert:  count_is_expected_value {
    expression: ${orders.count} = 150 ;;
  }
}

通常、assertはクエリ結果の1行目のみを対象とします。 「年ごとの売上推移」のように、dimensionごとの複数行の結果をそれぞれ検証したい場合は、以下のようにcase文を使って行ごとの値を判定することで可能です。

assert:  revenue_is_expected_value {
  expression: 
    case(
      when(
         ${orders.created_date} = "2017", 
         ${orders.total_revenue} = 626000
      ),
      when(
         ...
      )
      , no
    )
  ;;
}

使ってみて感じた課題点

• 「結果の統合」の検証ができない

複数のexploreの結果をUI上で統合する「結果の統合」やその上で行う「表計算」を使って表示している複雑なものがいくつかあり、テストを作成するにあたり最も自動で検証できるようにしたい対象だったのですが少なくとも僕が調べた限りでは難しそうでした... このテスト機能が1つのexploreを指定してテストするという形のものなので組み合わせた結果をというのは難しそうではあるのですが何か方法を探したいですね。

• テストコードが膨大になる

後回しになっていたテストの実装をするに至った理由としてフィルターが複雑になったことが大きな要因としてあるのですが、テスト1つにつき1個のフィルターしか適用ができないのでパターンを網羅しようとすると必然的に多くのテストが必要になり、コード量も実行時間も長くなってしまうという問題があります。
どうしようもない部分ではありますが共通化等がうまくできないかなと思っています。

まとめ

テスト機能はまだまだ使い始めたばかりでやりたいことも全てできているわけではないですが、テストコードがあることで、データ整合性の保証と回帰バグの防止が可能になり、DWH側やLookMLの改修を安全に行えるようになった結果、品質と開発効率が大きく向上しました！
Lookerを使うにあたって最も重要なことは正しい値を出すということだと思うので、今後もLookerのテスト機能を活用してミスを減らしていきたいです。