Работа с чужим кодом — одна из частых и сложных проблем, с которыми я сталкивался в своей работе.
Почти в каждом случае предыдущий разработчик писал код не так, как я хотел.
И такие ситуации возникают довольно часто.
Не у каждого клиента есть необходимость, желание или бюджет переписывать весь проект с нуля.
Недавно наша команда получила код от нового клиента, и после небольшого рефакторинга перед нами стояла задача быстро перейти к реализации нового функционала.
Мы знали, что можем улучшить код, перенеся клиентские стили в Sass, что облегчит нам поддержку в будущем.
С другой стороны, мы могли бы просто переименовать файлы и включить их в один предварительно скомпилированный CSS (без какого-либо рефакторинга).
Но для улучшения кода неплохо было бы провести рефакторинг стилей.
Эта работа дороже, но окупится в будущем.
И, самое главное, это позволило бы нам работать быстрее, с большей уверенностью, что мы ничего не сломаем.
Раньше я рассматривал такие изменения, как большие риски .
В конце концов, C в CSS — это каскадирование, где порядок абсолютно важен.
Реструктуризация нескольких стилей означает изменение порядка, что, естественно, сопряжено с высоким риском что-то сломать.
В результате нам приходилось либо дополнительно тестировать наши изменения вручную, либо выставлять заказчику такой счет, который сразу отпугивал бы его своей стоимостью.
На этот раз было решено визуально построить набор регрессионных тестов.
Этот тип теста в последнее время начал набирать популярность, и не зря.
По сути, это серия тестов, которые выполняются по всему сайту и делают снимки экрана различных компонентов, сравнивают их с базовыми снимками экрана и предупреждают вас об изменениях.
Это может показаться немного нелогичным.
Мы меняем CSS, потому что сами хотим, чтобы наш интерфейс выглядел по-другому.
Проще говоря, зачем нам создавать какой-то процесс, который уведомляет нас каждый раз, когда мы что-то ломаем, каждый раз, когда мы что-то меняем в наших стилях? Если вы меняете стили клиента или работаете в команде, довольно легко внести изменения в CSS, которые, по вашему мнению, затрагивают только один компонент. Лишь позже вы обнаружите, что ваши изменения что-то сломали на другой странице.
Чтобы понять полезность тестов визуальной регрессии, важно понять, в чем у человека все плохо.
Человек против машины
На самом деле человек действительно очень плохо различает изменения зрительных образов.Это связано с его физиологическими и психологическими особенностями.
На основе этого даже есть игра.
Помните картинки из серии «Найди отличия»? 
Существует ряд реальных проблем, которые психологи пытаются решить.
С другой стороны, учёные уже накопили много знаний в этой области, которые применимы и к веб-разработке.
Одним из важных явлений, которые следует здесь учитывать, является слепота к изменениям.
Слепота к переменам
Исследования в этой области начались еще в 1970 году.В 1996 году Джордж Макконки и Кристофер Карри из Университета Урбана-Шампейн, штат Иллинойс, провели серию исследований, вызвавших значительный интерес к этой области.
Слепота к изменениям – это дефицит восприятия.
Эксперименты показали, что крупные изменения в поле зрения часто остаются незамеченными, независимо от того, происходят ли они постепенно, резкими короткими всплесками или появляются неожиданно через разные промежутки времени.
Это не связано с каким-то визуальным дефектом, это чистая психология.
В исследовании McConkie & Currie выяснилось, что в некоторых случаях пятая часть всех изменений может остаться незамеченной.
Это видео — прекрасный пример того, как много изменений можно упустить, если не сосредоточиться на них.
Инструменты
Существует широкий набор инструментов для создания тестов.Я всегда рекомендую сравнивать инструменты и определять, какие из них лучше всего подходят для конкретных задач.
В качестве инструмента визуального регрессионного тестирования я выбрал PhantomCSS. Для этого было несколько причин.
Во-первых, у него относительно большое и активное сообщество на GitHub. Когда дело касается открытого исходного кода, я всегда слежу за тем, чтобы инструмент или библиотека активно развивались.
Работа с замороженными проектами с открытым исходным кодом может быстро стать обузой.
Во-вторых, у PhantomCSS есть удобный Плагин Grunt , что позволяет ему легко вписаться в мой существующий процесс разработки.
Ядро PhantomCSS представляет собой комбинацию трех ключевых компонентов:
- ФантомJS или SlimerJS - примитивный браузер.
PhantomJS — это примитивная версия WebKit, а Slimer — движок Gecko, используемый в Firefox.
- КасперJS — Casper — это утилита JavaScript для навигации и тестирования.
Это позволяет нам определить набор действий, которые происходят внутри нашего примитивного браузера.
- НапоминатьJS — это библиотека JavaScript/HTML5 для сравнения изображений.
Он будет искать различия между результатами наших тестов и базовыми результатами и предупреждать о различиях между ними.
Выполнение
Теперь, когда мы поняли, что к чему, давайте пройдемся по всем этапам реализации визуального регрессионного тестирования.
Настройка Гранта
Во-первых, для запуска наших тестов нам понадобится Grunt, поэтому убедитесь, что он установлен.Для этого в командной строке введите
Затем откройте Gruntfile проекта, загрузите задачу PhantomCSS и добавьте ее в grunt.initConfig():$ cd /path/to/your-site
grunt.loadNpmTasks('@micahgodbolt/grunt-phantomcss');
grunt.initConfig({
phantomcss: {
desktop: {
options: {
screenshots: 'baselines/desktop',
results: 'results/desktop',
viewportSize: [1280, 800]
},
src: [
'tests/phantomcss/start.js',
'tests/phantomcss/*-test.js'
]
}
}
});
Тестирование на различных устройствах
мне нравится использовать Сасс MQ для работы с различными устройствами.Дополнительным преимуществом этого подхода является возврат списка всех моих устройств, который я могу легко использовать для своих тестов.
С PhantomCSS вы сможете контролировать ширину браузера в рамках своего теста, но я предпочитаю абстрагироваться от своих тестов, чтобы придать им большую гибкость.
Поэтому я делегирую эту задачу Гранту.
С помощью grunt-phantomcss мы можем определить набор тестов для запуска на разных устройствах и, в качестве дополнительного бонуса, настроить их сохранение в разных папках.
Чтобы сохранить семантику и порядок, я стараюсь называть подзадачи в соответствии с устройствами в Sass MQ.
Пример: grunt.initConfig( {
pkg: grunt.file.readJSON('package.json'),
phantomcss: {
desktop: {
options: {
screenshots: 'baselines/desktop',
results: 'results/desktop',
viewportSize: [1024, 768]
},
src: [
'tests/phantomcss/start.js',
'tests/phantomcss/*-test.js'
]
},
mobile: {
options: {
screenshots: 'baselines/mobile',
results: 'results/mobile',
viewportSize: [320, 480]
},
src: [
'tests/phantomcss/start.js',
'test/phantomcss/*-test.js'
]
}
}
});
Мы провели один и тот же набор тестов, который работает на разных устройствах и сохраняет результаты в соответствующих каталогах.
Настройка тестов
В определении Grunt вы можете видеть, что мы запускаем процесс из файлаtests/phantomcss/start.js. Этот файл запускает Casper (который затем запускает тестовые скрипты и наш браузер) и выглядит следующим образом: phantom.casperTest = true;
casper.start();
Теперь вернемся к нашему Гранту.
Вы, наверное, уже заметили, что мы запускаем все файлы в каталоге `tests/phantomcss/`, которые заканчиваются на `-test.js`.
Grunt просматривает каждый из этих файлов в алфавитном порядке.
Вы можете сами решить, как организовать тестовые файлы.
Лично я создаю тестовый файл для каждого компонента своего приложения.
Написание первого теста
После того как вы реализовали файл `start.js`, пришло время написать первый тест. Мы назовем этот файл «header-test.js».
casper.thenOpen(' http://mysite.dev/ ')
.
then(function() { phantomcss.screenshot('.
site-header', 'site-header');
});
В начале файла мы говорим Casper открыть корневой URL-адрес, а затем сделать снимок всего элемента .
site-header. Второй параметр — название скриншота.
Я предпочитаю называть скриншоты по имени компонента, который они захватывают. Это значительно упрощает понимание результатов и обмен ими с товарищами по команде.
Для простейшего примера этого теста будет достаточно.
Однако мы можем построить более надежный тест, охватывающий фактическое состояние элемента, страницы и приложения в целом.
Взаимодействие сценариев
Casper позволяет автоматизировать взаимодействия, происходящие во время работы браузера PhantomCSS. Например, мы могли бы написать проверку состояния кнопки при наведении мыши следующим образом: casper.then(function() {
this.mouse.move('.
button');
phantomcss.screenshot('.
button');
});
Вы также можете проверить состояния входа/выхода.
В файле start.js мы можем написать функцию, которая будет заполнять форму входа в WordPress после запуска экземпляра Casper. casper.start(' http://default.wordpress.dev/wp-admin/ ', function() {
this.fill('form#loginform', {
'log': 'admin',
'pwd': 'password'
}, true);
this.click('#wp-submit');
console.log('Logging in.');
});
Вы можете заметить, что мы делаем это в casper.start() вместо того, чтобы делать это внутри каждого отдельного теста.
Настройка сеанса внутри casper.start() в файле start.js делает сеанс доступным из других файлов с вашими тестами, поскольку casper.start() всегда запускается первым.
Для получения дополнительной информации я рекомендую взглянуть на документацию Casper.
Запуск тестов
Теперь, когда мы реализовали набор тестов, пришло время их запустить.В командной строке запустите `$grunt phantomcss`.
PhantomCSS автоматически сделает снимки экрана при первом запуске и установит их в качестве базового уровня для сравнения с будущими результатами.
Если тест не пройден, PhantomCSS сохранит три разных снимка экрана в настроенной папке и назовет файлы «.
diff.png» и «.
fail.png».
Например, мы изменили размер шрифта текста на одной странице, но случайно уменьшили размер шрифта на другой.
PhantomCSS сделает скриншоты для сравнения: 
Проблемы
Конечно, создание набора тестов визуальной регрессии не лишено проблем.Две основные проблемы, с которыми пришлось столкнуться, — это динамический контент и распределение тестов внутри команды.
Динамический контент
Первый вопрос — как обращаться с динамическим контентом.Набор тестов просматривает каждую страницу, делает снимки экрана и сравнивает их.
Если содержимое страницы менялось динамически, тест не сможет это обнаружить.
Если вы работаете в команде, изменения всегда будут тестироваться в вашей локальной среде.
Тестирование в одной общей среде не всегда решает проблему, поскольку содержимое там все равно может измениться, например, если на странице имеется случайный набор связанных статей.
Для решения этой проблемы есть два подхода, которые мне нравятся.
Первый подход, который мне больше всего нравится, — использовать JavaScript для замены содержимого внутри тестируемых элементов.
Поскольку эти тесты не будут развернуты на рабочем сервере, вам не придется беспокоиться об уязвимостях XSS. Итак, прежде чем сделать снимок экрана, я использую в своих тестах `.
html()`, чтобы заменить динамический контакт статическим, который берется из объекта JSON, который я включил в свой репозиторий.
Второй подход заключается в использовании инструмента под названием Голограмма или мдксс , который позволит вам использовать комментарии CSS для создания автоматически генерируемых стилей.
Этот подход вносит большие изменения в рабочий процесс, который отнимает больше времени и денег, но имеет дополнительное преимущество, заключающееся в создании превосходной документации для интерфейсных веб-компонентов.
Распределение тестов внутри команды
Вторая серьезная проблема, с которой я столкнулся при регрессионном тестировании, заключалась в том, как лучше всего распределить эти тесты среди инженерной команды.До сих пор в наших тестах мы жестко запрограммировали тестовый URL-адрес, и это вызовет проблемы при работе в команде, поскольку один и тот же URL-адрес не может использоваться всеми программистами для локального тестирования.
Чтобы решить эту проблему, мы зарегистрировали нашу задачу `$grunt test`, которая принимает параметр `--url`, который затем сохраняется в файл локально с помощью grunt.log. // All a variable to be passed, eg. --url= http://test.dev
var localURL = grunt.option( 'url' );
/**
* Register a custom task to save the local URL, which is then read by the PhantomCSS test file.
* This file is saved so that "grunt test" can then be run in the future without passing your local URL each time.
*
* Note: Make sure test/visual/.
local_url is added to your .
gitignore * * Props to Zack Rothauser for this approach. */ grunt.registerTask('test', 'Runs PhantomCSS and stores the --url parameter', function() { if (localURL) { grunt.log.writeln( 'Local URL: ' + localURL ); grunt.file.write( 'test/visual/.
local_url', localURL );
}
grunt.task.run(['phantomcss']);
});
Затем в начале тестового файла пишем: var fs = require('fs'), siteURL;
try {
siteURL = fs.read( 'test/visual/.
local_url' );
} catch(err) {
siteURL = (typeof siteURL === 'undefined') ? ' http://local.wordpress.dev ' : siteURL;
}
casper.thenOpen(siteURL + '/path/to/template');
При запуске ваши тесты будут просматривать файл `.
local_url`, но если файл не существует, то будет использоваться значение по умолчанию ` http://local.wordpress.dev `.
Окончательно
Визуальное регрессионное тестирование может принести много преимуществ вашим проектам.Спринты и непрерывная интеграция все чаще используются разработчиками.
Визуальное регрессионное тестирование также отлично подходит для работы с людьми над проектами с открытым исходным кодом.
Фактически, проект WordPress работает над библиотека шаблонов со встроенным пакетом регрессионного тестирования.
Этот набор тестов обеспечивает основу, которая позволяет проекту WordPress уверенно двигаться вперед и реализовывать планы рефакторинга стилей.
Альтернативы
PhantomCSS — не единственный инструмент. Я выбрал его просто потому, что считал, что он лучше всего подойдет для целей нашей команды.Если вас интересует визуальное регрессионное тестирование, но вам не нравится PhantomCSS, я рекомендую взглянуть на следующие инструменты:
Теги: #регрессионное тестирование #CSS #JavaScript #тестирование ИТ-систем #CSS #JavaScript #тестирование веб-сервисов-
6 Способов Убить Agile
19 Oct, 24 -
Web 2.0 Для Построения Генеалогических Древ
19 Oct, 24 -
Колышки №40
19 Oct, 24 -
Вежливость – Это Унижение
19 Oct, 24
