Comments 5
Вообще в тестах принято прописать стандартный комментарий AAA - arrange, act, assert, чтобы разделить секции с разными операциями. Ну и часто тесты действительно могут копипаститься и писаться гораздо менее продуманно, чем основной код, но у них чисто утилитарная цель, непонятны цели инвестиций в код, кроме тех, где они реально оправданы.
Где-то принято, а где-то нет. Я не против всех-всех-всех комментариев, хотите так разделять секции - да пожалуйста. Тут важно, почему вы это делаете. Если ради психологического комфорта, и всем в команде это ок, то и ладно. А если это делается, потому что без такого разделения не разберешься, чё где происходит - вопросики.
Касательно инвестиций. Хорошие тесты должны работать долго. Чтобы они работали долго, нужна постоянная поддержка. Чтобы поддержка не сопровождалась болью в эээ сердце, код тестов должен быть написан чисто и понятно. Есть некая грань между "менее продуманно" и "недопустимо безответственно", я за то, чтобы её не пересекать.
Эльвира, спасибо за статью! Вы подняли очень важные и актуальные проблемы, с которыми сталкиваются многие команды, работающие с автотестами. Действительно, отношение к тестовому коду как к чему-то второстепенному — это распространённая ошибка, которая приводит к серьёзным последствиям. Ваши примеры антипаттернов очень наглядны и, к сожалению, знакомы многим из нас.
Хочу добавить несколько мыслей:
Комментарии в тестах: Вы правы, что комментарии часто маскируют проблемы, вместо того чтобы их решать. Однако, если комментарии используются для объяснения сложной бизнес-логики или неочевидных решений, они могут быть полезны. Главное — не злоупотреблять ими и не заменять ими качественный код.
Самодокументируемый код: Это идеал, к которому стоит стремиться. Если тестовый код написан чисто и понятно, он не только упрощает поддержку, но и становится частью документации. Это особенно важно для новых членов команды.
Page Object и DRY: Полностью согласен, что пренебрежение этими принципами приводит к хрупким и трудно поддерживаемым тестам. Page Object — это must-have для UI-тестов, а DRY — это основа любого качественного кода, будь то продукт или тесты.
Ревью тестов: Очень важный момент. Ревью тестов должно быть таким же тщательным, как и ревью продуктового кода. Покрытие, логика, корректность проверок — всё это должно проверяться. Иначе тесты теряют свою ценность.
Последствия пренебрежения: Вы абсолютно правы, что проблемы с тестами накапливаются, как снежный ком. В итоге это приводит к тому, что тесты перестают быть инструментом, а становятся обузой. И тогда команда возвращается к ручному тестированию, что сводит на нет все преимущества автоматизации.
Спасибо за ваш опыт и примеры! Думаю, многим командам будет полезно задуматься над тем, как они пишут и поддерживают свои тесты.
А, что вы думаете по поводу внедрения code style и линтеров для тестового кода? Это могло бы помочь избежать некоторых проблем, которые вы описали.
Спасибо за поддерживающий комментарий!
Опыта с линтерами у меня нет, но я отношусь к ним как и к остальным инструментам - при умелом применении могут быть полезны, при бездумном могут и навредить) Как минимум, на первых этапах такие инструменты наверняка помогают команде быстрее адаптироваться и привыкнуть к новым правилам.
Code style, конечно же, поддерживаю. Это одно из обязательных условий для поддерживаемости тестов.
Эмм.. После общения с ИИ-шками коммент выглядит как типичный ответ ии.
Мб я ошибаюсь, но рили:
Похвалил и сказал "Как важна тема"
Оценил каждый пункт и повторил (подтвердил) слова автора
Подвёл итог
Задал наводящие, уточняющие вопросы для продолжения темы
Что скрывают комментарии в тестах