Модульное тестирование для недопустимого значения перечислений

Question

У меня есть кусок кода, который выглядит немного как это:

If mode = DiaryMode.Admin Then 
    modeObject = DBNull.Value 
ElseIf mode = DiaryMode.Academy Then 
    modeObject = ApplicationSettings.Academy 
ElseIf mode = DiaryMode.Scouting Then 
    modeObject = ApplicationSettings.Scouting 
Else 
    Throw New NotSupportedException() 
End If 

Идея проверки заключается в приготовительный некоторые значения для передачи в вызов базы данных.

Есть два вопроса: стоит ли Else? Целью является предотвращение будущих расширений перечисления, заставляющих код возвращать результаты squify.

Если код действителен, я бы хотел, чтобы он мог тестировать поведение, если это стоит того, чтобы его проверить. Как я могу это сделать?

Answer 1

Если ваши бизнес-требования утверждают, что никакой другой DiaryMode не является приемлемым, то инструкция else является прекрасным способом предотвращения дальнейшего расширения вашего перечисления DiaryMode.

Что касается тестирования, это немного сложнее. Я бы точно проверил все действующие состояния (Admin, Academy и Scouting). Однако вы не можете установить режим на значение enum, которое не существует, и это единственный способ выбросить исключение NotsupportedException. Я мог бы попытаться написать тест, который будет проверять, что перечисление содержит только перечисления, которые вы ожидаете.

Вы можете сделать это, делая что-то вроде этого:

Enum.GetNames(typeof(DiaryMode)) 

, а затем проверяя каждое имя.

Подводя итоги, у вас будет 4 теста из того, что я описал.

• тест администратора
тест
• Академия
• тест скаутинг
• Тест, который проверяет все имена в DiaryMode перечислении

Answer 2

Вы бы предпочли реорганизовать это, используя Replace Conditional with Polymorphism.

Написание тестового примера для этих строк докажет, что оператор «if ... then ... else» возвращает правильный объект modeObject, но я бы не потратил на него много времени. Это может быть не совсем бессмысленно: если вы планируете добавлять новые режимы, тест будет гарантировать, что они будут обрабатываться, как ожидалось, особенно если будет какая-то вырезанная вставка & (это не редкость вставить код и не выполнить соответствующим образом измените его).

Это то, что я сделал бы: я бы написал тестовый файл (ы), а затем рефакторинг имел иерархию классов, обрабатывающих режимы, а затем повторно запускал тесты, чтобы убедиться, что я ничего не сломал. Звучит как план?

Answer 3

Добавление Else кажется достаточно разумным. Если вы используете встроенное тестирование модуля Visual Studio, на самом деле есть атрибут, указывающий на то, что вы ожидаете, что тест будет генерировать исключение для успеха: ExpectedExceptionAttribute.