Модульные тесты что это

Модульные тесты что это

В этой статье вы найдете следующую информацию:

В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.

Зачем нужно модульное тестирование?

Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время , а следовательно, в конечном итоге, и деньги.

Ниже перечислены методы покрытия кода:

Пример модульного тестирования: фиктивные объекты

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

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

Разработка через тестирование (TDD)

Модульное тестирование в TDD включает в себя широкое использование платформ тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже некоторые преимущества TDD:

Рекомендации по модульному тестированию

Статья подготовлена на основе материалов сайта guru99.com

Источник

Общая картина модульного тестирования

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

Тема модульного тестирования не так проста, как может показаться. Многие из нас, разработчиков, приходят в модульное тестирование под давлением клиентов, сотрудников, коллег, своих кумиров и так далее. Мы быстро понимаем его ценность, и, закончив технические приготовления, забываем об общей картине, если вообще когда-либо её понимали. В этой статье я вкратце расскажу о том, чем является и чем не является модульное тестирование как в целом, так и в PHP, а заодно опишу, какое место занимает модульное тестирование в сфере QA.

Что такое тестирование?

Прежде чем углубляться в модульные тесты, нужно изучить теорию самого тестирования, чтобы не делать ошибок вроде той, что совершили авторы одного из самых популярных PHP-фреймворков: на своём сайте они показали интеграционные тесты и назвали их модульными. Нет, Laravel, это не модульные тесты. Хотя это не мешает мне всё ещё любить этот фреймворк.

Тестирование ПО определяется как «расследование, проведённое с целью предоставления заинтересованным сторонам информации о качестве продукта». Этому противопоставляется «тестирование ПО — это пустая трата бюджета проекта разработчиками, которые не делают ничего важного, а затем просят ещё времени и денег, потому что «ничего» может быть весьма дорогим». Тут ничего нового.

Вот моя краткая история становления тестирования:

Чем на самом деле является тестирование?

Есть разные классификации тестирования ПО. Чтобы лучше понимать место модульного тестирования, упомяну лишь о наиболее широкораспространённых подходах.

Тесты бывают: статические и динамические, «ящичные» (белый ящик, чёрный ящик, серый ящик), уровни и типы. В рамках каждого подхода используются разные критерии классификации.

Статическое и динамическое тестирование

Статическое тестирование проводится без исполнения кода. Сюда относится корректура, проверка, ревизия кода (при наблюдении за работой другого / парном программировании), критический анализ, инспекции и так далее.

Динамическое тестирование для получения корректных результатов требует исполнять код. Например, для модульных тестов, интеграционных, системных, приёмочных и прочих тестов. То есть тестирование проводится с использованием динамических данных, входных и выходных.

«Ящичный» подход

Согласно этому подходу, все тесты ПО делятся на три вида ящиков:

Уровни тестирования

Их количество варьируется, обычно, в диапазоне от 4 до 6, и все они полезны. Названия тоже бывают разные, в зависимости от принятой в компании культуры вы можете знать «интеграционные» тесты как «функциональные», «системные» тесты как «автоматизированные», и так далее. Для простоты я опишу 5 уровней:

Типы тестирования

Каждый тип тестирования, вне зависимости от его уровня, также может подразделяться на другие типы. Существует больше 20 общепринятых типов. Самые распространённые:

Теперь вы знаете, что модульные тесты являются динамическими, относятся к классу «белый ящик», выполняются на уровне модулей, представляют собой регрессионные тесты, но при этом под модульными тестами можно понимать многие разновидности тестов. Так что же такое на самом деле модульные тесты?

Что такое модульное тестирование?

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

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

И это справедливо. У модульных тестов масса достоинств. Они:

Я часто обсуждал с коллегами и клиентами, что такое хороший модульный тест. Он:

Что нужно подвергать модульному тестированию?

В нормальных системах модульные тесты нужно писать для:

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

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

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

Что НЕ нужно тестировать

Чуть сложнее определить, что тестировать не нужно. Я постарался собрать список элементов, которые не нужно подвергать модульному тестированию:

Как писать модульные тесты?

