Когда модульные тесты не помогут

"Юнит-тесты" - "святая корова" наживульщиков и служителей культов TDD. Но если убрать все шаманство, то окажется, что технология автоматизированного модульного тестирования является давно известной и полезной. Надо, правда, учитывать затраты, потому что соотношение тестирующего кода к тестируемому примерно 2 к 1, как минимум. Вы готовы писать в три раза больше кода?

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

Простой пример из практики.

Имеется элемент управления интерфейса пользователя MyControl, который завязан на подключаемый к нему набор данных DatSet. Формат DataSet табличный, согласован на уровне имен и типов данных колонок. Заполнение DataSet из разных источников тестируется, работа MyControl с подставляемым ему тестовым DataSet - тоже.

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

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

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

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

Литература. "TDD is dead. Long live testing" от одного из разработчиков платформы Руби.