Найти отличия, или внедряем Snapshot-тесты для web. Опыт Звука

Всем привет! На связи Наталья Данилина и Чечиков Иван из Звука. В этой статье мы хотим поделиться опытом внедрения snapshot-тестов для web-приложения — расскажем, что это такое и для каких задач применяется.

Подробности – под катом.

Все началось с поиска ответов на вопросы: как сократить время на тестирование, как не выгореть на регрессе, как потестить фичу без дизайн-ревью, и как сократить кол-во багов в проде после релиза?

В чем суть. Мы имеем большое количество ручных тест-кейсов, которые покрыты e2e и component-автотестами. Наши автоматизированные тесты запускаются  каждый раз при старте регресса (при этом длительность его занимает от 3 до 4 дней). И бывают ситуации, что уже после завершения процесса мы находим баги в проде, связанные с UI — их сложно уловить на этапе регресса из-за человеческого фактора. 

Поэтому мы нашли подход, который сможет в перспективе решить подобные проблемы — так в работе появились snapshot-тесты.

Snapshot-тесты — это автоматизированные тесты, которые используются для проверки веб-страниц. Они позволяют сравнить текущее состояние веб-страницы с предыдущим (или ожидаемым) состоянием и обнаружить любые изменения или различия. Мы используем snapshot-тесты также и для сравнения отдельных html-элементов (попапов, модалок, фреймов и пр.). Происходит сравнение текущего состояния компонента в тестовой среде и эталона. Эталоном может быть компонент прода, но лучше, чтобы это был компонент актуального дизайна.

Snapshot-тесты используют попиксельное сравнение. Каждый пиксель эталона сравнивается с соответствующим пикселем изображения объекта тестовой среды, чтобы обнаружить различия. Это позволяет тестам быть очень точными и обнаруживать даже небольшие изменения на веб-странице или в компоненте. Однако надо учитывать погрешность в сравнении, так как могут быть холостые ошибки при небольшом проценте отличия (до 5%).

Работая со snapshot-тестами, мы выделили ряд их преимуществ: 

• Быстрая обратная связь. Snapshot Testing позволяет быстро проверить, изменился ли результат теста после внесения изменений в код. Это дает быструю обратную связь разработчикам и тестировщикам, что помогает быстрее реагировать на возникающие проблемы.

• Автоматизация тестирования интерфейса. Snapshot Testing автоматизирует процесс проверки интерфейса, что позволяет решать связанные с ним задачи быстрее и эффективнее.

• Упрощение процесса тестирования. Snapshot Testing упрощает процесс тестирования интерфейса, так как не требует большого количества кода для написания тестов. Это сокращает время, затрачиваемое на написание и поддержку тестов, освобождая ресурсы для других задач.

• Повышение качества кода. Благодаря snapshot-тестам можно легко отслеживать изменения в интерфейсе и быстро обнаруживать ошибки. Поэтому повышается качество кода и улучшается пользовательский опыт. В дальнейшем мы планируем использовать snapshot-тестирование в процессе разработки. 

• Сокращение времени на регрессионное тестирование. Внедрение Snapshot Testing позволяет сократить время, затрачиваемое на регрессионное тестирование. Поэтому проверка интерфейса автоматизируется, а проблемы выявляются быстрее.

Мы внедрили snapshot-тесты в наш UI-фреймворк, написанный на Kotlin с использованием Playwright. Под них мы создали отдельную директорию во фреймворке и выделили джобу для запуска тестов в GitLab CI. TMS у нас —  Allure TestOps.

Сами тесты логически не сложны. Рассмотрим на примере теста сравнения куки в темной теме:

.....
class CompareCookiesBlackSnapshotsTest : WebTest() {

    @Test
    @TestOpsId(44908)
    @DisplayName("Сравнение попапов кук (темная тема)")
    @Owner(CHECHIKOV_IVAN)
    fun testCase() {
        step(
            """
            |*Precondition*:
            |Пользователь не авторизирован и находится на главной странице"
            """.trimMargin()
        ) {
            assertThat(page).containsURL(baseUrl)
            page.waitForLoadState()
        }

        step("Проверяем, что включена темная тема") {
            SideMenuBar(page).checkedSwitcherDarkTheme()
        }

        step("Проверяем что попап куки есть на странице") {
            assertTrue(CookiesPage(page).cookiesBody.isVisible)
        }

        step("Сравниваем с эталоном") {
            screenStageBytes = CookiesPage(page).cookiesBody.screenshot()
            assertScreenShots(screenStageBytes, imageName = "cookieBlack")
        }
    }
}
.....

Шаги достаточно понятны: мы выполняем предусловие, проверяя URL главной страницы. Следующим шагом убеждаемся, что включена темная тема, далее — что присутствует кука на странице. В заключении мы делаем скриншот текущего состояния куки и вызываем метод сравнения тестового изображения с эталоном.

.....
    fun assertScreenShots(stageBytesArray: ByteArray, imageName: String) {
       val prodImage = ImageIO.read(File("src/test/resources/screens/expectedImages/$imageName.png"))
        val stageImage = ImageIO.read(ByteArrayInputStream(screenStageBytes))
.....

Эталоны лежат у нас в директории /screens/expectedImages под гитом. В тестах мы заранее знаем, каким будет тот или иной эталон, поэтому пробрасываем в переменную $imageName название нашего изображения. Сделав скриншот тестового компонента, мы переводим его в объект BufferedImage, как и эталон.

.....
val prodImageResized = resizeImage(prodImage, stageImage.width, stageImage.height)
.....

.....
fun resizeImage(image: BufferedImage, width: Int, height: Int): BufferedImage {
        val scaledImage = image.getScaledInstance(width, height, Image.SCALE_SMOOTH)
        val resizedImage = BufferedImage(width, height, image.type)
        resizedImage.getGraphics().drawImage(scaledImage, 0, 0, null)
        return resizedImage
    }
.....

Приводим объекты сравнения к одному размеру:

.....
val imageComparison = ImageComparison(prodImageResized, stageImage).setAllowingPercentOfDifferentPixels(5.0)
val diff = imageComparison.compareImages()
.....

Магию сравнения выполняет библиотека image comparision. В объект ImageComparison мы передаем наши BufferdImage объекты для сравнения и выставляем процент погрешности - 5.0. Проводим сравнение и получаем объект расхождения diff. 

.....
        val diffImageStream = ByteArrayOutputStream()
        val prodImageStream = ByteArrayOutputStream()
        val diffImg = diff.result
        ImageIO.write(diffImg, "png", diffImageStream)
        val diffBytesArray = diffImageStream.toByteArray()
        ImageIO.write(prodImageResized, "png", prodImageStream)
        val prodBytesArray = prodImageStream.toByteArray()
        saveScreenshot("actual", stageBytesArray)
        saveScreenshot("expected", prodBytesArray)
        saveScreenshot("difference", diffBytesArray)
        assertEquals(ImageComparisonState.MATCH, diff.imageComparisonState,
            "Изображение в тестовой среде отличается от эталона $imageName")
    }
.....       

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

Как это выглядит в Allure TestOps:

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

Итак, мы привели пример одного из наших snapshot-тестов. Cейчас мы продолжаем расширять покрытие, так как в долгосрочной перспективе надеемся, что Snapshot Testing поможет значительно улучшить эффективность работы команды QA, сократить время на выполнение рутинных задач, повысить качество тестирования и ускорить обнаружение ошибок в интерфейсе приложения.

Спасибо, что прочитали! Если у вас есть вопросы – будем рады ответить на них в комментариях.