Тестируем CSS в Selenium IDE

[@lolmaus]

verifyEval
window.getComputedStyle(window.document.getElementById('h1-test'),null).getPropertyValue('color');
green

Не вижу смысла в таких тестах.

Это не позволит вам определить, например, что элемент сполз из-за того, что изменились стили родителя его родителя.

[@wasil]

Так ведь можно добавить тестов на относительные, абсолютные позиции наиболее проблемных элементов.

[@headfire]

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

1. Тестирование CSS не имеет смысла, так как это декларативный язык, а его результатом является сверстанное изображение страницы, которое можно оценить лишь визуально.
2. Протестировать CSS можно с помощью снятия битмапов с сгенерированной страницы и сверка ее с эталонным изображением. Для этого даже есть некоторые инструменты.

Конечно, во многом Вы правы. Метод, описанный в данной статье, не идеален. Но и совсем бессмысленным, его я бы не назвал. Если удается протестировать хоть что-то — это уже пусть небольшое, но достижение. Здесь мы полностью можем протестировать правильность селекторов и механизм каскадирования. У нас появляется мало-мальски твердая почва для проведения рефакторинга. Мы можем легко вычислить мусор и балласт и удалить его. А это по-моему, немало.

Теперь насчет сползания элементов. Ваш комментарий заставил меня немного поискать в Интернете, и вот, что я нашел:

Одна из самых распространенных задач — определение абсолютной позиции элемента относительно левого верхнего угла документа.
Для определения позиции используются следующие свойства элемента:
offsetTop — отступ сверху, измеряется в пикселах относительно родительского элемента.
offsetLeft — отступ слева, измеряется в пикселах относительно родительского элемента.
offsetParent — ближайший родитель, относительно которого делается отсчет. Его значение будет null если текущий элемент невидим (display: none) или это корневой элемент документа.
Поскольку значение считается от ближайшего родителя, то абсолютная позиция относительно верхнего левого угла документа обычно считается в цикле, который завершается тогда, когда значение offsetParent будет равно null.

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

[@lolmaus]

Тут главная проблема в муторности и неестественности написания таких тестов. Овчинка совершенно не стоит выделки.

[@headfire]

Согласен, но с некоторой оговоркой. В БОЛЬШИНСТВЕ случаев овчинка не стоит выделки. И дело, мне кажется, больше в овчинке. Тесты всегда может показаться писать муторно. Проблема кроется в том, что в большинстве проектов, где используется CSS, ошибка в CSS-коде не критична. Ну съехало там чего-то куда-то. На скорость не влияет.

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

[@Elufimov]

Если удается протестировать хоть что-то — это уже пусть небольшое, но достижение.

Автоматизация не есть панацея. Как правильно сказал murr «Видимо у автора очень много свободного времени.» То время которое вы тратите на написание этих тестов не окупится в реальном проекте, не говоря уже просто о целесообразности таких тестов.

[@murr]

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

К тому же, вы тестируете отображение в одном, не самом популярном, браузере в одной ОС.

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

Для бессмысленного теста на проверку цвета некого элемента, вам нужно будет
заставить верстальщика написать тест, запустить тестовый сервер, подготовить страницу (в том числе заполнить тестовую базу), отрендерить ее в каждом из целевых браузеров, запустить там селениум или аналог, прогнать ваш js код, очистить базу после тестов — и так для каждой страницы!

Т.е. вы фантастически замедляете прогон тестов на проекте, при этом не внеся никакой ощутимой пользы от тестирования: вы не сможете отследить ситуации, когда элементы поехали от разного количества вложенных элементов, вы не сможете отследить правльное применение всевозможных хаков, когда ваш js будет падать в тестовом режиме, вам прийдется ковырятся, разбираясь, почему это фейсбучные скрипты или еще какая-то подобная какашка не успели догрузится в предложенные вами в идеальном мире 20 секунд. На таком уровне покрытия тестами невероятно сложно формализовать машине, какой именно вы представляете страницу. Я молчу про поддержку этого добра на больших проектах, особенно молчу про проекты с частыми редизайнами.

Если у вас есть лишнее время и желание сделать проект лучше, посмотрите лучше в сторону capybara, ознакомившись с хорошими практиками.

[@headfire]

Спасибо за наводку. Capybara обязательно посмотрю. Я сейчас копаю в сторону Selenium. Если Вы знаете, то Selenium IDE — это вершина айсберга. Есть еще Selenium-сервер. Из Selenium IDE можно одним кликом получить тесты на Вашем любимом языке для xxxUnit и прогнать их на большинстве браузеров.

И еще. Я с Вами вынужден согласится, что данная статья носит больше теоретический характер. Даже очень теоретически. И конечно, я представляю, что такое настоящие проекты с постоянной нехваткой времени и ресурсов. Скорее всего, в реальном проекте проводить тестирование CSS будет экономически невыгодно. А так жаль…

[@Elufimov]

Selenium IDE — это вершина айсберга.

И лучше её не трогать, а писать нормальные тесты через биндинг к любому языку с использование нужных паттернов.
Automated test script recorders (like Selenium IDE) are for dummies. (с) watirwebdriver.com/

[@Akela_wolf]

Классная статья! Если будет возможность — очень хотелось бы увидеть продолжение с типовыми сценариями тестирования — сетка, типографика, цвета, в общем то что пригождается практически в каждом проекте.

[@headfire]

Согласен. Правильная методология значительно ускоряет и повышает надежность написания кода. Мы можем уменьшать взаимовлияние участков кода друг на друга (так сказать, изолировать простанства состояний). На это, конечно, нацелены все современные технологии создания ПО. Но не думаю, что во многих случаях можно так просто удастся избавится от каскадирования (ведь не зря же его придумали). И не думаю, что правильная методология исключает необходимость тестирования. Спасибо за комментарий, мне он очень понравился. Я и сам об этом всем много думал. Но ведь все закоулки мысли в статье не опишешь, иначе она будет трудна для чтения.

О БЭМ, признаться, ничего не знал. Наверное, Яндекс плохого не придумает. Буду изучать.