Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы когда-либо тестировали API через Postman или иной инструмент, то это будет элементарной задачей для вас. Cypress – отличный инструмент тестирования, который также может быть полезен при тестировании API. В сегодняшней статье я пройдусь по основам создания API-теста в Cypress.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Возможно, вам нужно запускать ваши тесты в нескольких окружениях. Неоднократно видел, как люди делали что-то вроде этого:

cy.visit(Cypress.env('localUrl'))

Я большой поклонник использования Cypress.env() для хранения переменных, но есть способы куда лучше.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Среди тестировщиков множество перфекционистов. Практически у всех, с кем я сталкивался, чешутся руки использовать команду .wait() в Cypress и остановить тест на пару секунд. Если вы из таких людей, то отлично знаете, что такое использование .wait() – не лучшее решение, и пробуете найти альтернативу. Тест просто ничего не делает несколько секунд. Их может быть достаточно, но иногда этого мало.

Когда мы используем .wait(), то хотим, чтобы приложение пршило в нужное состояние. Закрытие модального окна, получение ответа от сети, смена состояния кнопки… Cypress был создан с учетом повторных попыток – это означает, что как только команда сработает, Cypress перейдет к следующей. Если команда не срабатывает, Cypress будет пытаться выполнить ее повторно в течение нескольких секунд.

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

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Вы узнаете:

• Как создать кастомную команду, автоматически дополняющую ваши селекторы
• Как выполнить проверку тестов, написанных на TypeScript
• Как грепнуть селекторы из приложения
• Как создать предупреждение, если в приложении есть неиспользуемые селекторы.

Cypress советует использовать селекторы data-cy в качестве лучшей практики для выбора элементов на странице. Недавно мы отлично подискутировали в дискорде, действительно ли эта практика хороша. Лично я сильно склоняюсь к "да". Если вы в моем лагере, у меня есть для вас ряд полезных советов.

Автор: Луиза Гиббс (Louise Gibbs)
Оригинал статьи
Перевод: Ольга Алифанова

UI-автоматизация может быть медленной, неуклюжей и склонной к ошибкам. Ее поддержка в условиях меняющейся базы кода неизбежна. Настройка тестов, исправление поломок и адаптация к изменениям ПО могут стать огромной проблемой.

Это звучит адски, но я обожаю это! Это похоже на серию головоломок, нуждающихся в решении, а я люблю головоломки. Если вы покупаете книгу головоломок в киоске, то загадки в начале книги будут намного проще загадок в ее конце. Если вы совсем новичок в этом типе задач, логично начинать с начала, с более простых головоломок.

Вне зависимости от вашего опыта автоматизации, вы должны подходить к проекту как новичок, если проект для вас в новинку. Начните с идентификации "простых" тестов. Я всегда начинаю с теста, запускающего приложение. Если вы не сможете это сделать, то все остальные тесты будут бесполезными.

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

В этом примере я расскажу, как я начинаю совершенно новый проект UI-автоматизации.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы оказались здесь через Google-поиск, то, возможно, недоумеваете, почему подобный код не работает в Cypress:

it('stores value in variable', () => {
 
     let id
 
     cy.request('/api/boards')
          .then( res => {
 
          id = res.body[0].id
     })
 
     cy.visit('/board/' + id) // "id" is undefined?!
 
})

Если вам нужно только решение, промотайте вниз до раздела Возможные решения. Если вы хотите разобраться, что происходит, читайте дальше.

Источник — блог HTML Academy

Быстрые сайты любят и пользователи, и поисковики.

С первыми всё просто: если страница долго грузится, пользователь её закроет и перейдёт на другой сайт. С поисковиками похожая история: скорость загрузки влияет на ранжирование сайта в поисковой выдаче.

Проверить производительность сайта можно с помощью разных инструментов. Один из наиболее известных — Lighthouse от компании Google. Он не только тестирует сайт и показывает оценку производительности, но и даёт конкретные рекомендации: что можно улучшить, чтобы сделать сайт быстрее.

Давайте разберём, как с помощью Lighthouse проверить качество сайта и повысить его производительность. Мы не будем углубляться в алгоритмы работы инструмента и принципы подсчёта внутренних метрик: начинающим веб-разработчикам это и не нужно. Однако знать, как работает инструмент, и уметь использовать его в своих проектах — очень важный навык.

Оригинальная публикация

Всем привет, меня зовут Катя, я QA Engineering Manager в inDriver. В этой статье расскажу про свой опыт использования Proxyman, а также о том, почему считаю его лучшей программой-сниффером. Приятного чтения! 

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Осторожно! Длинная статья!

Введение

Это отчет о попытке провести обзор и тестирование работоспособности инструмента "тест-автоматизации". Работа велась в сентябре 2021, а последующие мероприятия – 3-4 ноября. Приложение - Katalon Studio.

Мой самоназначенный чартер заключался в исследовании и инспектировании Katalon Studio с фокусом на рекламациях и идентификации функциональности продукта посредством лояльного применения.

Я включил в статью мета-заметки о тестировании, выделенные курсивом.

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

Тестирование работоспособности можно также назвать "смоук-тестированием", "быстрым тестированием" или "тестированием верификации сборки". Это краткое, поверхностное тестирование с целью определить, подходит ли продукт для глубокого тестирования, или же в нем есть очевидные или серьезные проблемы.

Идея лояльного тестирования не в поиске багов, а в использовании функциональности продукта относительно несложным образом.