Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

На картинке этой статьи вы видите прекрасный фронтэнд. Возможно, это не тот "фронтэнд", которого вы ожидали. Это фронтэнд Фольксваген Карманн Гиа 1974 года выпуска. Карманн Гиа славился, как "Порше для бедняков". Это очень необычная машина. По сути это совместный проект Вильгельма Карманна, немецкого производителя автомобилей, и Каррозцерии Гиа, итальянского автодизайнера. Гиа разработал произведение искусства – корпус, а Карманн поставил его на испытанную надежную платформу классического "Фольксваген Жук". Когда машину увидели директора Фольксваген, они не могли не разрешить массовое производство.

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

Хорошее качество, дизайн и опыт – неотъемлемые аспекты фронтэнда, неважно, для классических автомобилей или для Web. В этой статье я поделюсь семью основными тенденциями, которые я наблюдаю в тестировании фронтэнда. В этом мире происходит масса клевых вещей, но держите в уме основной момент: инструменты и технологии могут меняться, но базовые принципы тестирования остаются теми же. Тестирование – это взаимодействие плюс верификация. Тесты вскрывают истину о нашем коде и наших фичах. Мы тестируем в ходе разработки, чтобы получить быструю обратную связь для исправлений и улучшений. Все тренды, о которых я буду говорить, базируются на этих принципах. При хорошем тестировании вы убедитесь, что ваши приложения визуально идеальны, прямо как… сами знаете, что.

#1. End-to-end тестирование

Наш первый тренд: end-to-end тестирование становится трехсторонним сражением. Поясню: когда я говорю про "end-to-end тестирование", то подразумеваю автоматизацию черного ящика, взаимодействующую с рабочим веб-приложением в активном браузере.

Исторически самый популярный инструмент браузерной автоматизации – это Selenium. Проекту уже больше десяти лет, а протокол WebDriver – это стандарт W3C. У него открытый исходный код, открытые стандарты и открытое управление. У Selenium WebDriver есть биндинги для C#, Java, JavaScript, Ruby, PHP и Python. Проект также содержит Selenium IDE, инструмент записи и воспроизведения, и Selenium Grid, масштабируемый кластер для кросс-браузерного тестирования. Selenium жив-здоров и только что выпустил четвертую версию.

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

Cypress стал ответом на недостатки Selenium. Он создавался, как современный фреймворк с отличным опытом разработки, и всего за несколько лет быстро стал любимым инструментом тестирования у разработчиков фронтэнда. Тесты Cypress запускаются в браузере бок о бок с тестируемым приложением. Синтаксис предельно лаконичен. Имеются автоматические ожидания, что снижает нестабильность тестов. Есть визуальная трассировка. Есть вызовы API. Он симпатичный. И он отъел большой кусок от рыночной доли Selenium.

Cypress, однако, не идеален. Поддержка браузеров ограничена браузерами на основе Chromium и Firefox. Cypress также поддерживает только JavaScript, отсекая ряд сообществ. Хоть у него и открытый исходный код, он не следует открытым стандартам или принципам открытого управления, как Selenium. И, к сожалению, производительность у Cypress низкая – одни и те же тесты работают в нем медленнее, чем в Selenium.

Встречайте Playwright, новый тест-фреймворк с открытым исходным кодом от Microsoft. Playwright – духовный последователь Puppeteer. Он может похвалиться широкой поддержкой браузеров и языков, как Selenium, и утонченным опытом разработки, как Cypress. Там даже есть генератор кода, помогающий в создании тестов. К тому же Playwright – это быстро: в несколько раз быстрее Selenium и Cypress.

Playwright все еще, однако, новичок, и пока не оставил такой след, как другие инструменты. Некоторых может настораживать, что он использует браузерные проекты, а не стоковые браузеры. Меж тем он быстро растет, и может серьезно претендовать на первенство. В недавних битвах кода Applitools Let the Code Speak Playwright ловко обошел как Selenium, так и Cypress.

Сравнение Selenium, Cypress и Playwright

Selenium, Cypress, и Playwright сейчас, безусловно, "большая тройка" инструментов браузерного автоматизированного тестирования. Стоит также отметить четвертого игрока - WebdriverIO. WebdriverIO – это инструмент на основе JavaScript, который может использовать WebDriver или протоколы дебага. У него очень большая пользовательская база, но он ограничен JavaScript и не так велик, как Cypress. Есть и другие инструменты. Puppeteer все еще очень популярен, но больше используется для поисковых роботов, а не для тестирования. Protractor, когда-то разработанный командой Angular, сейчас устарел.

