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