Генератор американских адресов создаёт записи, которые выглядят как настоящие адреса США: номер дома, название улицы, город, двухбуквенный код штата и пятизначный индекс. Такие записи нужны разработчикам и тестировщикам, которые проверяют формы доставки, регистрации и оплаты и не хотят заполнять поля вручную десятки раз. Главная сложность здесь не в том, чтобы придумать улицу, а в том, чтобы все части адреса относились к одному месту: город лежал в правильном штате, индекс соответствовал этому штату, а код штата был взят из официального перечня, а не изобретён. Дальше разберём, из чего состоит запись, почему согласованность полей важнее их правдоподобия по отдельности и какие ошибки ввода стоит закладывать в тестовый набор. В конце вы сможете собрать небольшой набор американских адресов для своего теста и понять, чего эти данные подтвердить не могут.
Из чего состоит запись американского адреса
Американский адрес записывается от мелкого к крупному. Первым идёт номер дома, затем название улицы, и только потом населённый пункт, код штата и индекс. Такой порядок противоположен, например, японскому или китайскому, где запись начинается с крупной единицы, и это первое, что стоит учитывать, если ваша форма обслуживает несколько стран одновременно. Для машины важна не привычка, а то, что строка адреса читается слева направо как точка на карте: сначала конкретное здание, потом область вокруг него.
Название улицы почти всегда состоит из нескольких частей. В нём есть собственное имя, тип улицы и иногда направление. Тип улицы записывается сокращением или полностью, и оба варианта считаются допустимыми, но смешивать их в одной базе неудобно: поиск по сокращению не найдёт запись, где улица написана целиком. Направление вроде северного или южного указывает на часть города и стоит перед названием, а не после него, поэтому при разборе строки его нельзя принять за часть имени.
Вторая строка адреса — это уточнение внутри здания. Номер квартиры, офиса или этажа не работает сам по себе: голое число после названия улицы ничего не значит, пока рядом нет слова, которое объясняет, что это за число. Форма должна либо требовать такое слово, либо выносить уточнение в отдельное поле, иначе разбор строки становится догадкой. Это одна из тех деталей, из-за которых две системы, обменивающиеся адресами, расходятся в понимании одной и той же записи.
Завершают строку город, код штата и индекс. Код штата всегда состоит ровно из двух букв и берётся из закрытого официального перечня, а индекс состоит из пяти цифр, к которым иногда добавляют ещё четыре. Между городом и кодом штата принято ставить запятую, но её отсутствие ошибкой не считается.
Почему город, штат и индекс должны совпадать
Каждое из трёх полей по отдельности выглядит корректным почти всегда. Код штата — две буквы из перечня, индекс — пять цифр, город — обычное слово. Ошибка проявляется только в связке: индекс принадлежит конкретной зоне доставки, зона находится в конкретном штате и обслуживает конкретные населённые пункты. Адрес, где город и штат верны сами по себе, но индекс взят от чужого региона, выглядит правдоподобно и не соответствует ничему.
Именно поэтому генератор берёт все части из одной записи, а не собирает их из независимых списков. Если город выбирается случайно из общего перечня, штат случайно из пятидесяти значений, а индекс случайно из всех известных, вероятность совпадения мала, и большинство получившихся адресов будут внутренне противоречивы. Для демонстрации это незаметно, а для теста вредно: вы проверяете форму на данных, которых не бывает, и не понимаете, какой именно дефект ищете.
Согласованность важна ещё и потому, что она даёт готовый негативный тест. Возьмите запись, где все поля корректны по отдельности, и замените только индекс на значение из другого штата. Если форма пропускает такую запись, значит проверки полей не связаны между собой, и это отдельный дефект, который иначе не всплывёт. Полезно заранее решить, должна ли ваша система проверять такие связки вообще, потому что для международной формы это дорого, а для национальной вполне посильно.
Третья причина держать поля согласованными — читаемость отчётов. Когда тестовые данные выглядят как один связный адрес, упавший тест легко описать словами: город, штат и индекс упоминаются вместе, и коллега сразу понимает, о какой записи речь. Набор из несогласованных значений приходится объяснять дольше, и часть контекста теряется.
Сколько записей покрывает генератор
Справочник, на котором работает генератор адресов, устроен по уровням. В нём около двухсот городов, почти две тысячи административных единиц второго уровня и более тринадцати тысяч почтовых индексов, распределённых по всем штатам. Числа здесь важны не сами по себе, а как граница: покрытие задаёт, какие сочетания города, штата и индекса вы вообще можете получить и насколько разнообразным будет набор.
Уровневая структура нужна, чтобы форма могла предложить зависимые списки. Сначала пользователь или тест выбирает штат, затем город из этого штата, затем индекс из этого города. Если справочник хранит только плоский список адресов, зависимые списки придётся собирать на лету и поддерживать вручную, а при добавлении города легко забыть обновить связку.
Покрытие стоит проверять под свой сценарий, а не брать первое попавшееся. Если вы тестируете форму для одного региона, достаточно нескольких крупных городов и десятка индексов. Если вы проверяете сортировку, отчётность или нагрузку, понадобится широкий разброс: разные длины названий, разные штаты, индексы, начинающиеся с нуля, и адреса в территориях за пределами основной части страны. Официальный перечень кодов и правила индексации опубликованы на сайте Почтовой службы США, и сверять с ним тестовые значения полезно хотя бы изредка.
Как быть с округом Колумбия и территориями?
Пятидесятью штатами страна не ограничивается. Отдельно стоит округ Колумбия, который не является штатом, но имеет собственный код в поле состояния. Кроме него есть островные и заморские территории со своими обозначениями, а также военные адреса, которые обслуживаются отдельной почтовой системой и используют собственные двухбуквенные коды.
Для справочника это означает, что закрытый перечень значений шире, чем привычные пятьдесят позиций. Если форма предлагает выпадающий список только из штатов, часть корректных адресов будет отвергнута без причины. Если же список включает территории, нужно заранее решить, поддерживает ли ваша логика доставки их особенности: сроки, ограничения и правила возврата там отличаются.
Есть и противоположная крайность. Некоторые сервисы сознательно принимают только адреса основной части страны, потому что доставка или проверка в территориях им недоступна. Это законное решение, но его стоит выразить явно: ограничить список, объяснить ограничение и не выдавать отказ как ошибку формата. Молчаливая проверка, которая режет часть значений без объяснения, выглядит как дефект формы и приводит к лишним обращениям в поддержку.
Отдельный вопрос — как тестировать такие адреса. Возьмите по одной записи для округа и для пары территорий и добавьте их в набор отдельными случаями: они проверяют не столько формат, сколько ветвление логики, которое легко забыть.
Какие ошибки ввода встречаются чаще всего?
Первая и самая частая — придуманный код штата. Сокращение выглядит разумно, состоит из двух букв и проходит проверку длины, но в официальном перечне его нет. Заметить это можно только сверкой с таблицей значений, поэтому тест с таким кодом обязательно должен входить в набор.
Вторая — индекс неверной длины. Пользователь вводит четыре или шесть цифр, а форма либо молча принимает их, либо выдаёт непонятное сообщение. Отдельный случай — потеря ведущего нуля: индексы некоторых регионов начинаются с нуля, и если поле хранится как число, а не как строка, ноль исчезает при сохранении. Ошибка проявляется не в момент ввода, а позже, при выгрузке или сопоставлении, и найти её бывает непросто.
Третья — уточнение внутри здания без поясняющего слова. Строка с одиноким числом после улицы разбирается неоднозначно, и разные системы понимают её по-разному. Четвёртая — смешение полного и сокращённого написания типа улицы, из-за чего дедупликация не срабатывает и в базе оказываются две записи об одном месте. Пятая — лишние пробелы, неразрывные пробелы и похожие на латиницу символы из другой раскладки: визуально строка выглядит правильно, а сравнение со справочником не проходит.
Наконец, отдельно стоит упомянуть адреса территорий с диакритикой. Испанские названия содержат буквы с диакритическими знаками, и форма, которая приводит всё к латинице без знаков, теряет часть названия. Это редкая, но показательная ошибка, которая сразу видна на таких записях.
Как встроить адреса в проверки формы
Начните с того, что разделите проверки на две группы: формат и связность. Первая отвечает на вопрос, допустимо ли значение само по себе, вторая — согласуются ли поля между собой. Разные дефекты ловятся в разных группах, и смешивать их в одном наборе неудобно, потому что непонятно, что именно сломалось.
Дальше зафиксируйте записи, на которых тест сравнивает результат. Случайные значения годятся для проверки устойчивости, но не для эталонного сравнения: если адрес меняется при каждом запуске, тест падает через раз и причину приходится искать заново. Разбор этого подхода подробно описан в статье про адресные данные в тестовых наборах, и там же объясняется, как совместить оба режима в одном проекте.
Полезно добавить проверку отображения. Длинные названия улиц и населённых пунктов ломают вёрстку, а перенос строки посреди адреса превращает его в нечитаемый текст в письме или квитанции. Такие дефекты видны только на достаточно длинных записях, поэтому в наборе должны быть и они. О типовых сценариях формы оформления заказа рассказано в материале про тестовые случаи для адресной формы.
Отдельно проверьте, как форма ведёт себя при переключении страны. Если пользователь выбрал США, а затем сменил страну, поля штата и индекса должны перестроиться, а не остаться от прежнего выбора. Это частая ошибка, и она хорошо видна именно на согласованных тестовых данных.
Что эти данные не подтверждают
Записи, которые выдаёт генератор, синтетические. Они построены по правилам формата: код штата взят из официального перечня, индекс состоит из нужного числа цифр, остальные поля согласованы между собой. Но за каждой такой записью не стоит ни одного реального адреса, ни одного дома и ни одного человека.
Из этого следуют практические границы. Такой адрес нельзя использовать для отправки корреспонденции или посылки: письмо вернётся, потому что здания по этой записи не существует. Его нельзя предъявлять как подтверждение места жительства или как основание для открытия счёта. И его нельзя использовать, чтобы выдать себя за другого человека: данные не проходят проверку личности и не предназначены для этого.
Назначение этих записей — проверка ваших собственных программ, форм, валидаторов и тестовых окружений. Всё остальное выходит за границы задачи, и об этом лучше сказать прямо в документации проекта, чтобы у нового участника команды не возникло соблазна применить набор иначе.
Что делать дальше
Возьмите одну форму в разработке и составьте для неё короткий набор: несколько обычных адресов США, один адрес с расширением индекса, один с придуманным кодом штата, один с противоречащим индексом и один для территории. Этого хватит, чтобы поймать большинство ошибок ввода, о которых шла речь выше.
Затем зафиксируйте в тесте, какие записи считаются эталонными, а какие берутся заново при каждом запуске. И проверьте отдельно, как форма реагирует на смену страны — это последняя частая ошибка, которая не видна на одном статичном наборе. Если нужны данные по стране целиком, посмотрите, как выглядит США в нашем справочнике.