На одном из субботников я рассказывал, какие практики мы используем для поддержания качества кода наших авто-тестов. Одна из таких практик - статический анализ кода. Понятно, что анализ сам по себе особой ценности не несёт. Но вот если интегрировать его в процесс разработки - другое дело.
Подобные инструменты интегреруются двумя способами - либо прекомит, либо посткомит. Мы выбрали второй способ, т.к. в наших ультра-коротких итерациях нам важно доставлять свежие тесты потребителям как можно быстрее. Проблемы же, если они возникнут, в любом случае не останутся незамеченными.
Теперь о технической стороне. Для анализа мы используем open-source решение Sonar (который недавно переименовали в SonarQube). Для сборки кода тестов в артефакты мы используем Jenkins, у которого (вот удача!) есть плагин для Sonar’a. Самая интересная часть - это как поломать сборку если анализ выявил проблемы? Для этого у Sonar’a есть плагин под названием Build Breaker (какое говорящее название =)). Там можно настраивать как Warning Treshold (и почему разработчики так любят “некритичные ошибки”?), так и Error Treshold. При наступлении последнего сборка падает.
При включении Sonar’a с дефолтными настройками тебе может стать страшно от количества Error’ов и Warning’ов, да и сборка может сразу упасть. Если это действительно так - настрой Build Breaker на “неубывание метрик”. Т.е. если количество ошибок выросло после последнего коммита - ломаем сборку, если осталось прежним или уменьшилось - всё ок. Такие настройки помогут прекратить тебе генерировать новый говнокод, а старый можно будет потихоньку улучшать.
comments powered by Disqus