26 декабря 2014 в 09:40

Одиннадцатиклассница, или тестируем баги вёрстки



В современном вебе несправедливо мало внимания уделяется хоть сколько-нибудь автоматизированному тестированию UI. Особенно это касается статической вёрстки. На проекте 2ГИС Онлайн мы попытались частично восполнить этот пробел. Какие полезные практики мы приобрели, и о каких хороших библиотеках мы узнали, расскажем далее.

Верстка


Рассмотрим историю одной выдуманной кнопочки:



Квадратная кнопка с иконкой. Всё просто. Размеры можно хардкодить в пикселях — ведь какая разница?

Практически сразу кнопка начинает эволюционировать. Пользователи редко нажимают на кнопку. Что же делать? Как вариант — добавить поясняющую надпись. Осталось лишь чуть увеличить ширину, чтоб надпись входила:



А как же надпись на русском языке? Да и оригинальный текст может измениться. Так что хардкодить ширину нельзя, придется делать произвольную:



Текста может быть так много, что в одну строку он не читается. Нужно ограничить максимальную ширину и развязать высоту:



Кнопкой по-прежнему мало пользуются! Можно сделать вспомогательное многострочное описание. Для этого нужно добавить span-чик с соответствующими стилями:



Кажется, уже всё учтено, и никто не в силах сломать эту вёрстку. Никто кроме одиннадцатиклассницы — длинного слова, не помещающегося в максимальную ширину. Просто делаем перенос по буквам:



Пользователи стали жаловаться на навязчивую большую кнопку, поэтому было принято решение сделать крестик, закрывающий кнопку без фактического нажатия. Немного стилей для крестика, чуточку отступа для заголовка чтоб он не попадал под этот крестик — и всё готово:



Не забываем, что основного текста может и не быть, правим отступы:



Кажется теперь мы имеем многофункциональную кнопку на все случаи жизни, с поправленными багами, правда? Давайте ещё раз посмотрим все кейсы, только теперь одновременно:



Что же мы видим? Вместо полнофункциональной кнопочки мы видим обилие регрессионных багов: иконка вывалилась из кнопки, поломалось вертикальное выравнивание, появился лишний отступ для крестика… Иными словами, хотели как лучше, получилось как всегда.

А теперь представьте, что речь не о кнопке, а о большом, постоянно развивающемся проекте с многомиллионной аудиторией. Поддержка превращается в ад, в котором, к сожалению, живут многие верстальщики.

Есть множество техник и методологий, помогающих поддерживать вёрстку сложных проектов. Например, широко известный всем БЭМ, который мы тоже используем. Но сама по себе методология БЭМ не решает, а только локализует регрессионные баги вёрстки. Как же избавиться от них в принципе? На самом деле очень просто (и для этого вам не понадобится изучать API десятка новых js-библиотек!) — нужно создать одну тестовую html-страничку со всеми состояниями кнопки. Давайте дружно, прям сейчас, создадим её, это не займёт больше 10 секунд. Вот вам даже разметка:

<!doctype html>
<html>
<head>
    <meta charset="utf-8" />

    <!-- Стилевой файл проекта -->
    <link rel="stylesheet" href="style.css">

    <title>Test page</title>
</head>

<body>

<!-- Здесь будет первое состояние -->

</body>
</html>

Никакого js, npm-зависимостей, express-серверов… Просто html-файлик, открытый в браузере.

На каждую эволюционную итерацию нужно заводить одно или несколько новых состояний (то есть вариантов html-кода тестируемого элемента, включая контент), но не удалять старые. Просмотр всех старых состояний можно назвать полуавтоматической регрессией.

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

Одиннадцатиклассница


Более половины багов вёрстки связаны с очень простым просчетом: фронтэндер не учитывает, что в текстовые ноды его макета может попасть, вообще говоря, любой текст. Он может быть многострочный, состоять из длинных слов, или может быть пустой строкой.

