はじめに

新卒で初めてデータ基盤案件に入り、SQLの実装や単体テスト、結合テストを担当しました。

最初は、SQLを実行した結果のスクリーンショットを貼れば証跡になると思っていました。

しかし、実際には結果を貼るだけでは不十分です。

何を確認したテストなのか
何をもってOKと判断するのか
実際の結果が期待どおりなのか

これらを、実装者以外の人でも判断できる状態にする必要があります。

この記事では、単体テストと結合テストの観点の違いと、レビューしやすい証跡を作るために学んだことをまとめます。

※案件や会社によって証跡のルールは異なります。本記事は、私が参加した案件で学んだ内容をもとにしています。

単体テストと結合テストの違い

私が案件で理解した違いは、次のとおりです。

テスト	主な確認対象	確認すること
単体テスト（PT）	個別のSQLやビュー	実装した条件や変換が、設計どおり動作するか
結合テスト（IT）	複数の処理をつないだ結果	前後の処理を含めて、想定したデータが連携されるか

単体テストでは、実装したロジックを細かく確認します。

たとえば、次のような観点です。

WHEREの抽出条件が正しいか
CASEの変換結果が正しいか
JOINによってレコードが重複していないか
NULLや形式外のデータが残っていないか
集計結果が元データと一致するか

一方、結合テストでは、個別のSQLが正しいだけでは足りません。

前の処理で作られたデータを正しく読み込めるか
後続のテーブルやビューに正しく反映されるか
複数の処理を通して件数や値が変わっていないか
ファイル、テーブル、ビュー間でデータが正しく連携されるか

このように、単体テストは個別ロジックの確認、結合テストは処理全体のつながりの確認と考えると整理しやすくなりました。

証跡は、知識がない人でもOK／NGを判断できるようにする

証跡で最も重要だと感じたのは、実装内容を知らない人でも結果を判断できることです。

悪い例は、SQLの実行結果だけが貼られている状態です。

結果：0件

これだけでは、0件が正常なのか異常なのか判断できません。

証跡には、最低限次の情報を記載します。

確認内容：
区分に「0」「1」以外の値が存在しないことを確認する。

期待結果：
条件外のデータが0件であること。

実行結果：
0件

判定：
OK

実装者にとって当たり前の結果でも、レビューする人には前提が共有されていない可能性があります。

そのため、確認内容・期待結果・実際の結果・判定をセットで記載するようにしました。

見てほしい部分は原色で目立たせる

証跡では、きれいな配色よりも、レビューする人が確認箇所をすぐ見つけられることが重要です。

私は、次のような部分を赤や黄色などで目立たせるようにしていました。

SQLの絞り込み条件
実行結果の件数
修正前後で変化した値
OK・NGの判定に必要な箇所
元データと出力データを比較するキー

色を使いすぎると、逆にどこを見ればよいか分からなくなります。

そのため、強調するのは「今回のテストで判断に必要な部分」に絞ります。

証跡を開いた人が、数秒で確認箇所を見つけられる状態が理想です。

テストクエリは可能な限りシンプルにする

テスト用SQLは、複雑であるほど精度が高いわけではありません。

確認したい内容に対してSQLが複雑すぎると、テスト対象のSQLとテスト用SQLの両方に誤りが入る可能性があります。

たとえば、NULLが存在しないことを確認する場合は、次のように書けます。

SELECT COUNT(*) AS "条件外件数"
FROM "対象テーブル"
WHERE "対象カラム" IS NULL;

期待結果は0件です。

必要以上に共通テーブル式や複数の結合を使わず、何を確認しているSQLなのか、一目で分かることを優先します。

テスト用SQLが短いと、レビューする人も条件が正しいか確認しやすくなります。

SELECT *より、条件外データが0件であることを示す

テストでは、次のように対象データをすべて表示することがあります。

SELECT *
FROM "対象テーブル"
WHERE "設定値" NOT IN ('0', '1');

このSQLでも条件外データは確認できます。

ただし、データ量が多い場合や、結果が0件の場合は、何を確認した結果なのか分かりにくくなることがあります。

そのため、件数確認ではCOUNT(*)を使う方が明確です。

SELECT COUNT(*) AS "条件外件数"
FROM "対象テーブル"
WHERE "設定値" NOT IN ('0', '1')
   OR "設定値" IS NULL;

期待結果を「条件外件数が0件」とすると、OK・NGをすぐ判断できます。

条件外データが存在した場合は、原因調査用として別途明細を表示します。

SELECT
    "主キー",
    "設定値"
FROM "対象テーブル"
WHERE "設定値" NOT IN ('0', '1')
   OR "設定値" IS NULL;

つまり、次のように役割を分けます。

COUNT(*)：テスト結果の判定
明細のSELECT：NGデータの原因調査

確認ポイントが多い場合は、証跡を左右に広げる

1つのテストケースで複数の確認ポイントがある場合、証跡を縦に長く並べると比較しにくくなります。

たとえば、次の3つを比較するケースです。

元データ
SQL実行後のデータ
期待値

これらを上下に配置すると、確認するたびに画面をスクロールする必要があります。

そのため、可能であれば次のように左右に並べます。

左側	中央	右側
元データ	実行結果・期待値	判定（OK/NG）

横に並べることで、同じキーや値を視線移動だけで比較できます。

特に、次のようなテストで有効でした。

修正前後の差分確認
元データとビューの比較
今年と去年のデータ比較
複数テーブル間の値の一致確認
変換前と変換後の比較

ただし、横幅が広くなりすぎる場合は、確認項目を複数のテストケースに分ける方が分かりやすいこともあります。

まとめ

単体テストと結合テストでは、確認する範囲が異なります。

単体テスト：個別のSQLや変換ロジックが正しいか
結合テスト：複数の処理を通して正しくデータが連携されるか

また、証跡は実行結果を残すだけではなく、第三者がOK・NGを判断できる状態にする必要があります。

私が特に意識するようになったのは、次の5点です。

知識がない人でもOK・NGを判断できるように書く
見てほしい部分だけを色で目立たせる
テストクエリは可能な限りシンプルにする
COUNT(*)と絞り込みで、条件外データが0件と示す
比較項目が多い場合は、証跡を左右に並べる

テスト証跡の目的は、実施した事実を残すことだけではありません。

実装が仕様どおりであることを、他の人が短時間で確認できるようにすることが重要だと学びました。