|
|
@@ -0,0 +1,128 @@
|
|
|
+**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
|
