Ага, симуляторы у нас так запустить получилось, но в самом аппиуме захордкожены сокеты с расчетом на один симулятор. Поэтому дальше уже проблема в аппиуме. Мы попытались формировать сокеты для каждого симулятора по отдельности, но как-то ничего стабильного у нас не получилось(
Полностью разделяем вашу боль, так же начинали) Разработчики Appium тоже знают свои минусы и совсем недавно начали делать нормальную документацию appium.io/slate/en/v1.1.0/ с примерами appium.io/tutorial/
Sikuli пробовали, впечатления положительные, к сожалению, конкретно в нашем случае инструмент не очень подходит, потому-что в тестах графики на картах нет каких-то шаблонных изображений, полигоны перемещаются (под ними меняется фон), меняют форму и цвет.
Sikuli планируем использовать, но в других проектах, к примеру есть мысли попробовать данный инструмент в тестах мобильных приложений для подсчета одинаковых элементов на экране.
Конкретно в нашем решении, на страничке с отчетом отображаются скриншоты тестинга, продкашена и изображение с наложение первого на второе, где разница подсвечивается красным цветом. Если меняется внешний вид интерфейса (изменили шрифт в метке или изменили цвет текста), то приходится глазами проанализировать изображение с подсветкой разницы. Происходит это крайне редко и затрачивает секунды времени.
Тут надо отметить, что необходимо стараться проверять интерфейс по частям, тем самым мы минимизируем зависимость тестовых страниц от нетестируемых элементов.
Объясню на примере: вам необходимо протестировать возможность смены кругом цвета. Можно добавить на тестируемую страницу кнопку, при нажатии на которую круг изменит цвет, а можно повесить все ту же смену цвета на клик по самому кругу. Мы выбираем первый вариант. А потом у кнопок меняется шрифт и при сравнении скриншотов тест сообщит об ошибке. Поэтому надо было выбрать второй вариант, тогда бы у нас упали только те тесты, где проверялись кнопки. Если проверяем круг, и можно обойтись без использования сторонних объектов, то лучше обходиться без них.
Мы пошли по пути аналогичному вашему, т.е. все те же странички с примерами использования API Яндекс.Карт и просмотр их глазами.
По сути, изначально все именно так и тестировалось, но просмотр перед каждым релизом сотен страниц с примерами, во всех поддерживаемых браузерах, занимал огромное количество времени. Поэтому ту часть проверок, где нет анимации (а ее в API Яндекс.Карт не так уж и много) мы автоматизировали по описанной методике. Там же где есть анимация и в случае с проверкой новой функциональности от рук и глаз не отказаться.
Sikuli планируем использовать, но в других проектах, к примеру есть мысли попробовать данный инструмент в тестах мобильных приложений для подсчета одинаковых элементов на экране.
Тут надо отметить, что необходимо стараться проверять интерфейс по частям, тем самым мы минимизируем зависимость тестовых страниц от нетестируемых элементов.
Объясню на примере: вам необходимо протестировать возможность смены кругом цвета. Можно добавить на тестируемую страницу кнопку, при нажатии на которую круг изменит цвет, а можно повесить все ту же смену цвета на клик по самому кругу. Мы выбираем первый вариант. А потом у кнопок меняется шрифт и при сравнении скриншотов тест сообщит об ошибке. Поэтому надо было выбрать второй вариант, тогда бы у нас упали только те тесты, где проверялись кнопки. Если проверяем круг, и можно обойтись без использования сторонних объектов, то лучше обходиться без них.
Мы пошли по пути аналогичному вашему, т.е. все те же странички с примерами использования API Яндекс.Карт и просмотр их глазами.
По сути, изначально все именно так и тестировалось, но просмотр перед каждым релизом сотен страниц с примерами, во всех поддерживаемых браузерах, занимал огромное количество времени. Поэтому ту часть проверок, где нет анимации (а ее в API Яндекс.Карт не так уж и много) мы автоматизировали по описанной методике. Там же где есть анимация и в случае с проверкой новой функциональности от рук и глаз не отказаться.