Статьи

Модульное тестирование кратко: расширенное модульное тестирование

Это отрывок из электронной книги «Единичное тестирование » Марка Клифтона, любезно предоставленный Syncfusion.

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

Циклометрическая сложность — это мера количества независимых путей в вашем коде. Тестирование покрытия кода предназначено для обеспечения того, чтобы ваши тесты выполняли все возможные пути кода. Тестирование покрытия кода доступно в версиях Visual Studio Test, Premium и Ultimate. Покрытие кода не является частью NUnit. Также доступно стороннее решение NCover .

Чтобы проиллюстрировать эту проблему, рассмотрим этот код, который анализирует параметры командной строки:

и пара простых тестов (обратите внимание, что в этих тестах пропускаются пути кода, которые приводят к созданию исключений):

Теперь давайте посмотрим, как может выглядеть тест покрытия кода, сначала написав помощник по покрытию кода для бедного человека:

Нам также понадобится простой метод расширения; Вы поймете, почему через минуту:

Теперь мы можем добавить контрольные точки покрытия в наш код, который будет скомпилирован в приложение, когда оно будет скомпилировано в режиме отладки (жирные красные линии добавлены):

И теперь мы можем написать следующий тестовый прибор:

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

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

Этот пример иллюстрирует концепцию:

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

В качестве альтернативы, если методы защищены, рассмотрите возможность создания тестового класса:

Это позволяет создать экземпляр производного класса тестирования и получить доступ к защищенному методу с помощью открытого метода в подклассе.

Наконец, можно использовать отражение для закрытых методов или закрытых классов. Следующее иллюстрирует закрытый метод и его выполнение посредством отражения в тесте: