Комментарии 11
Какие я вижу недостатки:
— хотелось бы более гибкую спецификацию, позволяющую писать более общие правила вроде «расстояние между полями от X до Y% от высоты поля, контрастность текста на кнопке не менее Z%, длина строки текста не более W символов, строки текста не накладываются, не перекрыты непрозрачными элементами».
— вы прописываете в спецификацию куски CSS кода (ширина, высота), делая ее довольно бессмысленной. Плюс, непонятно зачем указывать размеры при наличии картинки-образца.
— сравнение через скриншоты не отличает незначительных изменений от значительных. Шрифт рендерится по-другому, слово стало на 2 пикселя шире и текст перенесся на новую строку — огромное количество расхождений. В выпадающем списке пропал треугольничек — незначительная мелочь. Мне кажется, это в нынешнем виде тупиковая технология.
— страшная смесь кирилицы и латиницы в спецификации
— какой-то велосипедный синтаксис в спецификации, напоминает yaml, но не yaml
— непонятно, как переносить длинные строки в спецификации
— вместо «совершен переход на страницу...» лучше, по моему, писать «мы на гитхабе» в целях повышения скорости чтения и написания кода
— селекторы вроде ".d-md-flex h1" ужасные. Ну это же явно стили, отвечающие за внешний вид, а не за назначение.
— для поиска обрезающегося текста скриншоты не подходят, так как у вас может быть 20 локализаций и только в одной текст обрезается. Тут наверно нужно решение, заточенное специально под поиск таких ситуаций (сравнить кол-во символов в дереве DOM и видимых на экране).
— хотелось бы более гибкую спецификацию, позволяющую писать более общие правила вроде «расстояние между полями от X до Y% от высоты поля, контрастность текста на кнопке не менее Z%, длина строки текста не более W символов, строки текста не накладываются, не перекрыты непрозрачными элементами».
— вы прописываете в спецификацию куски CSS кода (ширина, высота), делая ее довольно бессмысленной. Плюс, непонятно зачем указывать размеры при наличии картинки-образца.
— сравнение через скриншоты не отличает незначительных изменений от значительных. Шрифт рендерится по-другому, слово стало на 2 пикселя шире и текст перенесся на новую строку — огромное количество расхождений. В выпадающем списке пропал треугольничек — незначительная мелочь. Мне кажется, это в нынешнем виде тупиковая технология.
— страшная смесь кирилицы и латиницы в спецификации
— какой-то велосипедный синтаксис в спецификации, напоминает yaml, но не yaml
— непонятно, как переносить длинные строки в спецификации
— вместо «совершен переход на страницу...» лучше, по моему, писать «мы на гитхабе» в целях повышения скорости чтения и написания кода
— селекторы вроде ".d-md-flex h1" ужасные. Ну это же явно стили, отвечающие за внешний вид, а не за назначение.
— для поиска обрезающегося текста скриншоты не подходят, так как у вас может быть 20 локализаций и только в одной текст обрезается. Тут наверно нужно решение, заточенное специально под поиск таких ситуаций (сравнить кол-во символов в дереве DOM и видимых на экране).
Вы путаете gherkin сценарии и galen spec)
А если познакомитесь с документацией galen framework, увидите, что он использует специальный galen spec language похожий на yaml для описания требований к отображению элементов. И у него своя специфика и требования к описанию тех самых spec файлов.
По поводу более гибкой спецификации, ничего не мешает написать свой шаг, который будет проверять нужные Вам стили элементов, расстояния и т.д.
По поводу сравнения картинок по пикселям согласна, там есть подводные камни, о которых более подробно я рассказывала на Selenium Camp. Из решений на рынке, не использующих ML, galen на текущий момент лучший инструмент, который можно интегрировать со своими Selenium тестами.
А если познакомитесь с документацией galen framework, увидите, что он использует специальный galen spec language похожий на yaml для описания требований к отображению элементов. И у него своя специфика и требования к описанию тех самых spec файлов.
По поводу более гибкой спецификации, ничего не мешает написать свой шаг, который будет проверять нужные Вам стили элементов, расстояния и т.д.
По поводу сравнения картинок по пикселям согласна, там есть подводные камни, о которых более подробно я рассказывала на Selenium Camp. Из решений на рынке, не использующих ML, galen на текущий момент лучший инструмент, который можно интегрировать со своими Selenium тестами.
НЛО прилетело и опубликовало эту надпись здесь
Есть applitools.com Они используют AI для сравнения изображений. Гибкие, удобные, с Selenium тестами интегрируются но заставляют в своей экосистеме жить и стоят денег)
А все из-за того, что в новой версии браузера форма перевода средств с одного счета на другой уехала за пределы окна.
Может просто стоит делать нормальную вёрстку? Мне крайне сложно представить «баг» обновления браузера, который сломает лэйаут страницы.
Пообмажутся своими фреймворками…
Отличная статья, интересный метод, спасибо.
А можно через эту же методику локализацию тестировать? Например, что вёрстка не поползёт, если мы изменим язык системы на немецкий или китайский?
А можно через эту же методику локализацию тестировать? Например, что вёрстка не поползёт, если мы изменим язык системы на немецкий или китайский?
Спасибо) конечно можно. Описываете требования к отображению элементов в spec файле и просто дергаете проверку соответствия страницы после переключения на нужный язык. Все это с шагами теста можно интегрировать. Если сравнивать какие-то части страницы по скриншотам, есть вероятность, что их может быть много для разных языков. а так проверку для нескольких похожих скриншотов можно в spec файле в одну строчку реализовать: image file images/registration-form—*.png. Galen в данном случае будет по очереди сравнивать нужный элемент со скриншотами, название которых начинается на registration-form, пока не найдет подходящий
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестировать верстку? Легко