Аргументы в пользу модульных тестов

1. Улучшение качества кода. По сути, комбинация “основного” кода и модульных тестов – это двойная запись одной и той же функциональности. В коде могут быть ошибки. В тесте могут быть ошибки. Но вероятность ошибки в коде и в тесте гораздо меньше.

2. Возможность проводить рефакторинг (улучшение структуры кода) без опасений поломать работу приложения и погрязнуть в отладке. Основное назначение модульных тестов состоит не столько в том, чтобы находить баги в текущей версии продукта, сколько в том, чтобы не пропустить баги в старой функциональности при добавлении новой. К примеру, маленькое “улучшение” в алгоритме шифрования не разрушит всю систему, если на алгоритм и смежные компоненты есть модульные тесты.

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

4. Более удобная координация работы распределенной группы программистов. Модульные тесты позволяют провести приемочные испытания перед интегрированием модулей в единую систему.

5. Модульные тесты служат дополнением к документации и помогают новому разработчику войти в курс дела. Объектно-ориентированные языки программирования предполагают наличие зависимостей между классами. Небольшое изменение в, казалось бы, второстепенном классе, способно разрушить работу всей системы, поэтому модульные тесты в таких случаях могут оказаться очень полезны.

Аргументы против модульных тестов

1. Модульных тестов недостаточно для качественного тестирования приложений. Ясно, что модульные тесты не охватывают работу всей системы в целом. Они проверяют систему с позиций разработчика и не могут взглянуть на приложение глазами пользователя. Модульные тесты, как правило, не охватывают полный набор входных данных. Возможность увидеть все множество вариантов появляется только при интеграционном тестировании всей системы.

2. Модульные тесты – это не панацея. Они покажут наличие ошибок, но не докажут их отсутствие.