У нас, например, каждый блок имеет ограничение 320 пикселей по ширине, минимум. Если его зажмут в другой блок с элементом с меньшей шириной, то это баг в другом блоке, а не в первом. Его тоже можно выловить.
Если речь о виджете в произвольном окружении, то это отдельная тема. Тут можно и про iframe поговорить, и про кастомные теги…
Вот в том и дело, а тут чётко обвиняют фронта, он не учёл.
В таких случаях виноваты все, но статья про фронтэнд, поэтому вот так.
Не пользовались, но в целом скриншотеры это отдельный подход тестирования UI который, безусловно, имеет право на существование.
Главная проблема, на мой взгляд, у этого подхода одна: правильный подсчет процента расхождения. Он сильно повышается из-за, например, разного механизма рендеринга шрифтов на разных платформах. А это значит, что для pixel-perfect подхода тесты должны запускаться не у разработчика, а где-то на одном сервере…
Иными словами, сравнение скриншотов это, скорее, приемочные тесты, которые выходят за рамки данной статьи.
Проверка глазами хоть и не полностью автоматическая, но достаточно быстрая (быстрее приемочных тестов) и гораздо надёжнее.
так ещё и продумывать как должен выглядеть блок при бОльшем чем в макете материале?
Обычно ничего придумывать не надо, надо просто не хардкодить размеры.
Иногда нужно «придумывать» text-overflow: ellipsis, просто для того, чтобы контент не мог расгеить верстку при любых условиях.
Ну и мне не очень понятна позиция «кто-то должен», если честно) Если дизайнер, менеджер и фронтэндер объединены общей целью, то какая разница кто чего должен. Главное — результат.
На старте мы обычно учитываем всего 1 дополнительный кейс к дизайнам, это вот эти многострочные одиннадцатиклассницы. Затем «база» кейсов просто наращивается. По сути, вопрос стоит лишь так: делать ли двухминутную регрессию (с вероятным последующим фиксом багов) после внедрения очередной фичи, или забить и не думать о возникших багах, а фиксать их потом вне очереди как блокеры.
И кстати, вы описали «сферическую» кнопку в отрыве от контента, но кнопка обычно находится в контексте и контекст может зависеть от этой кнопки и следовательно его видоизменение тоже нужно предусматривать.
Безусловно) Например, мы все блоки делаем резиновыми и проверяем это во время регрессии в специальной тулзе, о которой напишем позже. Хотя большинство блоков имеют фиксированную ширину по дизайну.
На некоторые блоки у нас даже есть «контентные» автотесты, которые проверяют резиновость блока, то есть вообще без участия человека.
Потому что я фронтэндер, и в этом контексте «дизайнер с менеджером не учли» — обвинение, а «фронтэндер не учел» — это конструктивный мотив для развития.
Вот именно! Проблема в том, что «бизнес» не эксперт, и на предложение построить фундамент под домом ответит вяло — давайте потом, сейчас на это времени нет.
Я говорю про то, что сейчас у бизнеса нет понимания того, что автотесты — это часть фундамента приложения, и помогать ему делать плохой фундамент — медвежья услуга.
Очень правильная мысль: автотесты дело команды, а не заказчика. Точно так же как и стек технологий, фреймворк, воркфлоу и время митингов.
То есть, если уважающий себя разработчик пишет юнит-тесты на свой код, то уважающая себя команда пишет автотесты… либо просто не занимается проектом, если заказчик не может позволить себе эту команду.
Если бы вы видили, на каком позитиве разрабатывалась линейка в тройке, то пользовались бы только ей) На тот момент она была серьёзно быстрее (по скорости отрисовки) своих конкурентов.
Но на самом деле, если их не заполнять, результат сильно не улучшится.
У нас, например, каждый блок имеет ограничение 320 пикселей по ширине, минимум. Если его зажмут в другой блок с элементом с меньшей шириной, то это баг в другом блоке, а не в первом. Его тоже можно выловить.
Если речь о виджете в произвольном окружении, то это отдельная тема. Тут можно и про iframe поговорить, и про кастомные теги…
В таких случаях виноваты все, но статья про фронтэнд, поэтому вот так.
Главная проблема, на мой взгляд, у этого подхода одна: правильный подсчет процента расхождения. Он сильно повышается из-за, например, разного механизма рендеринга шрифтов на разных платформах. А это значит, что для pixel-perfect подхода тесты должны запускаться не у разработчика, а где-то на одном сервере…
Иными словами, сравнение скриншотов это, скорее, приемочные тесты, которые выходят за рамки данной статьи.
Проверка глазами хоть и не полностью автоматическая, но достаточно быстрая (быстрее приемочных тестов) и гораздо надёжнее.
Обычно ничего придумывать не надо, надо просто не хардкодить размеры.
Иногда нужно «придумывать» text-overflow: ellipsis, просто для того, чтобы контент не мог расгеить верстку при любых условиях.
Ну и мне не очень понятна позиция «кто-то должен», если честно) Если дизайнер, менеджер и фронтэндер объединены общей целью, то какая разница кто чего должен. Главное — результат.
На старте мы обычно учитываем всего 1 дополнительный кейс к дизайнам, это вот эти многострочные одиннадцатиклассницы. Затем «база» кейсов просто наращивается. По сути, вопрос стоит лишь так: делать ли двухминутную регрессию (с вероятным последующим фиксом багов) после внедрения очередной фичи, или забить и не думать о возникших багах, а фиксать их потом вне очереди как блокеры.
Безусловно) Например, мы все блоки делаем резиновыми и проверяем это во время регрессии в специальной тулзе, о которой напишем позже. Хотя большинство блоков имеют фиксированную ширину по дизайну.
На некоторые блоки у нас даже есть «контентные» автотесты, которые проверяют резиновость блока, то есть вообще без участия человека.
Я говорю про то, что сейчас у бизнеса нет понимания того, что автотесты — это часть фундамента приложения, и помогать ему делать плохой фундамент — медвежья услуга.
То есть, если уважающий себя разработчик пишет юнит-тесты на свой код, то уважающая себя команда пишет автотесты… либо просто не занимается проектом, если заказчик не может позволить себе эту команду.