Live unit testing visual studio как установить

Обновлено: 07.01.2025

В данной теме описывается пошаговый процесс создания простейшего Unit-теста в системе Microsoft Visual Studio 2010 (C++) для приложения типа CLR Console Application . Используя данный пример, можно научиться создавать собственные Unit-тесты. Пример также демонстрирует использование класса Assert для проведения тестирования работы функций.

Содержание

Условие задачи
Выполнение
- 1. Создать приложение по шаблону CLR Console Application
- 2. Реализация функции Max()
- 3. Текст программы, которую нужно протестировать
- 4. Создание теста
  - 4.1. Добавление нового проекта к решению
  - 4.2. Структура решения
  - 4.3. Текст файла теста «UnitTest1.cpp» . Атрибуты [TestMethod] и [TestClass]
  - 4.4. Выполнение изменений в тексте модуля UnitTest1
  - 4.5. Подключение модуля «MaxApp.cpp» проекта MaxApp к проекту TestMaxApp
    - 4.5.1. Способ 1. Подключение с заданием полного имени
    - 4.5.2. Способ 2. Подключение с заданием сокращенного имени
    Поиск на других ресурсах:
    
    Условие задачи
    
    Для приложения типа CLR Console Application необходимо разработать Unit-тест, который тестирует работу функции Max3() , определяющей максимальный элемент из трех чисел. Числа функция получает входными параметрами.
    
    Для функции Max3() установить метод тестирования TestMax() . Проверить работу функции.
    
    Выполнение
    
    1. Создать приложение по шаблону CLR Console Application
    
    После запуска Microsoft Visual Studio нужно выбрать
    
    В результате откроется окно New Project (рисунок 1), в котором нужно выбрать шаблон
    
    Рис. 1. Создание приложения по шаблону CLR Console Application
    
    После выбора OK, будет создано приложение типа CLR Console Application .
    
    После создания приложения, окно текстовой части Microsoft Visual Studio будет иметь приблизительный вид, как показано на рисунке 2.
    
    Рис. 2. Вид приложения после создания
    
    2. Реализация функции Max()
    
    Перед объявлением функции main() вводится текст функции Max() , который имеет следующий вид:
    
    Именно эту функцию нужно будет протестировать с помощью Unit -теста в Microsoft Visual Studio .
    
    3. Текст программы, которую нужно протестировать
    
    На данный момент текст программы, которую нужно протестовать, имеет вид:
    
    Поскольку, эта программа будет тестироваться из другого модуля тестирования, то в функции main() большее ничего вводить не нужно. Так как, в соответствии с условием задачи, нужно протестовать работу функции Max() . А это уже будет осуществляться из модуля тестирования. На данный момент наша программа готова к тестированию.
    
    4. Создание теста
    
    Тест создается отдельным проектом ( Project ) в решении ( Solution ). Программа, которая будет тестироваться не знает об этом. Программа-тест, которая будет тестировать вызывает функции тестируемой программы. В нашем случае программа-тест будет вызывать функцию
    
    4.1. Добавление нового проекта к решению
    
    Для создания теста нужно создать новый проект в решении (Solution). Для этого в Visual Studio вызывается последовательность команд
    
    Рис. 4. Текст модуля UnitTest1.cpp. Окно утилиты Solution Explorer с отображенными проектами TestMaxApp и MaxApp
    
    4.2. Структура решения
    
    Как видно из рисунка 4, утилита Solution Explorer отображает структуру решения ( Solution Items ), которое содержит два проекта:
    - проект MaxApp . Это проект, созданный по шаблону CLR Console Application с функцией Max() , которую нужно протестовать;
    - проект TestMaxApp . Этот проект предназначен для тестирования функций проекта MaxApp . Программный код, который будет тестировать функцию Max() , будет вноситься в файл проекта UnitTest1 проекта TestMaxApp .
    Оба проекта могут выполняться независимо друг от друга.
    
    Листинг файла UnitTest1.cpp , сформированный MS Visual Studio, следующий:
    
    Как видно из вышеприведенного кода, файл содержит класс с именем UnitTest1 . В классе есть общедоступный (public) метод с именем TestMethod1() . Перед реализацией метода TestMethod1() размещается атрибут [TestMethod] . Это значит, что в тело метода нужно вписать код, который будет тестировать функции проекта MaxApp .
    
    В классе можно вписывать любое количество методов, которые будут тестировать разные функции из разных модулей. Главное, чтобы эти методы были помечены атрибутом [TestMethod] . Например, если нужно добавить второй метод тестирования с именем MySecondTestMethod() , то в тело класса нужно вписать приблизительно следующий код:
    
    Аналогично, перед классом UnitTest1 размещается атрибут [TestClass] . Это означает, что в классе есть тестирующие методы.
    
    4.4. Выполнение изменений в тексте модуля UnitTest1
    
    Допускается изменять названия методов и добавлять новые методы, которые помечены атрибутом [TestMethod] в модуле UnitTest1.cpp . Учитывая это, в тексте модуля UnitTest1.cpp метод TestMethod1() необходимо переименовать на TestMax() .
    
    После выполненных изменений, сокращенный текст модуля файла UnitTest1.cpp будет иметь вид:
    
    Существует 2 способы такого подключения:
    
    В данной теме описываются оба способа.
    
    4.5.1. Способ 1. Подключение с заданием полного имени
    
    Этот способ более упрощенный. Он есть удобным, когда нужно подключить в проект небольшое количество файлов для тестирования.
    
    Здесь указывается полное имя на диске файла MaxApp.cpp , в котором размещается функция Max() , которую нужно протестировать.
    
    4.5.2. Способ 2. Подключение с заданием сокращенного имени
    
    Этот способ эффективен, когда нужно протестовать несколько модулей разных проектов. Подключается целый каталог (папка) с файлами тестируемого проекта.
    
    В нашем случае нужно подключить папку:
    
    в перечень ссылок на сборки (проекты), которые автоматически подключаются к проекту TestMaxApp . После этого, можно будет подключать модуль MaxApp.cpp по сокращенному имени
    
    избегая использования длинного имени как показано в пункте 4.5.1.
    
    Рис. 5. Вызов окна просмотра ссылок на сборки, которые используются в проекте TestMaxApp
    
    Рис. 7. Окно Add Reference с отображенными проектами в текущем решении
    
    После выбора на OK происходит возврат в предыдущее окно, в котором в перечне ссылок на сборки будет отображена ссылка на проект MaxApp .
    
    Чтобы сделать это, нужно сначала активировать строку
    
    как показано на рисунке 9.
    
    После выбора, окно Include Directories будет иметь вид как показано на рисунке 11.
    
    Рис. 11. Окно Include Directories после выбора папки E:\Test\MaxApp\MaxApp
    
    Для перехода к предыдущему окну нужно выбрать OK .
    
    Для перехода к написанию программного кода тестирования нужно выбрать OK.
    
    После выполненных действий, все файлы из папки
    
    можно подключать по сокращенному имени, например:
    
    4.6. Написание программного кода для проведения тестирования в методе TestMax()
    
    В вышеприведенном коде вызывается функция AreEqual() из класса Assert . Эта функция сравнивает значение, которое было возвращено из функции Max() и число 6. В данном случае, происходит сравнение числа 7 (максимум) с числом 6. Для такого варианту тест не будет выполняться, так как 7 не равняется 6. В результате функция Assert::AreEqual() выбросит исключительную ситуацию (exception), что будет отображаться в специальном окне (см. п.5).
    
    5. Запуск теста на выполнение и проверка результата тестирования
    
    В Microsoft Visual Studio для работы с Unit-тестами реализовано специальное меню команд, которое называется Test .
    
    Чтобы запустить тест на выполнение, нужно выбрать одну из команд
    
    как изображено на рисунке 13.
    
    Рис. 13. Вызов команды запуска тестирования и просмотр результата
    
    После запуска теста, результат можно просмотреть в нижней части в окне Test Results . Как видно, тест не сдан. Это логично, поскольку в функции Assert::AreEqual() мы сравниваем числа 6 и 7, которые различны между собой. Здесь специально введено число 6 вместо числа 7.
    
    Если вместо числа 6 ввести правильный ответ – число 7 (максимум между 5, 6, 7), то тест будет сдан. В этом случае текст метода TestMax() будет следующей:
    
    Окно результата изображено на рисунке 14.
    
    Рис. 14. Результат тестирования для случая, если ввести правильную проверку
    
    Теперь можно сделать вывод о том, что функция Max() разработана правильно
    
    6. Текст модуля UnitTest1
    
    7. Итог. Взаимодействие между проектами
    
    В данной работе в решении (Solution) сформированы два проекта. Один проект MaxApp содержит функцию Max() которую нужно протестировать. Второй проект TestMaxApp содержит методы, которые тестируют.
    
    В Microsoft Visual Studio каждый из проектов запускается с помощью различных команд меню. Так, проект MaxApp запускается стандартным способом из меню Run . А тестирующий проект TestMaxApp запускается из специального меню Test .
    
    В процессе разработки приложения функция Live Unit Testing автоматически выполняет все затронутые модульные тесты в фоновом режиме и отображает результаты и объем протестированного кода в реальном времени. При изменении кода эта функция предоставляет отчет о том, как внесенные изменения повлияли на имеющиеся и покрывается ли новый добавленный код одним или несколькими имеющимися тестами. За счет этого вы не забудете написать модульные тесты при исправлении ошибок или добавлении новых функций.
    
    Используемая для тестирования функция Live Unit Testing сохраняет данные о состоянии тестов. Благодаря этому Live Unit Testing обеспечивает высокую производительность наряду с динамическим выполнением тестов при изменении кода.
    
    Поддерживаемые тестовые платформы
    
    Если у вас есть старые тестовые проекты на основе MSTest, которые ссылаются на Microsoft.VisualStudio.QualityTools.UnitTestFramework, и вы не хотите переходить на более новые пакеты NuGet MSTest, выполните обновление до Visual Studio 2019 или Visual Studio 2017.
    
    В некоторых случаях, чтобы обеспечить работу Live Unit Testing, вам потребуется явным образом восстановить пакеты NuGet, на которые ссылается проект. Это можно сделать, выполнив сборку решения явным образом (в меню верхнего уровня Visual Studio выберите Сборка > Пересобрать решение) или восстановив пакеты в решении (щелкните решение правой кнопкой мыши и выберите пункт Восстановить пакеты NuGet).
    
    Настройка
    
    Чтобы настроить Live Unit Testing, в меню верхнего уровня Visual Studio выберите Инструменты > Параметры, а затем в левой области диалогового окна Параметры выберите Live Unit Testing.
    
    После включения функции Live Unit Testing (см. следующий раздел Запуск, приостановка и остановка) вы также можете открыть диалоговое окно Параметры, выбрав Тест > Live Unit Testing > Параметры.
    
    На следующем изображении показаны параметры конфигурации Live Unit Testing, доступные в этом диалоговом окне:
    
    С помощью этих параметров вы можете настроить следующее:
    
    Будет ли функция Live Unit Testing приостанавливаться во время сборки и отладки решения.
    
    Будет ли функция Live Unit Testing приостанавливаться, если заряд батареи системы опустится ниже установленного порогового значения.
    
    Будет ли функция Live Unit Testing запускаться автоматически после открытия решения.
    
    Следует ли включить отладочный символ и создание комментариев к XML-документации.
    
    Каталог, в котором хранятся сохраняемые данные.
    
    Возможность удалять все сохраненные данные. Это полезно, когда функция Live Unit Testing работает непредсказуемо, что свидетельствует о вероятном повреждении хранимых данных.
    
    Интервал, после которого истекает время ожидания тестового случая. По умолчанию используется значение 30 секунд.
    
    Максимальное число процессов тестирования, создаваемых Live Unit Testing.
    
    Максимальный объем памяти, которую могут использовать процессы Live Unit Testing.
    
    Уровень информации, записываемой функцией Live Unit Testing в окно Выходные данные.
    
    Можно также отобразить подробные выходные данные в окне Выходные данные в Live Unit Testing, задав для переменной среды уровня пользователя VS_UTE_DIAGNOSTICS значение 1 и перезапустив Visual Studio.
    
    Запуск, приостановка и остановка
    
    Чтобы включить Live Unit Testing, в меню верхнего уровня Visual Studio выберите Тест > Live Unit Testing > Запустить. После включения Live Unit Testing в меню Live Unit Testing параметр Запустить можно изменить на следующие параметры: Пауза и Остановить:
    
    Пауза. Этот параметр позволяет временно приостановить работу функции Live Unit Testing.
    
    В этом случае визуализация протестированного объема не отображается в редакторе, но все собранные данные сохраняются. Чтобы возобновить работу этой функции, в меню Live Unit Testing выберите Продолжить. Функция Live Unit Testing выполнит необходимую работу с учетом всех внесенных во время приостановки изменений и обновит глиф должным образом.
    
    Остановить. Этот параметр позволяет полностью остановить работу функции Live Unit Testing. Все собранные данные будут удалены.
    
    Вы можете в любой момент временно или полностью остановить работу этой функции. Это можно сделать, например, если вы выполняете рефакторинг и знаете, что некоторое время тесты не будут работать.
    
    Просмотр визуализации протестированного объема
    
    После включения функция Live Unit Testing обновляет каждую строку кода в редакторе Visual Studio, чтобы показать, охватывают ли модульные тесты написанный код и завершились ли они успешно. На следующем изображении показаны строки кода с выполненными тестами и тестами, завершившимися сбоем, а также строки кода, не входящие в протестированный объем. Строки с зеленым значком "✓" прошли все тесты, строки с красным значком "x" не прошли один или несколько тестов, а строки с синим значком "➖" не охвачены ни одним из тестов.
    
    Визуализация протестированного объема в Live Unit Testing обновляется сразу же после изменения кода в редакторе. Во время обработки правок визуализация изменяется, указывая, что данные не обновлены. В этом случае под символами успешного выполнения, сбоя и символом непротестированного объема появляется круглый значок таймера, как показано на изображении ниже.
    
    Получение информации о состоянии теста
    
    Наведя указатель мыши на символ удачного или неудачного выполнения в окне кода, вы можете увидеть, сколько тестов выполнялось в этой строке. Чтобы просмотреть данные о состоянии отдельных тестов, выберите символ:
    
    Кроме отображения имен и результатов тестов подсказка позволяет повторно запустить набор тестов или выполнить их отладку. Если в подсказке выбрать один или несколько тестов, можно также запустить или выполнить отладку только для них. Это позволяет отлаживать тесты, оставаясь в окне с кодом. Помимо возможности отслеживания всех настроенных точек останова, при отладке вы также можете запрограммировать приостановку, когда отладчик выполняет метод Assert, возвращающий непредвиденный результат.
    
    Если навести указатель мыши на непройденный тест в подсказке, она развернется. Здесь вы можете просмотреть дополнительные сведения, как показано на следующем рисунке: Чтобы перейти непосредственно к непройденному тесту, дважды щелкните его в подсказке.
    
    При переходе к непройденному тесту Live Unit Testing отображает в сигнатуре метода тесты, которые:
    - выполнены успешно (наполовину полная колба со значком "✓" зеленого цвета);
    - не удалось выполнить (наполовину полная колба со значком "🞩" красного цвета);
    - не обрабатываются Live Unit Testing (наполовину полная колба со значком "➖" синего цвета).
    Невключенные в тестирование методы теста не обозначаются значком. На следующем изображении показаны все четыре типа методов.
    
    Диагностика и устранение сбоев тестов
    
    В окне непройденного теста вы можете с легкостью отладить код продукта, внести изменения и продолжить разработку приложения. Так как функция Live Unit Testing выполняется в фоновом режиме, ее не нужно останавливать и перезапускать при отладке, внесении правок и продолжении цикла.
    
    Обозреватель тестов
    
    Обозреватель тестов предоставляет интерфейс, позволяющий выполнять и отлаживать тесты, а также анализировать их результаты. Функция Live Unit Testing интегрируется с обозревателем тестов. Когда эта функция отключена или остановлена, обозреватель тестов отображает состояние модульных тестов во время последнего запуска тестирования. При изменении исходного кода тесты необходимо выполнить повторно. И напротив, если функция Live Unit Testing включена, состояние модульных тестов в обозревателе тестов сразу же обновляется. Вам не нужно явно запускать модульные тесты.
    
    Откройте Live Unit Testing, выбрав Тест > Окна > Обозреватель тестов в меню верхнего уровня Visual Studio.
    
    Вы можете заметить, что в окне обозревателя тестов некоторые тесты затемнены. Например, если включить функцию Live Unit Testing после открытия ранее сохраненного проекта, в окне обозревателя тестов будут затемнены все тесты, кроме непройденных, как показано на следующем изображении. В этом случае Live Unit Testing перезапускает непройденный тест (но не успешно выполненные тесты). Это связано с тем, что сохраненные данные Live Unit Testing указывают на отсутствие изменений с момента последнего успешного выполнения тестов.
    
    Вы можете повторно запустить любые затененные тесты, выбрав параметры Выполнить все или Выполнить в меню обозревателя тестов. Либо выберите один или несколько тестов в меню обозревателя тестов, щелкните их правой кнопкой мыши и выберите Выполнить выбранные тесты или Отладка выбранных тестов во всплывающем меню. По мере выполнения тесты перемещаются наверх.
    
    Между автоматическим выполнением с обновлением результатов теста с помощью функции Live Unit Testing и явным выполнением тестов в обозревателе тестов есть некоторые различия. Эти отличия описаны ниже.
    - Во время выполнения и отладки тестов из окна обозревателя тестов используются обычные двоичные файлы, а при использовании функции Live Unit Testing — инструментированные двоичные файлы.
    - При выполнении тестов функция Live Unit Testing не создает домен приложения, а использует домен по умолчанию. При выполнении тестов в окне обозревателя тестов домен приложения создается.
    - Функция Live Unit Testing выполняет тесты из разных сборок последовательно. В окне обозревателя тестов можно выбрать режим параллельного выполнения нескольких тестов.
    Окно Live Unit Testing
    
    Live Unit Testing, как и обозреватель тестов, предоставляет интерфейс, позволяющий выполнять и отлаживать тесты, а также анализировать их результаты. При включении Live Unit Testing состояние модульных тестов в обозревателе тестов сразу же обновляется. Вам не нужно явно запускать модульные тесты. При отключении или остановке Live Unit Testing обозреватель тестов отображает состояние модульных тестов при их последнем запуске. После перезапуска Live Unit Testing для повторного выполнения тестов нужно изменить исходный код.
    
    Для запуска Live Unit Testing выберите Тест > Live Unit Testing > Запуск в меню верхнего уровня Visual Studio. Вы также можете открыть окно Live Unit Testing, последовательно выбрав Вид > Другие окна > Окно Live Unit Testing.
    
    Вы можете заметить, что в окне Live Unit Testing некоторые тесты затемнены. Например, если остановить и перезапустить Live Unit Testing, в окне Live Unit Testing будут затемнены все тесты, как показано на следующем изображении. Затемненные результаты означают, что в ходе последнего запуска Live Unit Testing этот тест не выполнялся. Тесты выполняются только при обнаружении изменений в тесте или его зависимостях. Если изменения отсутствуют, тест без необходимости не выполняется. В этом случае результат затемненного теста по-прежнему остается "актуальным", хотя в ходе последнего запуска тест не выполнялся.
    
    Любой затемненный тест можно перезапустить, внеся изменения в код.
    
    Между автоматическим выполнением с обновлением результатов теста с помощью функции Live Unit Testing и явным выполнением тестов в обозревателе тестов есть некоторые различия. Эти отличия описаны ниже.
    - Во время выполнения и отладки тестов из окна обозревателя тестов используются обычные двоичные файлы, а при использовании функции Live Unit Testing — инструментированные двоичные файлы.
    - При выполнении тестов функция Live Unit Testing не создает домен приложения, а использует домен по умолчанию. При выполнении тестов в окне обозревателя тестов домен приложения создается.
    - Функция Live Unit Testing выполняет тесты из разных сборок последовательно. В окне обозревателя тестов можно выбрать режим параллельного выполнения нескольких тестов.
    Крупные решения
    
    Если решение содержит 10 или более проектов, в Visual Studio отобразится следующее диалоговое окно при выполнении таких действий:
    - запуск Live Unit Testing без сохраненных данных;
    - выбор элементов Инструменты > Параметры > Live Unit Testing > Удаление хранимых данных.
    В диалоговом окне выводится предупреждение о том, что динамическое выполнение большого количества тестов в крупных проектах может значительно ухудшить производительность. Если нажать кнопку ОК, Live Unit Testing выполнит все тесты в решении. Если нажать кнопку Отменить, можно выбрать тесты для выполнения. Подробные сведения см. в следующем разделе.
    
    <a name="include-and-exclude-test-projects-and-test-methods">Добавление и исключение тестовых проектов и методов теста
    
    В решениях с большим количеством тестовых проектов вы можете контролировать, какие проекты и отдельные методы в проекте могут использоваться в функции Live Unit Testing. Например, если у вас есть решение с сотнями тестовых проектов, вы можете выбрать только целевой набор, который будет использоваться с этой функцией. Это можно сделать несколькими способами в зависимости от того, следует ли исключить все тесты в проекте или решении, включить или исключить большую часть тестов либо исключить отдельные тесты. Функция Live Unit Testing сохраняет состояние включения или исключения и запоминает его после закрытия и повторного открытия решения.
    
    Исключение всех тестов в проекте или решении
    
    Чтобы выбрать отдельные проекты в модульных тестах, запустите Live Unit Testing и выполните следующие действия:
    1. В обозревателе решений щелкните решение правой кнопкой мыши и выберите Динамическое модульное тестирование > Исключить, чтобы исключить все решение.
    2. Щелкните правой кнопкой мыши каждый тестовый проект, который вы хотите добавить в тесты, и выберите Динамическое модульное тестирование > Включить.
    Исключение отдельных тестов в окне редактора кода
    
    Включать и исключать отдельные методы теста можно в окне редактора кода. В окне редактора кода щелкните сигнатуру метода теста правой кнопкой мыши и выберите один из следующих вариантов:
    - Динамическое модульное тестирование > Включить <selected method>
    - Динамическое модульное тестирование > Исключить <selected method>
    - Динамическое модульное тестирование > Исключить все, кроме <selected method>
    Исключение тестов с помощью программных средств
    
    Вы также можете отменить создание отчетов о покрытии в Live Unit Testing для некоторых методов, классов или структур, применив к ним атрибут ExcludeFromCodeCoverageAttribute.
    
    Чтобы исключить отдельные методы из Live Unit Testing, используйте следующие атрибуты:
    - Для xUnit: [Trait("Category", "SkipWhenLiveUnitTesting")]
    - Для NUnit: [Category("SkipWhenLiveUnitTesting")]
    - Для MSTest: [TestCategory("SkipWhenLiveUnitTesting")]
    Чтобы исключить целые сборки тестов из Live Unit Testing, используйте следующие атрибуты:
    
    Пошаговое руководство. Создание и запуск модульных тестов для управляемого кода
    
    Создайте проект для тестирования
    
    Запустите Visual Studio.
    
    В меню Файл выберите Создать > Проект.
    
    Откроется диалоговое окно Новый проект .
    
    Присвойте проекту имя Bank и нажмите кнопку ОК.
    
    Будет создан проект Bank. Он отобразится в обозревателе решений, а его файл Program.cs откроется в редакторе кода.
    
    [!NOTE] Если файл Program.cs не откроется в редакторе, дважды щелкните Program.cs в обозревателе решений, чтобы открыть его.
    
    Запустите Visual Studio.
    
    На начальном экране выберите Создать проект.
    
    Назовите проект Bank и щелкните Далее.
    
    Будет создан проект Bank. Он отобразится в обозревателе решений, а его файл Program.cs откроется в редакторе кода.
    
    [!NOTE] Если файл Program.cs не откроется в редакторе, дважды щелкните Program.cs в обозревателе решений, чтобы открыть его.
    
    Переименуйте файл в BankAccount.cs, щелкнув его правой кнопкой мыши и выбрав команду Переименовать в обозревателе решений.
    
    В меню Сборка нажмите Построить решение (или нажмите клавиши CTRL + SHIFT + B).
    
    Теперь у вас есть проект с методами, которые можно протестировать. В этой статье тестирование проводится на примере метода Debit . Метод Debit вызывается, когда денежные средства снимаются со счета.
    
    Создание проекта модульного теста
    
    В меню Файл выберите Добавить > Создать проект.
    
    [!TIP] В обозревателе решений щелкните решение правой кнопкой мыши и выберите пункты Добавить > Создать проект.
    
    В поле Имя введите BankTests , а затем нажмите кнопку ОК.
    
    Проект BankTests добавляется в решение Банк.
    
    Назовите проект BankTests и щелкните Далее.
    
    Проект BankTests добавляется в решение Банк.
    
    В проекте BankTests добавьте ссылку на проект Банк.
    
    В обозревателе решений щелкните Зависимости в проекте BankTests, а затем выберите в контекстном меню Добавить ссылку.
    
    В диалоговом окне Диспетчер ссылок разверните Проекты, выберите Решение и выберите элемент Банк.
    
    Создание тестового класса
    
    Создание тестового класса, чтобы проверить класс BankAccount . Можно использовать UnitTest1.cs, созданный в шаблоне проекта, но лучше дать файлу и классу более описательные имена.
    
    Переименуйте файл и класс
    1. Чтобы переименовать файл, в обозревателе решений выберите файл UnitTest1.cs в проекте BankTests. В контекстном меню выберите команду Переименовать (или нажмите клавишу F2), а затем переименуйте файл в BankAccountTests.cs.
    1. Чтобы переименовать класс, выберите Да в открывшемся диалоговом окне, предлагающем также переименовать ссылки на элемент кода.
    1. Чтобы переименовать класс, поместите курсор в UnitTest1 в редакторе кода, щелкните правой кнопкой мыши и выберите команду Переименовать (или нажмите клавиши F2). Введите название BankAccountTests и нажмите клавишу ВВОД.
    Файл BankAccountTests.cs теперь содержит следующий код:
    
    Добавьте оператор using
    
    Можно также добавить оператор using в класс, чтобы тестируемый проект можно было вызывать без использования полных имен. Вверху файла класса добавьте:
    
    Требования к тестовому классу
    
    Минимальные требования к тестовому классу следующие:
    
    Атрибут [TestClass] является обязательным в любом классе, содержащем методы модульных тестов, которые необходимо выполнить в обозревателе тестов.
    
    Каждый метод теста, предназначенный для запуска в обозревателе тестов, должен иметь атрибут [TestMethod] .
    
    Можно иметь другие классы в проекте модульного теста, которые не содержат атрибута [TestClass] , а также иметь другие методы в тестовых классах, у которых атрибут — [TestMethod] . Можно вызывать эти другие классы и методы в методах теста.
    
    Создание первого тестового метода
    
    В этой процедуре мы напишем методы модульного теста для проверки поведения метода Debit класса BankAccount .
    
    Существует по крайней мере три поведения, которые требуется проверить:
    
    Метод создает исключение xref:System.ArgumentOutOfRangeException , если сумма по дебету превышает баланс.
    
    Метод создает исключение xref:System.ArgumentOutOfRangeException, если сумма по дебету меньше нуля.
    
    Если значение дебета допустимо, то метод вычитает сумму дебета из баланса счета.
    
    [!TIP] Метод по умолчанию TestMethod1 можно удалять, так как он не используется в этом руководстве.
    
    Создание метода теста
    
    Первый тест проверяет, снимается ли со счета нужная сумма при допустимом размере кредита (со значением меньшим, чем баланс счета, и большим, чем ноль). Добавьте следующий метод в этот класс BankAccountTests :
    
    Метод очень прост: он создает новый объект BankAccount с начальным балансом, а затем снимает допустимое значение. Он использует метод xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.AreEqual%2A?displayProperty=nameWithType, чтобы проверить, что конечный баланс соответствует ожидаемому. Такие методы, как Assert.AreEqual , xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.IsTrue%2A?displayProperty=nameWithType и другие, зачастую используются в модульном тестировании. Дополнительную концептуальную информацию о написании модульного теста см. в разделе Написание тестов.
    
    Требования к методу теста
    
    Метод теста должен удовлетворять следующим требованиям:
    
    Он декорируется атрибутом [TestMethod] .
    
    Он возвращает void .
    
    Он не должен иметь параметров.
    
    Сборка и запуск теста
    
    В меню Сборка нажмите Построить решение (или нажмите клавиши CTRL + SHIFT + B).
    
    Откройте Обозреватель тестов, выбрав Тест > Windows > Обозреватель тестов в верхней строке меню (или нажмите клавиши CTRL + E, T).
    
    Выберите Запустить все, чтобы выполнить тест (или нажмите клавиши CTRL + R, V).
    
    Во время выполнения теста в верхней части окна Обозреватель тестов отображается анимированная строка состояния. По завершении тестового запуска строка состояния становится зеленой, если все методы теста успешно пройдены, или красной, если какие-либо из тестов не пройдены.
    
    В данном случае тест пройден не будет.
    
    Выберите этот метод в обозревателе тестов для просмотра сведений в нижней части окна.
    
    Исправление кода и повторный запуск тестов
    
    Модульный тест обнаружил ошибку: сумма списания добавляется на баланс счета, вместо того чтобы вычитаться.
    
    Повторный запуск теста
    
    В обозревателе тестов выберите Запустить все, чтобы запустить тест повторно (или нажмите клавиши CTRL + R, V). Красно-зеленая строка становится зеленой, чтобы указать, что тест был пройден.
    
    Использование модульных тестов для улучшения кода
    
    В этом разделе рассматривается, как последовательный процесс анализа, разработки модульных тестов и рефакторинга может помочь сделать рабочий код более надежным и эффективным.
    
    Мы создали тестовый метод для подтверждения того, что допустимая сумма правильно вычитается в методе Debit . Теперь проверим, что метод создает исключение xref:System.ArgumentOutOfRangeException, если сумма по дебету:
    
    Создание и запуск новых методов теста
    
    Создадим метод теста для проверки правильного поведения в случае, когда сумма по дебету меньше нуля:
    
    Мы используем метод xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException%2A для подтверждения правильности созданного исключения. Этот метод приводит к тому, что тест не будет пройден, если не возникнет исключения xref:System.ArgumentOutOfRangeException. Если временно изменить тестируемый метод для вызова более общего исключения xref:System.ApplicationException при значении суммы по дебету меньше нуля, то тест работает правильно — то есть завершается неудачно.
    
    Чтобы проверить случай, когда размер списания превышает баланс, выполните следующие действия:
    
    Создать новый метод теста с именем Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange .
    
    Скопировать тело метода из Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange в новый метод.
    
    Присвоить debitAmount значение, превышающее баланс.
    
    Выполните два теста и убедитесь, что они пройдены.
    
    Тестируемый метод можно дополнительно улучшить. При такой реализации мы не можем знать, какое условие ( amount > m_balance или amount < 0 ) приводят к исключению, возвращаемому в ходе теста. Нам просто известно, что ArgumentOutOfRangeException где-то возникает в методе. Было бы лучше знать, какое условие в BankAccount.Debit вызвало исключение ( amount > m_balance или amount < 0 ), чтобы быть уверенными в том, что наш метод правильно проверяет свои аргументы.
    
    Еще раз проанализировав тестируемый метод BankAccount.Debit , можно заметить, что оба условных оператора используют конструктор ArgumentOutOfRangeException , который просто получает имя аргумента в качестве параметра:
    
    Рефакторинг тестируемого кода
    
    Затем изменим два условных оператора в методе Debit :
    
    Рефакторинг тестовых методов
    
    В этом случае метод Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange может выглядеть следующим образом:
    
    Повторное тестирование, переписывание и анализ
    
    Метод теста сейчас обрабатывает не все требуемые случаи. Если тестируемый метод Debit не смог выдать исключение xref:System.ArgumentOutOfRangeException, когда значение debitAmount было больше остатка (или меньше нуля), метод теста выдает успешное прохождение. Это нехорошо, поскольку метод теста должен был завершиться с ошибкой в том случае, если исключение не создается.
    
    Это является ошибкой в методе теста. Для решения этой проблемы добавим утверждение xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Fail%2A?displayProperty=nameWithType в конце тестового метода для обработки случая, когда исключение не создается.
    
    Однако повторный запуск теста показывает, что тест теперь оказывается непройденным при перехватывании верного исключения. Блок catch перехватывает исключение, но метод продолжает выполняться, и в нем происходит сбой на новом утверждении xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Fail%2A?displayProperty=nameWithType. Чтобы разрешить эту проблему, добавим оператор return после StringAssert в блоке catch . Повторный запуск теста подтверждает, что проблема устранена. Окончательная версия метода Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange выглядит следующим образом:
    
    Усовершенствования тестового кода привели к созданию более надежных и информативных методов теста. Но что более важно, в результате был также улучшен тестируемый код.
    
    [!TIP] В этом пошаговом руководстве используется платформа модульных тестов Microsoft для управляемого кода. Обозреватель тестов также может запускать тесты c платформ модульных тестов стороннего производителя, которые имеют адаптеры для обозревателя тестов. Дополнительные сведения см. в разделе Установка платформ модульного тестирования сторонних поставщиков.
    
    Итак, теперь у нас есть NuGet, но нам нужны NUnit (я буду использовать именно этот фреймворк вместо встроенного в Visual Studio) совместно с NSubstitute.
    
    Создадим тестовый консольный проект и назовем его SampleProject, я установил галочку напротив Create directory for solution, чтобы папка с тестами для проекта была не вложенной в сам проект, а была на одном уровне.
    
    Теперь создадим проект, содержащий юнит тесты для нашего проекта
    
    Прописываем имя проекта
    
    Заметьте что в Location я поднялся на уровень выше, изначально мне рекомендовали создать проект юнит тестов внутри папки с проектом.
    
    Открываем консоль NuGet
    
    И набираем команду
    Install-Package NUnit
    а затем
    Install-Package NSubstitute
    
    ВАЖНО: не забудьте выбрать в качестве дефолтного проекта ваш проект с юнит тестами а не с программой. Иначе библиотеки установятся не в тот проект.
    
    и видим, что компилятор теперь понимает наши атрибуты, старый using можно удалить (using Microsoft.VisualStudio.TestTools.UnitTesting)
    
    Я надеюсь вы прочитали книгу The Art Of Unit testing или просто имеете понятие как работать в общих чертах с NUnit, т.к. глубоко базис я объяснять не планирую, немного не тот формат статьи.
    
    Читайте также: