Как разбить приложение на модули для тестирования
UNIT TESTING — это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Цель состоит в том, чтобы проверить, что каждая единица программного кода работает должным образом. Модульное тестирование выполняется разработчиками во время разработки (фаза кодирования) приложения. Модульные тесты изолируют часть кода и проверяют его правильность. Единицей может быть отдельная функция, метод, процедура, модуль или объект.
В SDLC, STLC, V Model, модульное тестирование — это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование — это метод тестирования WhiteBox, который обычно выполняется разработчиком. Хотя в практическом мире из-за нехватки времени или нежелания разработчиков тестировать, инженеры QA также проводят модульное тестирование.
В этом уроке вы узнаете
Почему юнит тестирование?
Иногда разработчики программного обеспечения пытаются сэкономить время, выполняя минимальное модульное тестирование. Это миф, потому что пропуск модульного тестирования приводит к увеличению затрат на исправление дефектов во время системного тестирования , интеграционного тестирования и даже бета-тестирования после завершения приложения. Надлежащее модульное тестирование, выполненное на этапе разработки, в конечном итоге экономит время и деньги. Вот ключевые причины для выполнения модульного тестирования.
- Модульные тесты помогают исправлять ошибки на ранних этапах цикла разработки и снижают затраты.
- Это помогает разработчикам понять основы кода и позволяет им быстро вносить изменения
- Хорошие юнит-тесты служат проектной документацией
- Модульные тесты помогают с повторным использованием кода. Перенесите ваш код и ваши тесты в новый проект. Изменяйте код, пока тесты не запустятся снова.
Как сделать модульное тестирование
Модульное тестирование бывает двух типов
Модульное тестирование обычно автоматизировано, но все еще может выполняться вручную. Программная инженерия не поддерживает одно над другим, но автоматизация предпочтительнее. Ручной подход к модульному тестированию может использовать пошаговый инструктивный документ.
В рамках автоматизированного подхода
- Разработчик записывает в приложение часть кода, чтобы протестировать функцию. Позже они закомментируют и, наконец, удаляют тестовый код при развертывании приложения.
- Разработчик также может изолировать функцию для более тщательного тестирования. Это более тщательная практика модульного тестирования, которая включает в себя копирование и вставку кода в собственную среду тестирования, чем в естественную среду. Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте. Эти зависимости могут быть устранены.
- Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. Используя инфраструктуру автоматизации, разработчик кодирует критерии в тесте для проверки правильности кода. Во время выполнения тестовых случаев среда регистрирует неудачные тестовые случаи. Многие фреймворки также автоматически отмечают и сообщают, в общем, об этих неудачных тестах. В зависимости от серьезности сбоя платформа может остановить последующее тестирование.
- Рабочий процесс модульного тестирования: 1) Создание тестовых случаев 2) Просмотр / переработка 3) Базовая линия 4) Выполнение тестовых случаев.
Методы модульного тестирования
Методы покрытия кода, используемые в объединенном тестировании, перечислены ниже:
Пример модульного тестирования: фиктивные объекты
Модульное тестирование основывается на создании фиктивных объектов для тестирования фрагментов кода, которые еще не являются частью законченного приложения. Подставные объекты заполняют недостающие части программы.
Например, у вас может быть функция, которая нуждается в переменных или объектах, которые еще не созданы. В модульном тестировании они будут учитываться в форме фиктивных объектов, созданных исключительно для целей модульного тестирования, выполненного в этом разделе кода.
Инструменты модульного тестирования
Есть несколько автоматизированных инструментов, доступных для помощи в модульном тестировании. Ниже мы приведем несколько примеров:
Это лишь некоторые из доступных инструментов модульного тестирования. Их гораздо больше, особенно для языков Си и Java, но вы обязательно найдете инструмент для модульного тестирования для своих нужд программирования независимо от того, какой язык вы используете.
Разработка через тестирование (TDD) и модульное тестирование
Модульное тестирование в TDD включает в себя широкое использование структур тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже мы рассмотрим некоторые из того, что TDD приносит в мир модульного тестирования:
- Тесты написаны перед кодом
- Положитесь на тестирование фреймворков
- Все классы в приложениях протестированы
- Быстрая и простая интеграция стала возможной
Миф о юнит-тестировании
Миф: Это требует времени, и я всегда overscheduled
Моего кода скала! Мне не нужны юнит-тесты.
Мифы по самой своей природе являются ложными предположениями. Эти предположения приводят к порочному кругу следующим образом:
Правда юнит-тестирование увеличивает скорость разработки.
Преимущество модульного тестирования
Недостатки модульного тестирования
- Нельзя ожидать, что модульное тестирование выявит каждую ошибку в программе. Невозможно оценить все пути выполнения даже в самых тривиальных программах
- Модульное тестирование по своей природе ориентировано на единицу кода. Следовательно, он не может отловить ошибки интеграции или ошибки системного уровня.
Рекомендуется использовать модульное тестирование в сочетании с другими видами тестирования.
Убедитесь, что код работает, как ожидалось, создав и выполнив модульные тесты. Модульное тестирование получило такое название, так как функции программы разбиваются на отдельные тестируемые участки поведения, которые можно протестировать в качестве отдельных модулей. Обозреватель тестов Visual Studio предоставляет гибкий и эффективный способ запуска модульных тестов и просмотра результатов в Visual Studio. Visual Studio устанавливает платформы модульного тестирования Microsoft для управляемого и машинного кода. Платформа модульного тестирования используется для создания модульных тестов, их запуска и создания отчетов о результатах таких тестов. Завершив внесение изменений, запустите модульные тесты повторно, чтобы убедиться, что код по-прежнему работает правильно. Visual Studio Enterprise может выполнять эту задачу автоматически с помощью функции Live Unit Testing, которая определяет тесты, затронутые вносимыми в код изменениями, и выполняет их в фоновом режиме в процессе ввода.
Модульное тестирование максимально влияет на качество кода, когда оно является неотъемлемой частью рабочего процесса разработки ПО. После написания функции или другого блока кода приложения создаются модульные тесты, которые проверяют поведение кода в ответ на стандартные, граничные и некорректные случаи ввода данных; также проверяются любые явные или предполагаемые допущения, сделанные кодом. При разработке, управляемой тестами, модульные тесты создаются перед написанием кода, поэтому модульные тесты используются в качестве технической документации и спецификации функциональности.
Обозреватель тестов также может запускать тесты c платформ модульных тестов стороннего производителя и платформ на основе открытого кода, имеющих дополнительные интерфейсы для Обозревателя тестов. Многие из этих платформ могут быть добавлены при помощи Менеджера расширений Visual Studio и Галереи Visual Studio. Дополнительные сведения см. в разделе Установка платформ модульного тестирования сторонних поставщиков.
Начало работы
Для получения информации по введению в модульное тестирование, которое знакомит вас сразу с созданием кода, см. один из следующих разделов.
Пример решения MyBank
Первая попытка проектирования приложения MyBank включает в себя компонент счетов, который представляет собой лицевой счет и его транзакции с банком, а также компонент базы данных, который включает в себя функции объединения лицевых счетов и управления ими.
Создается решение MyBank , которое содержит два проекта.
Первая попытка создания проекта Accounts содержит класс для хранения базовой информации о счете, интерфейс, который определяет функции счета любого типа, например, для внесения и снятия средств со счета и класс, производный от интерфейса, который представляет собой текущий счет. Проект Счета начинается с создания следующих исходных файлов:
AccountInfo.cs, который определяет основную информацию о счете;
IAccount.cs, определяющего стандартный интерфейс IAccount для счета, включая методы внесения и снятия средств со счета и получения баланса счета;
CheckingAccount.cs, содержащего класс CheckingAccount , который реализует интерфейс IAccount для чекового счета.
Из опыта известно, что при снятии средств с текущего счета необходимо убедиться, что количество снимаемых средств меньше, чем размер баланса счета. Поэтому метод IAccount.Withdraw в CheckingAccount перекрывается методом, который проверяет данное условие. Метод может выглядеть следующим образом.
Теперь, когда есть немного кода, можно провести тестирование.
Создание проекта модульного теста и заглушек модульных тестов
В окне редактора кода выберите в контекстном меню команду Создать модульные тесты.
Заглушки модульных тестов создаются в новом проекте модульного теста для всех методов в классе.
Теперь рассмотрим процедуру Написания тестов, чтобы сделать ваш модульный тест значимым, а также любого рода дополнительные модульные тесты, которые вы, возможно, захотите добавить с целью тщательного тестирования вашего кода.
Создание проекта и модульных тестов вручную
Проект модульного теста отражает структуру проекта кода. В примере MyBank добавляются два проекта модульного тестирования с именами AccountsTests и BankDbTests в решение MyBanks . Имена проекта теста произвольны, но рекомендуется принять концепцию стандартного именования.
Добавление нового проекта модульного тестирование в решение
- В обозревателе решений щелкните решение правой кнопкой мыши и выберите Добавить > СоздатьПроект.
В диалоговом окне Новый проект разверните узел Установлено, выберите требуемый язык для тестового проекта, а затем Тест.
Чтобы использовать одну из платформ модульного тестирования Microsoft выберите Проект модульного тестирования из списка шаблонов проекта. В иных случаях выберите шаблон проекта платформы модульного тестирования, который необходимо использовать. Для тестирования проекта Accounts в нашем примере проект будет назван AccountsTests .
Не все платформы модульного тестирования сторонних разработчиков и на основе открытого кода предоставляют шаблоны проекта Visual Studio. Просмотрите информацию в документе платформы по созданию проекта.
Введите test в поле поиска шаблона проекта, чтобы найти шаблон проекта модульного теста для платформы тестирования, которую вы хотите использовать. (В примерах этого раздела мы используем MSTest.)
На следующей странице присвойте проекту имя. Для тестирования проекта Accounts в нашем примере проект можно назвать AccountsTests .
В проекте модульного тестирования добавьте ссылку на проект кода в тесте, а в данном примере — на проект Счета.
Создание ссылки на проект кода
В проекте модульного теста в обозревателе решений щелкните правой кнопкой мыши узел Ссылки или Зависимости, после чего выберите Добавить ссылку на проект или Добавить ссылку, в зависимости от того, что доступно.
В диалоговом окне диспетчера ссылок откройте узел Решение и выберите Проекты. Выберите наименование проекта кода и закройте диалоговое окно.
Каждый проект модульного тестирования содержит классы, которые отражают имена классов в проекте кода. В данном примере проект AccountsTests будет содержать следующие классы.
Класс AccountInfoTests содержит методы модульного тестирования для класса AccountInfo в проекте Accounts .
Класс CheckingAccountTests содержит методы модульного тестирования для класса CheckingAccount .
Написание тестов
Платформа модульного тестирования и Visual Studio IntelliSense помогут вам в написании кода модульных тестов для проекта кода. Для запуска в обозревателе тестов многие платформы требуют добавления особых атрибутов для определения методов модульного тестирования. Платформы также предоставляют способ — обычно при помощи оператора контроля или атрибутов метода -— для определения успешности или не успешности теста. Другие атрибуты определяют необязательные методы установки, которые выполняются при инициализации класса и перед каждым методом тестирования, а также методы разборки, которые запускаются после каждого метода тестирования и после уничтожения класса.
Модель AAA (размещение, действие, утверждение) является стандартным способом написания модульных тестов для метода тестирования.
Подраздел Размещение метода модульного тестирования инициализирует объекты и устанавливает значение данных, которые переданы методу для теста.
Подраздел Действие вызывает метод для теста с размещенными параметрами.
Дополнительные сведения о платформах модульного тестирования Microsoft см. в одном из следующих разделов:
Настройка времени ожидания для модульных тестов
Если вы используете платформу MSTest, можно использовать TimeoutAttribute для установки времени ожидания в отдельном методе теста:
Задние лимита времени на максимально разрешенный
Выполнение тестов в обозревателе тестов
При построении проекта тестирования тесты появляются в обозревателе тестов. Если обозреватель тестов не виден, выберите Тест в меню Visual Studio, Windows, затем обозреватель тестов (или нажмите клавиши CTRL + E, T).
При выполнении, написании и повторном запуске тестов обозреватель тестов может отображать результаты в группах Неудачные тесты, Пройденные тесты, Пропущенные тесты и Незапущенные тесты. Можно выбирать различные группы по параметрам на панели инструментов.
Кроме того, можно фильтровать тесты по совпадению текста в поле поиска на глобальном уровне или с помощью одного из предустановленных фильтров. Можно запустить любую выборку тестов в любое время. Результаты запущенного теста появляются сразу же в строке "успешно/не успешно" наверху окна обозревателя. Детальная информация результата метода тестирования отображается при выборе теста.
Выполнение и просмотр тестов
Панель инструментов обозревателя тестов помогает найти, организовать и запустить необходимые тесты.
Можно выбрать Запустить все, чтобы запустить все тесты (или нажать клавиши CTRL + R, V), или выбрать Запустить, чтобы выбрать подмножество тестов для запуска (или нажать клавиши CTRL + R, T). Выберите тест, чтобы просмотреть детальную информацию по нему на панели сведений. Выберите Открыть текст в контекстном меню (клавиша F12) для отображения исходного кода выбранного теста.
Если отдельные тесты не имеют зависимостей, предотвращающих запуск этих тестов в любом порядке, включите параллельное тестирование с помощью переключателя на панели инструментов. Это может заметно сократить время, необходимое для выполнения всех тестов.
Если отдельные тесты не имеют зависимостей, предотвращающих запуск этих тестов в любом порядке, включите параллельное тестирование в меню параметров на панели инструментов. Это может заметно сократить время, необходимое для выполнения всех тестов.
Запуск тестов после каждой сборки
| Кнопка | Описание |
|---|---|
 | Чтобы запускать модульные тесты после каждой локальной сборки, в стандартном меню выберите Тест, а затем выберите Выполнить тесты после сборки в панели инструментов обозревателя тестов. |
