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