Одна из проблем с тестированием конфигурации состоит в том, что нет готовой инфраструктуры
Я имею в виду, что когда вы собираетесь написать тест для кода — у вас уже многое есть. У вас есть какая-то доменная модель, у вас есть какие-то API, у вас есть какие-то builders/wizards/DSL. Да, поверх всего этого, обычно, все равно приходится дописать прослойку вспомогательного кода, предназначенного именно для тестирования (aka "test-harness"), но если основной код спроектирован и написан достаточно хорошо, то эта прослойка довольно тонкая. Условно, процентов 50-80 уже написано, и эти проценты очень облегчают начало.
А вот когда вы начинаете писать тесты для конфигурации — у вас нет нихрена, или почти нихрена, кроме кучи текстовых файлов. И это сильно осложняет начало (и тормозит внедрение самой идеи).
Да, везде можно найти свои плюсы: я приводил пример, как поверх примитивной структуры конфигов можно писать такие же примитивные тесты, бьющие по площадям ("все свойства, заканчивающиеся на .port, имеют в качестве значения целое число из диапазона доступных сетевых портов"). Но одними ковровыми бомбардировками каши не сваришь — рано или поздно появится желание (необходимость) проверить что-то конкретное и узкосфокусированное.
И вот тут часто возникает барьер: попытка написать такой тест "с лету" приводит к монструозному спагетти-коду, глядя на который хочется перекреститься "не дай бог коллеги увидят". А создание обвязки, позволяющей писать более-менее понятные тесты — выходит довольно дорого, потому что нет тех самых "50%-80%", и нет и наработанного опыта/понимания, как именно такую обвязку писать. Пару идей, как такую обвязку можно строить я в докладе давал, но все равно это каждый раз боль.
В общем-то, я еще помню как похожие же проблемы возникали лет 10-15 назад с тестированием кода. И в этом случае решением стало распространение идей TDD — что тестирование это неотъемлемая часть разработки, и уже на стадии написания кода необходимо думать о том, как ты его будешь тестировать. Может быть, распространение аналогичной идеи test driven configuration со временем решит аналогичную проблему и для тестов конфигурации. А может быть просто все больше конфигурации будет в виде кода (а тестировать код мы уже научились, так что задача сводится к предыдущей) — мне, как программисту, это кажется более экономным решением
когда-то не было ни junit, ни CI
ОтветитьУдалитьчастично и проблема в том, что нет каких бы то ни было готовых - пусть и кривых инструментов (либ) - через внедрение идеи и инструментов - произойдёт и качественный скачок - включение в джентельменский набор.