Что скрывают комментарии в тестах24.01.2025 10:30

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

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

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

      589aed174192737a968a98c90038f892.png

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

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

      ca508b1f984263abcccfa43b9a21ab2f.png

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

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

      13222ce2eba9b1fa2ad63720f2a5d7e3.png

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

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

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

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

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

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

      cea72655be36fea5eb33879b48b684c0.png

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

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

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

fd5350729476f0953681cc4d6419fd62.png

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

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

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

© Habrahabr.ru