Тестирование приватных методов 19.10.2016

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

Отмечу, что под приватными методами класса в контексте этой статьи я понимаю методы, используемые только внутри класса и не обладающие ценностью для клиентов этого класса.

Тестирование приватных методов часто путают с тестированием по стратегии белого ящика, подразумевающей тестирование публичного интерфейса системы, при котором набор тестов, необходимых для полного покрытия функционала системы, разрабатывается с учетом её внутренней реализации.

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

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

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

Здесь стоит отметить, что сложность и количество тестов иногда можно уменьшить осуществив декомпозицию тестируемого класса и тестирование его компонентов-зависимостей по отдельности.

by 19.10.2016