How Guru’s Engineers Use Cypress for Better Burn Testing
Нужен лучший способ справляться с тестами на сгорание? Два из наших фронтенд-инженеров нашли способ использовать Cypress, чтобы улучшить их подход к контролю качества.
Мы собираемся делиться знаниями в Guru, и когда мы открываем что-то новое и полезное, мы хотим, чтобы мир это знал! Наша команда разработчиков использует Cypress в процессе тестирования и контроля качества. Они нашли новый способ для проведения более качественных тестов, и они хотят поделиться своим новым и улучшенным процессом с другими инженерами и тестировщиками.
За последний год мы сосредоточились на увеличении охвата наших тестов — в частности, сквозном тестировании, которое гарантирует, что разные части потоков продукта функционируют корректно, когда мы обновляем код. Для этого типа тестирования мы используем инструмент под названием Cypress, который имитирует поведение пользователя с нашим веб-приложением и расширением для Google Chrome. Этот пакет тестов запускается при каждом pull-запросе, чтобы убедиться, что новый код не ломает вещи в нашем пользовательском интерфейсе. Мы также хотим блокировать релизы, если наш пакет тестов Cypress не проходит на нашей производственной ветке.
Что мы ищем в традиционном тестировании
Одной из проблем, с которыми мы сталкивались, было то, что некоторые наши тесты проваливались, но не по причинам, связанным с пользовательским интерфейсом или кодом. Так как Cypress помогает нам в таких случаях? Мы заставляем Cypress действовать как пользователя, чье поведение мы можем определить. Существует несколько переменных, которые могут привести к тому, что Cypress сообщает нам о сбое, но с точки зрения пользователя, ничего не кажется неправильным.
Например, может быть тест, который говорит: "Перейдите в эту часть веб-приложения > Добавьте новую карту Guru > Ожидайте видеть состояние после создания". Если состояние загрузки создания карты зависает на миллисекунду дольше, чем нужно, и Cypress начинает искать состояние после создания до того, как оно здесь, этот тест может провалиться (но чаще всего этот тест пройдет). Если он проходит раз на pull-запросе, мы можем объединить код, который иногда может зависать. Но мы не узнаем, если это так; пройденный тест не является гарантией того, что код правильный.
Подобная ситуация снижает надежность нашего охвата тестами. В результате, когда сбой теста появляется на нашем конвейере развертывания, нам нужно проверить, является ли это проблемой пользовательского интерфейса или теста. Чтобы это исправить, мы начали думать о том, как мы можем обнаружить, если тест может зависнуть, прежде чем он попадет в нашу производственную ветку кода.
Как помогает тестирование на сгорание
Вводим тестирование на сгорание. Тестирование на сгорание — это процесс, используемый для тестирования чего-то в более жестких или экстремальных условиях. Его также иногда называют стресс-тестированием или нагрузочным тестированием, в зависимости от метода или конкретной области, которая тестируется.
В Guru мы используем тестирование на сгорание как часть нашего пакета тестов Cypress для любых новых или модифицированных тестов, которые добавляются в нашу кодовую базу. Перед тем, как эти тесты могут быть объединены, мы запускаем их несколько раз подряд, и все они должны пройти, чтобы перейти к следующему этапу в нашем конвейере сборки CircleCI.
Этот шаг происходит сразу перед запуском всего пакета тестов Cypress. Преимущество этого порядка состоит в том, что если наш этап тестирования на сгорание дает сбой, мы можем сразу отметить все проверку как провалившуюся. Пропуская остальную часть пакета, мы можем сэкономить время и сократить количество циклов, которые могут потребоваться для гарантии того, что недавно добавленные тесты являются надежными и устойчивыми к ошибкам.
Чтобы найти файлы, которые мы ищем, мы используем git diff на текущей ветке и передаем вывод как параметр инструменту cypress-repeat, который позволяет нам запускать эти тесты любое количество раз, добавляя тестирование на сгорание как шаг в наш пакет сквозного тестирования.
Результат
Правка нашего плана тестирования дала некоторые довольно значительные положительные результаты. Для нас добавление тестирования на сгорание может сократить время, необходимое для нахождения ненадежных тестов, до 30 минут. Это также улучшает время отклика для добавления новой функциональности. Поскольку нововведенные тесты теперь запускаются первыми, они позволяют нам проверить стабильность перед продолжением остального процесса сборки.
В целом, наше постоянное внимание к увеличению эффективности и надежности наших процессов тестирования повышает уверенность всей инженерной команды в быстром выпуске новых функций. Мы исправляем ошибки быстрее и упрощаем работу со всеми нашими кодовыми базами. Мы надеемся, что этот пост поможет другим пользователям Cypress создавать лучшие тесты и всей команде работать более эффективно.
Мы собираемся делиться знаниями в Guru, и когда мы открываем что-то новое и полезное, мы хотим, чтобы мир это знал! Наша команда разработчиков использует Cypress в процессе тестирования и контроля качества. Они нашли новый способ для проведения более качественных тестов, и они хотят поделиться своим новым и улучшенным процессом с другими инженерами и тестировщиками.
За последний год мы сосредоточились на увеличении охвата наших тестов — в частности, сквозном тестировании, которое гарантирует, что разные части потоков продукта функционируют корректно, когда мы обновляем код. Для этого типа тестирования мы используем инструмент под названием Cypress, который имитирует поведение пользователя с нашим веб-приложением и расширением для Google Chrome. Этот пакет тестов запускается при каждом pull-запросе, чтобы убедиться, что новый код не ломает вещи в нашем пользовательском интерфейсе. Мы также хотим блокировать релизы, если наш пакет тестов Cypress не проходит на нашей производственной ветке.
Что мы ищем в традиционном тестировании
Одной из проблем, с которыми мы сталкивались, было то, что некоторые наши тесты проваливались, но не по причинам, связанным с пользовательским интерфейсом или кодом. Так как Cypress помогает нам в таких случаях? Мы заставляем Cypress действовать как пользователя, чье поведение мы можем определить. Существует несколько переменных, которые могут привести к тому, что Cypress сообщает нам о сбое, но с точки зрения пользователя, ничего не кажется неправильным.
Например, может быть тест, который говорит: "Перейдите в эту часть веб-приложения > Добавьте новую карту Guru > Ожидайте видеть состояние после создания". Если состояние загрузки создания карты зависает на миллисекунду дольше, чем нужно, и Cypress начинает искать состояние после создания до того, как оно здесь, этот тест может провалиться (но чаще всего этот тест пройдет). Если он проходит раз на pull-запросе, мы можем объединить код, который иногда может зависать. Но мы не узнаем, если это так; пройденный тест не является гарантией того, что код правильный.
Подобная ситуация снижает надежность нашего охвата тестами. В результате, когда сбой теста появляется на нашем конвейере развертывания, нам нужно проверить, является ли это проблемой пользовательского интерфейса или теста. Чтобы это исправить, мы начали думать о том, как мы можем обнаружить, если тест может зависнуть, прежде чем он попадет в нашу производственную ветку кода.
Как помогает тестирование на сгорание
Вводим тестирование на сгорание. Тестирование на сгорание — это процесс, используемый для тестирования чего-то в более жестких или экстремальных условиях. Его также иногда называют стресс-тестированием или нагрузочным тестированием, в зависимости от метода или конкретной области, которая тестируется.
В Guru мы используем тестирование на сгорание как часть нашего пакета тестов Cypress для любых новых или модифицированных тестов, которые добавляются в нашу кодовую базу. Перед тем, как эти тесты могут быть объединены, мы запускаем их несколько раз подряд, и все они должны пройти, чтобы перейти к следующему этапу в нашем конвейере сборки CircleCI.
Этот шаг происходит сразу перед запуском всего пакета тестов Cypress. Преимущество этого порядка состоит в том, что если наш этап тестирования на сгорание дает сбой, мы можем сразу отметить все проверку как провалившуюся. Пропуская остальную часть пакета, мы можем сэкономить время и сократить количество циклов, которые могут потребоваться для гарантии того, что недавно добавленные тесты являются надежными и устойчивыми к ошибкам.
Чтобы найти файлы, которые мы ищем, мы используем git diff на текущей ветке и передаем вывод как параметр инструменту cypress-repeat, который позволяет нам запускать эти тесты любое количество раз, добавляя тестирование на сгорание как шаг в наш пакет сквозного тестирования.
Результат
Правка нашего плана тестирования дала некоторые довольно значительные положительные результаты. Для нас добавление тестирования на сгорание может сократить время, необходимое для нахождения ненадежных тестов, до 30 минут. Это также улучшает время отклика для добавления новой функциональности. Поскольку нововведенные тесты теперь запускаются первыми, они позволяют нам проверить стабильность перед продолжением остального процесса сборки.
В целом, наше постоянное внимание к увеличению эффективности и надежности наших процессов тестирования повышает уверенность всей инженерной команды в быстром выпуске новых функций. Мы исправляем ошибки быстрее и упрощаем работу со всеми нашими кодовыми базами. Мы надеемся, что этот пост поможет другим пользователям Cypress создавать лучшие тесты и всей команде работать более эффективно.
Опробуйте мощь платформы Гуру на практике - пройдите интерактивный тур по нашему продукту
