Сложив в конце полученные расстояния между точками пересечения, мы получим некоторое значение. Чем меньше это значение, тем ближе нарисованная фигура к шаблону.
Думаю, математически более верно оперировать среднеквадратичным отклонением. (То, есть перед сложением возводить растояния в квадрат)
Согласен. Правильная методология значительно ускоряет и повышает надежность написания кода. Мы можем уменьшать взаимовлияние участков кода друг на друга (так сказать, изолировать простанства состояний). На это, конечно, нацелены все современные технологии создания ПО. Но не думаю, что во многих случаях можно так просто удастся избавится от каскадирования (ведь не зря же его придумали). И не думаю, что правильная методология исключает необходимость тестирования. Спасибо за комментарий, мне он очень понравился. Я и сам об этом всем много думал. Но ведь все закоулки мысли в статье не опишешь, иначе она будет трудна для чтения.
О БЭМ, признаться, ничего не знал. Наверное, Яндекс плохого не придумает. Буду изучать.
Согласен, но с некоторой оговоркой. В БОЛЬШИНСТВЕ случаев овчинка не стоит выделки. И дело, мне кажется, больше в овчинке. Тесты всегда может показаться писать муторно. Проблема кроется в том, что в большинстве проектов, где используется CSS, ошибка в CSS-коде не критична. Ну съехало там чего-то куда-то. На скорость не влияет.
Думаю, ситуация будет другой, если цена CSS-ошибки будет выше, чем в типичных для этой технологии проектов. Ведь неосторожная строчка в CSS может скрыть или исказить ценную информацию, от которой может зависит чье-нибудь здоровье. Тогда для тестов CSS найдется и время, и деньги, и исполнители.
Спасибо за наводку. Capybara обязательно посмотрю. Я сейчас копаю в сторону Selenium. Если Вы знаете, то Selenium IDE — это вершина айсберга. Есть еще Selenium-сервер. Из Selenium IDE можно одним кликом получить тесты на Вашем любимом языке для xxxUnit и прогнать их на большинстве браузеров.
И еще. Я с Вами вынужден согласится, что данная статья носит больше теоретический характер. Даже очень теоретически. И конечно, я представляю, что такое настоящие проекты с постоянной нехваткой времени и ресурсов. Скорее всего, в реальном проекте проводить тестирование CSS будет экономически невыгодно. А так жаль…
В начале статьи были указаны несколько точек зрения на проблему тестирования CSS. Из Вашего комментария ясно, что Вы придерживайтесь либо первого, либо второго варианта (может, конечно и еще какого-нибудь другого):
1. Тестирование CSS не имеет смысла, так как это декларативный язык, а его результатом является сверстанное изображение страницы, которое можно оценить лишь визуально.
2. Протестировать CSS можно с помощью снятия битмапов с сгенерированной страницы и сверка ее с эталонным изображением. Для этого даже есть некоторые инструменты.
Конечно, во многом Вы правы. Метод, описанный в данной статье, не идеален. Но и совсем бессмысленным, его я бы не назвал. Если удается протестировать хоть что-то — это уже пусть небольшое, но достижение. Здесь мы полностью можем протестировать правильность селекторов и механизм каскадирования. У нас появляется мало-мальски твердая почва для проведения рефакторинга. Мы можем легко вычислить мусор и балласт и удалить его. А это по-моему, немало.
Теперь насчет сползания элементов. Ваш комментарий заставил меня немного поискать в Интернете, и вот, что я нашел:
Одна из самых распространенных задач — определение абсолютной позиции элемента относительно левого верхнего угла документа.
Для определения позиции используются следующие свойства элемента:
offsetTop — отступ сверху, измеряется в пикселах относительно родительского элемента.
offsetLeft — отступ слева, измеряется в пикселах относительно родительского элемента.
offsetParent — ближайший родитель, относительно которого делается отсчет. Его значение будет null если текущий элемент невидим (display: none) или это корневой элемент документа.
Поскольку значение считается от ближайшего родителя, то абсолютная позиция относительно верхнего левого угла документа обычно считается в цикле, который завершается тогда, когда значение offsetParent будет равно null.
Таким образом, мы через JavaScript в наших тестах можем контролировать и взаимное расположение элементов, хотя это будет чуть сложнее, чем цвет или параметры шрифта.
Думаю, математически более верно оперировать среднеквадратичным отклонением. (То, есть перед сложением возводить растояния в квадрат)
Статья мне очень понравилась. Спасибо.
О БЭМ, признаться, ничего не знал. Наверное, Яндекс плохого не придумает. Буду изучать.
Думаю, ситуация будет другой, если цена CSS-ошибки будет выше, чем в типичных для этой технологии проектов. Ведь неосторожная строчка в CSS может скрыть или исказить ценную информацию, от которой может зависит чье-нибудь здоровье. Тогда для тестов CSS найдется и время, и деньги, и исполнители.
И еще. Я с Вами вынужден согласится, что данная статья носит больше теоретический характер. Даже очень теоретически. И конечно, я представляю, что такое настоящие проекты с постоянной нехваткой времени и ресурсов. Скорее всего, в реальном проекте проводить тестирование CSS будет экономически невыгодно. А так жаль…
Конечно, во многом Вы правы. Метод, описанный в данной статье, не идеален. Но и совсем бессмысленным, его я бы не назвал. Если удается протестировать хоть что-то — это уже пусть небольшое, но достижение. Здесь мы полностью можем протестировать правильность селекторов и механизм каскадирования. У нас появляется мало-мальски твердая почва для проведения рефакторинга. Мы можем легко вычислить мусор и балласт и удалить его. А это по-моему, немало.
Теперь насчет сползания элементов. Ваш комментарий заставил меня немного поискать в Интернете, и вот, что я нашел:
Таким образом, мы через JavaScript в наших тестах можем контролировать и взаимное расположение элементов, хотя это будет чуть сложнее, чем цвет или параметры шрифта.