Unit Testing

Тестирование unit-testing

Редактировать

Синонимы: Модульное тестирование

Граф зависимостей

Зависят от неё: 1

Текущая практика

Зависит от неё

Практики, которые требуют эту:

Test-Driven Development

Описание

Модульное тестирование — это тестирование программы на уровне отдельно взятых модулей, функций или классов. Это процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки. Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны. Также, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность.

Ценность

Преимущества:

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

Последствия отсутствия:

Большая часть дефектов будут обнаруживаться во время более дорогостоящих этапов тестирования.
Увеличивается сложность и время проведения рефакторинга ранее написанного кода.
Увеличивается сложность и время, необходимое на внесение изменений в ранее написанный код.