Запуск модульных тестов после каждой сборки требует Visual Studio 2017 Enterprise или Visual Studio 2019. В Visual Studio 2019 эта функция доступна в выпусках Community и Professional, а также в выпуске Enterprise.
Чтобы запустить модульные тесты после каждой локальной сборки, на панели инструментов обозревателя тестов щелкните значок "Параметры" и выберите в меню пункт Выполнить тесты после сборки.
Фильтрация и группировка списка тестов
Если тестов много, можно отфильтровать список по определенной строке. Для этого введите соответствующий текст в поле поиска обозревателя тестов. Можно ограничить фильтр при помощи выбора фильтров из списка.
| Кнопка | Описание |
|---|---|
 | Для группировки тестов по категории, нажмите кнопку Группировать по . |
Вопросы и ответы
Вопрос. Как выполнять отладку модульных тестов?
Ответ. Чтобы запустить сеанс отладки для тестов, можно использовать обозреватель тестов. Пошагово выполняя код, отладчик Visual Studio плавно переключается назад и вперед между модульными тестами и проектом для тестирования. Начало отладки
В редакторе Visual Studio установите точку останова в одном или нескольких методах тестирования, которые вы хотите проверить.
Так как методы тестирования могут запускаться в любом порядке, необходимо устанавливать точки останова во всех методах тестирования, которые необходимо проверить.
В обозревателе тестов выберите методы тестирования и затем Отладить выбранные тесты из меню быстрого запуска.
См. дополнительные сведения об отладке модульных тестов.
Вопрос. Если я использую TDD, как я могу создать код из тестов?
Ответ. Используйте быстрые действия для создания классов и методов в коде проекта. Напишите инструкцию в методе тестирования, которая вызывает класс или метод, который необходимо создать, затем щелкните значок лампочки, отображаемый под ошибкой. Если вызов предназначен для конструктора нового класса, выберите Сформировать тип из меню и следуйте подсказкам мастера, чтобы вставить класс в проект кода. Если вызов предназначен для метода, выберите Сформировать метод из меню IntelliSense.
Вопрос. Можно ли создать модульные тесты, которые принимают несколько наборов данных в качестве входных данных для выполнения теста?
Ответ. Да. Управляемые данными методы тестирования позволяют тестировать диапазон значений с помощью одного метода модульного теста. Примените к методу теста атрибут DataSource , который определяет источник данных и таблицу, в которых содержатся подлежащие тестированию значения переменных. В теле метода назначьте ряд значений для переменных при помощи индексатора TestContext.DataRow[ ColumnName ] .
Эти процедуры применяются только к методам тестирования, которые пишутся при помощи платформы модульного тестирования Microsoft для управляемого кода. Если используется другая платформа, проконсультируйтесь с документацией по платформе для эквивалентного функционала.
Например, предположим, что был добавлен ненужный метод в класс CheckingAccount , который называется AddIntegerHelper . AddIntegerHelper добавляет два целочисленных значения.
Для создания управляемого данными теста для метода AddIntegerHelper сначала создается база данных доступа с именем AccountsTest.accdb и таблица с именем AddIntegerHelperData . Таблица AddIntegerHelperData определяет колонки для указания первого и второго операнда сложения и колонку, указывающую ожидаемый результат. Заполняем несколько рядов соответствующими значениями.
Метод с атрибутом запускается один раз для каждого ряда в таблице. Обозреватель тестов оповещает о неудачном тесте для метода, если одна из итераций не была успешной. Панель подробных результатов теста для метода показывает статус "прошел/неудачен" для каждого ряда данных.
Вопрос. Можно ли узнать, какой объем кода проверяется модульными тестами?
Ответ. Да. Можно определить объем кода, который был фактически проверен модульными тестами, с помощью средства покрытия кода в Visual Studio Enterprise. Поддерживаются машинные и управляемые языки и все платформы модульного тестирования, которые могут быть запущены платформой модульного тестирования.
Можно запустить покрытие кода на выбранных тестах или на всех тестах решения. Окно результатов объема протестированного кода отображает процент блоков кода продукта, которые были задействованы по строке, функции, классу, пространству имен и модулю.
Чтобы запустить анализ объема протестированного кода для методов теста в решении, выберите Тестирование > Анализ покрытия кода для всех тестов.
Результаты покрытия появляются в окне Результаты объема протестированного кода.
Дополнительные сведения о покрытии кода .
Вопрос. Можно ли протестировать методы в коде, которые имеют внешние зависимости?
Ответ. Да. В выпуске Visual Studio Enterprise компонент Microsoft Fakes можно использовать с методами тестов, которые были написаны с помощью платформ модульного тестирования для управляемого кода.
Microsoft Fakes использует два подхода при создании классов-заменителей для внешних зависимостей:
Заглушки создают классы на замену, которые являются производными от родительского интерфейса класса зависимости цели. Методы заглушек могут быть заменены на публичные виртуальные методы класса цели.
Оболочки используют инструментарий среды выполнения для перевода вызовов целевого метода на метод заменяющей оболочки для невиртуальных методов.
При обоих подходах используются созданные делегаты вызовов для метода зависимости для определения требуемого поведения в данном методе тестирования.
В. Можно ли использовать другие платформы модульного тестирования для создания модульных тестов?
О . Да, выполните инструкции по поиску и установке других платформ. Перезапустив Visual Studio, повторно откройте решение, чтобы создать модульные тесты, и выберите установленные платформы здесь:
Следите за нашими новостями на Facebook! Всегда что-нибудь интересное ;)
В этой статье вы найдете следующую информацию:
- Что такое модульное (Unit) тестирование?
- Зачем оно нужно?
- Как его провести?
- Методы модульного тестирования
- Разработка через тестирование (TDD)
- Преимущества модульного тестирования
- Недостатки модульного тестирования
- Рекомендации по модульному тестированию
В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.
Зачем нужно модульное тестирование?
Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время , а следовательно, в конечном итоге, и деньги.
- Разработчик записывает в приложение единицу кода, чтобы протестировать ее. После: они комментируют и, наконец, удаляют тестовый код при развертывании приложения.
- Разработчик может изолировать единицу кода для более качественного тестирования. Эта практика подразумевает копирование кода в собственную среду тестирования . Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте .
- Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. Используя инфраструктуру автоматизации, разработчик задает критерии теста для проверки корректного выполнения кода, и в процессе выполнения тестовых случаев регистрирует неудачные. Многие фреймворки автоматически отмечают и сообщают, о неудачных тестах и могут остановить последующее тестирование, опираясь на серьезность сбоя.
- Алгоритм модульного тестирования:
- Создание тестовых случаев
- Просмотр / переработка
- Базовая линия
- Выполнение тестовых случаев.
Ниже перечислены методы покрытия кода:
- Заявление покрытия
- Охват решений
- Охват филиала
- Состояние покрытия
- Покрытие конечного автомата
Пример модульного тестирования: фиктивные объекты
Модульное тестирование основывается на создании фиктивных объектов для тестирования фрагментов кода, которые еще не являются частью законченного приложения. Подставные объекты заполняют недостающие части программы.
Например, у вас может быть функция, которая нуждается в переменных или объектах, которые еще не созданы. В модульном тестировании они будут учитываться в форме фиктивных объектов, созданных исключительно для целей модульного тестирования, выполненного в этом разделе кода.
Разработка через тестирование (TDD)Модульное тестирование в TDD включает в себя широкое использование платформ тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже некоторые преимущества TDD:
Расширение возможностей программного обеспечения и как следствие усложнение его архитектуры привело к тому, что возросли также сложность объём работы по его тестированию. В результате этого возникла необходимость автоматизации процесса тестирования. Чтобы программисту или тестировщику при каждой итерации не приходилось в очередной раз выполнять одни и те же действия по проверке правильности работы программы.
В качестве одного из вариантов решения данной задачи можно рассматривать модульное или Unit тестирование.
Идея модульного тестирования состоит в том, что параллельно основному компоненту программы, который включает непосредственно алгоритмы её работы, создаётся дополнительный «тестовый», в котором имитируется работа основного компонента в тех или иных условиях. По результатам выполнения «тестового» компонента судят о правильности работы основного.
При этом «тестовый» компонент можно запускать на выполнение, не компилируя программу целиком, в том числе в автоматическом режиме. Это обеспечивает достаточно высокую степень автоматизации процесса тестирования и значительно сокращает время на его выполнение.
Важно отметить, что задача автоматизации тестирования в принципе не может быть решена полностью. В частности невозможно автоматизировать исследовательское тестирование [1]. Однако автоматизировать рутинные операции, например, интеграционное и регрессионное тестирование можно вполне. Последнее особенно важно, так как при создании новой версии программного обеспечения значительный объём работ по тестированию состоит именно в том, чтобы убедиться, что новый функционал не привёл к ошибкам в работе уже существующего.
Что собой представляет модульный (Unit) тест
Как уже говорилось выше, модульный тест это вспомогательный компонент программы, предназначенный для имитации её работы в целях тестирования. По сути, это не что иное, как программный сценарий, который вызывает те или иные функции тестируемой программы и анализирует результаты их работы.
В настоящее время для создания подобных сценариев нет необходимости разрабатывать какие-либо сложные технические решения. Существует масса готовых фреймворков, которые не только облегчают разработку тестов, но и берут на себя значительную часть работы по анализу и представлению их результатов.
Подобные фреймворки часто входят в состав интегрированных сред разработки (IDE). Собственный фреймворк для модульных тестов имеет и Visual Studio.
Для его использования в разделе «Тест» окна создания нового проекта есть специальный шаблон под названием «Проект модульного теста».
Что собой представляет данный шаблон?
При создании проекта модульного теста создаётся обычный класс, но:
- Как сам класс, так и его методы помечаются специальными атрибутами TestClass и TestMethod соответственно.
Данные атрибуты сообщают компилятору о том, что это класс модульного теста и тестовые методы. - Методы класса должны быть открытыми (public) и иметь тип void.
Класс модульного теста может включать и вспомогательные члены, но лучше всего всё, что связано с процессом тестирования располагать в тестовых методах.
Тестовые методы предназначены для реализации непосредственно процесса тестирования. Для проведения тестирования класс модульного теста должен включать как минимум один тестовый метод.
Сценарии тестирования, реализуемые внутри тестовых методов, могут быть произвольными, но лучше всего всё-таки для каждого тестового случая создавать отдельный тестовый метод.
Тест считается не пройденным (в работе программы присутствует ошибка), если в ходе выполнения тестового метода возникло исключение.
Читайте также: