Комментарии 13
А если перед снятием скриншота мне необходимо выполнить какое-то асинхронное действие, такое как-то можно реализовать?
Сейчас это можно сделать комбинацией из действий executeJS() и wait(). WebDriver в принципе позволяет сделать более умный асинхронный execute, эта возможность просто не проброшена в gemini. Я создал тикет об этом (https://github.com/bem/gemini/issues/66). В ближайшее время планируем пробросить недостающие команды WebDriver, туда попадет и эта.
Cool.
И вот действительно, еще очень резонный вопрос, почему вы отказались от привычных интерфейсов, как у большинства библиотек для unit-тестирования, были ли на это какие-то серьезные причины? Мелочь, конечно, но пользователям было бы приятней.
И вот действительно, еще очень резонный вопрос, почему вы отказались от привычных интерфейсов, как у большинства библиотек для unit-тестирования, были ли на это какие-то серьезные причины? Мелочь, конечно, но пользователям было бы приятней.
Мы старались сохранить преемственность с обычными тестовыми фреймворками, там где инструмент работает также, как и они и сознательно делали интерфейс другим там, где gemini работает по другому. ИМХО, получить то что называется и вызывается также, как ты привык, но работает по другому было бы менее приятно.
Из общих черт c юнит-тстовыми библиотеками: У нас также есть именованные тест-сьюты, которые выстраиваются в иерархию, есть хуки before и after, есть общий контекст между всеми тестами в сьюте, как у mocha.
Отличия же в том, что нашему сьюту от программиста требуется вручную задать гораздо больше чем имя: как минимум нужна область скриншотов и URL. И это нужно для абсолютно всех тестов, поэтому требовать делать это в опциональном методе before/beforeEach было бы как-то неправильно.
Второе отличие в том, что наши 'capture' всегда выполняются последовательно и каждый последующий спокойно может зависеть от предыдущего (к в примере из статьи с кнопкой). Для традицонных тестов это не всегда так и тесты там подразумеваются независимыми, поэтому мы решили объявлять их немного по другому.
Ну и еще одно отличие – отсутствие assert проще всего объяснить. Assert у нас для любого теста всегда один: совпадение текущей и сохраненной картинки и писать его явно нет нужды.
Из общих черт c юнит-тстовыми библиотеками: У нас также есть именованные тест-сьюты, которые выстраиваются в иерархию, есть хуки before и after, есть общий контекст между всеми тестами в сьюте, как у mocha.
Отличия же в том, что нашему сьюту от программиста требуется вручную задать гораздо больше чем имя: как минимум нужна область скриншотов и URL. И это нужно для абсолютно всех тестов, поэтому требовать делать это в опциональном методе before/beforeEach было бы как-то неправильно.
Второе отличие в том, что наши 'capture' всегда выполняются последовательно и каждый последующий спокойно может зависеть от предыдущего (к в примере из статьи с кнопкой). Для традицонных тестов это не всегда так и тесты там подразумеваются независимыми, поэтому мы решили объявлять их немного по другому.
Ну и еще одно отличие – отсутствие assert проще всего объяснить. Assert у нас для любого теста всегда один: совпадение текущей и сохраненной картинки и писать его явно нет нужды.
Выглядит феерически круто. Скажите, я правильно понимаю, что первый раз при верстке элемента нужно просто прогнать gather и просмотреть глазами, правильно ли он выглядит во всех браузерах? А в дальнейшем уже считать получившийся результат эталонным и автоматически проводить тестирование на «не поломалось ли чего-то»?
Мы в нашей компании используем phantomFlow — под капотом phantomcss и Casper.
Для нас было не существенным различия в разных браузерах. Запускаем в связке grunt + teamcity. На все ушло всего 2-3 дня. Phantomflow пришлось немного модифицировать по дороге — сыровато немного конечно у них пока.
Спасибо за новый open source проект!
Для нас было не существенным различия в разных браузерах. Запускаем в связке grunt + teamcity. На все ушло всего 2-3 дня. Phantomflow пришлось немного модифицировать по дороге — сыровато немного конечно у них пока.
Спасибо за новый open source проект!
есть ещё отличный webdriver.io/guide/plugins/webdrivercss.html, в нём можно даже делать скриншот вьюбокса конкретного элемента и закрашивать ненужное через exclude.
НЛО прилетело и опубликовало эту надпись здесь
Судя по перовому тегу в webdrivercss, он вышел почти одновременно с gemini. Эксклуды действительно у него крутые, но и мы умеем пару вещей, которые он пока не умеет:
— позволяем задать несколько элементов в одном тесте (webdrivercss, насколько я понял, умеет либо снимать всю страницу, либо один элемент, либо заданный координатами прямоугольник)
— учитываем outline и box-shadow при снятии скриншота.
— считаем coverage
— позволяем задать несколько элементов в одном тесте (webdrivercss, насколько я понял, умеет либо снимать всю страницу, либо один элемент, либо заданный координатами прямоугольник)
— учитываем outline и box-shadow при снятии скриншота.
— считаем coverage
Поэкспериментировал.
Возник вопрос по работе.
При переключении страниц из скрипта (например нужна авторизация, а потом навигация через post запросы), слетает браузерный часть клиента gemini, и не совсем понятно как его опять туда подгрузить. И происходит ошибка:
Те когда можно попасть на страницу сразу по URL все вроде работает, а протестировать серверное приложение, у которого внутренняя архитектура сделано коряво, уже документации не хватает.
Возник вопрос по работе.
При переключении страниц из скрипта (например нужна авторизация, а потом навигация через post запросы), слетает браузерный часть клиента gemini, и не совсем понятно как его опять туда подгрузить. И происходит ошибка:
JSONWire Error: clientScript is not defined
Те когда можно попасть на страницу сразу по URL все вроде работает, а протестировать серверное приложение, у которого внутренняя архитектура сделано коряво, уже документации не хватает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тестируем CSS-регрессии с Gemini. Доклад на BEMup в Яндексе