Должен ли я использовать try catch в моих методах тестирования?

18

Я делаю юнит-тестирование.

Я пытаюсь проверить одну функцию.

Я звоню из моего тестового компонента. Но если удаленная функция не может обработать исключение, то мой компонент тестера также получит исключение, я полагаю.

Так стоит ли мне беспокоиться о получении исключения в моем компоненте тестера?

Благодарю.

РЕДАКТИРОВАТЬ:

PS:

Сгенерировать ошибку - это хорошо, но только для других функций, а не для конечных пользователей, пока не появится последний вариант!

OMG Я написал цитату программирования!

testing unit-testing exceptions

— Викас
источник

Я новичок в тестировании, и я должен только проверить поведение функции. Я думаю, что это называется тестирование черного ящика и белого ящика. О, я помню это. Я учился этому в колледже!

— Викас

Какой язык и фреймворк xUnit вы используете специально? Я бы сказал, да в некоторых случаях.

— Грег К

Я использую MXUnit с MockBox и ColdBox для языка ColdFusion.

— Викас

23

Краткий ответ: НЕТ.

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

Структура модульного теста должна обрабатывать исключения в разумной манере. Большинство (если не все) платформ xUnit имеют конструкцию для ожидания определенных исключений, которые вы используете, когда хотите вызвать конкретное условие исключения в тестируемой системе, и проходят тестовый прогон, если ожидаемое исключение возникает, но терпит неудачу, если это не так.

— mcottle
источник

Я думаю, что расширенная среда тестирования может очень хорошо справляться с исключениями, даже если я обнаружил, что в Visual Studio мы можем проверять исключения, как вы сказали «ожидаемое исключение». Так что это хорошо знать и делиться. Спасибо ..

— Викас

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

— Deadalnix

1

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

— С

1

@Jwenting Прочтите второй абзац - Фреймворки модульного тестирования перехватывают исключения и позволяют тестам проходить, если определенные исключения вызываются, и терпят неудачу, если их нет

— mcottle

5

(В отличие от ответа Маккоттла) Длинный ответ: НЕТ ... большую часть времени

Когда вы говорите, что ожидаете, что тест вызовет определенное исключение, вы будете знать, когда ЛЮБАЯ строка в этом тесте вызывает это конкретное исключение.

Это не совсем то же самое, что знать, что тестируемый метод вызывает исключение.

Если ваш тест включает в себя настройку объекта или контекста (в рамках теста, а не в версии вашего фреймворка SetUp), вам может быть лучше обернуть одну строку, которую вы действительно хотите протестировать, в try / catch, возможно, с помощью помощника.

Например,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

а потом

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

Если этот тест не пройден, я знаю, что мой тестируемый метод выдал исключение, а не что-то в случайной установке.

(Вы должны попытаться избежать случайной настройки. Иногда легче иметь некоторый установочный код в тесте.)

— Фрэнк Шиарар
источник

Хороший пример! Я стараюсь быть очень осторожным, ограничивая фазу «теста» только точным тестом, но я запомню этот трюк, когда я просто не могу понять, как это осуществить (например, при тестировании для состояния гонки). и нужно «настроить» близко к «тесту», чтобы выполнить условие).

— Этель Эванс

1

В общем, вы должны просто исключить исключение, и среда тестирования предоставит вам хороший отчет со всей необходимой информацией.

Но в методологии TDD мы должны следовать следующим шагам:

Написать тест
Смотрите, как это не получится, и сделайте ошибку понятной
Исправить код
Рефакторинг кода и теста

Когда вы выпускаете исключение, если ошибка ясна, тогда это нормально. Но иногда исключение является неясным или даже вводящим в заблуждение. Как вы могли бы позволить, чтобы это было в вашем коде (для вас позже, когда вы забудете, или для члена команды, который потеряет много времени на выяснение проблемы)? Так что моя политика такова: « Если необходимо четко указать на сбой, вам нужно перехватить исключение ».

— KLE
источник