Начало работы с модульным тестированием в C # с Visual Studio

Question

Я знаю, что Visual Studio предлагает некоторые вкусности модульного тестирования. Как я их использую, как вы их используете? Что я должен знать о модульном тестировании (предположим, я ничего не знаю).

Этот вопрос аналогичен, но он не рассматривает возможности Visual Studio, поэтому не помечайте его как дубликат из-за этого. Опубликовано как вики-сообщество, потому что я не пытаюсь быть представителем.

Answer 1

Несомненно, самое существенное отличие состоит в том, что поддержка MSTest встроена в Visual Studio и обеспечивает непосредственное тестирование модулей, поддержку кода и макетирование. Для выполнения одних и тех же типов вещей во внешних (сторонних) инфраструктурах модульного тестирования, как правило, требуются несколько платформ (структура модульного тестирования и среда для проверки подлинности) и другие инструменты для анализа покрытия кода.

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

Как правило, вы заканчиваете тем, что пишете тесты, которые выглядят примерно так:

string stringVal = "This";
Assert.IsTrue(stringVal.Length == 4);

Это говорит о том, что для переменной с именем stringVal свойство Length должно быть равно 4 после присваивания.

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

Answer 2

Первое, что я хотел бы сделать, это загрузить копию TestDriven.Net для использования в качестве тестового бегуна. Это добавит контекстное меню, которое позволит вам запускать отдельные тесты, щелкнув правой кнопкой мыши в методе тестирования и выбрав Run Test (s). Это также работает для всех тестов в классе (щелчок правой кнопкой мыши в классе, но вне метода), пространства имен (щелчок правой кнопкой мыши по проекту или в пространстве имен вне класса) или для всего решения (щелчок правой кнопкой мыши по решению). Также добавлена ​​возможность запуска тестов с покрытием (встроенным или nCover) или отладчиком из того же контекстного меню.

Что касается настройки тестов, обычно я придерживаюсь одного тестового проекта на проект и одного тестового класса на тестируемый класс. Иногда я создаю тестовые классы для аспектов, которые встречаются во многих классах, но не обычно. Типичный способ их создания - это сначала создать каркас класса - без свойств, без конструктора, но с помощью первого метода, который я хочу протестировать. Этот метод просто генерирует исключение NotImplementedException.

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

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

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

Answer 3

Структура модульного тестирования в VS похожа на NUnit в своем использовании. Одна интересная (и полезная) его особенность существенно отличается от NUnit. Модульное тестирование VS можно использовать с кодом, который не был написан с учетом модульного тестирования.

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

Фреймворк модульного тестирования VS на самом деле очень хорошо реализован и прост в использовании. Лучше всего использовать его с приложением, которое не было разработано с учетом модульного тестирования (что непросто с NUnit).