Положительные или отрицательные имена булева поля
В интеграционных тестах необходимо протестировать с реальной базой данных, поскольку необходимо проверить, что приложение может на самом деле говорить с базой данных. При изоляции базы данных, поскольку зависимость означает отсрочку реального теста того, была ли база данных развернута правильно, схема как ожидалось, и приложение настроено с правильной строкой подключения. Вы не хотите находить любые проблемы с ними, когда Вы развертываетесь к производству.
Вы также хотите протестировать и с предварительно созданными наборами данных и с пустым набором данных. Необходимо протестировать и путь, где приложение запускается с пустой базы данных только с исходными данными по умолчанию и начинает создавать и заполнять данные и также с четко определенные наборы данных, которые предназначаются для особых условий, которые Вы хотите протестировать, как напряжение, производительность и так далее.
кроме того, сделайте sur, что у Вас есть база данных в известном состоянии перед каждым состоянием. Вы не хотите иметь зависимости между своими интеграционными тестами.
7 ответов
Я всегда предпочитаю положительные имена, чтобы избежать двойных отрицаний в коде. «Не бездействует» часто является поводом для двойного взгляда при чтении. «Неактивен» всегда можно записать как «если (! Активен)», используя при этом семантику встроенного языка.
Мое личное предпочтение:
- Используйте префиксы типа «Is», «Has» и т. Д. Для логических полей, чтобы прояснить их назначение.
- Всегда называйте переменные в утвердительный . Для Active / Inactive я бы назвал его IsActive.
- Не делайте битовое поле допускающим значение NULL, если только у вас нет особой цели для этого.
В вашем конкретном варианте использования поле должно называться IsPublic или IsPrivate - в зависимости от того, какое имя приведет к ответу True когда пользователь ставит галочку.
Всегда используйте положительные имена.
Если вы используете отрицательные имена, вы очень быстро попадете в двойное отрицание. Не то чтобы двойное отрицание - это ракетная хирургия, но это мозговой цикл, и это ценно :)
Всегда используйте плюс.
Это проще.
Довести использование отрицания до логической крайности: если InActive лучше, чем Active, то почему бы не InInActive или InInInActive?
Потому что это было бы менее просто.
Правильный способ справиться с такими ситуациями - создать таблицу для хранения значений, связанных со столбцом, и создать отношения внешнего ключа между двумя таблицами. IE:
WIDGETS таблица:
WIDGET_IDWIDGET_STATUS(fk)
WIDGET_STATUS_CODES таблица:
WIDGET_STATUS_CODE
(pk) ] Если возможно, WIDGET_STATUS_CODE будет естественным ключом (IE: ACT для «Активный», INA для «Неактивный»). Это сделало бы записи более удобочитаемыми, но это не всегда возможно, поэтому вы должны использовать искусственный / суррогатный ключ (например, автоматический номер / последовательность / и т.д.).
Вы хотите сделать это, потому что:
- Это ' s читабельно, какой статус указывает (это был исходный вопрос)
- Будущее доказательство необходимости определения / использования большего количества статусов
- Обеспечивает ссылочную целостность, чтобы кто-то не мог установить значение 2, 3, 4 и т. д.
- Космос дешевый; нет ничего эффективного в разрешении неверных данных
Старайтесь вообще избегать логических полей в базах данных.
Во-первых, RM имеет гораздо лучший способ представления истинностной информации, чем с помощью логических полей: через наличие кортежа в table.
Два логических поля - очень плохие дискриминаторы при запросах. Индексировать их практически безумие, поэтому при запросе наличие логических полей не дает никакой пользы.
Я не мог бы не согласиться с некоторыми другими ответами, но определенно избегаю неправильного ответа, который не должен всегда указывать двойное отрицание