Возьмите пару любых своих макетов — готов поспорить на российский рубль, что их сможет сломать даже одна одиннадцатиклассница. Вставьте несколько одиннадцатиклассниц в каждое поле — поломка вёрстки гарантирована!

Предлагаю открыть любой популярный сайт и в отладчике выполнить следующий код

var a,w=document.createTreeWalker(document,NodeFilter.SHOW_TEXT);while(a=w.nextNode()){if(a.textContent.trim().length)a.textContent='Одиннадцатиклассница пошла посмотреть на достопримечательность, она шла долго, несколько строчек, пока не пришла'}

Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.

Конечно, это не значит, что одиннадцатиклассница каждый день ходит по всем текстовым нодам интернета и ломает вёрстку (с тем же успехом сайт можно защищать от эболавируса), но вы должны учитывать следующие факторы:

  1. Если ваш проект существует на нескольких языках, то на другом языке может быть более длинная фраза (русский длиннее английского, испанский длиннее русского и т.д.)
  2. У пользователя может не быть основного шрифта, а fallback окажется крупнее
  3. У пользователя может быть кастомный зум или иной механизм рендеринга шрифтов
  4. Текст может быть изменён в процессе поддержки, в том числе контент-менеджерами, которые вёрстку проверять уж точно не будут
  5. В поле может прилететь неправильный текст просто из-за бага в js-коде
  6. Баг в вёрстке другого блока может ужать ваш блок
  7. Кто-нибудь прочитает эту статью и выполнит приведённый код в отладчике :)

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

Автоматизация


Всё, о чем мы писали выше, назвать автоматическим тестированием нельзя, потому что требует глаз человека. Если вы не хотите напрягать свои глаза совсем, вам помогут тесты, которые мы называем dom-тестами.

Dom-тест — это js-код, выполняемый в браузере, который что-то проверяет в изолированной части приложения, или во всём приложении целиком. Проверяться может что угодно: от наличия класса и атрибута в html, до аргументов, с которыми была вызвана какая-то функция, в том числе асинхронная.

Здесь вам помогут такие замечательные библиотеки как:

mocha. Фреймворк для тестирования. Позволяет создавать тесты и группы тестов, включая асинхронные; выполнять какой-то код перед тестом или группой тестов, и после него.

chai. Библиотека для assert-ов. В принципе можно использовать нативный assert node.js, но у “чая” есть плюшки, например красивый diff deepEqual.

sinon. Библиотека, позволяющая делать две важных вещи:

  • Следить за функциями. Вы будете знать, сколько раз и с какими аргументами была вызвана функция, за которой вы следите.
  • FakeTimers. Позволяет подменять setTimeout и setInterval и, таким образом, “управлять” временем. То есть, после подмены вы может вызывать sinon.tick(20) — и мгновенно пройдет 20 миллисекунд времени, при этом выполнятся все таймауты, зарегистрированные на выполнение в этом периоде.

Комбинируя всё это можно писать тесты как на все приложение, так и на его изолированные части. В этих тестах можно делать буквально всё: заполнять форму и кликать в кнопки; менять dom-дерево; делать ajax-запросы… По сути, внутри таких тестов вы находитесь внутри отладочной консоли браузера, а в руках у вас любые js-библиотеки для тестирования, которые вам нравятся.

Преимущество таких тестов — они выполняются в браузере, а значит, могут быть запущены в любом браузере с нулевой затратой ресурсов на адаптацию (чего не скажешь о драйверах selenium, особенно в комбинации, допустим, с ie8 или android 4.0). Кроме того, такие тесты можно запускать в полностью автоматическом режиме на phantomJS, например на git-push hooks.

На всякий случай стоит отметить, что dom-тесты не являются альтернативой регрессионному тестированию вёрстки; это просто ещё один подход защиты кода, со своей спецификой и областью применения.

Выводы


