Хабрахабр

Тестировать верстку? Легко

Статья подготовлена Анной anna-che и Ксенией KseMish.

Мы с размаху наступили на баг, который стал проявляться после очередного обновления Хрома. Одной из причин, по которой мы активно взялись за тестирование верстки, стали, как обычно, грабли. А все из-за того, что в новой версии браузера форма перевода средств с одного счета на другой уехала за пределы окна. Оказалось, что в течение 3-х часов пользователи не могли осуществить перевод средств со счета через личный кабинет нашего интернет-банка.

Например, всем известный бренд одежды также наткнулся на эти грабли. Подобные баги бывают и безобидными. Благодаря недостаточному тестированию верстки, пользователи сайта этого бренда вместо кнопки «Узнайте больше» долгое время видели «Узнайте боль…».

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

Оказалось, что не во всех командах есть выделенный дизайнер, или у них не хватает времени, или, что еще страшнее, фронт и дизайнер не могут прийти к общему подходу к верстке той или иной страницы, формы или элемента. Осознавая эти проблемы, мы применили практику обязательного design review со стороны наших продуктовых дизайнеров, но не тут-то было.

Изучив возможные практики и инструменты для автоматизации тестирования верстки и насобирав шишек, мы внедрили следующий подход.
Недолго думая, мы отправились искать варианты, как мы можем минимизировать как количество дефектов верстки, так и противостояний «Фронт VS дизайнер».

Коротко о нас:
Сейчас мы разрабатываем единый продукт, над которым трудятся более 20 скрам-команд, каждая из которых отвечает за определенную функциональность, при этом мы стараемся сохранить единый стиль и дизайн самого продукта — визуальную подачу, расположение основных элементов и т.д.

Относительно распределения пользователей по браузерам, на сегодняшний день наши пользователи используют (значения округлены):

  • 60% — Chrome,
  • 30% — Firefox,
  • 10% — другие браузеры.

Тестируем функциональность мы с помощью нашего BDD-фреймворка Akita (Java + Cucumber + Selenide), о нем мы писали вот тут.

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

Описывают они свои договоренности в galen-spec файле.

Что такое galen-spec?

Для того чтобы автоматизировать тестирование верстки и тем самым минимизировать количество дефектов, мы решили внедрить инструмент Galen Framework. В основе него лежит как раз .spec-файл (спецификация или, как мы назвали, «Контракт»). И он легко интегрируется с Selenium-тестами.

Фреймворк использует свой собственный язык для написания спецификаций проверок. После того как дизайнер и фронт составили «Контракт», тестировщик на его основе формирует .spec-файл, согласно требованиям Galen.

Из чего же состоит .spec-файл?

Логически, его можно поделить на две части:

object definitions 1.

В общем, перечисляем основные элементы, которые будем проверять, даем им названия и определяем локаторы. Тут нам надо обязательно указать, какие объекты есть на нашей странице — header, footer, меню, контент и т.д.

@objects — элементы на странице (можно использовать CSS, XPATH, ID)

Для этого используется часть спецификации object specs, где мы подробно описываем, например, что наш блок текста (description-text) находится внутри формы описания, ниже хэдера и содержит определенный текст. 2. Когда определили локаторы, надо определить стили и спецификации конкретных объектов.

Main section — для каждого описанного элемента в @objects описываются параметры проверки.

* язык galen spec чувствителен к отступам в main section, поэтому обращайте на это особое внимание и соблюдайте табуляцию 🙂

Таким образом, «Контракт», заключенный между фронтом и дизайнером и перенесенный на язык Galen, позволяет нам автоматизировано проверить расположение и внутреннее содержание элементов, а также адаптивность и кроссбраузерность.

Пример быстрого старта

  1. Описываем элементы конкретной страницы и проверки в файлах .spec, используя язык Galen Spec, и кладем в пакет specs.
  2. Эталонные скриншоты складываем в пакет specs/images
  3. Мы работаем по BDD, поэтому сценарий в .feature-файле может выглядеть примерно вот так:

  4. Запускаем тестовый сценарий через обычный Cucumber Runner.

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

Разница в отчетах выглядит следующим образом:

error=Error{[Element does not look like «./akita-testing-template/src/test/resources/specs/images/registration-form.png». There are 10,47% mismatching pixels but max allowed is 10%]

Здесь видим, что проверка не прошла, изображения отличаются более чем на 10% и все эти цветные различия, кроме заливки черным цветом, это и есть разница между элементами.

Если элементы полностью идентичны, разница будет отображаться черным цветом.

Самый частый вопрос, где вообще взять эталонный скриншот?

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

К чему мы пришли, используя этот подход

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

Почитать документацию по составлению galen-spec файлов можно тут — galen-spec-language-guide.

О технических аспектах работы с Galen Framework, его возможностях и основных проверках мы рассказали на прошедшем Selenium Camp, и еще напишем в блоге.

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

А мы обязательно ответим.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть