Pull to refresh

Регрессионное тестирование вёрстки. Идея автоматизации

Website development
Когда мы верстаем новые фичи, либо фиксим баги в небольшом проекте, нет проблем проверить, не поломали ли мы что-то работающее. Для этого достаточно просто его прокликать. Но так бывает не всегда: наш текущий проект насчитывает около 200 уникальных страниц и мы столкнулись с проблемой автоматизации регрессионного тестирования вёрстки. И если у программистов всё всем давно известно, методы тривиальны, да и ПО соответствующее написано, то нам, front end разработчикам, приходится ломать голову. Но мысли некоторые есть.

В контексте этого документа, я буду условно разделять все ошибки вёрстки на ошибки раскладки (связаные с позицией блока в документе) и оформления (как то цвет текста, фона и др.) Далее мы будем рассматривать ошибки раскладки.

Из-за чего весь сыр-бор


При вёрстке мы используем подход вроде Object Oriented CSS. Таким образом, наша страница состоит из блоков, блоки могут быть как простые, не содержащие других блоков, так и составные, имеющие внутри себя простые блоки. Мы сделали свой код максимально некаскадным (за исключением некоторых наследуемых значений, вроде цвета ссылки, текста и шрифта), и, казалось бы, если мы аккуратно делаем девтест того самого блока, который подвергается изменениям, сломаться ничего не должно. Как бы ни так! Потому что:



  • В результате манипуляций с блоком, изменения тянутся за ним на составной блок (если таковой имеется), содержащий данный, и на страницы, в которую включается этот блок. Следовательно, в общем случае предполагается наличие багов.
  • При изменении блоков, опять же в общем случае, возможно нарушение выравнивания блоков по сетке документа. В результате могут появиться «скачки» уровней одних и тех же блоков при переключении страниц.
  • Ошибки могут быть вызваны следствием человеческого фактора: человеку иногда не чуждо, к сожалению, заговнокодить что-то по-быстрому, какой бы замечательный метод мы не придумали.
  • Ошибки могут иметь абсолютно любую природу, с которой мы ранее не сталкивались.


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

Идея алгоритма


Она простая. По большому счёту, единственным объективным машинодоступным критерием изменения раскладки документа является изменение положения неких контрольных точек. Т.е. шаги выглядят так:
  1. В документах (исходниках простых блоков, составных блоков, страниц на dev сервере) мы расставляем некие контрольные точки
  2. Программа-валидатор определяет координаты этих точек относительно системы координат (например, левая верхняя точка рабочей области браузера с горизонтальной и вертикальной осями) и записывает их значения в базу
  3. Программа-валидатор сравнивает предыдущее координаты точек с текущими и приводит список несоответствий вида «адрес страницы — id точки — старые координаты — новые координаты»
  4. В ручном режиме разработчик просматривает данные страницы и отмечает новые значения как корректные (в случае если это соответствует ожидаемому результату внесённых изменений) или некорректные

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

Программа-валидатор и контрольные точки


В моём понимании в физическом смысле точки выглядят как HTML комментарии некоторого шаблона в коде документа, например <!-- ###testing:id1### -->. Посредством JS утилиты, внедрённой в каждую страницу и HTML исходник, они заменяются на пустой блок с нулевой высотой. Затем рассчитывается положение этого блока, также посредством JS.

Точки предполагается расставлять руководствуясь следующей логикой:
  • После кода одного блока в исходниках блоков
  • В коде блока в характерных местах (зависит от каждого конкретного случая)
  • В коде страницы в характерных местах, и в местах условных направляющих сетки документа.

Программа-валидатор состоит из клиентской и серверной частей. Клиентская преобразует комментарии в блоки, определяет их кооринаты и передаёт значения параметров серверной части. Серверная часть сравнивает значения точек, добавляет новые точки в базу, обрабатывает выбор правильных точек разработчиком.

Резюме


Я не знаю, существуют ли в принципе методы автоматизации тестирования вёрстки. Гугление не дало никаких результатов, поэтому я попытался придумать свой метод. Если вы знаете готовый инструментарий, пожалуйста, поделитесь им в комментариях.
Я попытался оформить свои мысли на абсолютно универсальную систему тестирования, которая была бы абстрагирована от методов реализации вёрстки, а значит применимой для любого проекта. Пока это только первые наброски на сам алгоритм, по работе ПО у меня есть только общие соображения, описанные выше. Я не претендую на исключительную верность и эффективность такого подхода. Первые выводы можно будет сделать только после первых результатов работы.
И, самое главное, я призываю широкие массы обсудить в комментариях всё, что я описал, сделать замечания и предложения, а также энтузиастов помочь в реализации ПО.
Буду благодарен каждому, кто поставит ссылку на этот пост, разместит анонс у себя в блогах, твитнет и вообще всячески поможет широкому обсуждению данной темы тут или на моём блоге.
Tags:вёрсткатестирование версткиидеяавтоматизация
Hubs: Website development
Total votes 41: ↑39 and ↓2 +37
Views6.8K

Popular right now