Все это достойные для работы инструменты (кроме Protractor). Они справятся с любым вашим веб-приложением. Если вы хотите узнать о них больше, в Test Automation University есть курсы по каждому из них.

#2. Компонентное тестирование

End-to-end тестирование – не единственный тип тестирования, которым может или должна заниматься команда. Компонентное тестирование набирает популярность, так как ее набирают компоненты! Многие команды нынче создают библиотеки компонентов коллективного доступа, чтобы обеспечить единство веб-дизайна и избежать дупликации кода. Каждый компонент похож на "юнит пользовательского интерфейса". Они упрощают не только разработку, но и тестирование.

Компонентное тестирование отличается от юнит-тестирования. Юнит-тест напрямую взаимодействует с кодом. Он вызывает функцию или метод и проверяет результаты их работы. Так как компоненты имманентно визуальны, они нуждаются в рендере браузером для грамотного тестирования. Они могут подразумевать множество поведений, и даже производить вызовы API. Их, однако, можно тестировать в изоляции от других компонентов, поэтому на индивидуальном уровне им не нужны полноценные end-to-end тесты. Поэтому с точки зрения фронтэнда компонентное тестирование – это новое интеграционное тестирование.

Storybook – очень популярный инструмент для создания и тестирования компонентов в изоляции. В Storybook у каждого компонента есть набор стори, которые описывают внешний вид и поведение компонента. Разрабатывая компоненты, можно рендерить их в визуализаторе Storybook. Затем их можно вручную протестировать, взаимодействуя с ними или меняя их настройки. Applitools также предоставляет SDK для автоматического запуска визуальных тестов на основе библиотеки Storybook.

Визуализатор Storybook:

В игру тестирования компонентов вступает также и Cypress. 1 июня 2022 года Cypress выпустил десятую версию, включающую поддержку компонентного тестирования. Это огромный шаг вперед. Ранее людям приходилось на скорую руку мастерить собственный фреймворк для тестирования компонентов, обычно в форме расширения проекта юнит-тестирования или end-to-end. Многие решения просто запускали автоматизированные тесты компонентов чисто как Node.js-процессы без какого-либо участия браузера. Теперь Cypress дает возможность естественным образом проверять поведения компонентов по отдельности, но визуально.

Люблю эту цитату Cypress про их подход к компонентному тестированию:

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

https://www.cypress.io/blog/2022/06/01/cypress-10-release/

В этой цитате есть очень важный момент. Огромное количество автоматизированных тестов не способны вести себя в приложениях, как реальные пользователи. Они зависят от штук вроде ID, селекторов CSS и XPath. Они минимально проверяют внешний вид элементов или текста. Страница может быть полностью сломана, однако автотесты могут продолжать срабатывать.

#3. Визуальное тестирование

Нам нужно лучшее от обоих миров: простота и чувствительность ручного тестирования со скоростью и масштабируемостью автоматизированного тестирования. Это исторически болезненный баланс. Большинство команд мучаются решениями, что автоматизировать, что проверять вручную, а что пропустить. Думаю, что есть грандиозная возможность ликвидировать этот пробел. Современные инструменты должны помогать нам автоматизировать человеческую чувствительность, а не просто провоцировать события на странице.

Поэтому визуальное тестирование стало незаменимым для тестирования фронтэнда. Веб-приложения – это визуальный контакт. Визуализация – это ДНК пользовательского опыта. Одной лишь функциональности недостаточно. Пользователи ожидают вау-эффекта. Как создатели приложений, мы должны убедиться, что эти жизненно важные визуальные аспекты протестированы. Боже упаси, если отсутствует кнопка или перекосило CSS. А так как мы живем в мире непрерывной разработки и поставки, нам нужны непрерывные и масштабируемые визуальные контрольные точки. Глаза живого человека – это чересчур медленно.

К примеру, у меня может быть страница авторизации, у которой есть оригинальная версия (слева) и измененная (справа):

Инструменты визуального тестирования предупреждают вас о значимых изменениях и упрощают сравнение версий бок о бок. Они отлавливают то, что вы можете пропустить. К тому же они запускаются точно так же, как любой другой набор автотестов. В прошлом такое тестирование было нелегкой задачей, так как инструменты просто проводили попиксельные сверки, генерирующие много шума из небольших изменений и различий в окружениях. Теперь при помощи таких инструментов, как Applitools Visual AI, визуальные сравнения точно указывают на значимые перемены.

Современная автоматизация должна проверять внешний вид. Традиционные скрипты взаимодействуют только с базовым скелетом страницы. Можно сломать верстку и удалить все стили, как тут, и с хорошим шансом традиционный автотест продолжит срабатывать:

(та же страница, что и ранее, но без стилей CSS)

При помощи техник визуального тестирования можно также пересмотреть свой подход к кроссбраузерному и кроссплатформенному тестированию. Вместо того, чтобы прогонять полный набор тестов в каждой нужной конфигурации браузера, можно прогнать их один раз а затем переотрисовать визуальные снапшоты для разных браузеров, проверяя внешний вид. Это можно сделать даже для браузеров, которые исходно не поддерживаются тест-фреймворком! К примеру, используя платформу вроде Applitools Ultrafast Test Cloud, можно запускать тесты Cypress в Electron на CI, а затем выполнить визуальные проверки в облаке для Safari и Internet Explorer, помимо прочих браузеров. Этот стиль кроссплатформенного тестирования быстрее, надежнее и дешевле традиционных подходов.

#4. Тестирование производительности

Функциональность – не единственный значимый аспект качества. Производительность может решить судьбу пользовательского опыта. Большинство людей ожидает, что любая страница загрузится за пару секунд максимум. В 2016 году Google обнаружил, что половина посетителей покидает сайт, если он грузится долее трех секунд. Как индустрия, мы многое сделали для ускорения работы фронтэнда. Современные техники вроде рендера на стороне сервера, гидратации и снижения раздувания нацелены на улучшение времени ответа. Важно тестировать производительность страниц, дабы убедиться, что с опытом пользователей все будет в порядке.

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

Самый простой подход – напрямую из браузера. Любой сайт можно профилировать с помощью Chrome DevTools. Просто кликните на странице правой клавишей, выберите "Исследовать" и переключитесь на вкладку "Производительность". Затем запустите профайлер и начните взаимодействовать со страницей. Chrome DevTools будет фиксировать полный набор метрик в форме визуальной временной последовательности, и вы сможете наблюдать, что именно происходит, когда вы выполняете на странице какие-то действия. Также можно переключиться на вкладку "Сеть" и посмотреть, нет ли там долгих вызовов API. Если вы хотите узнать больше об этом типе анализа производительности, Test Automation University предлагает курс Tools and Techniques for Performance and Load Testing от Эмбер Рейс. Эмбер демонстрирует, как получить от вкладки "Производительность" максимум.

Вкладка "Производительность" в Chrome DevTools:

Другой остроумный инструмент, доступный в Chrome DevTools – это Google Lighthouse. Lighthouse – это аудитор веб-сайтов. Он демонстрирует, насколько хорош ваш сайт в плане производительности, доступности, прогрессивных веб-приложений, SEO, и многого другого. Он также дает рекомендации, как улучшить свои показатели, прямо внутри отчетов. Lighthouse можно запустить из командной строки или как Node-модуль вместо того, чтобы запускать его напрямую из DevTools.

Google Lighthouse в Chrome DevTools:

Использовать Chrome DevTools вручную для одноразовых проверок или исследовательского тестирования, конечно, полезно, но регулярное тестирование нуждается в автоматизации. Один из действительно классных способов автоматизировать проверки производительности – это использование Playwright, уже упомянутый мной фреймворк для end-to-end-тестирования. В Playwright можно создать протокольную сессию Chrome DevTools и собрать все необходимые метрики. Можно также сделать массу крутых штук при помощи профилирования и прерывания. Это как бэкдор в браузере. Что круче всего, так это то, что метрики можно собирать одновременно с функциональным тестированием! Один фреймворк удовлетворит как нужды функционального тестирования, так и нужды автоматизации производительности.

Пионер в этой области – Джон Хилл. Сейчас он занимается этим в рамках проекта Open MCT. Именно он показал мне, как автоматизировать тесты производительности в Playwright! Если вы хотите узнать больше, посмотрите его недавний доклад о тестировании производительности в Playwright, а также его проект js-perf-toolkit в GitHub.

const   client = await page.context().newCDPSession(page);
await client.send('Performance.enable');
 
await   page.goto('mce_href="https://www.google.com/">https://www.google.com/');
await   page.click('[aria-label="Search"]');
await   page.fill('[aria-label="Search"]', 'playwright');
 
await   Promise.all([
    page.waitForNavigation(),
    page.press('[aria-label="Search"]',   'Enter')
]);
 
let   perfMetrics = await client.send('Performance.getMetrics');
console.log( perfMetrics.metrics );

#5. Модели машинного обучения

Еще один крученый мяч тестирования сайтов: как насчет моделей машинного обучения? К примеру, при покупках в онлайн-магазине низ практически каждой карточки товара занят списком рекомендаций похожих или комплементарных продуктов. Скажем, когда я искал последнюю видеоигру Pokémon на Amazon, Amazon рекомендовал мне другие игры и игрушки:

