Как предотвратить проглатывание исключений, вызванных ненадлежащими ожиданиями по отношению к объекту?

Question

Я ищу способ изменить блок catch в зависимости от того, выполняется ли он во время модульного теста или нет.Цель в основном состоит в том, чтобы обнаружить / настроить ложные ожидания, которые проглатываются, потому что улов не отбрасывается.

Я использую MSTest.

Одна очевидная вещь - использование препроцессора, но я не думаю, что этоработает.Особенно если использовать DEBUG define.Должен быть простой способ обнаружить это, не так ли?Должно быть, я искал что-то не так, потому что не мог найти много информации об этом.

try {...}
catch(Exception)
{
    Log(...);
#if DEBUG
        throw;
#endif

}

ОТВЕТ: извлеките тело try в другой метод и протестируйте его.Предоставлено Джоном и Ритчем.Смотрите обсуждение под ответом Джона.Хотя всем спасибо за вклад.

Answer 1

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

Если вам нужно«закомментируйте» некоторую обработку исключений, чтобы ваши тесты были жизнеспособными, это может быть признаком того, что вы слишком рано ловите исключения в своем коде.

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

Answer 2

Как вы можете проверить обработку исключений, если хотите изменить обработку исключений?Тестирование измененного поведения не проверяет, что произошло бы, если бы вы не изменили поведение.

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

(Кстати, ловить ArgumentException - это , как правило, плохой знак для начала. Но, возможно, в этом случае это из-за плохо спроектированной библиотеки, которую вы должны использовать.)

РЕДАКТИРОВАТЬ: просто как мысль, если вы сможете проверить Log и Fix, это означает, что вы должны быть в состоянии проверить, были ли они вызваны или нет.В случаях, когда вы не ожидаете, что будет сгенерировано исключение, вы должны быть в состоянии проверить, что они не были вызваны.Если бы они были, вы фактически доказали, что было сгенерировано исключение.

Answer 3

"# IF DEBUG" следует использовать с особой осторожностью. Вы говорите тестируемому коду, что он действует по-разному во время теста, что делает тест довольно близким к бесполезному. Вместо этого ловите определенные типы исключений. Никаких исключений не нужно просто молча ловить - они должны оставить какой-то след. Таким образом, вы либо выбрасываете исключение, либо делаете что-то, что может быть обнаружено пользователями, включая ваш тест.

Я бы посоветовал определить различные типы исключений, с которыми столкнется ваш код, и создать блок catch для каждого из них. Помните, что вы можете создавать свои собственные типы исключений:

    private class MyException: Exception 
    {
    }

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

Если ваша программа не является windows- или веб-службой, я бы порекомендовал вам не перехватывать базовый тип «Exception». Это основано на философии, что, если программа встречает неожиданное поведение, она должна ощущаться громко и четко. В этом контексте исключения НЕ следует рассматривать как неожиданные (т. Е. При использовании базы данных следует ожидать случайные проблемы с подключением, тайм-ауты, проблемы с пользователем и т. Д.).