|
|
@@ -0,0 +1,34 @@
|
|
|
+ Unit-Tests
|
|
|
+До запуска приложения в производство, когда оно станет доступно пользователям, важно убедиться, что данное приложение функционирует, как и должно, что в нем нет ошибок. Для проверки приложения мы можем использовать различные схемы и механизмы тестирования. Одним из таких механизмов являются юнит-тесты.
|
|
|
+Юнит-тесты позволяют быстро и автоматически протестировать отдельные компоненты приложения независимо от остальной его части. Не всегда юнит-тесты могут покрыть весь код приложения, но тем не менее они позволяют существенно уменьшить количество ошибок уже на этапе разработки.
|
|
|
+Мы не должны тестировать код используемого фреймворка или используемых зависимостей. Тестировать надо только тот код, который написали мы сами.
|
|
|
+Надо отметить, что в целом концепция юнит-тестов не является непреложным требованием к веб-разработке, да и вообще к разработке. Кто-то считает, что юнит-тесты обязательно должны покрывать весь код проекта, кто-то полагает, что юнит-тесты можно использовать преимущественно для особо сложных моментов в коде приложения, какой-то сложной логики. Некоторые не используют юнит-тесты.
|
|
|
+Но тем не менее юнит-тесты несут потенциальные преимущества при разработке, к которым следует отнести не только собственно проверку результата и тестирование кода, но и другие, как например, написание слабосвязанных компонентов в соответствии с принципами 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 довольно прост:
|
|
|
+ Пишем юнит-тест
|
|
|
+ Запускаем его и видим, что он завершился неудачей (программный код ведь еще не написан)
|
|
|
+ Пишем некоторое количество кода, достаточное для запуска теста
|
|
|
+ Снова запускаем тест и видим его результаты
|
|
|
+Этот цикл повторяется снова и снова, пока не будет закончена работа над программным кодом. Так как большинство фреймворков юнит-тестирования помечают неудавшиеся тесты с красного цвета (например, выводится текст красного цвета), а удачный тест отмечается зеленым цветом (опять же выводится текст зеленого цвета), то данный цикл часто называют красным/зеленым циклом.
|
|
|
+
|
|
|
+Литература: https://metanit.com/sharp/aspnet5/22.1.ph
|
|
|
+
|
