Костыльный программист

Ах, да, тесты в базе я не пишу. Пишу тесты запросов в приложении.

Так должен быть смысл у дескрипшина.

ну ладно. Я тут возможно не очень удачное название для колонки выбрал. Эта колонка должна нести смысл для пользователя. Может не дескрипшин, а Caption. Name резервируем для имени перечисления в коде апп.

Главное — что он имеет смысл с т.з. документации и пользователя. Именно это название он увидит на мониторе. И именно отсюда, сверху начинает плясать смысл. Грош цена коду, который оторван от смысла, исходящего напрямую из требований. Это название, кепшин, насквозь должно проходить через код начиная с ГУИ. Даже если не отображается в ГУИ, описывается в документации.

Есть даже методики и языки (правда не работал так), где бизнес-требования механически переводятся в теоремы и программа строится на их доказательстве.

Вот здесь приблизительно то же самое. Если вы не связали эти названия не с ГУИ, ни с документацией, а держите связь в уме, то вы ошиблись во второй раз. И когда эта колонка никак не связана ни с чем, то стопроцентов так и будет — тест не будет ничего толком тестировать.

А вы рассматривайте всё в совокупности: есть бизнес-требования, написанные на человеческом языке. Код — это перевод этих требований. И чем лучше он связан, тем большие гарантии, что он делает именно то.

Если вы делаете абстрактные никак не связанные с требованиями переменные, а потом какие-то прилепливаете названия в ГУИ, то для вас требования не первичны, и программа — не перевод, что не гуд. А если сумели связать и исходите из требований — то гуд.

Давайте представим идеальный язык. В требованиях сказано: бывают статусы у документа «в обработке», «отослан» и т.д. И вы создаете множество из элементов, которые ровно так и звучат. С пробелами. Без никаких дополнительных айдишек. Вот оно — вы точно тогда передаете смысл своей программой. Если еще были бы у этого языка конструкции, близкие к выражению смысла на человеческом языке — мы бы ВООБЩЕ не кодили, а просто описывали задачу, перечисляя требования.

Но всё не так плохо. На наших языках можно также передавать смысл. Можно очень плохо, а можно лучше. И вот, большинство программистов исходят из интов, какой-то х… и другой, считая, что они делают что-то. А потом, привязывают типа названия и смысл в конце. Т.е. код не ориентированный на требования изначально.

Я бы разложил конкретную задачу для примера, чтобы было понятнее, как это возможно. А то вы смотрите на приоритет каких-то чисел и непонятно чего, а потом сами же говорите, что дескрипшин в вашем представлении с логикой не связан и поэтому нет смысла на него смотреть. Да просто вы сами себе так представили.

Если номер статуса — стандарт и не наш причем, то ради бога, не храните их в базе, а смело в тестах пользуйтесь номерами.

Две крайности — всё в базе и в тестах номера :) Связь ид-название/описание можно захардкодить в коде, чтобы можно было удобно и осмысленно писать тесты и сам код, и в то же время не допустить даже преднамеренной порчи связи администратором системы (не в смысле пользователем ОС с рутовскими правами, способного изменять бинарники, а в смысле роли в системе).

Поэтому не лишнее (даже обязательное) хранить предметную область в базе.

Ни разу не слышал, что это обязательно. Более того, на своём опыте убедился, что это бывает вредно. Связывать суррогатный id с названиями/описаниями зафиксированными в ТЗ я предпочту в коде. Приложение в целом должно отражать предметную область, а не каждый его слой. На уровне бизнес-логики и её (тестов) будет зафиксирован смысл константы IN_PROGRESS, на уровне БД она будет отображаться в 2, на уровне представления — в «В обработке». Пройти от одного уровня к другому можно за несколько кликов (с нормальной IDE :)) Это просто внутренний стандарт — надо будет, можно будет зафиксировать обе связи одновременно в тестах, в приёмочных или функциональных.

Вот что значит довести идеалистическую теорию до маразма.

Учу. Полей вида DocStates на самом деле есть три вида: системные состояния, которые вообще не видны пользователю, состояния, наименования которых он задает сам (как правило админ этим занимается), состояния, наименование которых жестко задает разработчик.

И не с одним из этих видов НЕЛЬЗЯ поступать так как вы предлагаете.

Если что-то нужно вам для тестирования — это артефакт тестирования, и ни в коем случае это не может быть навязано для реализации. В первом виде — пользователю до лампочки как это будет называться — достаточно комментария в sql-скрипте у разработчика, во втором случае — он к жестким кодам сам поставит свои названия как ему хочется, на своем языке, и согласно желанию его фирмы. В третьем случае задаем мы, но это артефакт пользовательского интерфейса — он не имеет ни какого отношения к базе данных и в общем случае отличается от предметной области. Наверное лишним будет говорить, что база данных не может нести/ выполнять роль модели предметной области. Модель предметной области существует только или в техническом задании (отличаем от документации пользователю) или в UML-диаграммах на стадии проектирования. Код это лишь проекция пространства на плоскость. Да, хорошо когда проекция простая, но на то и существует разделение на слои, чтобы отличать проекции на разные оси.

В базе оперируя кодами мы четко реализуем бизнес-логику — это один слой. Показывая слова, описания — это слой GUI. Эти слои в разных местах хранят информацию. Для хранения слов GUI база не требуется — нужен лишь языковая библиотека.

И уж совсем ужасно, когда якобы тестирование требует в логику базы всунуть логику GUI. Еще хуже когда это объявляется недостатками архитектуры приложения, т.к. вы смотрите совершенно не по архитекторскому, а как тесто-кодер. И эта роль тесто-кодера — здесь совершенно не права. Повторяя если что-то требуется только для тестирования — вводите эти сущности для тестирования, и не требуйте, и не обременяйте архитектуру вашей точкой/углом зрения.