👓

dbtでのtest戦略

2022/12/10に公開

はじめに

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

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

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

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

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