Тестирование в эпоху Agile 29.01.2016

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

В последнее время мне не раз приходилось рефакторить код продукта, разработка которого велась и ведётся по системе agile (в народе «тяп-ляп и в продакшен»). Слово «agile» на русский язык переводится как проворный. В отношение одноименного подхода к разработке «agile» перевели как «гибкий», мотивировав использование этого перевода негативным оттенком слова «проворный». Маркетинг в чистом виде. А ведь agile действительно является гибким с негативным оттенком — в agile-методологиях, как правило, отсутствует система управления и формализации требований, что со временем превращает поддержку проекта в кошмар.

Если при первичной разработке продукта все выглядит более менее сносно — память свежа и всегда можно найти человека, обладающего информацией о той или иной фиче (замена процессов формализации личным общением еще работает), то с течением времени ситуация меняется. Состав команды, поддерживающей продукт и продолжающей его разработку, постепенно меняется, заказчики отдельных фич перестают существовать физически, а для поддержки остаётся код, требования к функционалу которого разбросаны в десятках тикетов и описаны на коленке.

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

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

by 29.01.2016