Такие системы рекомендаций могут быть жестко закодированы у маленьких магазинов, но крупные операторы торговли вроде Amazon и Walmart используют модели машинного обучения для подкрепления своих рекомендаций. Такие модели ужасно трудно тестировать. Как узнать, "хороша" или "плоха" рекомендация? Как я узнаю, что люди, которым нравится Pokémon, польстятся на игру Kirby или Zelda? Плохие рекомендации – это упущенная бизнес-возможность. У других моделей могут быть последствия и посерьезнее, вроде внедрения вредоносных предубеждений, затрагивающих пользователей.

Модели машинного обучения нуждаются в отдельных подходах к тестированию. Заманчиво было бы пропустить валидацию данных, потому что это сложнее, нежели базовое функциональное тестирование, но не стоит так рисковать. Чтобы провести тестирование правильно, отделите функциональную правильность фронтэнда от валидности поставляемых данных. К примеру, мы можем дать продуктовым рекомендациям имитацию данных, чтобы тесты давали согласованные результаты проверки внешнего вида. Затем можно протестировать систему рекомендаций в отрыве от интерфейса, чтобы проверить, что ее ответы похожи на правду. Разделение этих вопросов тестирования делает каждый тип тестов более полезным для выявления багов. Это также сокращает время на тестирование моделей машинного обучения, так как тестировщики или скрипты не нуждаются в переходах по UI, чтобы проводить тесты.

Если вы хотите узнать больше о курсах тестирования машинного обучения, то Карлос Кидман создал прекрасный курс об этом в Test Automation University - Intro to Testing Machine Learning Models. В своем курсе Карлос демонстрирует, как тестировать модели на предмет конфронтационных атак, аспектов поведения и необоснованных предубеждений.

#6. JavaScript

Возможно, следующий наблюдаемый мной тренд покажется вам противоречивым: JavaScript – это еще не все. Исторически JavaScript был единственным языком для веб-разработки фронтэнда. В результате вокруг экосистемы фронтэнда сформировалась монокультура JavaScript. В этом по сути нет ничего плохого, но я предвижу, что в ближайшие годы ситуация изменится, и я сейчас не про TypeScript.

В последнее время раздражение одностраничниками и тяжелыми клиентскими фронтэндами привело к эпохе возрождения серверной части. В дополнение к фреймворкам JavaScript, поддерживающим SSR, классические серверные проекты вроде Django, Rails и Laravel живы и процветают. Народ из этих сообществ использует JavaScript, когда это необходимо, но любит изучать альтернативы. К примеру, HTMX – это фреймворк, который дает гипертекстовые директивы для множества динамических действий, которые иначе пришлось бы кодировать напрямую в JavaScript. Я могу использовать любой классический веб-фреймворк с HTMX и практически полностью избежать JavaScript-кода. Это дает программистам возможность делать клевые штуки с фронтэндом без необходимости переходить в чуждую экосистему.

Ниже – примерный сниппет HTML-кода с HTMX-атрибутами для отправки клика и показа ответа:

<script   src="/https://unpkg.com/htmx.org@1.7.0"></script>
<!--   have a button POST a click via AJAX -->
<button   hx-post="/clicked" hx-swap="outerHTML">
    Click   Me
</button>

WebAssembly, или “Wasm”, тоже с нами. WebAssembly – это по сути ассемблер для браузеров. Код, написанный на языках более высокого уровня, можно скомпилировать в код WebAssembly и запустить в браузере. Все крупные браузеры сейчас до какой-то степени поддерживают WebAssembly. Это означает, что JavaScript – больше не браузерный монополист.

Не знаю, сместит ли какой-либо язык JavaScript с трона браузеров, но предвижу, что в грядущие годы браузеры станут мультиязычными платформами с помощью WebAssembly. К примеру, на PyCon 2022 Anaconda сообщила о запуске PyScript, фреймворка для запуска кода Python в браузере. Blazor позволяет коду C# запускаться в браузере. Emscripten компилирует программы C/C++ в WebAssembly. Другие языки – например, Ruby и Rust – тоже поддерживают WebAssembly.

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

#7. Автономное тестирование

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

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

Автономное тестирование очень упростит нам жизнь. Оно серьезно повысить продуктивность разработчиков и тестировщиков. Мы, как отрасль, еще до этого не дошли, но этот этап близок, и, я думаю, наступит совсем скоро. Я делал доклад на эту тему на конференции Future of Testing: Frameworks 2022.

Заключение

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

Обсудить в форуме