Утверждение против обработанных исключений в NUnit

Question

У меня есть метод, который берет объект JSON и проходит его через несколько этапов обработки, обновляя значения в базе данных на каждом этапе. Мы хотели, чтобы этот метод был отказоустойчивым, и решили, что в случае сбоя какого-либо этапа обработки желаемое поведение будет записывать ошибку в базу данных и переходить к следующему этапу обработки, а не прерываться.

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

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

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

(работает в C #, но вопрос кажется довольно независимым от языка)

Answer 1

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

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

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

Если вы вводите регистратор, который выглядит примерно так:

public interface ILogger
{
    void LogError(Exception ex);
    void LogMessage(string message);
}

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

public class ListLoggerDouble : ILogger
{
    public List<Exception> Exceptions = new List<Exception>();
    public List<string> Messages = new List<string>();

    public void LogError(Exception ex)
    {
        Exceptions.Add(ex);
    }

    public void LogMessage(string message)
    {
        Messages.Add(message);
    }
}

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

---

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