フロントエンドの開発は、バックエンドが実データを返す準備が整う前に始まることがよくあります。動くAPIを待つ代わりに、適切な形の現実的なテスト用JSONデータを生成して、すぐに作業を始めることができます。
モックデータとは何か
モックJSONとは、生成されたものでありながら構造的にもっともらしいデータのことです。本物の名前らしく見える名前、正しい形式の日付、あるべき見た目のIDなどです。"test123"のようなプレースホルダーの値と違い、現実的なモックはUIが長い名前や空のフィールド、特定の日付形式を正しく扱えるかどうかをすぐに明らかにしてくれます。
なぜ必要なのか
- バックエンドチームがAPIを完成させる前にUI開発を始める。
- 実際のデータベースにデータを入れなくても、大量のレコードに対するUIの挙動をテストする。
- 実際のユーザーデータを公開せずにデモやプロトタイプを作る。
- 外部サービスやデータベースの状態に依存しない自動テストを書く。
日本の住所は「大きい方から小さい方へ」書く
日本の住所は都道府県 → 市区町村 → 丁目・番地の順に、英語圏とは逆の「大きい単位から小さい単位へ」という順序で書かれる。郵便番号も〒123-4567のように3桁・4桁をハイフンでつなぐ独自の形式で、住所の先頭に置かれることが多い。氏名も同様に姓が先、名が後という順序が標準だ。{{street}}や{{city}}を英語圏の順序でそのまま連結するモックテンプレートは、フィールドとしては動くが、日本語話者が見れば違和感のある住所になってしまう。
注意すべきこと
モックデータは実データの形や型はよく再現しますが、ビジネスロジックやレコード間の関係性は再現しません。本番環境に出す前には、やはり実際のAPIに対してコードをテストする必要があります — モックは開発の初期段階を速めるだけです。
モックにおける現実的なエッジケース
優れたモック生成ツールは、意図的に「扱いにくい」値を含めます — 非常に長い名前、空文字列、ひらがな・カタカナ・漢字が混在する文字列、ゼロや負の数、範囲の境界にある日付などです。まさにこうした値こそが、"John Doe" のような「都合の良い」データでしかテストしていなかったレイアウトやロジックを壊すことが最も多いのです — そのため、毎回同じテストサンプルよりも、モックのランダム性のほうが有用です。