Знакомство с фронтенд-тестированием. Часть первая. Введение
Авторизуйтесь
Знакомство с фронтенд-тестированием. Часть первая. Введение
Рассказывает Гил Тайяр, автор блога на Hackernoon
Недавно моя подруга, которая только начала изучать прекрасный мир фронтенд-разработки, спросила меня, как тестировать ее приложение. По телефону. Я ответил, что не могу помочь ей по телефону, так как мне требуется много времени для изучения этой темы, пообещав прислать ей несколько ссылок.
Сев за компьютер я загуглил этот вопрос и нашел много ссылок, которые отправил ей, но не был удовлетворен глубиной изложенного в них материала. Я не смог найти подробное руководство по тестированию фронтенда, в котором этот вопрос рассматривался бы с точки зрения новичка, причем в котором рассматривались бы как теория, так и практика.
В итоге я решил написать его сам.
Что такое тестирование?
На мой взгляд, тестирование — это код, который проверяет, работает ли код твоего приложения, так называемый «промышленный код», согласно ожиданиям. Некоторые люди подразумевают под этим TDD (разработку через тестирование), специфическую методологию тестирования, где тесты пишутся в самом начале и направляют дальнейшую разработку продукта.
Прим. перев. О том, зачем нужна TDD, читайте в нашей статье.
Откровенно говоря, я не думаю, что имеет значение, когда ты пишешь тесты — до или после кода приложения, если их достаточно, чтобы быть уверенным в качестве продукта. Однако многие люди, которых я уважаю, считают, что это важно.
8 декабря в 18:00, Онлайн, Беcплатно
К сожалению, индустрия объединила идею тестирования и TDD, и из-за этого у кода, написанного разработчиком параллельно с промышленным кодом, нет стандартного определения. Я решил назвать его просто тестированием.
Зачем нужно тестирование?
Нет, я не собираюсь обсуждать, зачем нужно тестировать код. Если вы не хотите тестировать, не делайте этого. Для вас будет очень неприятно вручную проверять ваше приложение снова и снова. Те докучливые баги, которые вы запомните, исправляя их, будут возвращаться снова, чтобы лишить вас сна. Запуск кода в продакшн будет сопровождаться риском и страхом.
Нет, я не собираюсь обсуждать, зачем нужно тестирование.
Типы тестирования
Другая область, сбивающая с толку людей, начавших изучать тестирование — это различные типы тестов. Если вы изучали эту тему, вы наверняка слышали о юнит-тестировании, интеграционном тестировании, end-to-end (E2E) тестировании и компонентном тестировании.
И что еще хуже, каждый человек описывает эти понятия по-своему.
Опять-таки, вопрос терминологии меня заботит мало — я считаю, что у типов тестирования нет строгого определения. На мой взгляд, все тесты лежат в диапазоне, который начинается с юнит-тестов и заканчивается E2E-тестами.
Многообразие типов тестирования
Давайте начнем с самого простого — юнит-теста. Юнит-тест — это по определению то, что тестирует «юнит» (англ. элемент). А что же такое «юнит»? Это зависит от языка программирования. Юнитом может быть функция, модуль, пакет, класс, даже объект (в языках вроде JavaScript и Scala). В JavaScript юнит — это обычно класс или модуль.
Прим. перев. Советуем также прочитать наш перевод статьи «Зачем нужны юнит-тесты».
Важно, что юниты тестируются в изоляции от всех других частей. Это идеально подходит для алгоритмических и функциональных вещей, например, для функции, которая считает количество символов в строке, или класса, который имеет набор проверяющих функций.
Легко тестировать элемент кода отдельно, когда он не зависит от других элементов вообще. Но что, если я хочу протестировать юнит, который зависит от другого элемента кода? Мы можем сделать две вещи: протестировать два юнита вместе или замо́кать один из них.
Если мы тестируем два элемента кода вместе, это может считаться юнит-тестированием? Педант скажет, что нет. Я скажу, что это не имеет значения. Я обычно называю такие тесты юнит-тестами, но вы можете называть их интеграционными тестами или двойными юнит-тестами.
Что же такое «мок»? Давайте посмотрим на примере:
Для тестирования данного модуля мы можем реализовать функцию записи в файл честно, или сделать мок-реализацию, которая не будет ничего и никуда писать.
Когда мы передаем мок в функцию, то тест становится юнит-тестом в строгом понимании этого термина. Но если бы реализация функции была честной, многие люди не согласились бы с тем, что это юнит-тест.
Итак, с одной стороны мы имеем юнит-тесты, с другой — E2E-тесты, тесты целого приложения. Все тестируется в E2E-тесте, а приложение работает так с теми же настройками, что и у пользователя.
С увеличением количества тестов объем протестированного кода увеличивается, а замоканного кода — уменьшается.
Интеграционными тестами я называю те, которые тестируют больше, чем юнит, но не тестируют все части приложения. Итак, в какой раздел вы поместите свои тесты? Многие люди утверждают, что существует пирамида тестирования: много юнит-тестов, поменьше интеграционных и малое количество E2E-тестов. Но давайте пока оставим эту тему — я собираюсь разобрать каждый из видов тестирования отдельно. Также я написал маленькое приложение, которое мы будем использовать в учебных целях — его исходники можно найти на GitHub.
Как мы тестируем frontend (html-верстку). Чек-лист
Меня зовут Павел, я со-основатель 100UP (разработка сайтов и рекламное агентство в одном лице). Мы занимаемся дизайном и разработкой технически сложных веб-проектов. В основном это e-commerce и b2b-порталы (личные кабинеты дилеров, производителей и др.).
В этой статье мы бы хотели поделиться своим опытом как мы в своей команде тестируем html-верстку, так как качественная верстка является неотъемлемой частью успешного запуска проекта.
Есть масса примеров, когда компании в спешке с желанием как можно скорее представить новый сайт клиентам, решали, что не стоит тратить “лишнее” время на качественное тестирование, выпускали очень “сырой” проект. Конечно, для простых корпоративных сайтов упущенная прибыль минимальна при запуске проекта с кривой версткой, а вот для коммерческих проектов стоимость ошибок слишком высока, особенно для интернет-магазинов, когда посетитель не может подобрать товар или даже оформить заказ.
1. Два вида тестирования: ручное и автоматизированное. Автоматизация: юнит-тесты и интеграционные тесты.
2. Чек-лист по тестированию верстки: что в себя включает проверка; проверяемые параметры.
3. В каких браузерах и на каких устройствах мы тестируем.
4. Разработка сайта и тестирование. Схема.
5. Сервисы, которые используются для тестирования верстки сайта.
Тестирование верстки сайта осуществляется двумя способами — вручную и с помощью автоматизированных тестов.
Для того, чтобы выполнить ручное тестирование, разработчику и тестировщику необходимо “пройтись” по всем пунктам разработанного заранее чек-листа (представлен в пункте статьи №2).
Преимущество ручного тестирование заключается в его “гибкости” и детальности. Тестировщик может увидеть сценарии, которые не прописаны в скрипте, и тут же протестировать их. Однако есть и существенный минус — приходится все “делать своими руками”, а это значит, что затрачивается значительное количество времени. Сократить время проверки помогает автоматическое тестирование.
Автоматическое тестирование осуществляется с помощью тестов, которые пишутся разработчиками, для выполнения повторяющихся монотонных действий, а также для поиска неочевидных ошибок. Разработчик один раз пишет тест, затем в последующем использует его для проверки похожих компонентов на разных сайтах.
Самые низкоуровневые (простые) тесты — это юнит-тесты. В широком смысле юнит-тесты — это код, который тестирует юниты (части) кода: функции, модули и классы. В рамках frontend-разработки юнит-тесты — это тесты javascript. Обычно каждый javascript-компонент сайта имеет большое количество мелких юнит-тестов. Каждый такой тест проверяет только одно взаимодействие с тестируемым компонентом.
Основным преимуществом юнит-тестов является их независимость от других частей приложения — часто корректировки в скрипты можно вносить точечно, не изменяя весь код теста. Кроме того эти тесты небольшие, и во многих случаях их написание не занимает много времени.
Для написания и воспроизведения юнит-тестов мы используем фреймворк jest. Тесты производятся в виртуальной среде, где взаимодействие с сервером эмулируется.
Кроме юнит-тестов также для автоматического тестирование верстки мы используем приемочные тесты или интеграционные тесты. В интеграционных тестах производится тестирование как и целых компонентов, так и взаимодействие разных компонентов друг с другом. Такие тесты позволяют проверить, как frontend будет вести себя на готовом сайте на CMS-движке. В первую очередь данными тестами проверяется взаимодействие различных javascript-компонентов между собой.
Приемочные тесты в отличие от юнит-тестов не проверяют мельчайшие детали компонентов, а тестируют их основные функции. Внутри этих тестов мы пытаемся максимально имитировать действия пользователей: тесты нажимают кнопки, ждут отклика, заполняют поля, переходят по ссылкам.
Для написания приемочных тестов мы используем Selenium.
Кроме того к автоматическим тестам мы относим мониторинг сайта и логирование javascript-ошибок, найденных при взаимодействии с этим сайтом. На наших сайтах мы логируем javascript-ошибки с помощью Sentry.
Данный чек-лист постоянно нами обновляется и каждый его пункт содержит описание, которое мы решили не вставлять в эту статью, так как она была получилась “километровая”. Актуальный чек-лист с комментариями можно посмотреть на нашем сайте.
Мы пришли к тому, что проверяемые параметры можно разделить на несколько групп:
1. Соответствие макету
2. Работа в разных окружениях
3. Проверка на разных разрешениях экрана (проверка десктопной и адаптивных версий)
Фронтенд Vs. Бэкэнд-тестирование
Что такое Frontend Testing?
Frontend Testing — это тип тестирования, который проверяет уровень представления 3-уровневой архитектуры.
С точки зрения непрофессионала, вы проверяете GUI — все, что видно на экране, на стороне клиента. Для веб-приложения интерфейсное тестирование будет включать проверку функциональных возможностей, таких как формы, графики, меню, отчеты и т. Д., А также связанный Javascript. Тестирование внешнего интерфейса — это термин, охватывающий различные стратегии тестирования. Тестер должен хорошо понимать бизнес-требования для выполнения этого типа тестирования.
В этом уроке мы узнаем
Что такое внутреннее тестирование?
Бэкенд-тестирование — это тип тестирования, который проверяет уровень приложений и базы данных 3-уровневой архитектуры.
В сложном программном приложении, таком как ERP, внутреннее тестирование повлечет за собой проверку бизнес-логики на уровне приложений. Для более простых приложений бэкэнд-тестирование проверяет серверную часть или базу данных. Это означает, что данные, введенные в интерфейс, будут проверены в базе данных. Формат базы данных может быть SQL Server, MySQL, Oracle, DB2 и т. Д. Данные будут организованы в таблицы в виде записи.
Базы данных проверяются на наличие свойств ACID, операций CRUD, их схемы, соответствия бизнес-правилам. Базы данных также проверяются на безопасность и производительность.
При внутреннем тестировании нет необходимости использовать графический интерфейс. Вы можете напрямую передавать данные с помощью браузера с параметрами, необходимыми для функции, чтобы получить ответ в некотором формате по умолчанию. Например, XML или JSON. Вы также подключаетесь к базе данных напрямую и проверяете данные с помощью SQL-запросов.
Тестирование внешнего интерфейса против внутреннего тестирования
| Тестирование внешнего интерфейса | Бэкэнд-тестирование |
| Тестирование внешнего интерфейса всегда выполняется в графическом интерфейсе. | Back End Testing включает тестирование баз данных и бизнес-логики. |
| Тестировщик должен быть осведомлен о требованиях бизнеса, а также об использовании инструментов сред автоматизации. | Тестер, чтобы иметь возможность выполнять внутреннее тестирование, должен иметь большой опыт работы с базами данных и концепциями языка структурированных запросов (SQL). |
| GUI используется для выполнения тестирования | GUI может или не может быть использован для выполнения тестирования |
| Не требуется никакой информации для хранения в базе данных. | Для этого нужна информация, хранящаяся в базе данных. |
| Важно проверить общую функциональность приложения. | Бэкенд-тестирование важно для проверки на наличие взаимоблокировок, повреждения данных, потери данных и т. Д. |
| Типы выполняемых тестов — юнит-тесты, приемочное тестирование, тестирование доступности, регрессионное тестирование и т. Д. | Три широко используемых типа тестирования базы данных: SQL-тестирование, API-тестирование и т. Д. |
Важные инструменты тестирования переднего плана:
Для фронтального тестирования доступно множество инструментов. Здесь приведены три популярных инструмента тестирования интерфейса.
Тестирование фронтенда: проверяем верстку
Привет! Я — Таня Перина, QA-тестировщик в Purrweb. Рассказываю про мелкие детали, которые сделают мир пользователя лучше. Надеюсь. Верю.
В жизни фронтендера случается так, что он становится немного верстальщиком. Тут очень важно не попасть в капкан собственной уверенности. Вёрстка как у боженьки на рабочем экране не означает, что такой же крутой результат получился везде.
Представь, тебе дали проект — допустим, какой-нибудь сайт. Дизайн сайта прилетел в виде макета: в Figma, Zeplin (Sketch) или Adobe XD. И вот ты его сверстал.
Настало время тестировать! Что делать? Расскажу по порядку.
Кому советую читать:
Учиться на ошибках чужих — хорошо. Для фронтенд-тестирования это правило работает так же хорошо. Вот что случается, если не сверять верстку с макетом.
Сверху экран Contact Us для нашего сайта. Eще год назад он был в разработке. Справа — макет или «то, как должно быть». Слева — то, что изначально получили на выходе.
Или вот еще пример.
Расстояние между баджами разное — не надо так
Опять то же самое. Макет справа, реальность слева. Тут проблема с баджами.
Чтобы предотвратить появление этих ошибок на этапе тестирования фронтенда, проверьте совпадают ли размеры элементов, шрифты, цвета. Если нужно сделать 1 в 1 — используйте Pixel perfect.
Сверять верстку с макетом сложно. Но не расстраивать же дизайнера — он это все «рисовал». И заказчика — он заапрувил макет и ждет, что ожидания совпадут с реальностью.
Что может случиться, если не учесть размер экрана при тестировании фронтенда? Давайте посмотрим.
На каких экранах сайт будет открываться? Необходимо выяснить это с командой на берегу. Так, можно минимизировать неприятные сюрпризы, а пользователи смогут без проблем открыть страницу. Даже на каком-нибудь маленьком экране.
Вот 10 популярных разрешений экрана, на которых пользователи открывают наш сайт:
Кто-то любит сидеть за MacBook Air, кто-то обожает огромные дисплеи. Но, открыв страницу сайта, каждый хочет увидеть что-то внятное — круто, когда вёрстка этому не препятствует:)
Во время фронтенд-тестирования не ограничивайтесь Google Chrome — откройте также Safari, Firefox и Microsoft Edge. Чтобы не произошло такое:
Слишком много нашего сайта. Впрочем, ладно. Держите еще один пример.
В процессе фронтенд-тестирования, cкорее всего, придется проверить и «мертвый» Internet Explorer. Статистика посетителей нашего сайта подтверждает факт, что кто-то до сих пор им пользуется.
Это же касается и IE 11. Потому что бывает вот так:
Поддержка Internet Explorer — главный страх и боль последних лет. Этот браузер часто остается в стороне. НО пользователи IE живы пока жив сам IE. Так что, проверьте результат работы и там — если ничего не работает, сообщите об этом команде (можно начать с проектных менеджеров).
Маленький совет: Помните о том, что Google Chrome на Mac OS совсем не тот, что на WIndows.
Лайтовый вариант, который не вводит в ужас обычных людей, но вводит в ужас дизайнеров:
Как часто вы открываете сайты с телефона в обычной жизни? Я — часто 😀 Сейчас смартфон заменяет компьютер, люди от быстрой жизни читают, смотрят, изучают всё с телефона. И если есть возможность использовать сайт мобильной версии, то не забудьте посмотреть, как он выглядит. Зачем? Чтобы пользователь, зашедший на сайт со смартфона не выколол себе глаза от ужаса 😀
Допустим, у тебя форма регистрации пользователя с именем, почтой и паролем. И где-то на сайте будет отображаться имя. Именем может быть «Ян», а может «Барнаби Мармадюк Алоизий Бенджи Кобвеб Дартаньян Эгберт Феликс Гаспар Гумберт Игнатий Джейден Каспер Лерой Максимилиан Недди Объяхулу Пепин Кьюллиам Розенкранц Секстон Тедди Апвуд Виватма Уэйленд Ксилон Ярдли Закари Усански». И это не моя бурная фантазия, а реальное имя. Имя, которое может всю верстку сломать 🙂
Верстка — это важная часть любого веб-проекта. Это то, что пользователи видят в первую очередь. Это обертка, по которой судят. Сделать ее классной — ваш священный долг!
Выполняя эти простые шаги, вы здорово повысите перформанс проекта. И тогда (возможно не с первого раза) тестировщик, заказчик или менеджер не заставят вас переделывать верстку по сто раз. И будет вам счастье!
Спасибо за материал, но к сожалению я побуду занудой — очень поверхностные советы для совсем новичков.
«Смотрите сайт в разных браузерах, ведь верстка должна выглядеть одинаков на разных устройствах, а ещё бывает разная ширина окна, может что-то вылезти за край, будьте внимательны» — весь смысл статьи в одном предложении, причем чтобы получить ценность, достаточно просто помнить об этих вещах, никаких секретов.
в них и метили 🙂 без секретов и открытия Америк.
Зачем у Кунг-фу панды подпись скоммуниздили?
Скоммуниздили и скоммуниздили, чего бубнить-то?
Что-то я не помню такого в кунг фу панда🤷🏻♂️
Где пруфы?
не скоммуниздили, позаимствовали)
Рассказывая про верстку сломали ux, хехе. Как-то привычней слева видеть исходник, а справа — результат.
В IE длинный текст в меню не растянулся на весь размер блока
На картинке, судя по описанию, Edge и Chrome. Несостыковочка.
«Слева — макет или «то, как должно быть». Справа — то, что получили на выходе.»
А почему тогда макет красным крестиком помечен, а результат зеленой галочкой?
Все ещё в тексте «слева макет, справа результат» красный крестик у макета, зеленая галочка у результата.
думали, что поправили, оказалось, проморгали :))
теперь точно порядок, спасиб!
А расскажите лучше, про какую-нибудь автоматизацию. Как, например, тестят большие сайты на сотни страниц или и-магазы? Не вручную же?
Не наша специфика. Мы больше про продукты, не про интернет-магазины.
Догоняя ваш коммент,
А вообще тема неоднозначная, интересная. Спасибо за идею!
Все баги, которые находят тестировщики, попадают в виде задач в Трелло и отправляются на оценку.
Конкретно в этом кейсе верстальщику потребовалось 15 минут. Мы посчитали, что срок адекватный и сделали задачу.
Кто-то занимается тестированием на аутсорсе? Или может кого-то посоветовать?
Знакомство с фронтенд-тестированием. Часть четвертая. Интеграционное тестирование
Авторизуйтесь
Знакомство с фронтенд-тестированием. Часть четвертая. Интеграционное тестирование
Рассказывает Гил Тайяр, автор блога на Hackernoon
Мы рассмотрели два вида тестирования: юнит-тестирование различных модулей и E2E-тестирование всего приложения. Но между этими двумя этапами тестирования происходят и другие. Я, как и многие другие, называю такие тесты интеграционными.
Несколько слов о терминологии
Много общаясь с любителями разработки через тестирование, я пришёл к выводу, что они имеют другое определение для термина «интеграционные тесты». С их точки зрения, интеграционный тест проверяет «внешний» код, то есть тот, который взаимодействует с «внешним миром», миром приложения.
Поэтому, если их код использует Ajax или localStorage, или IndexedDB и, следовательно, не может быть протестирован с помощью юнит-тестов, они оборачивают этот функционал в интерфейс и мокают этот интерфейс для юнит-тестов, а тестирование реальной реализации интерфейса называют «интеграционным тестом». С этой точки зрения «интеграционный тест» просто тестирует код, который взаимодействует с «реальным миром» вне тех юнитов, которые работают без учета реального мира.
Я, как и многие другие, склонен использовать понятие «интеграционные тесты» для обозначения тестов, которые проверяют интеграцию двух или более юнитов (модулей, классов и т. д.). При этом неважно, скрываете ли вы реальный мир через замоканные интерфейсы.
Мое эмпирическое правило о том, следует ли использовать реальные реализации Ajax и других операций I/O (ввода-вывода) в интеграционных тестах, заключается в следующем: если вы можете это сделать и тесты все еще выполняются быстро и не ведут себя странно, то проверяйте I/O. Если операция I/O сложная, медленная или просто странная, то используйте в интеграционных тестах mock-объекты.
В нашем калькуляторе, к счастью, единственным реальным I/O является DOM. Нет вызовов Ajax и других причин писать «моки».
Фейковый DOM
Возникает вопрос: нужно ли писать фейковый DOM в интеграционных тестах? Применим моё правило. Использование реального DOM сделает тесты медленными? К сожалению, ответ — «да»: использование реального DOM означает использование реального браузера, что делает тесты медленными и непредсказуемыми.
Мы отделим большую часть кода от DOM или протестируем всё вместе в E2E-тестах? Оба варианта не оптимальны. К счастью, есть третье решение: jsdom. Этот замечательный и удивительный пакет делает именно то, чего от него ждёшь — реализует DOM в NodeJS.
Он работает, он быстр, он запускается в Node. Если вы используете этот инструмент, то можете перестать рассматривать DOM как «I/O». А это очень важно, ведь отделить DOM от фронтенд-кода сложно, если не невозможно. (Например, я не знаю, как сделать это.) Я предполагаю, что jsdom был написан именно для запуска фронтенд-тестов под Node.
Давайте посмотрим, как он работает. Как обычно, есть инициализирующий код и есть тестовый код, но на этот раз мы начнём с тестового. Но перед этим — отступление.
Отступление
Эта часть является единственной частью серии, которая ориентирована на конкретный фреймворк. И фреймворк, который я выбрал — это React. Не потому, что это лучший фреймворк. Я твердо верю, что нет такого понятия. Я даже не считаю, что существуют лучшие фреймворки для конкретных случаев использования. Единственное, во что я верю — люди должны использовать среду, в которой им наиболее комфортно работать.
И фреймворком, с которым мне наиболее комфортно работать, является React, поэтому следующий код написан на нём. Но, как мы увидим, интеграционные тесты фронтенда с использованием jsdom должны работать во всех современных фреймворках.
Вернемся к использованию jsdom.
Использование jsdom
Затем мы проверяем, что в строках 12 и 14 элемент в DOM показывает на дисплее калькулятора начальное значение, равное 0.
Строка 10, которая вызывает ReactDom для визуализации компонента, также использует document (и window ), так как ReactDom часто использует их в своем коде.
Итак, кто создает эти глобальные переменные? Тест — давайте посмотрим на код:
В строке 4 мы создаём глобальное window для объекта. Это нужно React.
Функция cleanup удалит эти глобальные переменные, и они не будут занимать память.
В идеале переменные document и window должны быть не глобальными. Иначе мы не сможем запустить тесты в параллельном режиме с другими интеграционными тестами, потому что все они будут переписывать глобальные переменные.
К сожалению, они должны быть глобальными — React и ReactDom нуждаются в том, чтобы document и window были именно такими, поскольку вы не можете им их передать.
Обработка событий
А как насчет остальной части теста? Давайте посмотрим:
Остальная часть теста проверяет сценарий, в котором пользователь нажимает «42 * 2 =» и должен получить «84».
Но встроенный метод click работает, поэтому мы используем его.
Проницательный заметит, что этот тест проверяет точно то же самое, что и E2E-тест. Это правда, но обратите внимание, что этот тест примерно в 10 раз быстрее и является синхронным по своей природе. Его гораздо проще писать и гораздо легче читать.
А почему, если тесты одинаковы, нужен интеграционный? Ну, просто потому, что это учебный проект, а не настоящий. Два компонента составляют всё приложение, поэтому интеграционные и E2E-тесты делают одно и то же. Но в реальном приложении E2E-тест состоит из сотен модулей, тогда как интеграционные тесты включают в себя несколько, быть может, 10 модулей. Таким образом, в реальном приложении будет около 10 E2E-тестов, но сотни интеграционных тестов.
