Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core
Одно из преимуществ разработки на платформе ASP.NET MVC предоставляют богатые возможности по тестированию веб-приложения. Можно самим выполнять тестирование тех или иных моментов вручную, а можно использовать специальные небольшие программы, которые называются юнит-тесты.
Юнит-тесты позволяют быстро и автоматически протестировать отдельные участки кода независимо от остальной части программы. При надлежащем составлении юнит-тесты вполне могут покрыть большую часть кода приложения.
Большинство юнит-тестов так или иначе имеют ряд следующих признаков:
Тестирование небольших участков кода ("юнитов")
При создании юнит-тестов выбираются небольшие участки кода, которые надо протестировать. Как правило, тестируемый участок должен быть меньше класса, а в большинстве случаев тестируется отдельный метод класса. Упор на небольшие участки позволяет довольно быстро писать простенькие тесты.
Однажды написанный код нередко читают многократно, поэтому важно писать понятный код. Особенно это важно в юнит-тестах, где в случае неудачи при тестировании разработчик должен быстро прочитать исходный код и понять в чем проблема и как ее исправить. А использование небольших участков кода значительно упрощает подобную работу.
Тестирование в изоляции от остального кода
При тестировании важно изолировать тестируемый код от остальной программы, с которой он взаимодействует, чтобы потом четко определить возможность ошибок именно в этом изолированном коде. Что упрощает и повышает контроль над отдельными компонентами программы.
Тестирование только общедоступных конечных точек
Всего лишь небольшие изменения в классе могут привести к неудаче многих юнит-тестов, поскольку реализация используемого класса изменилась. Поэтому при написании юнит-тестов ограничиваются только общедоступными конечными точками, что позволяет изолировать юнит-тесты от многих деталей внутренней реализации компонента. В итоге уменьшается вероятность, что изменения в классах могут привести к провалу юнит-тестов.
Автоматизация тестов
Написание юнит-тестов для небольших участков кода ведет к тому, что количество этих юнит-тестов становится очень велико. И если процесс получения результатов и проведения тестов не автоматизирован, то это может привести к непроизводительному расходу рабочего времени и снижению производительности. Поэтому важно, чтобы результаты юнит-тестов представляли собой простое решение, означающее, пройден тест или нет. Для автоматизации процесса разработчики обычно обращаются к фреймворкам юнит-тестирования
MS Test: фреймворк юнит-тестирования от компании Microsoft, который по умолчанию включен в Visual Studio (начиная с VS 2012 во все версии)
NUnit: портированный фреймворк с JUnit для платформы .NET
xUnit.net: еще один фреймворк тестирования от создателей NUnit для платформы .NET
Разработка через тестирование (TDD) процесс применения юнит-тестов, при котором сначала пишутся тесты, а потом уже программный код, достаточный для выполнения этих тестов.
Использование TDD позволяет снизить количество потенциальных багов в приложении. Создавая тесты перед написанием кода, мы тем самым описываем способ поведения будущих компонентов, не связывая себя при этом с конкретной реализацией этих тестируемых компонентов (тем более что реализация на момент создания теста еще не существует). Таким образом, тесты помогают оформить и описать API будущих компонентов.
Порядок написания кода при TTD довольно прост:
Пишем юнит-тест
Запускаем его и видим, что он завершился неудачей (программный код ведь еще не написан)
Пишем некоторое количество кода, достаточное для запуска теста
Снова запускаем тест и видим его результаты
Этот цикл повторяется снова и снова, пока не будет закончена работа над программным кодом. Так как большинство фреймворков юнит-тестирования помечают неудавшиеся тесты с красного цвета (например, выводится текст красного цвета), а удачный тест отмечается зеленым цветом (опять же выводится текст зеленого цвета), то данный цикл часто называют красным/зеленым циклом.
Даже если вы охватите юнит-тестами практически всю логику приложения, все равно могут быть моменты, которые будут работать не так, как надо. Кроме того, сложно протестировать представления. Подобные вещи тестируются с помощью интеграционных тестов, выполняющихся на уровне веб-браузера. Для создания подобных тестов в Visual Studio 2013 в версиях Ultimate и Premium доступен такой тип проекта как Coded UI Test Project. Кроме того, доступны open-source решения для создания интеграционных тестов:
WatiN - эмулирует поведение пользователя в веб-браузере. Поддерживает в том числе сайты, использующие ajax
SeleniumHQ - набор инструментов для тестирования в браузерах на различных платформах
Еще один вид тестов представляют нагрузочные тесты, которые призваны протестировать работу сайта в условиях высокой нагрузки. Подобные тесты позволяют выявить узкие места при работе с базой данных или при обращении к диску и ряд других проблем, которые сложно выявить другими способами.
Visual Studio Ultimate также имеет инструментарий для создания нагрузочных тестов.