Проверяем Утверждения в Коде
Иногда нам приходится делать предположения в коде. Например, что какое-то свойство или переменная имеет определённое значение. Либо у нас есть определённое представление о значении, но мы не уверены на 100%, верно ли оно. Сегодня познакомимся с Debug.Assert.
Сразу оговоримся, есть TDD, где вы можете записать свои предположения в виде тестов https://t.me/NetDeveloperDiary/2471. Сегодня не об этом. Иногда у вас есть предположения об определённых характеристиках данных или среды, которые вы не хотите тестировать по какой-то причине (например, потому что вы думаете, что переменная никогда не должна иметь это значение в этом пути кода). Так что рассматривайте это как дополнительный инструмент разработки.
Debug.Assert
Рассмотрим следующий код:
return view
.Where(s => s.TimeSignal is not null)
.GroupBy(v => v.SomeField)
.Select(v =>
{
var signals = v.ToList();
Debug.Assert(signals.Count == 2);
return new Model
{
Id = v.Key,
First =
CreateFromSignal(signals[0].TimeSignal),
Last =
CreateFromSignal(signals[1].TimeSignal),
};
})
.ToArray();
Код анализирует коллекцию объектов представления, группирует их по SomeField, а затем создаёт новый объект Model для каждой группы. Мы ожидаем, что каждая группа должна иметь ровно два элемента. Если это не так, то что-то не так с данными, и мы хотим об этом узнать. И, конечно, мы можем написать тест для этого, но означает ли это, что производственная/тестовая база данных также должна будет удовлетворять этому предположению? Может быть, а может и нет.
Отличительная особенность Debug.Assert, как следует из названия, в том, что он работает только в режиме отладки. Поэтому вы можете усеять свой код этими утверждениями, и они будут работать только в режиме отладки (надеюсь, в проде у вас код работает в режиме RELEASE). Если условие не выполняется, вы получите исключение.
Мне нравится такой подход, чтобы записывать некоторые из моих предположений в код. Это как небольшая заметка для меня и моих коллег. Если мы точно знаем, что предположение должно быть верным в 100% случаев, тогда мы утверждаем это тем или иным способом. В противном случае удаляем Debug.Assert и позволяем коду работать. Часто я запускаю свой код локально с включенным режимом DEBUG.
Microsoft тоже использует эту технику повсеместно: https://grep.app/search?current=2&q=Debug.Assert&case=true&filter[lang][0]=C%23
Trace.Assert
Также есть Trace.Assert, который похож на Debug.Assert, но выполняется, когда в проекте определён символ условной компиляции TRACE.
В проектах Visual Studio и Rider по умолчанию символ условной компиляции DEBUG определяется для отладочных сборок, а TRACE — для всех сборок. Однако, если вы его удалите, либо создадите новую конфигурацию без него, то Trace.Assert не будет выполняться.
Источник: https://steven-giesel.com/blogPost/0c8009eb-0bb6-4716-ae6c-fcb3de4a26e6/how-to-assert-assumptions-in-code-that-might-not-be-true