Пару месяцев назад я перешел от разработчика к тестировщику проекта, над которым сейчас работаю.

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

Когда я присоединился к команде, моей первой задачей было добавление тестовых случаев в пакет автоматизации для некоторых из этих изменений, но при этом мне стало очевидно, что причина, по которой пакет изо всех сил пытался не отставать, заключалась в следующих причинах:

  • Никто в команде не обращал внимания на работоспособность пакета автоматизации, он давно вышел из строя, но поверх него создавалось больше тестовых случаев.
  • Пакет автоматизации было трудно поддерживать и поддерживать в рабочем состоянии из-за того, что код создавался с использованием шаблона Page Object Model, но без четких архитектурных правил для его поддержки.
  • Не было формального процесса ветвления, слияния и проверки кода.
  • Из-за проблем с ремонтопригодностью пакета автоматизации ни один из разработчиков не хотел нести ответственность за обеспечение их обновления при изменении частей приложения.

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

Из первой встречи вышли три основных момента:

  1. Чтобы восстановить видимость работоспособности приложения, мы сосредоточимся на меньшем наборе тестов, которые мы будем держать зелеными, и со временем рефакторим неудачные тесты.
  2. Рефакторинг пакета автоматизации был крайне необходим
  3. WebdriverIO, используемая среда автоматизации, не давала нам такой гибкости, как мы надеялись, в отношении запуска сценариев Cucumber в наших IDE или просто неудачных тестов.

Из этих действий мы занялись пунктами 1 и 2 в первую очередь. Установив четкие архитектурные правила при выполнении пункта 2, мы могли бы упростить переход на другой фреймворк (пункт 3).

Очистить проблемы

Чтобы реорганизовать код, который я предложил команде, мы разобьем код (который следовал шаблону Page Object Model, изложенному в учебниках WDIO) на более мелкие объекты со своими собственными проблемами:

Объект выбора

  • Заботится о селекторах, необходимых для доступа к веб-элементам для различных компонентов.
  • Строки-селекторы будут абстрагированы в функции. Это позволяет более семантически именовать различные селекторы, а также позволяет нам объединить несколько селекторов, которые просто различаются селектором индекса (например, nth-child) в одну функцию с аргументом индекса.

Объект компонента

  • Занимается компонентами на странице. На разных страницах может использоваться один и тот же компонент
  • Это единственная точка, которая использует селекторы для получения веб-элементов. Это предотвращает обход объектов страницы компонентом при доступе к элементам.
  • Любые геттеры и сеттеры веб-элементов и атрибутов веб-элементов будут абстрагированы в функции. Это позволяет более семантически именовать различные операции и позволяет легко изменять внутреннюю реализацию.

Объект страницы

  • Занимается взаимодействием с различными компонентами, составляющими страницу, в объекте страницы нет прямых вызовов элементов на странице.
  • Сложные действия абстрагируются в функции, которые приводят к идемпотентным операциям. Например, функция входа все равно будет регистрировать вас независимо от того, была ли у вас открыта форма входа или нет при ее вызове.

Определение шага

  • Занимается вызовом действий на разных объектах страницы для достижения определенной задачи в шаге корнишона.

Это дало нам четкое разделение для работы и позволило проводить более конструктивные проверки кода.

Это также позволило разбить код объектной модели страницы на собственную библиотеку, которую можно было разработать вне кодовой базы комплекта автоматизации, которая на тот момент представляла собой лабиринт различных файлов определения шагов с различными реализациями в них.

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

Основными препятствиями во время рефакторинга были:

  • Что считалось компонентом и каковы были границы различных компонентов. В основном это было связано с тем, что различные реализации, использующие существующую кодовую базу, противоречили друг другу.
  • Члены команды возвращаются к старым привычкам, хотя они были устранены с помощью код-ревью.

Изменения неизбежны

Как только мы провели рефакторинг пакета автоматизации, проект сместил акцент с интеграции с одним набором систем на совершенно новый набор систем.

Это изменение в системах означало, что половина кода в пакете автоматизации стала избыточной за одну ночь. Было сочтено, что это будет хорошим предлогом для перехода с WebdriverIO на использование CucumberJS и WebdriverJS.

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

Пару недель спустя было принято решение расширить новый пакет на основе WebdriverJS для поддержки старых функций, которые были в старом пакете WebdriverIO.

Это включение двух разных наборов компонентов в объект страницы изначально рассматривалось как трудная для решения проблема, пока мы не провели быстрый групповой чат и не поняли, что можем использовать шаблон стратегии в конструкторе объекта страницы для назначения соответствующего объекта компонента в время выполнения, и это не нарушило первоначальных архитектурных границ.

Результаты и извлеченные уроки

Результаты шага назад, обдумывания каждого определения шага и объекта страницы/компонента/селектора, гарантирующие, что эти архитектурные границы не будут нарушены посредством дисциплинированного обзора кода, были очень положительными для команды.

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

Преимущества архитектурных изменений были замечены как минимум трижды с тех пор, как мы их приняли, и я уверен, что они будут замечены снова.

Уроки, извлеченные из этого рефакторинга:

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

Примечание от команды Plain English

А вы знали, что у нас четыре публикации? Подарите им немного любви, подписавшись: JavaScript на простом английском, ИИ на простом английском, UX на простом английском. , Python на простом английском — спасибо и продолжайте учиться!

Кроме того, мы всегда заинтересованы в продвижении хорошего контента. Если у вас есть статья, которую вы хотели бы отправить в какое-либо из наших изданий, отправьте электронное письмо по адресу [email protected], указав свое имя пользователя на Medium и то, о чем вы хотели бы написать, и мы вернуться к вам!