Тестуємо верстку правильно

Makeup — інструмент для комфортного ручного регресійного тестування верстки
Що не так тестуванням верстки
Ми часто їм нехтуємо. Написання функціональних, інтеграційних і юніт-тестів давно стало повсюдною практикою. Верстці ми зазвичай приділяємо набагато менше часу.

Проблема тестування верстки в те, що тільки жива людина може сказати, добре зверстаний блок на сторінці чи ні. Тому найчастіше ми тестуємо HTML і CSS вручну: перевіряємо, як буде вести себе блок, якщо в ньому буде дуже багато (або дуже мало) тексту або дочірніх елементів; дивимося, щоб всі можливі варіанти відображення блоку виглядали коректно; пам'ятаємо про те, як блоки повинні адаптуватися до різним пристроям і дозволами екрану.

Як тестувати верстку правильно
Нам не треба вигадувати нічого нового. Ми можемо застосувати ті ж підходи, які використовуємо при написанні автотестів.

Спочатку потрібно подивитися на вимоги, дизайн. На на основі цього скласти список всіх значущих станів програми, які потрібно перевірити. Далі, справа за малим   перевірити кожен тест-кейс.

У статті розповім, як ми створили для себе Makeup, як змінили свій процес розробки інтерфейсів і як це спростило нам життя.

Makeup   графічний інтерфейс для швидкого і комфортного ручного регресійного тестування верстки, заснованої на методології BEM. Це інструмент, для якого ми готуємо тестові дані так, щоб можна було проініціалізувати будь-незалежний блок з різними даними і швидко подивитися його в всіх нас цікавлять станах.

Описаний підхід може допомогти, якщо на вашому проекті дотримуються 2 умови:

  •  вас є еталонні дизайн для всіх блоків, і  хочете, щоб ваш проект точно відповідав цьому дизайну;
  • ви дотримуєтеся BEM-методології в HTML CSS.
А тепер про все по порядку.

Як виміряти якість верстки
Перша версія Makeup (тоді у нього ще не було імені) виникла в файлі spec/index.html. На цій сторінці повторювались юніт-тести з всім модулям (читай: блокам) нашого застосування. Все було традиційно: ми ініціалізувати кожен модуль з різними наборами тестових даних і перевіряли тестами те, що нас цікавило.

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

У мережі можна знайти величезну кількість чек-листів на якість верстки. Перевірку багатьох пунктів з них можна легко доручити аналізатора коду. Але зазвичай ці чек-листи перевіряють якість роботи з непрямим або нерелевантних ознаками.

&Nbsp;великим рахунком, критеріїв якості верстки всього два:

  • відповідність макету: верстка повинна бути ідентична дизайну.
  • працездатність: верстка повинна відображатися в браузері користувача всіх пристроях, які нас цікавлять.
При недотриманні будь-якого з двох пунктів виконана робота не має ніякого сенсу.

Як перевірити відповідність макету
Порівняти верстку з вихідним макетом і знайти відмінності. Але це часом не так просто. Пам'ятаєте, в дитячих журналах були головоломки «знайди 10 відмінностей»?



Будь інженер миттєво запропонує очевидне рішення, як простіше знаходити відмінності. Достатньо накласти одне зображення на інше верхнє зображення зробити напівпрозорим.

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



Навіщо для цього спеціальний інструмент
Для реалізації подібної задумки не потрібен спеціальний інструмент. Якщо потрібно порівняти верстку з вихідним дизайном сторінки сайту, то такий підхід можна реалізувати прямо в браузері.

1. Додаємо картинку з макетом

<img src="index.png" width="1280" height="2000" id="psd">

2. Позиціонуємо поверх зверстаній сторінки

#psd {
/* Позиціонуємо макет */
position: absolute;
top: 0;
left: 50%;
margin: 0 0 0 -640px;

/* Робимо його напівпрозорим */
opacity: .5;

/* Залишаємо можливість взаємодії з елементами */
pointer-events: none;

/* Інвертуємо зображення у вашому улюбленому -webkit (-blink) браузері */
-webkit-filter: invert(100%);
}
body:hover #psd {
/* Ховаємо картинку при наведенні */
opacity: 0;
}

За таким принципом працює величезна кількість існуючих інструментів:

  • JavaScript-плагіни
    • Resemble.js
  • Розширення для браузера
    • PerfectPixel
    • 1px

При бажанні ви знайдете ще декілька десятків або сотень таких інструментів.

  ж проблема
Цей підхід застосуємо тільки в тому випадку, коли при розробці ми можемо побудувати однозначна відповідність між макетами і сторінками верстки.


На ми все частіше працюємо з складними веб-додатками. І зазвичай ми не використовуємо термін «сторінка». У звичних нам термінах веб-додаток з точки зору верстки складається з довільного набору BEM-блоків і  станів.



Стан блоку — це його кінцеве відображення при певному наборі елементів, модифікаторів і при певному вмісті. Іншими словами, кожен стан блоку — це один кейс його використання.

На практиці це означає, що якщо, наприклад, у вас на проекті всього 100 незалежних блоків, і для кожного з них передбачено всього 10 значимих кейсів використання, то вам доведеться пам'ятати про 1000 унікальних станів вашого додатка.

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

1000 станів — це дуже багато. Ні не в змозі утримати все це в голові. І тим більше бути впевненим в якості верстки кожного блоку.

