SQL・テストデータ
実データを使わず、同じテストデータを何度も作りたい
使うツール
テスト画面を更新したら不具合が消えてしまった。でも直ったのではなく、表示データが変わっただけかもしれません。毎回違うダミーデータは便利な一方、再現条件をなくすことがあります。Seed付きの生成では、同じ条件から同じデータを作り直せます。実在する利用者の情報をコピーせず、問題を共有できる架空の小さなデータを用意してみましょう。
まず三行、四列の架空一覧を作る
ダミーデータ生成で件数3、Seed42、形式JSONを選びます。列はidをinteger、nameをname、activeをboolean、emailをemailとして、この順番にします。現在の実装では次の値になります。名前は用意された候補から選ばれ、メールはexample.testの架空アドレスです。実在する人物や連絡先を取得する機能ではありません。
[{"id":1,"name":"Haru","active":false,"email":"user1@example.test"},{"id":2,"name":"Ren","active":false,"email":"user2@example.test"},{"id":3,"name":"Mina","active":false,"email":"user3@example.test"}]同じ条件でもう一度生成し、結果が同じことを確認します。名前を持つデータでも、特定の利用者をモデルにしていません。テスト用であることが分かる場所へ置き、通知やメール送信を伴う本番処理へ流さないようにします。架空のアドレスを使うことと、送信処理を試験環境で無効化することは、別の対策です。
Seedだけでなく、列の順番も再現条件
Seedを43にすると、この例の二行目の名前はHaru、三行目はAoiになり、三行目のactiveはtrueになります。一行目は同じなので、Seedを変えればすべてのセルが変わるとは限りません。integerは行番号、emailも行番号から作るため、これらはSeedだけを変えても同じです。どの型が乱数を使うかを分けて考えると、結果の変化を読みやすくなります。
名前やbooleanなど、乱数を使う列を追加・並べ替えすると、同じSeedでも後の値が変わることがあります。乱数を取り出す順番が変わるためです。再現用のメモにはSeedだけでなく、列名、型、順番、件数、形式も残します。さらに生成ロジックが将来変われば同じ出力を保証できないので、長期の回帰テストには必要な生成結果そのものをFixtureとして管理する方法もあります。
JSON・CSV・SQLでは、同じ情報の見え方が違う
同じ列定義とSeedで形式をCSVへ変えると、見出し行とデータ行になります。SQLへ変えると指定テーブル向けのINSERTです。JSONのbooleanがCSVではtrueやfalseという文字に見えても、CSVを読む側が自動でbooleanへ戻すとは限りません。形式を切り替えたときは、表示だけでなく、次のツールがどの型として読むかまで確認します。
SQL形式はDBへ接続せず文字列を作るだけです。実在テーブルの制約、既定値、外部キーを調べて整合させません。列名が同じだからそのまま本番表へ投入できる、という使い方は避けます。再現に必要な最小の表と値を試験環境側で用意し、外部通知や課金につながる処理から切り離して使います。
三行のランダムデータだけでは、境界を通らない
Seed42の例ではactiveが三行ともfalseです。これだけでtrue側の表示を検証したとは言えません。長い名前、空文字、NULL、引用符、絵文字、最大値なども、標準の名前候補から偶然すべて出るわけではありません。通常の一覧を生成した後、検証したい条件をconstant型や明示的なFixtureへ用意します。ランダムな例と、意図して作る境界例は役割が違います。
件数の境界も別に確認します。生成ツールは1〜1,000行なので、空一覧の画面は生成件数0で作るのではなく、試験側の空配列などで用意します。ページ切替や一覧の末尾の動作を見るなら、ちょうど一ページ、一件だけ超える件数といった具体的な数を選びます。たくさん作るほどよいのではなく、どの境界を通すかを先に決めます。
再現できる乱数を、秘密に使わない
Seedから同じ値を再現できることは、テストでは利点ですが、秘密値には向きません。この生成器で作る文字列やメールを、認証トークンや実際の利用者アカウントとして扱わないでください。秘密の乱数が必要なら、暗号学的乱数を使うランダムトークン生成など別の用途のツールを選びます。ただし、そこで生成した秘密を再現用Fixtureへ貼ることも避けます。
不具合報告には、列定義、Seed、件数、形式、期待した表示、実際の表示をそろえます。再現できる最小件数へ減らし、他の人が同じ条件で確かめられるようにします。『たくさんのランダムデータで何となく試した』から、『この三行のこの値で問題が起きる』へ変わると、修正後の回帰確認も具体的になります。
ランダムで見つけた不具合を、固定した再現例へ変える
大量のダミーデータで一度だけ画面が崩れたなら、次に別のSeedで成功しても、その不具合が直ったことにはなりません。まず失敗した入力を再現できるようにします。Seedだけでなく列定義、列順、件数、形式を残し、同じ内容がもう一度出るか確かめます。ツールや生成処理の版が変われば、同じSeedから同じ値を得る保証の範囲も変わり得るので、長期の回帰テストには問題を起こした行そのものを架空の固定Fixtureとして持つ方法が役立ちます。
次に、関係のない行や列を減らしても問題が残るかを試します。千行必要だと思っていた不具合が、同じ表示名を持つ二行だけで再現するかもしれません。逆に、件数が境界を超えたときだけ起きるなら、直前と直後の件数を固定して比較します。ランダム生成は未知の組合せを探す入口になりますが、修正後の確認には『何が問題を起こす条件だったか』が分かる短い例が向いています。量を減らすことと、必要な条件を落として再現しなくすることは区別します。
ダミーデータの名前やメールアドレスは、実在の利用者の行動を表すものではありません。もっともらしい一覧ができても、実データの分布や偏りを再現したという意味にはなりません。性能や容量を評価するなら、文字列の長さ、値の種類、重複の多さなど、どの特徴を再現する必要があるかを別に決めます。この生成画面の簡単な型だけで十分でない場合は、その不足を説明し、作った件数だけで試験の十分性を判断しないようにします。