テスト用ランダム日付生成器：より良いテストデータを作る方法

01 / 目的

テスト用ランダム日付生成器が出力すべきもの

役に立つフィクスチャは、日付らしい文字列だけではありません。登録日、予約期間、更新期限、レポートの絞り込み、並べ替えるイベントなど、使う理由があります。生成器は多様な値を素早く作れますが、その値で何を証明するかはテスト設計が決めます。最初に対象フィールドと確認したい挙動を名前にしましょう。

たとえばcreated_atで並べる一覧なら、すべての行が同じ1月の日付にならないように複数の月を含めます。予約フォームなら許可範囲の前、範囲内、範囲後を入力します。年齢の判定なら誕生日の前日、当日、翌日を試します。ランダム選択は入力であり、期待結果を検証するのはテスト側の仕事です。

この違いにより、この記事はトップページのツールと重複しません。トップページは日付を直接選ぶ作業を解決し、この記事はその結果をソフトウェアの証拠へ変える手順を、開発者、テスター、分析担当者向けに説明します。

• 日付を受け取るフィールドまたは機能を明確にする。
• 生成値ごとに守るべき挙動を定義する。
• 偶然に任せず、手動で追加すべき境界日を決める。

02 / 日付モデル

日付、時刻、タイムスタンプを区別する

生成前にフィールドの意味を確認します。締切日のようなカレンダー日付には時刻帯がありません。created_atのようなタイムスタンプには時刻があり、通常は明示的なタイムゾーンが必要です。日時入力は両方を含み、夏時間の規則も関係します。日付だけをローカルの真夜中へ変換すると、別の地域で前日になることがあります。

日付だけを保存、並べ替え、比較、API送信するなら2026-11-18のような順序付き形式を使います。画面確認用には長い表記も残します。米国式と欧州式の数字表記は表示テストに有用ですが、03/04は3月4日か4月3日か曖昧です。表示とパーサーの契約を別々に確認してください。

生成器は日付範囲と形式を用意します。製品が時刻やタイムゾーンを扱う場合は、テスト側で日時ケースを追加します。日付だけの値でタイムスタンプの挙動を証明することはできません。

03 / 範囲設計

曖昧な期間ではなく両端を含む範囲を使う

開始と終了の2つを具体的に書きます。FromとToは両端を含むため、1日だけの範囲には1つの候補があり、1年の範囲には1月1日と12月31日が含まれます。このルールはテスト計画に書きやすく、アサーションにもできます。アプリが上限を含めない仕様なら、フィクスチャを変換するか違いを記録します。

広い範囲は通常のばらつきを探すのに向きますが、境界を保証しません。月末、年の切り替え、年齢の閾値の周辺では範囲を短くして、期待結果を明確にします。分布確認用のサンプルと、境界を手で選んだリストを分けると、偶然の成功を過信せずに済みます。

出力には範囲も保存します。開始日、終了日、曜日フィルター、重複設定、形式がない10件のリストは後から再現できません。これらをフィクスチャ名、テスト名、QAメモに残しましょう。

• 広い範囲：並べ替え、集計、ページング、分布を確認する。
• 短い範囲：両端と件数の上限を確認する。
• 境界範囲：月末、うるう年、業務ルールを確認する。
• 空の範囲：曜日フィルターで候補がなくなるときのエラーを確認する。

04 / 生成

制御を失わず現実的なサンプルを作る

最初は少ない件数にします。5〜20件ならフィクスチャを目視しやすく、多い件数はステージング表やページングの確認に使えます。各行を別イベントとして扱うなら重複を避けます。同日レコード、重複インポート、復元抽出をテストする場合だけ重複を許可します。

評価の前に曜日フィルターを適用します。月曜から金曜はカレンダー規則であり、祝日カレンダーではありません。月曜日が休業日になることもあります。国別の営業日が必要な製品では、通常の平日を作った後、製品の公式な祝日データを別に加えます。

ブラウザーの乱数を安全性の保証として説明しないでください。ランダムな日付はサンプルや通常の選択に向きますが、パスワード、トークン、暗号用シード、正式な抽選記録には使えません。この境界をドキュメントとフィクスチャに残します。

• 大きな投入の前に小さなサンプルを確認する。
• 別イベントには一意値、重複処理には重複値を使う。
• 機械にはYYYY-MM-DD、人には長い日付を使う。
• 範囲とフィルターを結果リストの横に保存する。

05 / 境界ケース

ランダム抽出が見落とす日付を追加する

ランダムサンプルは通常のばらつきを見せますが、まれな日付は意図的に追加します。うるう年の2月29日と前後の日、30日月と31日月の末日、年をまたぐレポートなら12月31日と1月1日を入れます。

年齢や資格の規則では、要件から境界を計算して両側をテストします。今日18歳になる人と、誕生日が明日の人は異なります。請求や更新なら、有効期限当日、その直前、最初に有効になる翌日を確認します。生成器は日付を用意しますが、アサーションはテスト計画が決めます。

タイムゾーンを扱うアプリでは、夏時間の切り替え付近に日時フィクスチャを追加し、保存された瞬間と画面のローカル日付を比較します。日付だけのガイドはその作業を置き換えませんが、カレンダー日付をタイムスタンプとして扱う誤りを防ぎます。

• うるう年：2月29日と前後の日。
• 月末：2月、4月、6月、9月、31日月。
• 年末年始：12月31日、1月1日、業務上の締め日。
• 規則の境界：前日、当日、翌日。

06 / レビュー

説明でき、再現できるテストデータにする

生成器を開かなくても、範囲、候補条件、重複の可否、コピーした形式の4点をレビュー担当が答えられるフィクスチャは保守しやすくなります。名前やメタデータに記録してください。`orders_2026Q1_unique_iso`の方が`random_dates_1`より意味を伝えます。

生成リストを実際のバリデーション規則と比較します。各日付を解析できるか、不正文字列を拒否するか、表示と保存値が一致するか、ローカライズ文字列をアルファベット順にしていないかを確認します。ランダムだと主張するより、リストへのアサーションが役立ちます。

失敗したら範囲と出力をそのまま保存します。決定的なシードを用意する必要はありませんが、フィクスチャやテスト成果物は必要です。再現性は同じ乱数が出る期待ではなく、入力と結果を保存することで生まれます。

• 範囲、フィルター、件数、重複設定、形式を結果と一緒に残す。
• 有効性、解析、順序、表示、境界を別々にアサートする。
• 失敗した出力をフィクスチャとして保存する。

07 / 限界

生成された日付で証明できること、できないこと

生成日付は、コードが選んだ値を受け取り処理できることを示します。空き時間、国の祝日、法的な期限の正しさまでは証明しません。それらには業務カレンダー、規定、信頼できる一次資料が必要です。

通常のブラウザー処理では、日付のアップロードやアカウントは必要ありません。それでも共有メモへ実在の誕生日、顧客記録、機密の予定を書き込まないでください。架空の値を使い、ホスティング、分析、Cookie、ウェブビーコン、識別子、広告についてはプライバシーポリシーを確認します。

用途は計画、例、QAフィクスチャ、通常の抽出に限定します。パスワード、アクセスコード、トークン、規制された抽選、監査証跡が必要な判断には、セキュリティ専用の乱数源を使ってください。

よくある質問

テスト用ランダム日付 FAQ