テスト固定装置に住所データを入れるとき、最初に決めるべきは「どの住所を使うか」ではなく「どんな性質を持つ住所を何件必要とするか」です。実在の住所を写してくると、あとで差し替えが必要になったときに手間がかかりますし、そもそも個人の居所を試験用の資材に残すべきではありません。この記事では、合成で住所データを作るときの組み立て方を整理します。
固定装置に住所を直接書くべきか？
書くべきではありません。理由は三つあります。
- 実在の住所を書くと、その建物や住人と無関係な文脈で値が使われます。テストの失敗を報告するときに、第三者の住所が開発者の端末や記録に残ります。
- 一度書いた値は、検証の仕様が変わってもそのまま残ります。桁数や必須欄の規則が更新されたとき、固定装置だけが古い前提を持ち続けます。
- 件数が足りなくなったとき、増やす手段が人の手作業しかありません。国を一つ足すたびに同じ作業が発生します。
代わりに、住所は生成するものとして扱い、固定装置には生成の条件だけを書きます。国、件数、必要な性質の一覧です。こうしておけば、仕様が変わったときの修正は条件の側だけで済みます。実際の値はランダム住所生成のような仕組みから取り込みます。
何件あれば足りるのか？
件数は網羅したい性質の数で決まります。多ければよいものではありません。
まず、最小構成として次の性質を一件ずつ用意します。郵便番号を持つ国、郵便番号を持たない国、桁数が最短の国、桁数が最長の国、英数字混在の郵便番号を使う国、そして行政区分を複数層持つ国です。これで六件です。
次に、境界の値を足します。郵便番号の前導ゼロ付き、番地の数字が一桁、通り名が長い場合、部屋番号を含む場合です。四件を足して十件になります。
最後に、同じ国で複数件を用意します。同じ国で一件しかないと、一覧の並び替えや重複の検出を試せません。三件程度あれば、並べ替えの結果が一件だけ同じになる事故を検出できます。
合計しても二十件に満たない程度です。国を八十六すべて網羅する必要はありません。網羅すべきは国ではなく、書式の型と境界です。
生成値と固定値はどう使い分けるのか
両方を使います。使い分けの基準は、値そのものを検証したいのか、値の扱いを検証したいのかです。
値の妥当性を確かめるテストでは、固定値を使います。正しい値と誤った値を並べ、期待した判定になるかを見ます。誤った値は人が作る必要があるため、固定値でしか用意できません。
処理の流れを確かめるテストでは、生成値を使います。登録、更新、検索、表示といった流れは、値の中身よりも件数と組み合わせが重要です。ここで固定値を使うと、同じ値ばかりが流れて、重複や並び順の問題が見えなくなります。
固定値のほうにも注意点があります。正しい値として用意したはずの郵便番号が、その後の改定で正しくなくなることがあります。固定値には、いつ時点の規則に基づくかという注記を添えてください。
開発者向け: データの置き場所と更新
住所データは、テストコードのなかに直接書かず、外部のデータとして持ちます。テストの本体から値を切り離しておくと、規則が変わったときの修正範囲が小さくなります。
データの形式は、一件ごとに国、住所の各欄、郵便番号、期待する性質を持つ構造にします。期待する性質を書いておくと、テスト側は性質で値を選べます。前導ゼロ付きの値が欲しいときは、その性質を持つ一件を取り出せばよいことになります。
更新は、規則の変化を検出したときにだけ行います。定期的に見直す運用も有効ですが、その場合は前回の見直しからの差分を確認できる形にしておきます。
件数を増やすときは、性質の一覧に新しい行を足す形にします。既存の値を書き換える必要がないため、他のテストへの影響を気にせずに追加できます。国ごとの書式の違いは郵便番号の書式に、検証と正規化の役割の違いは住所の検証と正規化の違いに整理しています。
見直しのきっかけ
固定装置が古くなったことに気づくきっかけは、いくつかあります。本番のフォームから新しい形式の値が届くようになったとき、海外の利用者からの不具合報告が増えたとき、検証の規則を変更したときです。いずれの場合も、まず固定装置の性質一覧に不足があるかを確認します。
逆に、テストが通っていることを理由に固定装置が正しいと判断しないでください。通っているのは、用意した値の範囲だけです。
次のステップ
まず、自分の固定装置に実在の住所がそのまま入っていないかを確認してください。入っていたら、値を合成で作り直す余地があります。次に、性質の一覧を書き出し、抜けている型がないかを見ます。テスト用の住所を実際に用意するときはランダム住所生成で国と件数を選ぶと、各欄が分解された状態の値を取り出せるため、期待する性質ごとの選別がしやすくなります。