ETLおよびレポートプロジェクトにTDDメソッドを使用してユニットテストを行うにはどうすればよいですか？

ETLプロジェクトは、SSIS、PowerCenterなどのETL（抽出-変換-ロード）ツールを使用して作成されたプロジェクトです。

これらには通常、外部ソースからのデータの読み取り、ステージングデータベースへのデータの読み込み、特定の変換の実行、最終データベースへの読み込みが含まれます。

簡単な例は、SSISを使用して、SSISを使用して学校の先生が提供するExcelファイルを読み取り、データベースにロードすることです。次に、ストアドプロシージャまたは複数のSSISパッケージを作成して各生徒の成績を計算し、そのデータをデータマート\ウェアハウスにロードします

次に、マートの上にストアドプロシージャを構築して、レポートツール（SSRS \ Excel \ etc）が視覚化を生成するために使用する出力を生成します。

このシナリオでTDDと適切な単体テストを実行する方法を理解しようとしています。ETLのテストは、主にステージングテーブルにロードされたデータがソースからのデータの正しいサブセットであることを確認することに関するものです。そのため、テストを実装すると、ETLのミニバージョンが実装されます。レポートSPの出力はテーブル自体のデータに依存するため、スクラブされたテストデータを含むデータベースを作成したとしても、メンテナンスの悪夢がなければ安定した出力データのセットを持つことはできません。

例：

スプリント1：学生テーブルには名前、年齢、成績が含まれます

このテーブルのテストデータを作成し、それに基づいて単体テストを作成します

スプリント2：性別フィールドがテーブルに追加されます。

学生フィールドのデータを更新して性別属性を設定すると、データが変更されたため、テストケースは無効になります。しなければ、性別の列を必要とするテストケースを作成できません

私が過去に行ったことは、Acceptance Test Driven Developmentを使用することです。ETLコードは、多くの場合、さまざまな段階/言語および技術に分散され、密結合されています。ほとんどのETLプロセスは、パイプライン内の変換のシーケンスに依存しています。

ETLでのみユニットテストを使用する場合のリスクは、統合をカバーしないことです。変換の順序付けは、多くのETLの実際の変換と同じ部分です。自動化されたテストスイートの作成にリソースを費やしている場合は、シーケンスもカバーしていることを確認します。

独自の変換シーケンスごとにTDDに焦点を当てるか、少なくともこれらのテストをより大きなテストスイートに含めます。組み合わせが多すぎる場合は、テストするシーケンスを選択する必要があります。アイデアは、ETLパイプラインが使用されるデータセットのETLパイプラインを検証することです。すべてのコードでテストカバレッジがあることを確認します。

ETLはTDDで実行でき、ほとんどのプロジェクトとほぼ同様にテストできます。

失敗するテスト（赤）を書く失敗を修正する（緑）コードのパフォーマンスと保守性を高める（リファクタリング）

したがって、ETLの場合は次のようになります。

• 1レコードをロードするスクリプトを作成します
• 失敗（データソースが定義されていない）
• ソースの定義[緑]
• リファクタリング不要
• 1つのフィールドのみを埋めて1つのレコードをロードするテストを作成します
• 失敗（そのフィールドにコードは書かれていません）
• そのフィールドのコード詳細を定義する
• リファクタリング
• 有効な値を持つ属性を検索する失敗したテストを定義する[赤]
• 等