Что разработчики имеют против тестируемости?
Грегори Пачига
В ходе карьеры я неоднократно сталкивался с разработчиками, убежденными, что код приложения никогда не должен меняться только ради упрощения тестирования. Даже если все были согласны, что нестабильные тесты создают проблемы, добавление в приложение фич для тестируемости и исправления нестабильности почему-то оставалось за рамками приличия. С этим убеждением я сталкивался во множестве компаний, среди различных продуктов, в водопаде и в Agile, в компаниях, где были тестировщики и где их не было.
Что же с этим делать?
Недавно я задал этот вопрос в Slack-группе тестировщиков и на форуме Министерства Тестирования. Вот основные идеи, рожденные в этих обсуждениях. Я расположил их по степени полезности, от наименее полезных к наиболее. Спускаясь ниже, мы подберемся ближе к тому, что я считаю первопричиной. Буду рад услышать другие мысли на этот счет.
Прикройте свою задницу
Даже не пытайтесь понять, почему разработчики не следуют советам тестировщиков. Убедитесь, что у вас есть документы, подтверждающие, что вы хотели внести улучшение, но вам воспрепятствовали. Затем, когда вам настучат по шее за трату времени на нестабильные тесты, вы сможете подтвердить, что хотели как лучше.
Думаю, очевидно, почему я не считаю это хорошим решением вопроса.
Сделайте это проблемой кого-нибудь еще
Если разработчики не согласны с тестировщиками, не считайте ,что их переубеждение – ваша проблема. Расскажите об этом менеджерам, и пусть решают они. Кто-то рангом повыше должен быть в состоянии заставить разработчиков уступить и внести нужные вам изменения. Пусть у вашего менеджера голова болит.
К сожалению, принуждение разработчиков к внедрению того, что они считают плохой практикой, не заставит их поверить, что это хорошая идея.
Единственное полезное зерно тут – сделать масштаб проблемы как можно более явным. Это всегда можно использовать для приоритезации изменений.
Сделайте изменения безопасными
Один человек предположил, что причина избегания изменений кода в недостатке уверенности в коде. Разработчиков может волновать, что изменение с шансами принесет новые проблемы, или сломает их хрупкие представления о том, как все работает.
Это тяжелее оценить с точки зрения полезности – со мной такого не случалось, но если разработчики не могут уверенно вносить изменения в свой код, это может стать колоссальной системной проблемой. Также тут присутствует проблема курицы и яйца – тестируемость нельзя повысить, потому что вы не доверяете коду, но вы не доверяете коду, так как у него плохая тестируемость.
Если причина в этом, подумайте о том, как сделать предлагаемое изменение как можно более безопасным; подумайте о том, как оно может потенциально повлиять на приложение, и как протестировать это изменение.
Сделайте изменения небольшими
Я слышал, что разработчики беспокоятся о раздутом коде или не хотят все усложнять. Некоторые версии этой идеи действительно несут подобный риск, и это волнение оправдано. Внедрение множества путей кода в зависимости от того, в тест-окружении вы или нет – это зачастую плохая идея. Особенно это верно, если вы предлагаете изменить существующее поведение. Может также возникнуть вопрос безопасности, если вы хотите обнажить новые API или информацию, которая должна быть защищена.
Старайтесь, чтобы изменения ради тестируемости были минимальными и неинвазивными. Ограничивайтесь добавлением, а не изменением, если это возможно. Зачастую все, что требуется нестабильному тесту – это дополнительное сообщение лога или публикация Boolean-состояния "готово". Общее у таких изменений в том, что они не выглядят как "тест-код", если вы не знаете, почему они добавлены, и их не нужно оборачивать в логику "if (тест)". Чем меньше "о тестировании" будет ваше изменение, тем лучше.
Демонстрируйте, а не рассказывайте
Иногда у разработчиков нет времени работать над "всяким для тестирования". Возможно, на арене асимметричная проблема заключенного – разработчики ничего не выигрывают от упрощения тестов, если это отвлекает их от их прямых обязанностей.
В ответ сделайте их работу за них. Тест-разработчики должны иметь такой же доступ к коду для вноса изменений и пулл-реквестов, а не только знать, как хорошо этот код тестировать. Конечно, это возможно только при условии, что вы не работаете с хрупким кодом и не вносите гигантские изменения – см. "сделайте изменения безопасными и небольшими" выше.
Возможно также, что разработчики не знают, как выглядит тестируемость и как выглядит внутреннее качество кода. Они могут не знать или не обращать внимания на то, что способны писать код, проверить который – тривиальная задача. Поэтому TDD поначалу так сложен; он заставляет разработчиков думать о том, как написать юнит тестируемым образом до того, как вообще к нему приступить. Это может ощущаться как извращение привычного стиля программирования некомфортным образом, пока вы не привыкнете и не начнете воспринимать тестируемый код как должное. Вместо того, чтобы описывать, каким код должен быть, покажите им, как это выглядит в реальности.
Пусть это будет их решение
Вместо того, чтобы делегировать проблему выше и рассчитывать, что менеджеры решат ее насильно, обсудите ее напрямую с разработчиками. Аргументы, которые вы бы применяли в жалобе менеджерам, тут тоже должны сработать: "нам тяжело тестировать, потому что…", или "релиз занимает на Х часов больше, потому что…"
Разница тут в том, что если вы работаете над проблемой совместно с разработчиками, они могут помочь в выработке наилучшего решения. Возможно, у них будет другая идея, которая сработает не хуже. Вы можете прийти к тому решению, которого и добивались, но теперь это идея разработчиков, а не нечто навязанное им свыше.
К тому же, если вы – инженер-автоматизатор, то пообщаться с разработчиками о ваших общих трудностях всегда есть смысл.
Пусть это будет их проблема
Все вышесказанное предполагает, что это проблема тестировщика. У тестировщика есть требующая решения проблема, и ему нужна помощь разработчиков. Но так быть не должно.
Чем больше барьеров между тестированием и разработкой мы сломаем, тем более разделенной с разработчиками станет боль борьбы с нестабильными тестами. Если разработчики не могут слить пулл-реквесты, потому что тесты падают, если разработчики должны точно так же тестировать код перед релизом – они будут замотивированы решить проблему так же, как и вы. Однако если разработчики могут игнорировать нестабильные тесты – они будут их игнорировать. И тогда решать этот вопрос будет тестировщик.
Иногда стоит сделать им больно.
Пусть это будет их код
Мы уже затрагивали одно из самых частых возражений против добавления фич тестируемости в код приложения: это нечто вроде "это добавит сложностей" и "придется поддерживать больше кода". Но помните, что все обручи, через которые прыгает тест-код в попытке создать стабильный тест для нестабильного приложения – это тоже сложный код, нуждающийся в поддержке. Эти рассуждения демонстрируют, что разработчики думают о коде приложения, как о своем коде, а о тест-коде – как о чужом.
Я даже слыхал пару раз, что добавление "тест-кода" к приложению каким-то образом портит их чистую базу кода. Тест-код считается "тем, другим". Иногда достаточно нескольких контрпримеров, чтобы опровергнуть эту мысль: пробовали ли вы рефакторить код, чтобы юнит-тесты стали проще? Добавляли ли вы сообщения в логи, чтобы проще было дебажить? Меняли ли вы реализацию продукта, чтобы разработка стала проще, образом, не связанным с бизнес-функциональностью? Правильно формулируя, вы подведете разработчиков к осознанию, что они постоянно пишут "тест-код".
Если тест-код изначально разрабатывается параллельно коду приложения, а не создается опосля и впопыхах, необходимость тестируемости становится частью процесса разработки. Фичи тестируемости можно изначально сделать требованием. Все мы любим поговорить, что за качество отвечают все, но сформулируйте это конкретным образом. Что, если последний коммит прямо сейчас уйдет на прод? (такой вопрос имеет побочный эффект – он мотивирует к внедрению сильных практик CI/CD)
Это необязательно значит, что нужно избавиться от тестировщиков – у вас все равно может получиться команда разработчиков, складывающих код по разным ментальным корзинам. Избавиться нужно от идеи, что тест-код – это нечто отдельное от приложения. Тест-автоматизация – это фича приложения, и относиться к ней нужно соответственно.