Но ответить на первый вопрос (как писать код, пригодный для модульного тестирования) гораздо легче, и вряд ли ситуация сильно изменится со временем:

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

Источник

Юнит тесты Vs функциональные тесты — взгляд руководителя и разработчика

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

Обычно используют два вида автоматических тестов:
Модульное тестирование (тестирование отдельных частей продукта, обычно отдельных функций/методов)
Функциональное тестирование — тестирование некого функционала продукта, при этом продукт воспринимается как единый «чёрный ящик».

Но давайте зададим интересный вопрос — действительно ли нужны оба вида тестирования сразу, и если нет — то какое из них важнее?

Итак, для начала модульное тестирование.
Кто пишет? Как правило автор модуля/метода/функции, т. к. обычно только он знает, что данная функция ДОЛЖНА делать. Как правило, это разработчик, и его цель — покрытие кода юнит-тестами. А это значит, что скорее всего, юнит-тест будет весьма не полным (как правило разработчики проверяют лишь работу с корректными данными, либо добавляют небольшой набор некорректных данных, т. к. у них не стоит задачи «сломать» свой код), либо, если разработчик действительно ответственно подойдёт к процессу написания юнит-теста, то разработка займёт вдвое больше времени. Не верите? А ведь только качественное покрытие функции «является ли аргумент числом» требует более 10 проверок. К тому же, существует огромное число функций, проверить которые модульным тестированием невозможно, либо очень сложно (это функции, поведение которых зависит от состояния системы в целом).
И даже правильная работа всех модулей системы, отнюдь не гарантирует их правильное взаимодействие.
Ещё один момент, если у вы хотите ввести модульное тестирование в продукт, на котором оно раньше не использовалось — то это очень серьёзные трудо-затраты, и покрытие небольшого числа функций абсолютно ничего не даёт.

Самое главное — даже успешное прохождение всех юнит-тестов не гарантирует правильной работы продукта: ведь одна и та же функция может быть использована в различных частях системы, в то время как юнит-тест писался для неё с оглядкой лишь на один вариант использования.
Простой пример: допустим у нас есть функция checkInt(a). При этом в юнит-тесте нет проверки на отрицательное число. Что это значит? А то, что если некий разработчик модифицирует данную функцию как
checkInt(a), то юнит-тест будет проходить как ни в чём не бывало. А вот функционал будет повреждён. А после того, как ошибка будет найдена и исправлена (функция вернётся к своему изначальному состоянию), отвалится часть функционала в другом месте. При неизменно удачном прохождении юнит-тестов.

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

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

Теперь вернёмся к функциональным тестам. Как правило, они пишутся тестерами. У которых стоит задача найти ошибку (по крайней мере своим тестерам мы всегда ставим такую задачу). А значит будет больше проверок на нестандартные данные — что согласитесь, просто великолепно! К тому же, мы можем разделить правами доступов код продукта и тестов, что позволит избежать изменений тестов «чтоб он был зелёный, потому что надо релизиться»

К тому же, функциональными тестами гораздо проще покрывать готовый продукт, чем модульными — т. к. гораздо проще понять что конкретно должна и не должна делать определённая часть пользовательского интерфейса, чем определить что ДОЛЖНА делать данная функция. И самая большая прелесть — вы можете начать покрывать функциональными тестами только самые важные части продукта — и они будут исправно гарантировать их работоспособность.

Источник

Unit-тесты, пытаемся писать правильно, чтобы потом не было мучительно больно

100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».

Глобально модульные тесты можно условно поделить на две группы: тесты состояния (state based) и тесты взаимодействия (interaction tests).

Тесты состояния — тесты, проверяющие что вызываемый метод объекта отработал корректно, проверяя состояние тестируемого объекта после вызова метода.

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

Стоит также заметить, что модульный (unit) тест может запросто превратиться в интеграционный тест, если при тестировании используется реальное окружение(внешние зависимости) — такие как база данных, файловая система и т.д.

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

Внешняя зависимость — это объект, с которым взаимодействует код и над которым нет прямого контроля. Для ликвидации внешних зависимостей в модульных тестах используются тестовые объекты, например такие как stubs (заглушки).

