Внутренние проверки безопасности, как достичь 100% покрытия кода? - PullRequest
Новая
       15

Внутренние проверки безопасности, как достичь 100% покрытия кода?

0 голосов
/ 07 апреля 2019

У меня есть много классов, похожих на следующий: 

public class Foo
{
    private readonly Ba _ba;

    private Foo(Ba ba)
    {
        if (ba is null) throw new ArgumentNullException(ba);

        _ba = ba;
    }
}

Во внутренних классах других классов я называю этот конструктор Foo, но, как это было бы непреднамеренно, в каждом вызове конструктораba - это не null.

Я написал много тестовых методов для составляющей среды, но мне не удалось достичь 100% покрытия кода, так как исключение в приведенном выше фрагменте кода вызвано более новыми.

Я вижу следующие альтернативы:

  • Снимите нулевую проверку: Это будет работать для текущей реализации проекта, но всякий раз, когда я могу добавить случайный вызовFoo(null), отладка будет более сложной.
  • Украсьте конструктор с помощью [ExcludeFromCodeCoverage]: Это будет работать для текущей реализации Foo(Ba), но всякий раз, когда яможет изменить реализацию, новые пути кода в конструкторе могут развиться и случайно пропустить для тестирования.

Как бы вы решили дилемму?

Примечания

Пример кода написан на C #, но этот вопрос может решить общую проблему модульного тестирования / обработки исключений.

C # 8 может решить эту проблему путем введения необнуляемых ссылочных типов , но яищу хорошее решение, пока оно не будет стабильно выпущено.

1 Ответ

2 голосов
/ 17 апреля 2019

Вы пропустили самую важную альтернативу: не рассматривайте ее как желаемую цель для достижения 100% покрытия кода.

Проверка надежности в вашем коде, строго говоря, не поддается проверке разумным способом. Это будет происходить и в различных других частях вашего кода - это часто происходит в операторах switch, где все возможные случаи явно рассматриваются, и добавляется дополнительный случай по умолчанию, просто чтобы вызвать исключение или иным образом обработать эту «невозможную» ситуацию. Или подумайте об утверждениях утверждений, добавленных в код: поскольку утверждения никогда не должны завершаться ошибкой, строго говоря, вы никогда не сможете охватить ветку else, которая скрыта внутри оператора утверждений - как проверить, что выражение внутри утверждения является хорошо на самом деле обнаружить проблему, которую вы хотите?

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

И, как последнее замечание, помните, что высокий охват кода не обязательно свидетельствует о высоком качестве вашего набора тестов. Ваш набор тестов имеет высокое качество, если он обнаружит ошибки в коде, которые могут существовать. У вас может быть набор тестов со 100% охватом, который не обнаружит потенциальных ошибок.

...