Согласен. Приведу еще один пример (как раз про еду).
У нас в городе есть два кафе. Одно работает по-старинке, другое «автоматизировали».
Как выглядит посещение автоматизированного кафе? Подходишь на кассу и говоришь «Мне салат и чашку кофе». Тебя спрашивают: «Назовите НОМЕР столика». Ээээ… С удивлением оглядываешся, и видишь что все столы перенумерованы. Выбираешь свободный стол и идешь снова на кассу, во-первых, стараясь не забыть номер столика, а во-вторых, следя, чтобы за этот столик никто ни сел (тут у тебя два варианта — либо следить, чтобы за столик никто не сел, либо оставить там пальто и следить, чтобы его никто не спер). Когда подходишь снова к кассе, оказывается что там уже очередь. Пока стоишь очередь, забываешь номер столика… Ну и так далее.
Как работает не автоматизированное кафе. Подходишь на кассу, рассказываешь кассирше (она же барменша), что тебе надо. Она пробивает заказ, сует в окошко поварам от руки написанную записку. И говорит, «Присаживайтесь пожалуйста, куда хотите». После этого тебе приносят заказ. Причем именно твой и именно туда, куда ты сел. Как это этой барменше удается — загадка. Кстати она там работает, сколько помню. А в автоматизированном кафе работники меняются очень часто.
Конечно же я понимаю, что подобные изменения вызваны сокращением издержек. От того у меня и такое чувство, что на мне очень удачно сэкономили. Вы пробовали дозвониться в поддержку Билайн?
Поддерживаю. Часто автоматизация идет во вред. Было время, когда у всех наших провайдеров Интернета в городе на телефоне сидели живые люди. Было очень удобно. Причем на телефоне сидел «суровый сисадмин» и любой вопрос решался моментально. Потом один за другим провайдеры стали внедрять call-центры и переносить службы поддержки в Москву. Дозвонится до живого человека, а особенно до человека с квалификацией админа, стало очень трудно. Пришлось сменить провайдера, на того, у которого служба поддержки оставалась еще «живой» (он из таких был последний). И, вот, совсем недавно звоню в поддержку, и вместо хриплого уверенного голоса «в чем дело?», слышу красивую механическую фразу: «Вы позвонили в компанию XXX, сейчас все линии заняты, дождитесь ответа оператора». А после 5 минутного ожидания ответила девушка. Хотя у нее и было желание мне помочь, но квалификации явно не хватало. Моя проблема так и осталась не решенной. Грустно.
Почему бы перед тем, как писать класс, не подумать, как он будет использоваться? То есть, разработать типичные сценарии вызовов. А от этого и до тестов недалеко.
По себе заметил, что тесты вперед писать получается редко. Но также заметил: если пишешь вперед реализацию, получаются классы, которые проще реализовать. Когда пишешь вначале тесты получаются классы, которыми легче пользоваться.
Подобные расчеты производительности интерфейса читал у Джефа Раскина в «Интерфесе». Интересная вычислительная задача. Расчет среднего времени прохождения по взвешенному графу с временем на ребрах и вероятностями в узлах. Причем, если в графе будут циклы, что вполне вероятно при моделировании работы с интерфейсом, то задача становится не столь тривиальной. Не могу навскидку сказать, какой инструмент может это сделать. Наверное, что-нибудь, из моделирующих программ. Было-бы здорово, если бы такие диаграммы обсчитывались автоматически.
Сложив в конце полученные расстояния между точками пересечения, мы получим некоторое значение. Чем меньше это значение, тем ближе нарисованная фигура к шаблону.
Думаю, математически более верно оперировать среднеквадратичным отклонением. (То, есть перед сложением возводить растояния в квадрат)
Согласен. Правильная методология значительно ускоряет и повышает надежность написания кода. Мы можем уменьшать взаимовлияние участков кода друг на друга (так сказать, изолировать простанства состояний). На это, конечно, нацелены все современные технологии создания ПО. Но не думаю, что во многих случаях можно так просто удастся избавится от каскадирования (ведь не зря же его придумали). И не думаю, что правильная методология исключает необходимость тестирования. Спасибо за комментарий, мне он очень понравился. Я и сам об этом всем много думал. Но ведь все закоулки мысли в статье не опишешь, иначе она будет трудна для чтения.
О БЭМ, признаться, ничего не знал. Наверное, Яндекс плохого не придумает. Буду изучать.
Согласен, но с некоторой оговоркой. В БОЛЬШИНСТВЕ случаев овчинка не стоит выделки. И дело, мне кажется, больше в овчинке. Тесты всегда может показаться писать муторно. Проблема кроется в том, что в большинстве проектов, где используется 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 в наших тестах можем контролировать и взаимное расположение элементов, хотя это будет чуть сложнее, чем цвет или параметры шрифта.
У нас в городе есть два кафе. Одно работает по-старинке, другое «автоматизировали».
Как выглядит посещение автоматизированного кафе? Подходишь на кассу и говоришь «Мне салат и чашку кофе». Тебя спрашивают: «Назовите НОМЕР столика». Ээээ… С удивлением оглядываешся, и видишь что все столы перенумерованы. Выбираешь свободный стол и идешь снова на кассу, во-первых, стараясь не забыть номер столика, а во-вторых, следя, чтобы за этот столик никто ни сел (тут у тебя два варианта — либо следить, чтобы за столик никто не сел, либо оставить там пальто и следить, чтобы его никто не спер). Когда подходишь снова к кассе, оказывается что там уже очередь. Пока стоишь очередь, забываешь номер столика… Ну и так далее.
Как работает не автоматизированное кафе. Подходишь на кассу, рассказываешь кассирше (она же барменша), что тебе надо. Она пробивает заказ, сует в окошко поварам от руки написанную записку. И говорит, «Присаживайтесь пожалуйста, куда хотите». После этого тебе приносят заказ. Причем именно твой и именно туда, куда ты сел. Как это этой барменше удается — загадка. Кстати она там работает, сколько помню. А в автоматизированном кафе работники меняются очень часто.
Как вы думайте — какое кафе я посещаю чаще?
Ну почему же сразу true. В фейковых объектах можно делать много интересных проверок.
По себе заметил, что тесты вперед писать получается редко. Но также заметил: если пишешь вперед реализацию, получаются классы, которые проще реализовать. Когда пишешь вначале тесты получаются классы, которыми легче пользоваться.
Чем докажете?
Думаю, математически более верно оперировать среднеквадратичным отклонением. (То, есть перед сложением возводить растояния в квадрат)
Статья мне очень понравилась. Спасибо.
О БЭМ, признаться, ничего не знал. Наверное, Яндекс плохого не придумает. Буду изучать.
Думаю, ситуация будет другой, если цена CSS-ошибки будет выше, чем в типичных для этой технологии проектов. Ведь неосторожная строчка в CSS может скрыть или исказить ценную информацию, от которой может зависит чье-нибудь здоровье. Тогда для тестов CSS найдется и время, и деньги, и исполнители.
И еще. Я с Вами вынужден согласится, что данная статья носит больше теоретический характер. Даже очень теоретически. И конечно, я представляю, что такое настоящие проекты с постоянной нехваткой времени и ресурсов. Скорее всего, в реальном проекте проводить тестирование CSS будет экономически невыгодно. А так жаль…
Конечно, во многом Вы правы. Метод, описанный в данной статье, не идеален. Но и совсем бессмысленным, его я бы не назвал. Если удается протестировать хоть что-то — это уже пусть небольшое, но достижение. Здесь мы полностью можем протестировать правильность селекторов и механизм каскадирования. У нас появляется мало-мальски твердая почва для проведения рефакторинга. Мы можем легко вычислить мусор и балласт и удалить его. А это по-моему, немало.
Теперь насчет сползания элементов. Ваш комментарий заставил меня немного поискать в Интернете, и вот, что я нашел:
Таким образом, мы через JavaScript в наших тестах можем контролировать и взаимное расположение элементов, хотя это будет чуть сложнее, чем цвет или параметры шрифта.