dbtでのtest戦略

はじめに

この記事は、Qiita dbt Advent Calendar 2022 11日目の記事になります。

業務の中でDWHにある特定のデータを加工して、データマートに格納するという業務があり、基本設計を行った内容が通りの内容になっているのかを判断する術を持っていないことに悩みました。
システム開発における単体テストや結合テストに該当する方法をdbtのtestを利用して紹介することができればと思います。

今回は、SQLによるデータ加工においての正しさの担保がスコープとして記載。

この記事で得ることができる知識

SQLを用いたテスト駆動開発の手動

環境

dbt version : dbt 1.3.0
database : BigQuery

用意するもの

結合テスト

dbt project内の table or view に付き１つ作成。
データの加工ロジック全体の結合テスト用。
基本設計時に正解用のinput csvと output csvを作成
(下記ではそれぞれ、input_seed export_seedと記載。)

単体テスト

dbt project内の modelに付き１つ作成。
modelでの加工ロジックの単体テスト用。
詳細設計時に正解用のinput csvと output csvを作成
(下記ではそれぞれ、input_seed export_seedと記載。)

dbtのコンポーネント構造

今回では、dbtのmodelを下記のようなコンポーネントに分けてProjectを構築。

コンポーネント構築にはデータエンジニアリングの背景を踏まえてdbt（Data Build Tool）を少し深く理解してみる -dbtにおけるコンポーネントの全体像やHow we structure our dbt projectsを参考にしました。

テスト方法について

基本戦略

dbtで利用することができるSeedの機能を利用して参照データ or modelをmock。
出力される結果を事前に定義していたexport_seedとEXCEPTなどのテーブル間の差分を求める関数で、テストを実施。

結合テスト

結合テストでのmock箇所はsouceのmockとstagingコンポーネントのmodelの差し替えです。

ポイントとしては、ビジネスロジックを加工するmartsに影響がない形でmockを行うことです。

単体テスト

dbtで利用することができるSeedの機能を利用して参照データ or modelをmock。
出力される結果を事前に定義していたexport_seedとEXCEPTなどのテーブル間の差分を求める関数で、テストを実施。

利点

• 変更に対して堅牢になる。
  • 変更して要件を満たさなくなった場合エラーになるため、変更による障害の影響範囲を減らすことができる。
    • リファクタリングやクエリパフォーマンス改善などの変更に対しても堅牢になる。
  • コンポーネントで、基本設計✖︎結合テストの責任領域と詳細設計✖︎単体テストの責任領域が分かれているため、問題の切り分けがしやすい。
• テスト駆動開発的に開発をすることができ、開発がしやすい。
  • 目指すべきゴールが明確になるため、とくにアジャイル開発と相性が良い。

問題点

1. seedで利用するcsvファイルもgitで管理されるため、csvファイルのファイルサイズが大きい場合リポジトリが肥大化する。
2. BigQueryのデータセットの中が多くなりそう。（筆者はテスト対象が少ないため、viewで作成している。ephemeralでも同様のテストができるかは未検証。）