Заведите html-страничку для регрессии вёрстки, пустите в неё одиннадцатиклассницу, и ваша вёрстка станет в 10 раз качественнее. Защищайте свой код js-тестами, и вы сможете отказаться от услуг тестировщиков (которым придётся переквалифицироваться в автоматизаторов и помогать вам писать тесты). На проекте 2ГИС Онлайн 90% задач попадают на бой без ручного тестирования, и это во многом стало возможным благодаря озвученным выше подходам тестирования.

Не дожидайтесь, когда одиннадцатиклассница придёт к вам сама!

Больше информации можно почерпнуть из моего выступления на Web Standards Days.
Автор: @Diokuz
2ГИС
рейтинг 135,35
Карта города и справочник предприятий

Комментарии (88)

  • +12
    Нажмите, чтобы поехать!
    Это кнопка, на которую можно нажимать.
    • +11
      Пахом.jpg
      • +1
        Нажимать кнопки пахом — это какое-то совсем уж особенное извращение.
  • +21
    «фронтэндер не учитывает»

    Ну зачем же так? почему никто не говорит что дизайнер не учел этого, проектировщик не учел этого, манагер не учел этого в конце концов.
    • –5
      Потому что есть разработчик, который не учел этого =))
    • +6
      Потому что я фронтэндер, и в этом контексте «дизайнер с менеджером не учли» — обвинение, а «фронтэндер не учел» — это конструктивный мотив для развития.
      • 0
        Это безусловно хороший повод, но не в случае ограниченного времени и оценки (если платят за часы). В редкие моменты удается прошерстить Github и посмотреть что используют в своих интересных проектах другие, чтобы потом использовать это в своих целях. Всегда хочется решить задачу не как обычно, а как кажется лучше и правильнее, даже в ущерб оплате… но вот несколько раз «согрешишь» и до следующего порыва (а потому что печеньки стали внезапно дороже и кофе уже не греет по дороге домой, лишь одноразовый стаканчик, заправленный офисной кофе-машиной в целях экономии).
        На стабильных проектах можно и нужно постоянно развиваться, даже увлекаться «добрым мазохизмом».
        • 0
          На разовых проектах теряет смысл само понятие регрессии. Но таких проектов мало, всегда есть поддержка, хотя бы в рамках обсуждений «а давай бордер на три пикселя подвинем».
    • 0
      Конечно, проще найти другого «виноватого», вместо того чтобы сесть вместе и договориться как сделать лучше и наладить процесс.
      • 0
        Поиск виновного, если так подумать, он как раз и нужен для того, чтобы понять, на каком этапе начался факап. И вот тут как раз и нужно садиться и думать всем вместе, как улучшить процесс.
    • 0
      Ага. Менеджер особенно.

      Очень люблю разработчиков, которые говорят, что в ТЗ не было указано «сделать без ошибок» (утрирую конечно)

      Теперь всегда пишу «Сделать без ошибок в функционале». Кстати, работает, но иногда эти трудности перевода очень грустны и забавны)
      • +2
        «Это не баг, это фича»?
  • +7
    А как же трудозатраты? Менеджер проекта говорит сделать кнопку, фронтендер просчитывая 10 вариантов эволюции кнопки (и еще 10 гипотетических вариантов) выдаёт менеджеру время на работу, за которое можно сделать пол-сайта, менеджер в недоумении и сомневается в компетенции фронтенда.

    Над последним проектом работали по аджайл — часто внедрение таких эволюций отбрасывали: будет следующий спринт будем дорабатывать иначе трудозатраты не влезут ни в какие рамки.

    Про проектировщика, дизайнера уже писали выше — зачастую они об этом вообще не думают (а дизайнер так мыслит вообще фиксированными габаритами и объектами).

    И кстати, вы описали «сферическую» кнопку в отрыве от контента, но кнопка обычно находится в контексте и контекст может зависеть от этой кнопки и следовательно его видоизменение тоже нужно предусматривать.
    • +5
      Так ведь никто не говорит что все 100500 состояний кнопки нужно учесть здесь и сейчас!
      Такой подход позволит при создании нового состояния убедиться что старые не поломались.
    • +4
      А как же трудозатраты?

      На старте мы обычно учитываем всего 1 дополнительный кейс к дизайнам, это вот эти многострочные одиннадцатиклассницы. Затем «база» кейсов просто наращивается. По сути, вопрос стоит лишь так: делать ли двухминутную регрессию (с вероятным последующим фиксом багов) после внедрения очередной фичи, или забить и не думать о возникших багах, а фиксать их потом вне очереди как блокеры.

      И кстати, вы описали «сферическую» кнопку в отрыве от контента, но кнопка обычно находится в контексте и контекст может зависеть от этой кнопки и следовательно его видоизменение тоже нужно предусматривать.

      Безусловно) Например, мы все блоки делаем резиновыми и проверяем это во время регрессии в специальной тулзе, о которой напишем позже. Хотя большинство блоков имеют фиксированную ширину по дизайну.
      На некоторые блоки у нас даже есть «контентные» автотесты, которые проверяют резиновость блока, то есть вообще без участия человека.
    • +3
      Стабильность проекта в любом случае требует трудозатрат. Экономия времени на таких вещах может легко превратить в краткосрочной перспективе разработку в ад. Нам хочется быть в любую минуту уверенными в качестве продукта.

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

      • +1
        " выдаёт менеджеру время на работу, за которое можно сделать пол-сайта, менеджер в недоумении и сомневается в компетенции фронтенда" это стереотипы, которые нужно ломать.

        Ломать например так. Посмотрите сколько времени вы обычно тратите на поддержку FE, на регулярное регресионное тестирование, сколько времени проходит между началом разработки и попаданием фичи на продакшн. В абсолютных величинах. В какую эмоциональную стоимость вам выливается эта поддержка. И тд.

        Затем попробуйте на мелкой фиче покрыть ее например таким инструментом с нуля. И понаблюдайте, изменятся ли затраты, запары, закидоны на вышеупомянутых этапах.

        Как тестировщик, от работы которого успешно и регулярно избавляется автор статьи, могу заметить еще один профит — имея инструмент контроля верстки на старте и грамотный подход к архитектуре, менеджер будет вас еще больше любить и поощерять. Потому что вы становитесь гибче к изменению его требований, доставляете эти изменения быстрее, сохраняя при этом стабильность приложения.
  • +9
    «фронтэндер не учитывает» ээээ, серьёзно? То есть проектировать интерфейс должен фронтэнд? Не проектировщик с дизайнером, а фронтэнд? Я уже привык, что всякие всплывашки и алёрты доделываю сам за дизигнера, так ещё и продумывать как должен выглядеть блок при бОльшем чем в макете материале?

    Нет уж увольте, пусть дизайнер и проектировщик решают как оно должно выглядит и растягиваться, а уж я это реализую.
    • +17
      Вы мыслите не конструктивно! Вы же профессионал! Разве вы не можете сделать семь перпендикулярных красных прямых линий?
      • +12
        И одна должна быть прозрачного цвета, так?
        • 0
          Хм, мне что ссылку на оригинал дать тому, кто не понял?
          • 0
            • 0
              Там изначально неверно, линии должны быть перпендикулярны все всем.
              • 0
                Там все линии пересекают друг друга под 90°, это и есть перпендикулярность, по определению.
    • +4
      так ещё и продумывать как должен выглядеть блок при бОльшем чем в макете материале?

      Обычно ничего придумывать не надо, надо просто не хардкодить размеры.
      Иногда нужно «придумывать» text-overflow: ellipsis, просто для того, чтобы контент не мог расгеить верстку при любых условиях.

      Ну и мне не очень понятна позиция «кто-то должен», если честно) Если дизайнер, менеджер и фронтэндер объединены общей целью, то какая разница кто чего должен. Главное — результат.
      • +2
        При чём тут хардкорные размеры? А если это элемент внутри небольшого блока? Где бай дизайн нет места? Я понимаю, что надо обрезать, но своё имя обрезанным мне видеть не хочется, что ж я виноват, что меня зовут Шерафудинов Бадулай Фаттулаевич?

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

        п.п.с. Выше была шутка.

        «Если дизайнер, менеджер и фронтэндер объединены общей целью, то какая разница кто чего должен. Главное — результат.» Вот в том и дело, а тут чётко обвиняют фронта, он не учёл.
        • +3
          А если это элемент внутри небольшого блока?

          У нас, например, каждый блок имеет ограничение 320 пикселей по ширине, минимум. Если его зажмут в другой блок с элементом с меньшей шириной, то это баг в другом блоке, а не в первом. Его тоже можно выловить.

          Если речь о виджете в произвольном окружении, то это отдельная тема. Тут можно и про iframe поговорить, и про кастомные теги…

          Вот в том и дело, а тут чётко обвиняют фронта, он не учёл.

          В таких случаях виноваты все, но статья про фронтэнд, поэтому вот так.
          • –1
            Ну так и пишите, что всё виноваты, какая разница о чём статья? Люди ведь читают разные, а потом удивляемся, что от программиста требуют чинить кофеварку.
      • 0
        Не подскажите, случаем, как сделать ellipsis для многострочного текста? С однострочным это действительно рабочее «полу-решение». Но как только дело доходит до многострочных блоков…

        К тому же не очень приятно многократно за 1 макет брать на себя ответственность за решения из области «чтобы не развалилось и было удобно», которые должен был взять на себя дизайнер. Получается что большинство дизайнеров не утруждают себя сделать нечто большее, чем просто красивую картинку, которая понравилась клиенту.
        • +1
          Есть CSS решение, надо поискать. Если забуду тут скинуть, напишите в личку.
          • 0
            Очень любопытно. Все известные мне решения имеют ряд недостатков:
            • position: absolute блок с «…» строго в нижнем правом углу. Выглядит вовсе не так, как хотелось бы. И если блок содержит текст, который всё таки помещается, то выглядит и вовсе глупо;
            • javascript-решения. Помимо прочего плохи эти решения тем, что любое изменение размера блока (к примеру повернуть смартфон на 90 градусов) нуждаются в повторной обрезке. Да и до загрузки скриптом текст выглядит некрасиво;
            • only -webkit или -opera css. Решения для firefox-а мне найти не удалось :( да и не только firefox в них нуждается.

            • 0
              • 0
                Ну собственно вы про п.1 из моего списка… На мой взгляд лучше воспользоваться JS решением, чем таким.
                • 0
                  Нет, эта штука работает адекватно когда текста мало, и когда много, в отличие от позиционирования.
      • 0
        Да-да, до определенного предела тянем контейнер, потом ellipsis, но если он обрезает слишком много от и так небольшого контента или начался после пробела нужно просто резать и…
        Фронтендер везде свой ад найдет.
    • +1
      как минимум, вы должны можете задать вопрос дизайнеру на предмет «А как должна выглядеть кнопка, если будет то-то?» и исходя из ответа уже делать реализацию
      • 0
        Это само собой, это чаще всегда самое первое, что происходит после получения макета. Просто реакция на столь категоричное утверждение.
    • +3
      Конечно, вы ничего не должны проектировать, просто будьте эдаким HTML–оператором, печатайте код и ни о чем не думайте.
      • +2
        «Ой, всё»?

        Ещё раз посыл попытайтесь понять, я только за общий подход к делу. Меня задело то, что «общая» проблема повешена на фронта в данном конкретном посте.
        • 0
          Вас задевает то, что кто-то работает больше? Или вы в курсе обязанностей фронтендера в 2GIS?
          • +2
            А ну если проектирование интерфейса и отрисовка в 2GIS лежит исключительно на фронте, тогда да.
        • 0
          Есть интересный доклад Артема Поликарпова «Технолог — тоже дизайнер». И не все можно учесть при дизайне.
          www.youtube.com/watch?v=h4QuJ0xBGfc
  • 0
    О-о-о, одиннадцатиклассница-а-а. Имхо, у кнопок просто не должно быть таких названий и описаний. Хотя… это же заказчик решает, а жаль.
    • 0
      У кнопок нет, а у названий товаров да.
      Не раз и не два мне приходилось отвечать заказчику: «а я же говорил, что не влезет, давайте вносить правки в дизайн».
      • 0
        Вы торгуете одиннадцатиклассницами? Что за бизнес такой, если не секрет?
        • 0
          Сейсмоустойчивыми воздухозаборниками.

          А если серьёзно, то в одном случае были кованные изделия, а в другом автозапчасти и оба раза зона текста в одну строку символов на 12-15.
  • +1
    Могу предположить, что данная проблема стоит свеч при выводе введённых пользовательских данных или данных из какой-нибудь импортированной БД — никогда не знаешь фамилия пользователя 10 букв или 30. уместится в 1 строчку имя с фамилией или нужно просчитывать 2 или 3. Количество цифр в сумме какого-нибудь заказа.
    • +5
      Счет Германия-Бразилия, курс доллара… ))
      • 0
        ну про счёт, вы зря, там даже перехода на следующий порядок не было, ну и уж 2 символа вместо одно несложно реализовать.
        • 0
          там был скролл, потому-что 8 фамилий не вмещались в фиксированный блок по высоте.
          • 0
            Ну так не счёт тогда, а список забивших + 7 забитых голов достаточно частый результат в футболе.
  • 0
    А про gemini что думаете?
    • 0
      Не пользовались, но в целом скриншотеры это отдельный подход тестирования UI который, безусловно, имеет право на существование.

      Главная проблема, на мой взгляд, у этого подхода одна: правильный подсчет процента расхождения. Он сильно повышается из-за, например, разного механизма рендеринга шрифтов на разных платформах. А это значит, что для pixel-perfect подхода тесты должны запускаться не у разработчика, а где-то на одном сервере…

      Иными словами, сравнение скриншотов это, скорее, приемочные тесты, которые выходят за рамки данной статьи.

      Проверка глазами хоть и не полностью автоматическая, но достаточно быстрая (быстрее приемочных тестов) и гораздо надёжнее.
      • 0
        А вот зря вы так.
        Я в первой половине статьи думал, что вы как раз про что-то вроде gemini расскажете, а вы начали про тестирование frontend – функции, асинхрон, ещё что-то. Начинали про вёрстку, продолжили программированием. Странно как-то.
  • +3
    Могу предложить вам для тестирования верстки вот этот инструмент galenframework.com
    Я уже писал для него статью на хабре habrahabr.ru/post/203506/

    Он позволяет проверять расположение элементов относительно друг друга, а также имеет возможность проверять изображения отдельных элементов по цветовой схеме или по-пиксельно. При грамотном подходе ваши тесты могут превратится в читабельный документ полностью описывающий верстку.
    • +1
      Спасибо! Давно присматриваюсь к такому подходу, но не знал, что уже что-то есть.
  • 0
    Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.


    Наполнять текстом даже пустые текст-ноды немного не честно.
    • 0
      Ну это как минимум говорит о том, что на проекте нет минификации)

      Но на самом деле, если их не заполнять, результат сильно не улучшится.
    • 0
      По просьбам перезапилил скрипт, теперь обходятся только реальные текстовые ноды.
  • +1
    А нормальный перенос по слогам со знаком переноса разве в наши дни нельзя запилить?

    Одиннадцатикл
    ассница

    Вот это очень убого смотрится.

    Одиннадцати-
    классница

    Вот это гораздо лучше.
    • 0
      Не во всех браузерах работает без допусилий (разбиения на сервере).
      • 0
        Насколько я понимаю, речь идёт о предопределённых словах, а не пользовательском вводе. Кроме того реально длинных слов, которым это надо, очень мало. Наконец, есть алгоритмы, которые неплохо разбивают автоматически и редко ошибаются. Думаю, было бы желание, а сделать можно.
  • +1
    Мне кажется, что метод оправдан в основном на крупных/сложных проектах.
    На простых проектах, действительно, менеджеры будут возмущены сроками и стоимостью.
    Но, в принципе, подход интересный.
    Фраза
    Не дожидайтесь, когда одиннадцатиклассница придёт к вам сама!
    ушла в сборник цитат =)
  • –1
    добавьте код в виде ссылки-закладки для браузера. кол-во желающих воспользоваться увеличиться в разы.
    • 0
      javascript:(function(){var%20a,w=document.createTreeWalker(document,NodeFilter.SHOW_TEXT);while(a=w.nextNode()){if(a.textContent.trim().length)a.textContent='Lorem%20ipsum%20dolor%20sit%20amet,%20consectetur%20adipiscing%20elit.%20Fusce%20congue%20semper%20sodales.%20Sed%20ultricies%20eget%20neque%20eu%20semper.%20Nam%20ut%20diam%20vitae%20orci%20blandit%20eleifend%20a%20eget%20sapien.%20';}})()
      
    • 0
      Дык это же не тут выполнять надо, а на любимом сайте)
      • 0
        это понятно :) но если я хочу девелопить сайты и тестировать, то и не знаю, куда деть кусочек текста, а в виде буркмарка в браузере оч удобно.

        как пример подобных полезных закладок — авторелоадер css стилей nv.github.io/css_auto-reload/
  • –1
    Какая-то притянутая за уши проблема, я считаю.
    Ваша одиннадцатиклассница ломает на моём сайте блок с номером телефона. И блок с ценой. О чем это говорит? Да ни о чем.
    Вы пришли с каким-то громким тезисом «все сайты в интернете свёрстаны неправильно», хотя оснований для таких утверждений нет.
    Идея, разумеется, здравая, но с очень узкой областью применения: с помощью таких методик можно тестировать только элементы интерфейса (меню, кнопки), а не элементы оформления, коих на обычном сайте на порядок больше.
    Попробуйте бутстрап потестировать таким способом. Тоже, считаете, непрофессионально свёрстан?
    Проблемы людей, у которых «нет шрифта», «изменен зум» или иным образом целенаправленно сломан мой сайт, я решать не собираюсь. А все остальные кейсы (вроде кривого контента, плохого перевода или сломанного яваскрипта) закрывают тестировщики.
    • 0
      А разве кому-то Bootstrap обещает пуленепробиваемую верстку и кофе в постель? Это лишь инструмент для облегчения рутины и повод к созданию своего луна-парка с кефиром и поэтессами (как мне кажется поводом становится использование практически любого фрэймворка).
      Описанные вами проблемы не пользователя, а вашего не слишком удачного подхода к разработке.
      • 0
        Скажите, почему производители любой электроники отказывают в гарантии на устройство из-за любого вмешательства в его конструкцию? Чем сложный веб-сайт отличается от сложной электроники? Почему я должен предоставлять гарантию на работоспособность, если пользователь самовольно внёс какие-то изменения в мой сайт?
        • 0
          Производители электроники не откажут в гарантии если обновленная версия ПО внезапно привела к частичной утрате заявленного в спеках функционала.
          То же самое справедливо и в случае с «одиннадцатиклассницей», внезапно выбравшейся из очередной таблицы БД. Вы же не скажете клиенту «это все ваш MySQL, у меня в верстке все шикарно с 200 символами».
          • 0
            А, вы про это. Я упорно настаиваю на том, что задача выявления таких проблем — это задача QA. У профессиональных QA есть всегда набор кейсов вроде аномально длинного имени пользователя.
            Но выявление таких багов должно быть делом точечным — есть сценарии вроде «длинное имя пользователя», «длинное слово в названии товара» и именно их невоспроизводимость и должна проверяться на тестовом окружении. А пихать длинное слово во все текстовые ноды страницы и называть это тестированием — это, извините, профанация какая-то.
            • 0
              Хотите пуленепробиваемую верстку — пихайте во все ноды. Во всех остальных случаях делайте соглашения типа «вот в этой ноде должно быть не более 12 символов». Иначе баг становится сиротой на фоне выясняющих друг с другом его отцовство создателей.

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

              Ну и потом, речь ведь не о кардинальном смене воркфлоу, разметки или css-кода, увеличении временного бюджета задачи на 50%; в большинстве случаев всё сводится к градиентику или text-overflow: ellipsis. То есть, у разработчика учёт одиннадцатиклассниц занимает порядка 1% времени от задачи (1-5 минут), а поиск бага с дальнейшей игрой в футбол им — в сумме может достигать десятков минут, неприятные ощущения у пользователей и ухудшения отношений с коллегами по этому футболу.

              Можете называть меня QA специалистом, если это что-то упростит в вашем понимании. Для меня главное — результат, а не зоны ответственности.
        • 0
          Почему я должен предоставлять гарантию на работоспособность, если пользователь самовольно внёс какие-то изменения в мой сайт?

          Это называется «защита от дурака».
          Ваше право, конечно, предоставлять доступ к своему сайту «as is» и на любых условиях.
          Но бывают случаи, когда сайт приносит его владельцу деньги, и такие случаи нужно стараться учитывать.
          В том числе варианты, когда у пользователя:
          • Отключён JavaScript
          • Отключены картинки
          • Включён режим «Турбо», что может повлиять на качество картинок и на часть вёрстки
          • Стоит AdBlock или его параметры
          • Слабое зрение и он использует собственный набор CSS
          • и т. д.

          Посмотрите на Яндекс, например, без JavaScript, без картинок и с AdBlock и вы меня поймёте, что такое «сайт с гарантией».
          • 0
            Я стили отключил, сайт поломался.
            Он точно с гарантией?
  • +3
    Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.

    Кроме 2ГИС говорите?
    Осторожно картинка
    image
    • +1
      Хоть один человек проверил)
      Я намерено не правил эти баги, чтоб было видно, насколько на самом деле у нас лучше чем у других.
      • +3
        Похоже на отмазку
  • 0
    Я так и не понял в чем ценность этой статьи. Вы решили рассказать, что начали использовать регрессионное тестирование для js в своих проектах?
    Ну ок, только что в этом нового, интересного, неизвестного? Кажется, что профита от этой статьи ноль.

    Ну и да, попробуйте делать регрессионные тесты для css (like gemini, huxley, etc), кажется, что для ваших проблем это эффективней.
    • –1
      для верстки, без использования фреймворков
      • –1
        Забрать работу у машин и начать делать ее руками, да, кажется, что это прорыв.
  • –1
    Можно вопрос? (слегка оффтопик). Чем chai нравится больше других библиотек (should.js)?
    • –1
      Другими не пользовался, могу сравнить только с нодовским асертом — у него лучше вывод. Но есть и нюансы)
  • 0
    Одиннадцатиклассница на 2ГИС тоже не плохо смотрится…
    screencast.com/t/vwivKfIV
  • 0
    Вам привет от РЖД и Эха Москвы: img-fotki.yandex.ru/get/16115/7547815.3/0_ac466_49e39772_orig.png
    • 0
      АААААААА!
      Спасибо за слово)
  • 0
    Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.

    К сожалению ваш скрипт вставляет одиннадцатиклассницу в теги style и script. В таком случае сайты сделанные с учетом critical css ломаются вне зависимости от текста.

    Я набросал небольшое логическое продолжение этой статьи и добавил туда букмарклет, который не лезет в стили и скрипты.

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

Самое читаемое Разработка