Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

sikuli robotframework PageObject


(automatizator) #1
Хочу попробовать автоматизировать тесты с помощью связки sikuli + robotframework.
 
возник вопрос, где лучше реализовывать PageObject и DSL(domain specific language) :
1. на java/python, а из робота уже дёргать кейворды dsl.
2. или в роботе, а на java/python написать только обёртки для sikuli
 
Кто что думает по этому повооду? 

(Taras) #2

так как для простого клика Вам нужно несколько обьектов ScreenRegion, Target, Mouse и нет необходимости их держать уникальними всегда, по етому думаю лучше обертки писать


(automatizator) #3

спасибо за ответ.

в общем решил вообще не использовать RobotFramework, а писать тесты просто на java + testng/junit,

т.к. используя  RF возни прилично увеличивается, а преимуществ кроме няшных отчётов для себя не вижу.

 

 

 


(Mykhailo Poliarush) #4

если вам необходимо только автоматизация веб-приложений и вы умеете программировать, то вы сделали правильный выбор

robotframework хорошо подходит, когда нужно автоматизировать разные технологии для одного теста и когда, пользователи автоматизации не умеют программировать


(Mykhailo Poliarush) #5

у меня только вопросов почему java?


(automatizator) #6

в принципе с питоном знаком достаточно для написания тестов. Но решил попробовать java для разнообразия. Так же было интересно попробовать новую IDE,  после просмотра классного доклада http://www.youtube.com/watch?v=42HEBONX_cA.

 

т.е. Java или Python - вопрос не принципиальный, и там и там каких-то хоть сколько-нибудь существенных плюсов или минусов для написания тестов я не вижу.

Вопрос, почему Sikuli - намного интереснее


(Mykhailo Poliarush) #7

ну а почему sikuli? :)


(automatizator) #8

Сейчас как раз думаю надэтим вопросом - какой инструмент использовать. На данный момент испытываю Sikuli на пригодность для моих нужд.

В целом сикули подкупил своей простотой, отсутствием глючности


(Sergey Korol) #9

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

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


(automatizator) #10

Всё так. Сейчас анализом инструментов и занимаюсь. Отсутсвие глючности, простота - это те причины по которым данный инструмент не был выкинут из рассмотрения в первый же день. И, безусловно, на степень пригодности Sikuli для моих нужд смотрю в первую очередь.