Як я робив раніше
Раніше при розробці складних блоків з великою кількістю станів для порівняння верстки окремого блоку з дизайном я використовував неймовірно повільний спосіб.

  • ⌘ + Shift + Ctrl + 4 виділяємо область сторінки з блоком, робимо скріншот в буфер обміну
  • ⌘ + Tab переміщаємося в сусідню вкладку з Фотошопом
  • ⌘ + v вставляємо скріншот
  • ⌘ + 5 виставляємо шару прозорість 50%
  • v вибираємо інструмент Move Tool
  • Shift + Arr або Arr × n розсовуємо до тих пір, поки точно не сумісний з макетом
  • Delete
Після цього правимо CSS і повторюємо всю послідовність заново. Поки макет не стане ідеальним.

Цю послідовність можна навчитися виконувати по-справжньому швидко, але процес все одно буде займати величезну кількість часу. Але такий підхід ніколи не надасть впевненості при регресії або рефакторинге. Так і займатися такою нісенітницею не хочеться.

Як ми зробили ще один інструмент
Ми не знайшли інструмент, який б нам дозволив будь-який момент часу…

  • мати можливість швидко і комфортно перевірити відповідність блоку вихідним дизайн-макетів і продуктовим вимогам;
  • бути впевненим в те, що всі значущі кейси використання блоку працюють коректно;
  • при внесенні змін до блок просто і швидко перевірити, що всі попередні кейси використання не зламані;
  • проводити регрессионное тестування верстки;
  • мати оглядову карту проекту з точки зору верстки.
Тому ми вирішили зробити для себе Makeup.

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


На ілюстрації майже всі можливості Makeup. Це неймовірно простий інструмент.

Що потрібно для реалізації
  • Ресурси вашого застосування: шаблони (або просто HTML), стилів, JavaScript-код, графіку — все, що є у верстки.
  • Зображення з вихідним дизайном блоків в різних станах.
  • Конфігураційний файл, який покаже «Makeup», яким чином все перераховане можна зв'язати воєдино.


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

Наша команда майже повністю збирає конфігурацію автоматично на основі наявних тестових даних. Вручну залишається дописати тільки «заплатки» стилів, текстові фрагменти і посилання на документацію. На етапі складання програми формуються всі необхідні конфігураційні файли і створюється окремий порт, на якому запущений Makeup.



У нашій команді Makeup   основа розробки інтерфейсу програми. Ми активно використовуємо його на всіх етапах життя блоку.

  1. Розробка. При розробці блоку з нуля, потрібен оригінальний дизайн, продуктові вимоги та ізольована середа для розробки. Зручно, коли це виявляється під рукою в одному інтерфейсі.
  2. Код-рев'ю. Коли дивишся на чужу роботу, потрібно швидко побачити перелік змін; звірити результати з продуктовими вимогами і дизайном; перевірити працездатність всіх кейсів використання блоку.
  3. Рефакторинг. При рефакторинге існуючого блоку потрібно швидко побачити весь блок і всі його можливі стани. Іноді станів буває багато, і деякі з них зовсім не очевидні. Після внесення змін, важливо перевірити, що нічого не зламано.
При цьому треба віддавати собі звіт в те, що покластися на інструмент можна тільки в тому випадку, якщо описані нами тест-кейси використання забезпечують достатнє покриття. Тут працюють ті ж принципи, як і при написанні тестів.

Якщо своєчасно додавати всі необхідні тест-кейси і використовувати Makeup на всіх етапах розробки, можна спати спокійно   ніяких несподіваних неприємностей ваша верстка вам не принесе.

Як підібрати тест-кейси
У початку статті я використовував термін «значущі стану». Пора розповісти про те, як ми в роботі вибираємо значущі кейси та як намагаємося забезпечити гарне покриття для верстки.

Ми прийшли до висновку, що достатньо фіксувати 3 типу станів.

  • Стану, описані в дизайні.
    Якщо дизайнер підготував макет, який намалював блок 4 різних станах, нам потрібно описати всі ці стани для Makeup.
  • Стани, які викликали баг в минулого
    Якщо на проекті з'являється баг, пов'язаний з версткою, його недостатньо просто полагодити. Хорошим тоном вважається написати тест цей баг. Ми в цьому випадку ще зберігаємо в Makeup кейс, в якому вопроизводился баг. Тоді при рефакторинге блоку, коли розробник перевірить всі стани блоку, він може бути впевнений, що цей баг не відтворюється.
  • Екстремальні стани
    Екстремальними станами ми називаємо ті, в яких найчастіше ламається верстка: довгі тексти (які можуть ще й не містити пробілів), відсутність елементів у блоці і інші.
Можемо ми перестати тестувати верстку руками
Якщо нам важливо точне відповідність до оригінального дизайну, до жаль, немає. Але в наших силах зробити тестування верстки комфортним, швидким і надійним.

Тому ми зробили для себе простий і зручний інструмент. &Nbsp;великим рахунком він просто виводить ті дані, які ми самі зберігаємо в конфігураційних файлах блоків. Але незважаючи на уявну простоту, для нашої команди Makeup став основою робочого процесу розробки інтерфейсів. З його допомогою ми завжди знаємо про самопочутті проекту і на будь-який момент побачити повну картинку проекту з точки зору верстки.

А як тестуєте верстку ви?

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.