testomat.io управление авто тестамиОтличное видео! Спасибо!
Товарищи, так в итоге такая архитектура норм или мне лучше удавиццо ?
1)
В идеале: 1 тест - 1 проверка
В крайне запущенном случае: 1 тест - проверка 1го бизнес процесса
DataProvider’ы рулят. Один код позволяет проверить over9000 вариаций (и positive, и negative)
Тесты могут состоять из шагов (если с п.1 не повезло). Шаги простые, с friendly названием и как можно больше переиспользуются в других тестах
Из тестов/шагов идет вызов методов PageObjects / всяких Helper’ов работы с БД/сервисами
В тестах/шагах вызываются assert’ы. При необходимости (если тесты объемные) - soft assert’ы, дабы за 1 проход поймать косяки/дефекты в разных частях кейса и не тратить время.
Все веселье с инициализацией/передачей/остановкой драйвера и т.п. спрятано как можно глубже. Желательно куда-нибудь в аля Selenide (чтобы вообще не переживать за driver и его жизнь).
{Хорошая компанияя, и конкурсы интересные. У нас обычно сразу все на auto сваливают)
Кстати, на счет идеи, которую выступающий доносит:
как вам показалось? действительно зачастую не стоит заморачиваться паттерном PageObjects?
А делать такие степы, внутри которых и идентификация локаторов и операции с ними…
1 лайк
Мне кажется, зависит от того, насколько сильно будет расти проект.
Обычно автотест нужен сегодня, завтра он не нужен.
И если реально первый месяц тратить на “супер” фреймворк - то в топку такой автотест.
Я считаю, что в любой момент можно “старые” тесты обособить и запускать отдельно, а новые делать в созданном фреймворке, если в оном вдруг возникла необходимость.
3 лайка
Данный подход в видео мне лично не очень понравился… Сегодня все так просто, решается проблема, а завтра проект разрастается, все усложняется и новые проблемы. Есть ведь ряд проблем и правил (наработки опытом других людей), используя которые, ты избавишься от них в будущем. Почему бы не понять о чем идет речь в PageObjects или еще что-то, и не применить сразу. Я у себя вообще на стадии написания первого автотеста заморочился с многопоточностью. И теперь я сплю лучше… Если завтра придет на проект 10-ть автоматизаторов или через время напишется 500 тестов, я не буду заморачиваться с переписыванием или еще чем… Многопоточность есть и работает хорошо. Даже 100 тестов прогоняются значительно быстрее…
В общем в корне не согласен с автором видео. Скорее всего этот доклад сделали ради доклада… Надо развиваться учится новому, позновать опыт других людей… Просто решать насущную проблему сейчас, а завтра 100% появится еще какая-то и придется многое переписать…
ИМХО: лучше базовые наработки с чужого опыта и советов внедрить сразу, если они имеют смысл и оправданы и на это не надо тратить пол года… Вопрос только что именно из такого внедрять? Вот он таки хороший… Стоит продумать и взять все самое полезное из наработок и внедрить, для меня это было:
- многопоточность
- pgaObject
- еще реализовал свои аннотации для вебэлементов, по типу кнопки, инпута и т.д… Очень хорошо тогда все раскладывается по полочкам…
- allure отчеты
Я все это делал в нерабочее от работы время, дома, по вечерам… 
Теперь есть некий опыт, следовательно в контексте новой задачи, смогу потратить меньше времени…
2 лайка
Основная мысль доклада: “Ребята, вы не программисты, спроектировать и реализовать паттерн пейджобъжект у вас грамотно не выйдет. Тесты должны как можно быстрее и раньше приносить пользу, а пока вы пилите свой кривой фреймворк, никакого КПД компания не получает.”
В принципе он верное подметил… Но все же, я тоже склоняюсь, чтобы делать все сразу по “промышленному стандарту”.
Это два неправильных подхода, как по мне… И там и там есть плюсы и минусы… Когда все разрастеться у вас получится огромный костыль из решенных проблем. Иногда одно решение проблемы не контуется на новое решение проблемы и переписываешь многое, и прошлую проблемму… Есть ведь опыт людей, наработанные практики… Внедряя их заранее избавляешься от 20-ти проблем дальше сразу комплексно вначале, а не изобретаешь велосипед по ходу дела… Такой фреймворк, как он советует ляжет на первые 10-20 тестов, а на остальны 150 придется все переписать и создать комплексное решение…
Во втором подходе:
ребята, вы не программисты, спроектировать и реализовать паттерн пейдж-обжект у вас грамотно не выйдет
полностью согласен с ним. Но может и выйдет 50 на 50… Ведь все уже есть на гите и в гугле, и в комьюнити, просто надо правильные вопросы задавать и много думать, рисовать юмл и показывать его ребятам, которые шарят…
Есть еще третий подход… Писать все это и спрашивать у разработчика с опытом, пусть даже андроид разработчика - мол смотри, хочу зафигачть вот это и это, так и так, а он те в ответ говорит - та не, так никто не делает, надо сделать вот так и вот так. А как? Гугли, пробуй снова спрашивай, правильный вопрос задавай Это самый правильный путь развития… Решать просто насущную проблему, и не смотреть в даль - путнего думаю мало чего выйдет. Стоит забегать вперед и думать комплексно… Иначе получишь велосипед, который придется переписать на 125-ом тесте так, что придется долго и мутарно все рефакторить и читать уже наработанные практики…
Есть ООП, наработанные какие-то штуки, надо их юзать, познавать, пытаться реализовать…
По сути, автор начал создавать свою интерпретацию решения с экселем, про который рассказывал в видео… Решая проблему походу поступления, а не продумав заранее…
Никто же не хочет разводить костер не используя спичек или зажигалку… Пытаться сделать это по новому, в контексте проблемы… Варик с тем что нет спичек или зажигалки - не совсем подходит, потому что везде написано и рассказано, что такое pageObject и чем он хорошо. Также многое можжно спросить здесь…
2 лайка
Почему свою интерпретацию? У меня на проекте пилят жуткий велосипед, и для заполнения веб-форм (документ с кучей инпутов, чекбоксов, кнопочек и так далее) решили заюзать excel файл, в который задротным образом вбиваются какие-то буквы и цифры (xpath локаторов даже).
Он как раз привел частый убогий прием…
1 лайк
Все эти горя решения приходят от попыток как-то заставить мануальщиков, которые не знают код - писать автотесты, сэкономить. Решается немного сложнее, дороже, но качественней с перспективой на будущее и развитием хорошей среды для автоматизации… К примеру отправить ребят на курсы по программированию, рассказать ООП, нанять одного синьора для менторства…
Я кстати, когда зинтересовался автоматизацией просто пошел на базовый курс по джаве, когда курс закончился, я даже не умел геттеры и сеттеры делать и не понимал, в принципе, зачем их делают… Но потом когда начал изучать гит, решать проблемы комплексно, начал понимать что к чему, почитал еще разные подходы ООП и начал понимать немного, что хорошо, что плохо… Так что обучить хоть какому-то программированию можно абсолютно любого человека с желанием…
Ну и чем вам не решение проблемы, которая появляется? Можно ведь было почитать, подумать решить может как-то иначе… А может это и вправду стоящее решение, ведь всего контекста нет, как и какую проблему решает…
Меня подобные велосипеды отпугивают, я лучше пойду почитаю, как другие решают что-то подобное…
1 лайк
Ну все верно, я с тобой согласен, но я вижу, как среди автоматизаторов полно ленивых, не желающих разбираться в сложных вопросах людей)
Автор доклада ведь приводит ситуацию, которая реально царит в компаниях…
Вот у нас в компании, автотестеры мне прям так и сказали:
“Ни кто не хочет заморачиваться, пытаться понять сложные структуры, давай делать спагетти-код, его “легче” будет поддерживать, легче людей среди мануальщиков подключить, легче писать тесты, легче читать их…”
и так далее и тому подобное…
Короче, я имею в виду, что автор доклада рассматривает вполне часто встречаемую ситуацию в автоматизации тестирвоания в средне-статистических компаниях, в которых не тратят много денег на продвинутых, опытных автоматизаторов. И автор рассматривает решения задачи по построению автоматизации как раз в этом контексте.
То есть, если принять в учет изначальные данные, что имеем: двух юных полупрограммистов + одного мануальщика - и они как-то должны сварить автоматизацию, которая должна начать приносить эффект как можно скорее, то пусть не ломают голову педжобжектами, а пусть сделают степы и возможно этого будет достаточно.
Но это все ерунда, конечно.
Надо грызть гранит науки
Доброго времени суток!
Благодарю, за вопрос. Довольно лестно слышать, что моё мнение об автоматизации может быть кому-то еще интересно (кроме моего начальства 
), но сам я еще падаван и слишком юн и зелен, чтобы выдвигать сколько-то веские и авторитетные высказывания.
Из своего скудного опыта и опираясь на первую часть приведенного мною доклада:
Frameworks-shrameworks or how to ruin your test automation (Mikalai Alimenkou, Ukraine) могу сказать, что во-первых автоматизация делается не сама по себе, а с какой-то целью и опираясь на текущие реалии (ресурсы). Если, конечно, вы сами не являетесь заказчиком этой автоматизации тестирования (что вряд ли - такого еще ни разу нигде не встречал и не слышал о таком даже), либо вы не на “добровольных началах” стали внедрять у себя на проекте автоматизацию, являясь по сути мануальным тестировщиком, а автоматизация - это ваш побочный продукт и делается он в нерабочее время (хотя конечно же это почти никогда не бывает так 
)
Тогда подходы к разработке и эксперименты вы можете себе позволить абсолютно любые. Строить велосипед любой высоты и сложности. Это не возбраняется.
Другое дело, когда делается заказная автоматизация (а она почти всегда такая, просто иногда заказчик - сам отдел QA или разработка). И тут может быть несколько различных вариантов.
-
есть устоявшиеся требования к оформлению кода, используемым инструментам и фрейморкам. По сути - делай на том что дают и так как говорят. Тут без вариантов, точнее вариант есть - вы предоставите рабочий прототип, который во всем лучше текущего решения, применяемого в компании, а текущий прототип компанию давно не устраивает. Тогда могут к вам прислушаться и сменить подход, но процесс может этот затянуться и вообще зависнуть в воздухе. К этому тоже нужно быть готовым. Как вариант почему компания не захочет такое решение, даже при очевидных для всех преимуществах - кадровая проблема и боязнь попасть в зависимость от “спецов” (извечная проблема гуманитариев и менеджмента, который не хочет вникать в детали). Тут думаю описывать больше нечего - либо делай как говорят “старшие”, либо предлагай и отстаивай своё “более лучшее” решение, но тут нужно быть готовым к тому, что вас могут не понять.
-
проект новый (автоматизации) и требований к подходу четкого нет. Тогда тут нужно смотреть по своим силам, по специфики проекта, количеству времени, бюджету, наличии опытных разработчиков, хорошей аналитики и продуманной тестовой модели и т.д. По хорошему - нужно делать красиво сразу. Но красота понятие относительное. Если ваш уровень достаточно высок и уже есть отличные наработки, которые можно переиспользовать - то пользуйтесь ими конечно. Если же вы только начинаете путь в автоматизации, то ничего страшного, если вы набьете себе пару шишек. Это лишь улучшит ваше понимание в будущем о необходимости правильно продумывать структуру на начальных этапах. Но если этого опыта нет, а автоматизацию делать нужно, то почему бы не начать делать тесты здесь и сейчас, чем тратить время на изучение самых лучших практик и подходов, а потом все равно сделать ужасный велосипед в котором даже вы сами не сможете сходу разобраться.
P.S. интересный пример с экселем, на текущем проекте тоже какую-то приблуду для экселя прикручивали. Причем от бизнеса и от аналитиков были запросы приделать именно его. По-моему эти люди сами не понимали чего хотели. Точнее хотели чего-то, но внятно объяснить словами так и не смогли. В итоге оставил в полусыром виде. Проблема началась, когда нужно было одинаковые параметры в разных шагах одного теста передавать. Причем передавать в BDD сценарий и перезаписывать значения из него. Это звучит почти также ужасно как и выглядит. На мои резонные вопросы “а вам оно зачем такое?”, были ответы - “чтобы тестировщик мог менять входные параметры на лету”. При том, что BDD-сценарий это всего лишь текст, который распарсивается и добавить в него еще несколько новых тестов или изменить старые - не составит труда. Но почему-то у них была уверенность, что в табличном виде это удобней для восприятия. Я так и не понял как оно должно там было в таблице выглядеть, чтобы быть при этом еще и удобным.
P.P.S. ООП - не единственная парадигма при разработке ПО. И далеко не лучшая. До сих пор не утихают баталии на сей счет. Почти такие же как Maven vs Gradle. Хотя тут у ООП явно получше ситуация. На хабре тоже вот любят про ООП всякое писать: Десять вещей, которые я терпеть не могу в ООП и есть масса других подобных статей и заметок в сети. Есть множество языков программирования, которые не поддерживают объектную парадигму и они до сих пор активно используются и никуда на пенсию не собираются. Хотя конечно можно писать вроде бы и на Си в объектно-ориентированной парадигме, но я таких “эстетов” не встречал - Objekt-orientierte Programmierung mit ANSI-C
1 лайк
В том-то и вся суть принципа KISS! Вы не можете предсказать заранее, какие проблемы будут завтра. Эта судьба постигает всех: вы сегодня пытаетесь сделать “сразу хорошо”, заранее решить потенциальные проблемы, и строите сложную, но типа хорошую систему. А потом наступает завтра и выясняется, что проблемы-то пришли совсем другие, и их ваша “типа заранее продуманная” система нифига не решает. В итоге всё обрастает новыми костылями и степень усложнённости всего зашкаливает.
Поэтому правильно делать максимально просто и не тратить на это много времени, а проблемы решать только тогда, когда они появятся. Это не от глупости и не от лени.
Правильно!
И одна из таких наработок - KISS. Делайте всё просто и на наступите на те же грабли, на которые наступили многие и многие.
Ой ли? Вы прямо думаете, что Николай Алименков сделал свой доклад потому, что не понял Page Objects?
2 лайка
Да нет, думаю, что он парень с богатым опытом… И понимает о чем говорит. Просто мое мнение, что такое развитие - не правильное. Что бы вы не говорили, начиная делать все как он сказал, рано или поздно вы все равно придете либо к пейдж-обжекту, либо к каким-то компонентам, только со своей велосипедной интерпиратцией…
Тоже самое можно сказать и про Selenide… Но так сказать будет не совсем верно, потому что люди собрали все что посчитали нужное из личного опыта, проблем, и создали решение (Selenide), которым можно пользоваться, так и с остальными наработками. Лучшее развитие - это постигать чужой опыт и понимать, для чего это было сделано… А не изобретать свой велосипед по ходу дела и по ходу возникновения проблем. Разобраться в пейдж-обжекте - это не пол года времени… А профит поболее, чем самому приходить к тому же самому, прятать низкоуровневые вещи куда-то, чтобы они во фреймворке выглядили хорошо, а не везде сендкеи и клиры перед тайпом в инпутах и прочее…
Приведу здравый пример… Когда у меня появлялись проблемы, по началу, я их тоже решал по мере поступления, копаясь в недрах Selenide, пытаясь понять как там это реализовано, немного переделав под свои нужды… Но можно ведь было просто взять решение и заюзать. В разных контекстах будет правильно сделать по разному
ну вы же в селениде решили ряд проблем каких-то! Есть разная природа проблем… Я не говорю о каких-то сложных решениях, где у вас все приложение в попапах и мего сложной логике, думаю что для большинства проектов хорошие наработки лягут без проблем… И их познать быстрее, чем изобретать свое и прийти рано или поздно к тому же пейдж-обжекту…
Просто мне как-то показалось, что данный доклад сделан был ради доклада… Люди с огромным опытом, в разработке, тоже могут выдавать мега креативные решения с экселем. Что им тоже перестать проектировать?
Посыл хороший, мол не надо разбираться в сложном, решайте походу дела, но автоматизация - это не написание тестов под Wordpress блог, рано или поздно все на что вы пишите автотесты - будет развиваться и надо об этом подумать заранее…
В корне неверно решать проблему сроком в пол года… Чтобы показать демо заказчику и отчитаться (отстреляться) перед ним, вы получаете деньги за свою работу и должны к ней подойти с правильной стороны. Сегодня вы все так упростили, а завтра уже кто-то другой будет делать rm -rf /*
Я исключительно за простоту… И есть ряд простых решений наработанных опытом для реализации этой простоты, нежели созерцать простоту самому…
Ничего схожего в принципе нет, с Maven и Gradle и споров нет никаких на эту тему… Просто кому-то нравится работать с красивым и современным файлом из меньшего количества строк, а кто-то без проблем готов переиспользовать свои наработки, так как прям огромной разницы нет в чем собирать…
Посмотреть бы на гибкость какого-то энтрепрайс решения с процедурным программированием и большим количеством разработчиков, да и желанием там что-то развивать новое и переиспользовать. С таким подходом можно и на Git забить, заливать через FileZilla и папочки с разными датам создавать
Я исключительно за простоту, просто есть море простых решений, которые спасут в будщем и нет смысла создавать эту простоту с нуля и прийти к томуже самому, в конце пути…
P.S. как просто построить дом? чтобы к зиме не замерзнуть? Да просто берешь и ложишь кирпич на кирпич, а там уже по ходу дела решаешь все и состыковуешь, то что не сотыковалось… Но на практике сначала почитаешь как это делают другие и как заложить фундамент, вы не будете сами экспериментировать и приходить потом к этому всему… Есть множество простых и правильных решений, которые получились из опыта других людей… Надо только правильно понять, что заюзать, а отчего отказаться… В корне неверно начинать все с нуля и собирать в кучу все самому, тем более если у тебя в этом нет никакого опыта…
Если у тебя нет опыта, ну ты просто обязан, начинать все познавать с уже кем-то придуманных вещей… Ведь ты должен проводить параллель, как делать верно, а как делать не верно… А вот если ты уже опытный паренек в написании автотестов и в проектировании приложений. Тогда ты уже можешь исходя из личного опыта упрощать сложные вещи и двигаться от простого к сложному, иначе никак…
Вот когда я буду очень опытным, я зайду на селенид (просто яркий пример, не упрек) и разверну демо проект и начну без проблем выстраивать автоматизацию, потому что это быстро и просто. А пока не очень опытный, буду лезть в дебри и пытаться повторить все это, читать опыт людей, как делать верно, а как делать не верно…
Исходя из всех этих рассуждений выше, предполагаю, что доклад Николая Алименкова был сделан ради доклада, или может (лично я), не правильно понял посыл доклада… Эт как бы мое ИМХО, мне кажется вот так, я конечно же могу быть не прав…
Но!!! Хотя с другой стороны, у парня 100500 лет опыта, а тут я со своими 6-ть месяцев о чем-то подобном рассуждаю, умничаю Наверное просто с моей колокольни как-то так…
3 лайка
Если внимательно смотреть доклад Николая, то можно сделать вывод, на кого он направлен.
Этот доклад не нужен опытному автоматизатору, в первую очередь он нужен зеленым (таким как я) automated qa, которые хотят сразу делать свой шмеймворк.
Многие юные автоматизаторы не являются прогерами и не всегда могут написать что-то вменяемое и легко поддерживаемого. Вот автор и говорит - зачем это на первых порах делать. Делайте - чтобы работало. А потом по мере появления шишек придет понимание, что так работать нельзя и родится человеческий фреймворк.
Я начал заниматься автоматизацией недавно. Пробовал просто в питоне простыми def`ами фигачить тесты с детским восторгом, потом нашел py.test, изучил фикстуры, а потом почувствовал, что неудобно работать - хотелось иметь описание страниц со своими локаторами и методами, начал искать по этой теме - оказалось, все уже придумано. Я взял из придуманного только то, что нужно было нашей команде и пошли работать дальше.
Вот об этом видео. Не делайтся overhead, начните с малого. Конечно, в другой компании всегда можно переиспользовать свои знания, свои наработки.
Ядро Линукса пишется на Си, без плюсов. Как вам такой “энтерпрайз”? Я не хочу тут устраивать бесполезный холивар по этому поводу. Про Maven vs Gradle - тоже мимо. Тут же на этом форуме недавно уже его обсуждали. Сошлись на том, что те кто не видит для себя плюсов в Gradle и давно и успешно сидят на Maven и не испытывают с ним никаких проблем - могут и дальше с ним жить. В конце концов, проблема Градла/Мавена зачастую находится на 101-й позиции и людям просто нет какого-то резона менять шило на мыло, если переход не сулит им никаких выгод. Вот и пользуются тем, что давно изучено и проверено временем.
Остаться на MAVEN или переехать на Gradle?
Если у вас есть время и умения экспериментировать со своим фрейморком - то никто не будет вас за это осуждать. Каждый на своем проекте решает сам как ему быть и какой подход будет более оптимальным. С ваших слов я понял, что у вас какой-то очень долгий проект (бесконечный), на котором ведется непрерывная автоматизация тестирования. Но есть проекты с другой спецификой. Например, пилотные проекты или проекты с неизвестным будущим. Зачастую там нужно успевать создавать тесты под новый функционал, что очень и очень сложно сделать. А как раз эти тесты самые интересные. В отличии от тех же регрессионных тестов. При этом требования могут меняться по нескольку раз в течении проекта. Если у вас с аналитикой на проекте намного лучше, то это не значит что так везде. Я не агитирую за создание плохих тестов. Или к созданию спагетти кода. Но нужен и рациональный подход.
Еще есть автоматизация без ручной тестовой модели. Вот такие штуки тоже бывают. Как вы будете продумывать свой “мега-фрейморк”, если еще сами не знаете сколько и какие тесты будут нужны?
1 лайк
Контекст видео в том, что - “нет смысла человеку без опыта что-то проектировать, потому что хорошо это не сделает, так как нет опыта, лучше решать вопросы по ходу поступления и якобы делать проще”… Вот контекст видео материала, немного не то, о чем говорите вы в своем сообщении…
Я считаю, что нет смысла двигаться так, потому что у человека без опыта не возникнет вопросов:
- зачем скрывать низкоуровневые вещи?
- как делать правильно и зачем, если я решаю контекст проблемы и оно работает и все просто?
- и еще куча других вопросов
по итогу рано или поздно придут к уже ранее продуманным вещам кем-то. Вот изобретать велосипеды с экселем - это да, потому что нет опыта в таких решениях и начинается создоваться велик, на первый взгляд очень удобный…
Я считаю, что лучше оперировать опытом опытных людей, проектировать, рисовать ЮМЛ и идти к людям понимающим в разработке, вот подход который нравится мне, и с подходом в видео - не согласен… Вот что я имею ввиду. Если ты разбираешься и развиваешься и тебе это надо, найди время по вечерам, не от проекта зависит, а от вас, многое…
Но если вы с опытом, то без проблем идите по пути найменьшего сопротивления и решайте вопрос по ходу дела, но не на старте изучения предметной области… Если я не ошибаюсь подтекст видело был именно в этом - "нет смысла человеку без опыта что-то проектировать, потому что хорошо это не сделает, так как нет опыта, лучше решать вопросы по ходу поступления и якобы делать проще"
Лично я бы в таком подходе по итогу не знал как делать правильно, нагородил бы кучу всякой фигни и не смог бы проводить аналогию, что хорошо, а что плохо
Яркий тому пример, вот недавно пошел я решать проблему, когда в BasePage - куча методов без какой либо логики, и тапы и вейты и клики и прочая лабуда… Я создал интерфейсы такого типа:
public interface Validator {
@Step("Verify that \"{1}\" = \"{0}\"")
default void verifyTextEquals(final String actual, final String expected, final String message) {
assertEquals(actual, expected, message);
}
@Step("Verify that \"{1}\" = \"{0}\"")
default void verifyTextEquals(final String actual, final String expected) {
assertEquals(actual, expected);
}
@Step("Verify that \"{0}\" contains \"{1}\"")
default void verifyTextContains(final String actual, final String containsString) {
assertTrue(actual.contains(containsString));
}
@Step("Verify that \"{0}\" not contains \"{1}\"")
default void verifyTextNotContains(final String actual, final String containsString) {
assertTrue(!actual.contains(containsString));
}
}
и вот еще один пример такого интерфейса:
public interface JavaScript {
Logger logger = LogManager.getLogger(JavaScript.class);
/**
* Method which executes an async JS call
*
* @param javascript the JavaScript code to execute
* @return the object returned from the executed JavaScript
*/
@Step("Executes an async JS: \"{0}\"")
default Object executeAsyncJS(String javascript) {
Object returnObj = null;
try {
getDriver().manage().timeouts().setScriptTimeout(10, TimeUnit.SECONDS);
JavascriptExecutor jsExecutor = (JavascriptExecutor) getDriver();
returnObj = jsExecutor.executeAsyncScript(javascript);
} catch(Exception e) {
logger.error("Async javascript execution failed! Please investigate the issue.");
logger.debug("Failed Javascript:" + javascript);
}
return returnObj;
}
/**
* @param javascript the Javascript to execute on the current page
* @return Returns an Object returned by the Javascript provided
*/
@Step("Executes JS: \"{0}\"")
default Object executeJS(String javascript) {
Object returnObj = null;
try {
JavascriptExecutor jsExecutor = (JavascriptExecutor) getDriver();
returnObj = jsExecutor.executeScript(javascript);
} catch(Exception e) {
logger.error("Javascript execution failed! Please investigate into the issue.");
logger.debug("Failed Javascript:" + javascript);
}
return returnObj;
}
Куки:
public interface Cookies {
@Step("Deleting all the cookies of the domain")
default void deleteAllCookies() {
getDriver().manage().deleteAllCookies();
}
/**
* Deleting the specific cookie with cookie name
* @param cookieName Cookie name "--utmb"
*/
@Step("Deleting the specific cookie with cookie name \"{0}\"")
default void deleteCookieNamed(final String cookieName) {
getDriver().manage().deleteCookieNamed(cookieName);
}
}
Затем я имплементирую эти интерфейсы там где хочу юзать выполнение JS или где мне надо делать верификацию и т.д., таких интерфейсов поболее, но не очень много, поскольку я реализовал еще кастомные аннотации для элементов, и уже там описываю логику по работе с элементами: тапы, клики, вейт в базовом классе, ввод в поле, гет тексты и т.д…
Вот будучи неопытным, идя по контексту проблемы я сделал удобное решение, которое работает и дает четкое понятие где и что лежит по логике в одном месте, но по факту так делать - нельзя…
Надо было либо статику юзать (хочу меньше статики) или создавать эти вещи классами, создавать объекты в базовом классе… И юзать их наследуясь от базового класса…
Тоесть будучи неопытным, заюзал такое по ходу дела неграмотное решение, но удобное и рабочее, но разве это правильно? Теперь надо идти, рисовать ЮМЛ, как бы мне это хотелось реализовать, как я это вижу, и разбирать с кем-то кто опытней и понимает, как изящней реализовать такие вещи…
Я думаю тут безсмысленно спорить, просто у меня такое видение вещей, у вас другое. Автор бесспорно очень грамотный и очень опытный парень… Но, просто как-то эта идея в видео, на меня бы повлияла очень плохо…
Давайте лучше решать, какой же все же должна быть “идеальная” структура проектов автотестов
На счет Maven & Gradle, то ту темку, как раз я и создовал