Работая с автотестами на разных проектах, я часто сталкивалась с тем, что к коду тестов люди относятся не так, как к продуктовому. Причем это касается и разработчиков, и тестировщиков, и менеджеров. Коду тестов прощаются грехи, недопустимые в продуктовом коде. Хорошо это или плохо? Зависит от ситуации. В этой статье – сборник больных антипаттернов из моего опыта.

1. Комментарии в тестах. Они в заголовке, с них и начнем. В какой момент эти ребята перестают помогать и начинают сильно мешать? В первую очередь, когда позволяют кому-то в команде лениться. Например, автору кода тестов. Или читателям кода тестов. Или тем, кто будет вносить изменения. Примеры из реальной жизни:
   

   1. Тестировщики не знают язык программирования, поэтому автор тестов дополняет шаги теста комментариями. Как это выглядит:

      

      На лицо ситуация, когда реальная проблема (тестировщики не умеют программировать, хотя это нужно проекту) скрывается за фейковым решением (BDD на минималках).

   2. Правильное решение какой-то задачи откладывается на потом, алгоритм пишется в лоб. Как правило, код теста от этого становится непонятным и появляется жгучее желание объяснить, почему не дописано нормально сделано так. Самодокументируемый код? Не, не слышали, это же просто тесты. На практике может выглядеть примерно так: 

      

2. Сильно упрощенный код, отсутствие паттернов. Причины часто такие же – отсутствие навыков и/или спешка. Это ж тестировщики, печатать код умеют – уже молодцы. Да? Нет.
   

   1. Удивительно, но не все применяют Page object в UI тестах, даже когда прям напрашивается. Вместо этого пишутся стандартные портянки кода с локаторами, ожиданиями и т.д.

      

   2. Нарушается принцип Single responsibility. Вместо маленьких специализированных классов для работы с базой, драйвером и т.д. появляются монстры с общим названием TestHelper. Найти там что-то довольно затруднительно, поэтому часто в таких монстрах методы почти (или не почти) дублируют друг друга.

   3. Игнорируется принцип DRY – пишутся одинаковые действия в тестах или идентичные на 99% методы. Например, два метода RaisePriceBy10Dollards() и RaisePriceBy20Dollars() вместо метода RaisePriceBy(int countOfDollars).

3. Невнимательное ревью тестов. Здесь примеры разные:
   

   1. Тесты написаны разработчиком – другой разработчик и тестировщик просто смотрят, что тесты есть, не разбирая покрытие. Потому что автор кода ведь лучше всех покроет его тестами.

   2. Тесты написаны тестировщиком – аналогично, другой тестер или разработчик, делающие ревью, проверят код, но не покрытие. Потому что мы этому тестировщику доверяем, он же знает тест-дизайн.

   3. Для экономии времени часто проверяется правильность конструкций, а не логики. В итоге получаются тесты, которые не проверяют то, что заявляют. Или проверяют не так, как надо. Один из классических примеров – когда в UI тестах проверяется только сообщение об успехе на тестируемой странице, и упускаются проверки изменений на сервере.

      

Вместо заключения

Конечно, примеры пренебрежительного отношения к тестам этим не ограничиваются.

Чем в итоге плохо такое отношение? Ну тесты ведь и правда не продуктовый код, что плохого случится?

Со временем проблемы накапливаются как снежный ком (да простит меня бог литературы за такие выражения), и тесты превращаются в спутанный, пахнущий проблемами кусок кода, куда никто не хочет заглядывать. Тесты стали нестабильными? Непонятно реальное покрытие? Ой, долго разбираться, давайте просто протестируем это руками.

В итоге тесты из инструмента быстрой обратной связи превращаются в развлечение для тестировщиков (чтобы не уставали от ручного тестирования) и источник раздражения для разработчиков.

Автотесты – это прежде всего код, и их написание безусловно требует навыков программирования и внимательного отношения.