От автора: когда и как использовать разные варианты тестирования кода front end? Множество разработчиков до сих пор не умеют тестировать front end код. Учитывая постоянное усложнение front end разработки и то, что разработчики ответственны за стабильность, как никогда ранее, front end тестирование должно войти у вас в привычку. Мы разберем различные варианты тестирования и объясним, в каких ситуациях их лучше всего применять.
Front end тестирование – общий термин, покрывающий разные стратегии автоматизированного тестирования. Некоторые из них, как например юнит тесты и интеграционное тестирование, уже долгие годы считаются хорошей практикой среди back end разработчиков. Другие стратегии новее и вытекают из изменений, в которые превратилась front end и back end разработка сейчас.
К концу статьи вы точно будете знать, какие стратегии тестирования лучше всего подходят вашей команде и коду. Примеры в статье будут написаны на фреймворке Jasmine, но правила и процесс схожи с большинством фреймворков для тестирования.
1. Юнит тестирование
Юнит тестирование – один из ветеранов тестирования – самый нижний уровень тестирования. Его задача проверять, что маленькие кусочки кода (юниты) функционируют независимо и как ожидается.
Представьте, у вас есть набор лего для создания дома. Перед строительством дома вы проверяете, что в наборе есть все части (5 красных квадратов, 3 желтых прямоугольника). Юнит тесты проверяют, что отдельные кусочки кода – валидация полей и вычисления – работают, как предполагается, еще до создания большой функции.
Мантра «делай хорошо что-то одно» помогает думать о юнит тестах. Если у вас есть кусок кода с единственной функциональностью, для него необходимо написать юнит тест.
Разберем код ниже. Это юнит тест простого калькулятора:
|
1 2 3 4 5 6 7 |
describe("Calculator Operations", function () { it("Should add two numbers", function () { Calculator.init(); var result = Calculator.addNumbers(7,3); expect(result).toBe(10); }); }); |
В приложении Calculator необходимо, чтобы вычисления всегда функционировали независимо. В коде выше мы проверяем, что мы всегда можем складывать точно два числа.
Сперва мы описываем серию необходимых тестов с помощью Jasmine describe. Так создается тест сьют – группа тестов для определенной области приложения. Для приложения калькулятор мы будем группировать все тесты вычислений в свой сьют.
Сьюты хорошо подходят не только для организации кода, они также позволяют запускать целые сьюты тестов. Если вы работаете над новой функцией для приложения, вы не хотите запускать все тесты при разработке, так как это отнимет много времени. Отдельное тестирование сьютов позволяет быстрее писать код.
Далее мы пишем сами тесты. В функции it мы пишем функцию или кусок функциональности для тестирования. В нашем примере проверяется функция сложения, поэтому мы будем запускать сценарии, подтверждающие правильность работы.
Далее идут проверки в тесте – именно здесь мы проверяем наш код на ожидаемый результат. Инициализируется калькулятор и запускается функция addNumbers с двумя параметрами для сложения. Значение выполнения сложения мы помещаем в result и сравниваем его на равенство с ожидаемым числом (в нашем случае 10).
Если addNumbers вернет другое число, наш тест провалится. Мы напишем подобные тесты для других вычислений – вычитание, умножение и т.д.
2. Приемочные тесты
Юнит тесты – это проверка всех деталей лего, а приемочные тесты – это проверка всех этапов строительства на завершенность. Если есть все детали, это не значит, что инструкции выполнимы и позволят построить конечную модель.
Приемочные тесты проводятся на запущенном приложении и проверяют, чтобы спроектированные действия, пользовательский ввод и поток были завершенными и правильно функционировали.
Если функция addNumbers нашего приложения возвращает правильное число, это не значит, что интерфейс калькулятора будет работать точно, как ожидается. Что если кнопки неактивны, или результат вычислений не отображается? Приемочные тесты помогают ответить на эти вопросы.
|
1 2 3 4 5 6 7 8 9 |
describe("Sign Up Failure state", function () { it("Shouldn't allow signup with invalid information", function () { var page = visit("/home"); page.fill_in("input[name='email']", "Not An Email"); page.click("button[type=submit]"); page.click("button[type=submit]"); expect(page.find("#signupError").hasClass("hidden")).toBeFalsy(); }); }); |
Структуры похожа на юнит тест: определяется сьют с помощью describe, далее пишется тест внутри функции it, после чего выполняется код и проверяется результат.
Здесь не проверяются определенные функции и значения, здесь мы проверяем правильность работы сценариев (сценарий регистрации) при неправильном заполнении. В коде выше выполняются более мелкие действия, такие как проверки формы, которые можно вынести в юнит тесты, а также любые обработки для того, что отображает наше состояние об ошибке (элементс ID signupError).
Приемочные тесты – замечательный способ проверить ключевые сценарии на правильность работы. Также легко можно добавить тесты по крайним случаям и помочь QA командам найти их в приложении.
Прежде чем принимать решение, что учитывать в приемочном тестировании, послушайте пользователей. Как пользователи взаимодействуют с вашим сайтом, что ожидается в этом взаимодействии? В этом отличие от юнит тестирования, которое лучше подходит для проверки требований функций (требования валидации полей).
3. Визуальный регресс
Как было упомянуто в начале, некоторые типы тестирования уникальны для front end. Первый такой тип – визуальный регресс. Он не тестирует код, а сравнивает отрендереный результат кода –интерфейс – с рендер версией приложения в production, staging и pre-changed.
Делается это путем сравнения скриншотов, снятых с браузера без оболочки (браузер с сервера). Далее инструменты по сравнению изображений находят мельчайшие различия между двумя кадрами.
В PhantomCSS ваши тесты указывают место, куда необходимо переместиться, снять скриншот, а фреймворк показывает различия.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
casper.start("/home").then(function(){ // Initial state of form phantomcss.screenshot("#signUpForm", "sign up form"); // Hit the sign up button (should trigger error) casper.click("button#signUp"); // Take a screenshot of the UI component phantomcss.screenshot("#signUpForm", "sign up form error"); // Fill in form by name attributes & submit casper.fill("#signUpForm", { name: "Alicia Sedlock", email: "alicia@example.com" }, true); // Take a second screenshot of success state phantomcss.screenshot("#signUpForm", "sign up form success"); }); |
Этот фреймворк визуального регресса иллюстрирует деревья решений в приложении, увеличивая сложность тех деревьев, которые пока не разрабатываются.
В отличие от юнит тестов и приемочного тестирования, визуальный регресс мало полезен при разработке чего-то нового. В фазе активной разработки ваш UI будет быстро претерпевать значительные изменения, поэтому приберегите эти тесты к моменту, когда интерфейс придет к визуально законченному состоянию. Поэтому тесты на визуальный регресс нужно писать в последнюю очередь.
На данный момент множество инструментов для визуального регресса требуют ручной настройки. Возможно, вам придется запустить снятие скриншотов еще до начала разработки в своей ветке, или же вручную обновлять скриншоты в исходных условиях при внесении изменений в интерфейс.
Все дело в характере разработки – изменения в UI могут быть и ожидаемыми, но тесты знают только «да, тут так же» и «нет, это отличается». Тем не менее, хотя визуальный регресс и является самой больной точкой в приложении, этот подход может сэкономить время и усилия вашей команде, по сравнению с постоянными фиксами регрессий.
4. Тесты доступности и производительности
Культура и знание front end тестирования растут, как и наши способности тестировать различные аспекты экосистемы. Наша технокультура большое значение уделяет доступности и производительности, их интеграция в тестовые сьюты поможет убедиться, что концепции все еще в приоритете.
Если у вас проблемы с соблюдением бюджета производительности или стандартов доступности, то вот вам способ держать эти требования на первом месте в головах людей.
Обе проверки можно интегрировать в рабочий процесс как с помощью билд инструментов типа Grunt и Gulp, или интегрировать полу-вручную через терминал. Для бюджетов производительности есть инструмент grunt-perfbudget, позволяющий прогонять сайт через WebPageTest автоматически через заданную задачу.
Если же вы не используете таск раннеры, вы можете подключить perfbudget как независимый NPM модуль и запускать тесты вручную.
Как запускать через терминал:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
perfbudget --url //www.aliciability.com --key [WebPageTest API Key] --SpeedIndex 2000 --render 400 And likewise, setting up through Grunt: perfbudget: { default: { options: { url: '//aliciability.com', key: 'WebPageTest API Key', budget: { SpeedIndex: '2000', render: '400' } } } } [...] grunt.registerTask('default', ['jshint', 'perfbudget']); |
То же самое можно сделать для тестирования доступности. Для Pa11y вы можете запустить как команду pa11y в браузере для вывода, так и создать задачу для автоматизации этого шага. В терминале:
|
1 2 3 4 5 6 7 8 9 10 |
pa11y aliciability.com // As a JavaScript command after NPM install var pa11y = require('pa11y'); // require pa11y var test = pa11y(); // get pa11y ready to set test.run('aliciability.com', function (error, results) { // Log our parse your results }); |
Большую часть инструментов можно использовать сразу после подключения, но в них также можно настроить способ запуска тестов. Например, можно заставить тесты игнорировать определенные WCAG стандарты.
Многие разработчики уже используют front end тестирование у себя в коде, другие же до сих пор сомневаются в выгоде. Если вы думаете о включении front end тестирования в рабочий процесс, вам следует учесть следующие моменты:
1. Начните с известных болевых мест
Если вы замечаете, что в одних и тех же местах кода постоянно выскакивают одни и те же баги, то было бы неплохо подумать, а не поможет ли здесь тестирование.
Если у вас регрессия кода и уже невозможно написать юнит тесты, попробуйте написать приемочные тесты, чтобы они покрывали сценарии высокого уровня. Вы получите базовые тесты, с которыми можно экспериментировать. Если количество регрессий функции снижается после написания тестов, вы можете найти других разработчиков, более склонных к написанию тестов в будущем.
2. Сделайте тестирование частью рабочего процесса
Чтобы разработчики говорили только правду о написании тестов, нужно чтобы все чувствовали ответственность. Возможно разговоры о тестах станут частью процесса ревью кода: спросите, почему не написаны тесты, или укажите области, где они бы пригодились.
Ведя открытый диалог по тестам, вы можете найти способ замотивировть команду писать их. Используйте сервисы непрерывной интеграции для автоматического прогона тест сьютов на dev ветках – это повысит прозрачность тестов.
3. Не делайте все сразу
Если команда до этого не была знакома с тестированием, то принятие всех методик сразу перегрузит людей. Если вы начинаете с нуля, то вам и не нужны все методы. Например, если у вас не так много клиентской логики и пользовательского взаимодействия, возможно, визуальные регресс покроет большую часть приложения.
Внедрение типов тестирования по одному даст вашей команде возможность понять, как тестировать и корректировать любые сложные части процесса.
4. Пересмотр и ревью
Тестирование, как и другой код, требует постоянного пересмотра для проверки, что текущая реализация отражает действительность. Помните, что тест сьют, который никто не запускал – это тест сьют, который не существует.
Но если вы уделите время и усилия стратегии тестирования, то время, сэкономленное на правках регрессий, можно будет потратить на разработку новых функций или улучшение существующего кода.
Автор: Alicia Sedlock
Источник: //www.creativebloq.com/
Редакция: Команда webformyself.