Стоит заметить что существует классический труд по модульным тестам за авторством Жерарда Месароша под названием «xUnit test patterns: refactoring test code«, в котором автор вводит аж 5 видов тестовых объектов, которые могут запросто запутать неподготовленного человека:

— dummy object, который обычно передается в тестируемый класс в качестве параметра, но не имеет поведения, с ним ничего не происходит, никакие методы не вызываются. Примером таких dummy-объектов являются new object(), null, «Ignored String» и т.д.

— test stub (заглушка), используется для получения данных из внешней зависимости, подменяя её. При этом игнорирует все данные, могущие поступать из тестируемого объекта в stub. Один из самых популярных видов тестовых объектов. Тестируемый объект использует чтение из конфигурационного файла? Передаем ему ConfigFileStub возвращающий тестовые строки конфигурации для избавления зависимости на файловую систему.

— test spy (тестовый шпион), используется для тестов взаимодействия, основной функцией является запись данных и вызовов, поступающих из тестируемого объекта для последующей проверки корректности вызова зависимого объекта. Позволяет проверить логику именно нашего тестируемого объекта, без проверок зависимых объектов.

— mock object (мок-объект), очень похож на тестовый шпион, однако не записывает последовательность вызовов с переданными параметрами для последующей проверки, а может сам выкидывать исключения при некорректно переданных данных. Т.е. именно мок-объект проверяет корректность поведения тестируемого объекта.

— fake object (фальшивый объект), используется в основном чтобы запускать (незапускаемые) тесты (быстрее) и ускорения их работы. Эдакая замена тяжеловесного внешнего зависимого объекта его легковесной реализацией. Основные примеры — эмулятор для конкретного приложения БД в памяти (fake database) или фальшивый вебсервис.

Roy Osherove в книге «The Art of Unit Testing» предлагает упростить данную классификацию и оставляет всего три типа тестовых объектов — Fakes, Stubs и Mocks. Причем Fake может быть как stub-ом, так и mock-ом, а тестовый шпион становится mock-ом. Хотя лично мне не очень нравится перемешивание тестового шпиона и мок-объекта.

Запутанно? Возможно. У данной статьи была задача показать, что написание правильных модульных тестов — достаточно сложная задача, и что не всё то mock, что создаётся в посредством mock-frameworks.

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

Источник

Основные сведения о модульных тестах

Убедитесь, что код работает, как ожидалось, создав и выполнив модульные тесты. Модульное тестирование получило такое название, так как функции программы разбиваются на отдельные тестируемые участки поведения, которые можно протестировать в качестве отдельных модулей. Обозреватель тестов Visual Studio предоставляет гибкий и эффективный способ запуска модульных тестов и просмотра результатов в Visual Studio. Visual Studio устанавливает платформы модульного тестирования Microsoft для управляемого и машинного кода. Платформа модульного тестирования используется для создания модульных тестов, их запуска и создания отчетов о результатах таких тестов. Завершив внесение изменений, запустите модульные тесты повторно, чтобы убедиться, что код по-прежнему работает правильно. Visual Studio Enterprise может выполнять эту задачу автоматически с помощью функции Live Unit Testing, которая определяет тесты, затронутые вносимыми в код изменениями, и выполняет их в фоновом режиме в процессе ввода.

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

Обозреватель тестов также может запускать тесты c платформ модульных тестов стороннего производителя и платформ на основе открытого кода, имеющих дополнительные интерфейсы для Обозревателя тестов. Многие из этих платформ могут быть добавлены при помощи Менеджера расширений Visual Studio и Галереи Visual Studio. Дополнительные сведения см. в разделе Установка платформ модульного тестирования сторонних поставщиков.

Начало работы

Для получения информации по введению в модульное тестирование, которое знакомит вас сразу с созданием кода, см. один из следующих разделов.

Пример решения MyBank

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

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

AccountInfo.cs, который определяет основную информацию о счете;

IAccount.cs, определяющего стандартный интерфейс IAccount для счета, включая методы внесения и снятия средств со счета и получения баланса счета;

