You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Сейчас Kaspresso не предоставляет готовых инструментов для автоматизированного дизайн ревью.
Решение
Поддержать возможность автоматизированного дизайн ревью путем попиксельного сравнения скриншотов.
Возможный путь реализации инструмента
Текущие проблемы
DocLocScreenshotTestCase не переиспользует интерфейс Screenshot, вместо него использую свою приватную реализацию (это кажется весьма неожиданным поведением, такой подход может вызывать недоумение, так как переопределение базового интерфейса никак не влияет на работу док&лок тестов) . Эту проблему предлагается решить унификацией интерфейса Screenshot путем добавления туда нового метода и последующей миграции DocLocScreenshotTestCase на использование Screenshot интерфейса.
interfaceScreenshots {
<...>/** * Делает полный скриншот экрана устройства*/funtakeDeviceWindow(tag:String)
}
Нет возможности вешать перехватчики на вызовы Screenshot интерфейса. Это мешает реализовать некоторые возможности Алюра о которых ниже. Интерфейс для перехватчиков мог бы выглядеть так:
interfaceScreenshotInterceptor {
funbeforeScreenshot(tag:String, mode:ScreenshotMode)
funafterScreenshot(tag:String, mode:ScreenshotMode, file:File)
funonScreenshotError(tag:String, mode:ScreenshotMode, e:Exception)
// Для примера, можно сделать отдельные методы или наоборот общий метод с этим параметром в ScreenshotenumclassScreenshotMode {
SIMPLE,
FULL,
WINDOW,
}
}
Нет перехватчика для DocLocTestCase который бы аттачил все скриншоты к Алюр отчету. Это было бы полезно для удобства анализа скриншотов. Необходимо добавить такой функционал использую интерсептор из пункта 2.
После исправления проблем выше можно приступить к реализации основной фичи.
Реализация основной фичи
Добавляем скриншот компаратор - интерфейс для сравнения двух скриншотов (в предполагаемой реализации сравнивать будем на android девайсе так как это в разы проще и на практике не сильно медленнее, сравнение попиксельное):
interfaceScreenshotsComparator {
funcompare(
expected:File,
actual:File,
diff:File? = null,
diffColor:Int = Color.MAGENTA,
accuracy:Float = 0f // разрешенная погрешность при сравнении (сколько пикселей могут отличаться) в %
): Boolean
}
Добавляем перехватчики для ScreenshotsComparator аналогично ScreenshotInterceptor.
Добавляем перехватчики для добавления в алюр отчеты отличающихся скриншотов
Добавляем DesignReviewScreenshotTestCase аналогичный по виду DocLocScreenshotTestCase, тут следует рассписать подробнее:
DesignReviewScreenshotTestCase добавляет новый метод compareScreenshot который можно вызвать в любой момент теста, данный вызов делает скриншот и сравнивает его с эталоном в режиме проверки или обновляет эталон в режиме обновления (режим задается через конструктор). Важная особенность таких сравнений что при провале проверки тест падает не сразу, а после полного прохождения - это необходимо что бы собрать другие отличающиеся скриншоты и не прогонять тест повторно после фикса каждого отдельного скриншота.
Эталоны будут загружаться на устройство либо самим тестом по переданному пути через AdbServer, либо должны быть заранее загружены на устройство сторонней системой.
Выгрузка эталонов может быть реализована с помощью уже существующего механизма выгрузки артефактов.
Отдельно почему сравниваем именно на устройстве?
Сравнивать на устройстве значительно более проще с точки зрения реализации в коде, а так же с точки зрения конфигурации, вся философия Kaspresso строится на выполнении кода тестов на устройстве. Конечно, как вариант, можно реализовать такие проверки внутри adb на стороне хоста, но adb не является обязательным инструментом. Так же такие сравнения на хосте могут вызывать сложности при формировании Alure отчета если он формируется на устройстве.
Касательно производительности сравнения скриншотов, фактически сравнение происходит достаточно быстро и мы не испытывали никаких проблем что бы гонять этот код на устройстве.
P.S. подобный подход (за вычетом отдельных перехватчиков, так как как нам не нужно отделять alure в отдельный модуль) используется у нас уже достаточно длительное время и в целом неплохо себя зарекомендовал.
The text was updated successfully, but these errors were encountered:
Проблема
Сейчас Kaspresso не предоставляет готовых инструментов для автоматизированного дизайн ревью.
Решение
Поддержать возможность автоматизированного дизайн ревью путем попиксельного сравнения скриншотов.
Возможный путь реализации инструмента
Текущие проблемы
Screenshot
, вместо него использую свою приватную реализацию (это кажется весьма неожиданным поведением, такой подход может вызывать недоумение, так как переопределение базового интерфейса никак не влияет на работу док&лок тестов) . Эту проблему предлагается решить унификацией интерфейсаScreenshot
путем добавления туда нового метода и последующей миграцииDocLocScreenshotTestCase
на использованиеScreenshot
интерфейса.Screenshot
интерфейса. Это мешает реализовать некоторые возможности Алюра о которых ниже. Интерфейс для перехватчиков мог бы выглядеть так:DocLocTestCase
который бы аттачил все скриншоты к Алюр отчету. Это было бы полезно для удобства анализа скриншотов. Необходимо добавить такой функционал использую интерсептор из пункта 2.После исправления проблем выше можно приступить к реализации основной фичи.
Реализация основной фичи
ScreenshotsComparator
аналогичноScreenshotInterceptor
.DesignReviewScreenshotTestCase
аналогичный по видуDocLocScreenshotTestCase
, тут следует рассписать подробнее:DesignReviewScreenshotTestCase добавляет новый метод
compareScreenshot
который можно вызвать в любой момент теста, данный вызов делает скриншот и сравнивает его с эталоном в режиме проверки или обновляет эталон в режиме обновления (режим задается через конструктор). Важная особенность таких сравнений что при провале проверки тест падает не сразу, а после полного прохождения - это необходимо что бы собрать другие отличающиеся скриншоты и не прогонять тест повторно после фикса каждого отдельного скриншота.Эталоны будут загружаться на устройство либо самим тестом по переданному пути через
AdbServer
, либо должны быть заранее загружены на устройство сторонней системой.Выгрузка эталонов может быть реализована с помощью уже существующего механизма выгрузки артефактов.
Отдельно почему сравниваем именно на устройстве?
Сравнивать на устройстве значительно более проще с точки зрения реализации в коде, а так же с точки зрения конфигурации, вся философия Kaspresso строится на выполнении кода тестов на устройстве. Конечно, как вариант, можно реализовать такие проверки внутри adb на стороне хоста, но adb не является обязательным инструментом. Так же такие сравнения на хосте могут вызывать сложности при формировании Alure отчета если он формируется на устройстве.
Касательно производительности сравнения скриншотов, фактически сравнение происходит достаточно быстро и мы не испытывали никаких проблем что бы гонять этот код на устройстве.
P.S. подобный подход (за вычетом отдельных перехватчиков, так как как нам не нужно отделять alure в отдельный модуль) используется у нас уже достаточно длительное время и в целом неплохо себя зарекомендовал.
The text was updated successfully, but these errors were encountered: