Pull to refresh

Модульное тестирование — личный опыт

Reading time 2 min
Views 8.4K
Лет пять назад я узнал про модульное тестирование. Как любой нормальный программист, загорелся идеей и ринулся ее реализовывать, попутно перечитал кучу восторженной теории и скептической критики. Так постепенно накапливался практический опыт применения технологии в реальной жизни, в крупных рабочих проектах.

А личный опыт показал то что, к сожалению, я не сразу понял из теории: плохо спроектированный код почти невозможно автоматически тестировать, и наоборот — намерение тестировать код вынуждает более грамотно проектировать архитектуру..



Сразу поясню — под «хорошей архитектурой» я имею в виду разделение системы на слабозависимые модули (слои), при котором система сохраняет устойчивость после изменений внутри модулей.

А заметил я это следующим образом: начинаю писать код с желанием покрыть его юнит-тестами. В другой ситуации накатал бы несколько страниц говнокода, лишь бы работало и выполняло то что требуется. Но из-за намерения использования юнит-тесты приходится выделять интерфейсы, создавать на всё отдельные службы, абстрагироваться от UI, применять всяческие шаблоны типа IoC, DependencyInjection, ослабляющие связанность системы и т. п.

Я знаю идею про то что сперва нужно писать тесты, а потом уже код, и поначалу так и делал. Но когда объем кода очень большой — уже не до этого. В итоге тесты я стал писать только в том случае, когда в коде обнаруживаются ошибки. Заглючил метод — пишу на него тест. Глюков нет — не пишу. Таким образом я как бы реализую правило «не писать тесты для тривиального кода».

Но, несмотря на то что юнит-тестов мало, код готов к тому чтобы любой класс или метод можно было при необходимости протестировать.

И именно это стремление к потенциальной возможности написания юнит-тестов задает нижнюю планку качества проектирования приложения.

Случалось работать с унаследованным кодом — нужно было его поддерживать и улучшать. Обычно выяснялось, что это «банка с червяками» — там всё взаимосвязано так, что изменения в одном месте самым непредсказуемым образом откликались в других местах. Возникало естественное желание (по науке, как в книжках) перед изменением такого кода покрыть его тестами. Но как покрывать, если для создания экземпляра класса, бывает, требуется создать десяток других классов, которые еще тянут за собой сотню других? И даже mockи не всегда помогают. Вот и получается, что для запутанного кода создать полноценные тесты крайне сложно — он изначально для этого не предназначен.

Еще по теме: статья habrahabr.ru/blogs/development/51706

Резюме: пишите код так, как будто вы его на самом деле собираетесь покрывать юнит-тестами :)
Tags:
Hubs:
+22
Comments 50
Comments Comments 50

Articles