waldeh

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

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

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

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

Всем известно, что теги <b>, <i>, <s>, <small> являются презентационными, а следовательно, исходя из парадигмы «структура, представление, поведение» их использование не приветствуется. Куда более привычными представляются элементы <strong>, <em>, <del>. Так было на протяжении долгих лет практики разработки. Однако многое поменялось в семантике этих элементов с приходом HTML5. Теперь у нас 4 новых тега со смыслом и каша в голове.