Зміст
Для цього в Geb передбачені методи withWindow і withNewWindow. Метод withWindow — нове вікно відкривається в існуючому, виробляються дії перевірки і відразу ж повертається в попереднє вікно. Зрештою, я перестав писати методи на елементах. Якщо я звертаюся до певного елемента, мені відразу повертається або текст, або я клікаю по ньому, чи виконую інші дії прямо в рамках PageObject. Посилання на елемент є посиланням на набір об’єктів іншого модуля.
На відміну від бібліотек, які допомагають працювати для опису моделі в рамках PageObject, існують тестові фреймворки з вже готовими рішеннями. Гнучкість, звичайно, втрачається, у цьому й відмінність готового рішення від самопісного. Перше, з чого варто почати автоматизацію, — подумати, що потрібно зробити, щоб нічого не писати, а якщо і писати, то як можна менше. Чим менше ви пишете, тим менше помилок ви робите.
WithNewWindow відкриває нове вікно, що набагато спрощує процедуру. Коли дія закінчується, автоматично ми повертаємося назад в попереднє вікно. І знову в Geb все це є в готовому вигляді. Перше, у нас є wait, який визначає, чекати елемент на сторінці чи ні.
Показ Прихованого Елементу
Це може значно розширити можливості з точки зору фреймворку і оптимального опису необхідних дій. Іноді ми відчуваємо великі труднощі — як запровадити ті чи інші значення або поля. Коли з’являються Windows-вікна, ми використовуємо хто на що здатний. У Geb є можливість використовувати будь-які кнопки, вкладки, переходи. Перше, що ми шукаємо, — як описувати сторінки, що могло б нам у цьому допомогти.
По-перше, щоб писати на Groovy, треба писати дуже мало. По-друге, він використовує Java, тому всі Java-бібліотеки, які у нас є, ми можемо «переиспользовать». Додатково — в ньому чудові asserts, які не треба розписувати, як в TestNG або JUnit.
Звичайно, дещо не працюватиме у зв’язку зі специфікою нативних мобільних додатків, але побудова PageObject, модулів можна застосовувати і до цих додатків. Для опису цих дій на Java 7 з використанням Selenium доведеться створювати набагато більший обсяг коду, ніж наведений вище. З точки зору програми, використання Geb дуже спрощує опис PageObject.
Коли ви пишете PageObject, у вас використовується метод static at. Ви просто вказуєте, який елемент на сторінці повинен бути присутнім в поточному стані, якщо ви знаходитесь на конкретній сторінці. Тестовий фреймворк Selenide останнім часом стали активно використовувати.
Готові Рішення Для Qa: Як Писати Автотесты На Groovy
Раніше у вас була таблиця, де потрібно було вибирати всі елементи, вибудовувати в певні об’єкти і з ними надалі працювати. Тут же цього робити не потрібно — кожний рядок є певним модулем зі своїм набором значень. В рамках цього модуля ви завжди можете повернути набір модулів з таблиці і з ним викликати необхідні вам методи. Перша перевага Geb — використання мови Groovy.
Великий мінус в тому, що, по-перше, щоб команда починала писати на Groovy, вам треба спочатку навчити команду. По-друге, не завжди замовник готовий до використання Groovy, частіше до Java, а краще Java 7. Що ще може вам допомогти в роботі над проектами? У нас є поняття методів wait, і не завжди на сторінці є ті чи інші елементи. Для перевірки ми пишемо метод isElementPresent, робимо track catches, обробляємо, повертаємо true або false.
- Це відбувається з-за того, що створені автотесты потрібно підтримувати, а ті, хто буде їх підтримувати, про нових фреймворках можуть не знати.
- І знову в Geb все це є в готовому вигляді.
- Для перевірки ми пишемо метод isElementPresent, робимо track catches, обробляємо, повертаємо true або false.
- Якщо я звертаюся до певного елемента, мені відразу повертається або текст, або я клікаю по ньому, чи виконую інші дії прямо в рамках PageObject.
- Ми відкриваємо бібліотеку Selenium, пишемо рівні фреймворку — сторінки, тести, бізнес-логіку і т.
Ми можемо не чекати появи цього елемента, а перевірити його наявність. Якщо ви хочете використовувати тестовий фреймворк, ви можете скористатися певним комплексом готових рішень. Це доцільно, якщо у вас є не дуже досвідчена команда, а вам потрібно побудувати процес автоматизації з нуля. Якщо вам необхідно перевірити, чи ви знаходитесь на сторінці, у вас є чудовий метод isAt. Ви передаєте поточну сторінку, і у вас виходить перевірка true/false (на поточній сторінці чи ні). В рамках фреймворку можна використовувати і описувати певні елементи, які будуть використовуватися у різних сторінках з допомогою класу Module.
Переваги І Недоліки Готового Рішення
Але дуже добре у мене вийшло використовувати Geb з Cucumber. У нього дуже хороша підтримка, BDD, добре оформлений звіт. Всередині, звичайно ж, була підтримка Вакансія Middle QA Automation Engineer (C#) Geb і всі сторінки описувалися за допомогою Geb. Підтримуються також JUnit і TestNG, і всі тестові перевірки на базі цих фреймворків можна робити в Geb.
В Groovy ж підтримка парсинга і розбору JSON-файлу відбувається «коробочки». Природно, у нас є first-метод, за допомогою якого можна вибрати всі елементи зі знаком $. В даному випадку нам потрібен перший, тому ми вказуємо одиницю — «перший елемент» і «клік».
На нього іноді навіть погоджуються і замовники, хоча багато з них все ж вимагають виключно Java 7 і Selenium. Це відбувається з-за того, що створені автотесты потрібно підтримувати, а ті, хто буде їх підтримувати, про нових фреймворках можуть не знати. Крім того, що в Geb є вбудована підтримка JS, підтримка jQuery.
У кожного рішення є свої переваги і свої недоліки. При виборі технологічного стека визначатися аутстафінг вам! Цей вибір залежить від складу і знань вашої команди і завдань, які ви хочете вирішити.
Улюблений клас By дозволяє нам з того чи іншого селектору зробити вибір тих чи інших елементів. Метод login.submit знаходить і викликає кнопку, якою ви відразу ж клікаєте. З даним рішенням автоматизацію https://wizardsdev.com/ можливо побудувати і з одним сеньйором в команді так як це рішення з коробки. У вас буде від початку і до кінця продумана архітектура, підтримка Jira, гарний звіт і багато іншого.
Оптимальне Рішення
До того ж у вас з’являється вільний час, щоб випити кави, поспілкуватися з друзями або зайнятися самоосвітою. Geb і потрапити до IT Spock — це одна зв’язка, нові підходи у BDD. Особисто у мене не дуже вийшло використовувати Geb+Spock, і ось чому.
Далі — область тестового середовища , для якої ми задаємо імена оточення і створюємо ті драйвера, які необхідні. Geb — готове рішення, яке можна сміливо використовувати при написанні вашого фреймворка. На сайті gebish.org доступна дуже хороша документація, яка постійно оновлюється актуальними доповненнями.
Взаємодія З Мишею І Підтримка Кнопок
Ви можете порівнювати все, не треба підключати сторонні бібліотеки, як це робиться в JUnit і Hamcrest. Отже, у нас є рівень PageObject для опису сторінок, є кроки і тест — це класичний підхід до побудови тестового фреймворка. Ми окремо розподіляємо рівень сторінок (опис нашого додатка), окремо виносимо бізнес-логіку. При використанні бізнес-логіки пишемо тести, щоб вони не зверталися до сторінок безпосередньо.
В залежності від того, які завдання ви створили, у вас буде запускатися та чи інша тестова середовище в рамках існуючого. В XPath іноді нам не вистачає можливості використовувати матчеры і, відповідно, регулярні вирази. Тут це можна використовувати прямо «з коробки». Це дуже великий бонус і дуже великий плюс для автоматизації процесу тестування. Природно, за текстом не дуже добре вибирати, але по класу ви можете це зробити. В Java вам потрібні сторонні бібліотеки для роботи з JSON-файлом.
Велосипед, Або Що Ми Зазвичай Робимо Все
Досить часто ми використовуємо в коді JS, так як є речі, які без нього зробити не можна. Для цього потрібно написати певний шматок коду, привести його до Java executor та інше. Для рівня опису сторінок він підходить, але завжди хочеться більшого — все максимально автоматизувати.
Якщо ви налаштовуєте Jenkins, ви запускаєте job та тестові набори стартують у певної середовищі. Необхідно умовити замовника розпочати використовувати нові фреймворки та технології. Для замовника головне питання — хто це буде підтримувати. У підсумку я став писати зовсім по-іншому.
Велосипед, Або Що Ми Зазвичай Робимо Все
Друге — не витрачати час на винахід велосипеда для створення тестового фреймворка. Ми відкриваємо бібліотеку Selenium, пишемо рівні фреймворку — сторінки, тести, бізнес-логіку і т. Після цього всього ще обов’язково витрачаємо дорогоцінний час на створення звіту, який не соромно було б показати клієнту.
ModuleList в рамках модуля, де ми викликаємо ще один модуль. Вибір селекторів величезний — і це найбільша проблема у їх виборі. Я ставлюся до останніх і міг би навести безліч аргументів на користь XPath. Підтримка всіх тестових фреймворків, поєднання з Cucumber, jUnit, TestNG.
