До запуска приложения в производство, когда оно станет доступно пользователям, важно убедиться, что данное приложение функционирует, как и должно, что в нем нет ошибок. Для проверки приложения мы можем использовать различные схемы и механизмы тестирования. Одним из таких механизмов являются юнит-тесты.
Юнит-тесты позволяют быстро и автоматически протестировать отдельные компоненты приложения независимо от остальной его части. Не всегда юнит-тесты могут покрыть весь код приложения, но тем не менее они позволяют существенно уменьшить количество ошибок уже на этапе разработки.
Мы не должны тестировать код используемого фреймворка или используемых зависимостей. Тестировать надо только тот код, который написали мы сами.
Надо отметить, что в целом концепция юнит-тестов не является непреложным требованием к веб-разработке, да и вообще к разработке. Кто-то считает, что юнит-тесты обязательно должны покрывать весь код проекта, кто-то полагает, что юнит-тесты можно использовать преимущественно для особо сложных моментов в коде приложения, какой-то сложной логики. Некоторые не используют юнит-тесты.
Но тем не менее юнит-тесты несут потенциальные преимущества при разработке, к которым следует отнести не только собственно проверку результата и тестирование кода, но и другие, как например, написание слабосвязанных компонентов в соответствии с принципами SOLID. Ведь чтобы тестировать компоненты приложения независимо друг от друга, нам надо, чтобы они были слабосвязанными. А подобное построение приложения в дальнейшем может положительно сказаться на его последующей модификации и поддержке.
Большинство юнит-тестов так или иначе имеют ряд следующих признаков:
Тестирование небольших участков кода («юнитов»)
Для создания юнит-тестов выбираются небольшие участки кода, которые надо протестировать. Тестируемый участок, как правило, должен быть меньше класса. В большинстве случаев тестируется отдельный метод класса или даже часть функционала метода. Упор на небольшие участки позволяет довольно быстро писать простенькие тесты.
Однажды написанный код нередко читают многократно, поэтому важно писать понятный код. Особенно это важно в юнит-тестах, где в случае неудачи при тестировании разработчик должен быстро прочитать исходный код и понять в чем проблема и как ее исправить. А использование небольших участков кода значительно упрощает подобную работу.
Тестирование в изоляции от остального кода
При тестировании важно изолировать тестируемый код от остальной программы, с которой он взаимодействует, чтобы потом четко определить возможность ошибок именно в этом изолированном коде. Что упрощает и повышает контроль над отдельными компонентами программы.
Автоматизация тестов
Создание юнит-тестов для небольших участков кода ведет к тому, что количество этих юнит-тестов становится очень велико. Если процесс получения результатов и проведения тестов не автоматизирован, то это может привести к непроизводительному расходу рабочего времени и снижению производительности. Поэтому важно, чтобы результаты юнит-тестов представляли собой простое решение, означающее, пройден тест или нет. Для автоматизации процесса разработчики обычно обращаются к фреймворкам юнит-тестирования
Тестирование только общедоступных конечных точек
Даже небольшие изменения в классе могут привести к неудаче многих юнит-тестов, поскольку реализация используемого класса изменилась. Поэтому при написании юнит-тестов ограничиваются только общедоступными конечными точками, что позволяет изолировать юнит-тесты от многих деталей внутренней реализации компонента. В итоге уменьшается вероятность, что изменения в классах могут привести к провалу юнит-тестов.
Фрейморки тестирования
Для написания юнит-тестов мы можем сами создавать весь необходимый функционал, использовать какие-то свои способы тестирования, однако, как правило, для этого применяются специальные фреймворки. Некоторые из них:
- xUnit.net: фреймворк тестирования для платформы .NET. Наиболее популярный фреймворк для работы именно с .NET Core и ASP.NET Core
- MS Test: фреймворк юнит-тестирования от компании Microsoft, который по умолчанию включен в Visual Studio и который также можно использовать с .NET Core
- NUnit: портированный фреймворк с JUnit для платформы .NET
Данные фреймворки предоставляют несложный API, который позволяет быстро написать и автоматически проверить тесты.
Разработка через тестирование (Test-Driven-Development)
Отдельно стоит сказать о концепции TDD или разработка через тестирование. TDD представляет процесс применения юнит-тестов, при котором сначала пишутся тесты, а потом уже программный код, достаточный для выполнения этих тестов.
Использование TDD позволяет снизить количество потенциальных багов в приложении. Создавая тесты перед написанием кода, мы тем самым описываем способ поведения будущих компонентов, не связывая себя при этом с конкретной реализацией этих тестируемых компонентов (тем более что реализация на момент создания теста еще не существует). Таким образом, тесты помогают оформить и описать API будущих компонентов.
Порядок написания кода при TDD довольно прост:
- Пишем юнит-тест
- Запускаем его и видим, что он завершился неудачей (программный код ведь еще не написан)
- Пишем некоторое количество кода, достаточное для запуска теста
- Снова запускаем тест и видим его результаты
Этот цикл повторяется снова и снова, пока не будет закончена работа над программным кодом. Так как большинство фреймворков юнит-тестирования помечают неудавшиеся тесты с красного цвета (например, выводится текст красного цвета), а удачный тест отмечается зеленым цветом (опять же выводится текст зеленого цвета), то данный цикл часто называют красным/зеленым циклом.