SpectaclesでLooker（LookML）のテストをやってみた

大阪オフィスの玉井です。

Spectaclesを実際に使ってみました。

Spectaclesとは

下記の記事で説明されています。

もう少しシンプルかつざっくりいうと、指定したタイミングでLookMLやコンテンツのテストを行ってくれるツールです。Lookerのための自動テストツールって感じでしょうか。

現在、Spectaclesを利用するためには、公式サイトからデモ依頼を行う必要があります（デモをやってもらった後、トライアル環境がもらえる）。当然、英語でやり取りをするので、私は翻訳サービスを駆使してなんとかがんばりました。

やってみた

Looker側の準備

Spectaclesは、LookerのAPIを利用して、各種テスト（バリデーション）を実施するので、先にSpectacles用のAPIを用意する必要があります。公式の推奨として、Spectacles用のユーザーを個別に作ったほうが良いとあるので、今回はユーザーも作ります。

Permission Setの作成

Spectacles用ユーザーのためのPermission Setを作ります。ドキュメント曰く、下記の権限が必要とのことです。

Roleの作成

Spectacles用ユーザーのためのロールを作ります。Model Setは、実際にテストしたいモデルやExploreがあるModelを見られるようなModel Setを使います。Spectacles側でテストをかけるModelやExploreは指定できるので、今回はとりあえずAllでいきます。

ユーザーの作成及びAPIキーの発行

Spectacles用ユーザーを作成し、APIキーの発行をします。

Spectaclesの設定

初期設定

いよいよ、Spectaclesを使っていきます。今回はGUI版を使います。

トライアル環境にアクセスすると、こんな感じです。

最初に、Lookerインスタンスの情報を求められます。適切な情報を入れます。APIのキーとシークレットもここで入力します。

設定完了まで待ちます。

設定が終わってトップ画面が表示されます。こんな感じです。後は、対象のLookML Projectを指定するだけです。

GitHubの設定

Spectaclesは、テストの実行タイミングとして、「（LookMLの）Gitリポジトリへのプルリク時」を指定できます。これを使うことで、まさに継続的インテグレーションって感じの運用ができるのですが、プルリクのタイミングをSpectaclesでキャッチするために、設定画面でGitHubの連携認証を行う必要があります。注意点としては、LookML Projectで使っているGitHubと同じアカウントで認証しないと、そもそも意味がないというところですね。

連携認証自体はクリックするだけの簡単な作業です。

Spectaclesで色々テストをする

諸々の設定が完了したら、実際に色々使っていきたいと思います。

Spectaclesでは、1つのタスク（どんなテストをどういうタイミングで回すか）をSuiteと呼称します。ですので、まずはSuiteを設定しましょう。

Suiteについて

メニュー画面の上から、Suiteの作成画面に遷移できます。まずは、名前と実行タイミングを指定します。今回は簡単な検証目的なので、時間を選びました。ちなみに、別途手動実行も可能です。

1つのSuiteの中に、3種類のValidatorを組み合わせることができます。1つずつ見ていきましょう。

SQL Validator

これは、LookML上のsqlパラメータ内に記述されているSQLが間違ってないかチェックできます。Looker側では、中のSQLまではチェックされないので、非常に有用な機能といえます。ちなみに、実際にクエリを実行してチェックするので、LookerとDWHが動作するという点はおさえておきましょう。

Explores to queryで、*/*と書くと、Project内の全Model（全Explore）をバリデーション対象にします。model_a/explore_a, model_a/explore_bみたいに、個別に指定することもできます。Explores to excludeは、その名の通り、対象外にしたいModelやExploreを指定できます。Fail fastは、一発目のエラーが出た時点でSuiteを止めるかどうか、という設定ですね。最後の数値はクエリの同時実行数です。

実際にSuiteを作って手動実行します。

実行する環境を選びます。Productionはともかく、Developmentモードの各ブランチ単位で実行できるのは便利ですね。

定期実行でしばらく放置すると、こんな感じで履歴が見れます。

1つの実行結果の詳細はこんな感じ。

ちなみに、エラーの場合（sqlパラメータの中のクエリが実行できなかった場合）、下記のように表示されます。

Content Validator

その名の通り、Lookerのコンテンツバリデーターとやることは一緒です。ただし、本家はインスタンス全体でしか実行できないのに対し、こちらはProject単位やModel、Explore単位で実行することができます。

設定によって、個別フォルダ内のコンテンツは対象外にすることができます。Only incremental errorsというのは、Production環境のコンテンツエラーは無視します。ドキュメント曰く、ブランチの変更で発生したコンテンツエラーを把握するのに役立つ、とのことです。

問題がない場合は下記のように表示されます。

エラーがあった場合（コンテンツが壊れていた場合）、下記のように表示されます。これは、コンテンツに使わているフィールドの名前が変わって参照できなかったパターンです。

ちなみに、現在、Exploreの名前が変わったエラーについては認識できない、という仕様があります。Exploreごと消えてるので、それがエラーなのか、そもそも無いのか、というのが判断できなからっぽいです。これは下記のIssueで改善中とのことです。

Assert Validator

これは、LookMLに記述されているデータテストをチェックするものです。LookMLのtestについては、下記をどうぞ。

設定は一番シンプルです。

成功例

エラー例（testの内容が通らなかった）

Slack配信

Suiteでエラーが発生した時に、Slackに通知させることができます。設定画面でSlackの認証を行うだけです。

考慮事項

Gitリポジトリについて

Looker側で使用しているのがGitHub以外の場合、Spectaclesのプルリクトリガーは使えない気がしました（未検証）。

こんなのがあれば

LookML側で定義されているtestやsqlなどが、Spectacles側でザザッと見れたら便利かな、と思いました。Spectacles側でバリデーションする内容を把握したい、という感じですね。

おわりに

今回は手動実行で各バリデーションを検証したに過ぎませんが、プルリク時にSuiteが発動するようにすれば、LookMLを開発している過程で必ずチェックが通るようになるので、本番環境に間違ったコードを上げなくて済む→LookMLの品質を保てるようにできます。

私がもう一つ注目しているのは、dbtとの連携です。dbt側のプルリクに合わせてSpectaclesが動作し、dbt側の変更によって、LookML側の（テーブル等への）参照が一致しなくなった時に、エラーを返してくれたりするそうです。こちらも、どこかでブログにしたいと思います。