как было бы хорошо протестировать верстку с помощью вашего makeup`а
Что вас останавливает?
прошу прощения. ссылку не заметил.
Я тоже не заметил ссылку.
Продублируй её в конце статьи.
Готово, теперь в статье есть все явки.
Ну это не совсем тестирование верстки ;)
Вы проверяете соответствие макету.
А тестировать, в моем понимании, проверять работу интерфейса на разных браузерах, в разных разрешениях и на разных операционных системах…
Это один момент.

Есть — второй момент, это уже больше касается юзабилити.
Я например для этого использую яндекс.метрику и его инструмент — Вебвизор.
С его помощью, я смотрю поведение пользователя на сайте — куда он курсор наводит, куда кликает, что копирует и прочие действия…
В итоге, те элементы (кнопки, менюшки) что наиболее часто используемые — я их размещаю на самом удобном для пользователе плане. А что мало используется — убираю или скрываю под дополнительные опции…
Это офигенно, особенно под адаптивный дизайн, под мобильные. Кучу коррекций выявил только по одному этому Вебвизору.
Тут есть элементы именно того тестирования, о котором вы говорите. Поскольку Мейкап — веб-приложение, его можно открывать в разных браузерах и на разных ОС. Разница в том, что можно не приводить большое и сложное приложение в определенное состояние, которое вы хотите проверить, а сразу отрендерить блок в нужном состоянии. Соответственно, задача регрессии вёрстки блока — просто прокликать все готовые, заранее сохраненные кейсы.
А как будете тестировать работу скриптов?
Допустим пользователь произвел действие, а например AngularJS «перерисовал» интерфейс.
Как узнаем, что действие вышло успешным и ничего не слетело (допустим, тег забыли по коду закрыть)?
Скрипты мы тестируем другими инструментами. Например, линтерами и юнит-тестами.
Второй момент, о котором вы говорите, не имеет ничего общего с версткой. Это часть UX, отделяющаяся постепенно в отдельное направление под названием CX (Client Experience)
Это бюджетный вариант тестирования интерфейса на фокусной группе :)
Косяки в верстке тоже всплывают.
Например, включаешь плей сессии и видишь, что клиент зашел с телефона с разрешением 320. И вот при таком разрешении появляется на одной из топовых страниц горизонтальный скролл — на странице одно из слов в заголовке не умещается, вот и распирает страницу. Тогда берем и правим цсс для таких экранов, делаем шрифт чуть меньше.

В данном случае верстка — это лишь инструмент. Как и дизайн. Но сам процесс, о котором вы говорите — это именно CX. Увеличение конверсии по результатам тестирования в реальных условиях. Тут и косяки верстки выявляются, и дизайна как такового, и текстов. Все вместе. Я просто говорю о более глобальном процессе. =)
Очень клевый подход, молодцы!

Скажите пожалуйста, планируется ли адаптация этого инструмента для react?
В репозитории есть ветка, в которой есть кое-какие эксперименты на эту тему. В будущем очень хочется довести эти эксперименты до релиза. =)
Есть нечто подобное для реакта пока еще нестабильное https://github.com/scup/atellier
А будет/планируется ли интеграция Makeup в TARS?
Задача пока в backlog'е. Думаю весной вернемся к ней. Следить можно за этим issue.
Я не очень поменял, как вы описываете состояние каждого блока. Можно примерчик?

Офф: отсюда — сюда. Это фейл по-моему
Для https://2gis.ru, например, используются свой javascript-фреймворк Slot. В нем шаблоны рендерятся с помощью handlebars.

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

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

На уровне файловой системы, такие данные хранятся вместе с блоком, и поддерживаются по мере изменения требований или дизайна.

Для других фреймворков система аналогичная. Для React, к примеру, это может быть props для компонента.
Ну т.е. ваш инструмент может взять допустим реактовский или ангуларовский компонент. И отрендерить в нескольких состояниях. Верно?
Да, но способ, как именно рендерить компоненты, нужно будет указать Мейкапу отдельно.
Есть пересекающаяся тема по автоматизации тестирования верстки: — visual diffing tools: webdiff, dpxdt, etc.
https://www.youtube.com/watch?v=jUUTqgzNR3M с конференции по Пайтон 2015 и слайды http://bit.ly/pycon2015-visual-diffs
Говоря об инструментах, которые решают похожую задачу, стоит упомянуть еще о Gemini и Galen Framework.
Не совсем понял, решает ли ваш инструмент проблему кроссбраузерности верстки? То есть в Chrome может работать все ок, а в Android браузере верстка ломается, через что вы прогоняете ваши тесты?
Мейкап нельзя назвать средством автоматизации. Это инструмент, в котором можно посмотреть набор заранее сохраненных кейсов данных для блока.

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

Для мобильных браузеров это возможно, но не так удобно, как в случае с большими экранами.
Очень интересный проект, я для таких целей в хроме использовал PixelPerfect, но есть всегда одна проблема, если я все правильно понял, то для работы например в различных состояниях нужно иметь несколько скриншотов этого состояния, пример: различные размеры экрана., различные ОС.
Если со вторым еще можно справиться, то как быть с первым?
А вообще задумка чертовски хороша, но 16 февраля Яндекс проводили свою школу дизайна и там Антоном Шеиным, была замечена очень хорошая вещь для дизайнеров — научитесь уже наконец таки использовать веб-технологии и будет вам радость.
В этом случае и дизайнер и разработчик будут говорить на одном языке.

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

Мы иногда практикуем состояния без приложенных скриншотов. Тогда можно просто посмотреть глазами, нормально ли выглядит блок. Есть и второй способ: можно не сохранять отдельное состояние, а в каком-то другом подергать ползунок и поменять ширину.
Просто например на данный момент, я много работаю с мобильной версткой в приложении и вот тут назревает вопрос, как тестировать такую верстку?
Если например с iOS все ясно и понятно, то с Android есть проблемы, слишком большое кол-во размеров у экранов.
Конечно же надо делать ее резиновой, но что делать если надо вставить в background картинку, на одном из экранов она так или иначе возьмет либо растянется, либо еще чего. Но я ушел от сути…
Я думаю вы доработаете и будет неплохой инструмент для верстальщиков!
А вы пробовали gemini: https://github.com/gemini-testing/gemini?
Тем более что вы используете БЭМ.
Gemini — обеспечивает визуальную регрессию в сравнении с предыдущими итерациями. Нам важно было иметь представление, насколько верстка соответствует первоначальному дизайну. А сравнивать с макетами автоматически почти невозможно: радикально будут отличаться рендеринг шрифтов, например.

А вообще, Gemini — отличный инструмент. Реконмендовал его в этом комментарии.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.