Данные без противоречий. Связи между полями

[SpiderEkb]

Пол настоящий, имя настоящее, диагноз из справочника. Просто вместе они дают человека, которого не бывает.

Сейчас все бывает :-)

А если серьезно - это про что вообще? Генератор каких-то тестовых данных? Или что?

В реальной жизни любой ввод данных должен проходить через валидатор. Который будет отслеживать такие вот противоречия (типа того как если вы заводите клиента ФЛ, но указываете ему 10-значный ИНН который может быть только у ЮЛ, или ставите гражданство Беларусь, но основной ДУЛ - паспорт РФ и т.д. и т.п.).

В целом все верно - для разного типа клиентов набор данных может быть сильно разным (например, в ЮЛ и ФЛ будут совершенно разные наборы данных, у мужчин и женщин разные наборы диагностических процедур и специалистов). И вам неизбежно придется ветвится в какой-то момент. В пределе - с самого начала (ввод клиента ФЛ и ввод клиента ЮЛ это разные процедуры, разные карточки, аналогично ввод пациента мужчины и пациента женщины).

[NickLiapin]

Да, это генератор тестовых данных, всё верно. Статья первая из цикла, вводная — я в ней просто показал на простом примере, как оно работает.

Про сам инструмент написал только в конце. Побоялся, что иначе получится самореклама, а Хабр её не жалует. Похоже, перестарался: раз вопрос возник первым же.

Про валидаторы вы правы, всё так. Только валидатор ничего не создаёт — он умеет сказать «нет». А данные для тестов надо откуда-то взять, и желательно сразу непротиворечивые. Бывает нужно и обратное: намеренно сломанные, чтобы проверить сам валидатор.

А про ветвление вы прямо в точку, в статье ровно оно и есть. Ваши примеры с ИНН и ДУЛ, кстати, нагляднее моих диагнозов.

[SpiderEkb]

Ну я так и подумал, что тестовые денные. С этой точки зрения я бы делал генератор, который подает эти данные на вход реальной системы У нас это называется "модуль внешнего ввода" - наша система ведения таблицы состоит из четырех модулей - интерактив, внешний ввод, валидатор и собственно занесение в таблицу. Данные могут как вводиться руками (модуль интерактивного ввода), так и подаваться извне в виде некой заполненной структуры (модуль внешнего ввода). Дальше они попадают в валидатор и оттуда, если не было ошибок, уже уходят в модуль записи.

И для полноты тест-кейсов в генератор нужно закладывать возможность генерации ошибочных данных. Именно для контроля валидатора.

Мои примеры - из моей жизни. Я (в том числе) занимаюсь клиентскими данными. А в банке это очень большой объем. Тут и ФИО/наименование, и контактные данные, и адреса (а их штук пять разных типов - почтовый, юридический, регистрации, фактического нахождения...), разные ИНН/СНИЛС/ОГРН и т.п. (для разных типов клиентов, а их тоже не два - физики, юрики, ипшники, банки, уполномоченные лица, третьи лица...), ДУЛы (документы, удостоверяющие личность) - основной, неосновные... В общем, там огромный зоопарк разных данных и вариантов разных противоречий огромное количество. Логика валидации достаточно сложная в общем случае - проверок разных очень много.

Естественно, все это покрыто достаточно объемными автотестами. Но сценарии пишем руками (обычно аналитики или тестировщик этим занимаются). В том числе есть сценарии которые должны приводить к ошибкам валидации - это тоже контролируется - ожидаемым результатом может быть и код ошибки определенный (что именно не прошло валидацию).

И у нас "карточка клиента" (это ведение клиентов - изменение или добавление записи) для каждого типа клиента отдельная. Отдельно для ОП, отдельно для ФЛ, отдельно для ЮЛ, для банков... Потому что и логика валидации отличается и набор данных. Да и хранится в разных таблицах в итоге с разной структурой (хотя есть и общая таблица клиентов и общая таблица допинфо по клиентам и общая таблица адресов, ДУЛов для тех типов у кого они есть...)

[NickLiapin]

Спасибо, что поделились своим опытом!