Из опыта известно, что при снятии средств с текущего счета необходимо убедиться, что количество снимаемых средств меньше, чем размер баланса счета. Поэтому метод IAccount.Withdraw в CheckingAccount перекрывается методом, который проверяет данное условие. Метод может выглядеть следующим образом.

Теперь, когда есть немного кода, можно провести тестирование.

Создание проектов модульных тестов и методов тестирования (C#)

Для C# как правило, проще создать проект модульного теста и заглушки модульных тестов из кода. Кроме того, можно создать проект модульных тестов и тесты вручную в зависимости от потребностей. Если вы хотите создавать модульные тесты из кода на сторонней платформе, вам потребуется установить одно из этих расширений: NUnit или xUnit. Если вы не используете C#, пропустите этот раздел и перейдите к разделу Создание проекта и модульных тестов вручную.

Создание проекта модульного теста и заглушек модульных тестов

В окне редактора кода выберите в контекстном меню команду Создать модульные тесты.

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

Заглушки модульных тестов создаются в новом проекте модульного теста для всех методов в классе.

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

Создание проекта и модульных тестов вручную

Добавление нового проекта модульного тестирование в решение

В диалоговом окне Новый проект разверните узел Установлено, выберите требуемый язык для тестового проекта, а затем Тест.

Не все платформы модульного тестирования сторонних разработчиков и на основе открытого кода предоставляют шаблоны проекта Visual Studio. Просмотрите информацию в документе платформы по созданию проекта.

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

В проекте модульного тестирования добавьте ссылку на проект кода в тесте, а в данном примере — на проект Счета.

Создание ссылки на проект кода

В проекте модульного теста в обозревателе решений щелкните правой кнопкой мыши узел Ссылки или Зависимости, после чего выберите Добавить ссылку на проект или Добавить ссылку, в зависимости от того, что доступно.

В диалоговом окне диспетчера ссылок откройте узел Решение и выберите Проекты. Выберите наименование проекта кода и закройте диалоговое окно.

Каждый проект модульного тестирования содержит классы, которые отражают имена классов в проекте кода. В данном примере проект AccountsTests будет содержать следующие классы.

Написание тестов

Модель 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.

Вопрос. Можно ли создать модульные тесты, которые принимают несколько наборов данных в качестве входных данных для выполнения теста?

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

Метод с атрибутом запускается один раз для каждого ряда в таблице. Обозреватель тестов оповещает о неудачном тесте для метода, если одна из итераций не была успешной. Панель подробных результатов теста для метода показывает статус «прошел/неудачен» для каждого ряда данных.

Вопрос. Можно ли узнать, какой объем кода проверяется модульными тестами?

Ответ. Да. Можно определить объем кода, который был фактически проверен модульными тестами, с помощью средства покрытия кода в Visual Studio Enterprise. Поддерживаются машинные и управляемые языки и все платформы модульного тестирования, которые могут быть запущены платформой модульного тестирования.

Можно запустить покрытие кода на выбранных тестах или на всех тестах решения. Окно результатов объема протестированного кода отображает процент блоков кода продукта, которые были задействованы по строке, функции, классу, пространству имен и модулю.

Чтобы запустить анализ объема протестированного кода для методов теста в решении, выберите Тестирование > Анализ покрытия кода для всех тестов.

Результаты покрытия появляются в окне Результаты объема протестированного кода.

Вопрос. Можно ли протестировать методы в коде, которые имеют внешние зависимости?

Ответ. Да. В выпуске Visual Studio Enterprise компонент Microsoft Fakes можно использовать с методами тестов, которые были написаны с помощью платформ модульного тестирования для управляемого кода.

Microsoft Fakes использует два подхода при создании классов-заменителей для внешних зависимостей:

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

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

При обоих подходах используются созданные делегаты вызовов для метода зависимости для определения требуемого поведения в данном методе тестирования.

В. Можно ли использовать другие платформы модульного тестирования для создания модульных тестов?

Заглушки модульных тестов будут созданы с помощью выбранной платформы.

Источник