C # Best Practices: код модульного тестирования, который ссылается на другие методы?

Question

У меня есть следующий код:

    public static String GetHashString(this HashAlgorithm algorithm, Stream inputStream)
    {
        if (algorithm == null)
            throw new ArgumentNullError("algorithm");

        if (inputStream == null)
            throw new ArgumentNullError("inputStream");

        Byte[] bytes = algorithm.ComputeHash(inputStream);

        //Convert the bytes into a hash string
        String result = ...;
        return result;
    }

Мне интересно несколько вещей:

1. Глядя на метод Microsoft.NET4 HashAlgorithm.ComputeHash(Stream inputStream) Iможно увидеть, что есть исключение, которое может вернуться.Лучше ли в этой ситуации переносить строку Byte[] bytes = algoirthm.ComputeHash(inputStream) с блоком try-catch?Я спрашиваю, потому что мне кажется, что если эта строка выдает исключение, я могу позволить вызовам моего расширения обрабатывать ошибки.Или это должен быть try-catch, завернутый простым броском.

2. Кроме того, при модульном тестировании я должен тестировать модуль на ВСЕ возможные исключения, включая те, которые могут быть получены от другихметод?Особенно в этом случае ... это лучшая практика?В этой ситуации мне нужно только ожидать ObjectDisposeException.Но меня интересует ситуация, когда я вызываю метод, который может отбросить 10 различных исключений.Поскольку я на самом деле не изменяю свой вывод на основе этих исключений, я не думаю, что необходимо проводить модульное тестирование всех типов ошибок, которые приводят к одному и тому же результату.Правильно ли я так думаю?

3. И, наконец, мне интересно, нужно ли даже проверять, чтобы inputStream был нулевым, если метод HashAlgorithm.computeHash(Stream inputStream) даже не делает этого.

Answer 1

помните, что вы должны тестировать свой код, а не .NET Framework,

Я бы не помещал Byte [] bytes = algoirthm.ComputeHash (inputStream) в блок try-catch, код, который вызываетваш метод должен справиться с этим.

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

Я думаю, что ваш код в порядке и именно потому, что .NET выдает исключение, если inputStream имеет значение null, вы делаете эту проверку и выдает ArgumentNullException , если вызывающий код пропускает нулевое значение inputStream

Davide.

Answer 2

1. Делайте try...catch, только если вы хотите как-то обработать исключение (даже если это означает создание нового исключения - но в этом случае используйте параметр innerException). Если вы ничего не можете сделать в случае исключения, нет необходимости использовать его.
2. Чтобы начать думать о всех возможных путях, когда какой-то кусок кода может пойти не так, это путь к безумию. Вы должны проверить все возможные успешные выполнения, вы должны проверить наиболее распространенные ошибки, но иногда вы просто не можете проверить каждую возможную ситуацию. Используйте свое собственное суждение.
3. Если для метода .NET невозможно вернуть значение null, я полагаю, можно не проверять эту возможность. Кстати, некоторые инструменты (например, ReSharper) могут помочь вам с таким решением.

Что касается пункта 3, то этот тип теста, который вы делаете, является предварительным условием, и этот стиль программирования называется Проектирование по контракту . Существует новая платформа .NET, которая помогает определять предусловия, постусловия и инварианты - думаю, вам стоит взглянуть на это:

DevLabs: кодовые контракты

Answer 3

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