Привіт всім,
хочу для себе розібратися в теорії. Де найкраще і в яких випадках форматувати драйвер.
я зустрічав кілька варіантів:
- в самому тесті і передавати його в конструкторі в сторінки
- в самому тесті, але перед виконанням тесту наприклад анотація в testng
- в самій сторінці (і коли йде звернення до сторінці вона піднімає драйвер)
Можливо є ще якісь цікаві варіанти?
Мені подобається ідея повністю ізолювати логіку тестів від драйвера, але підозрюю, що цей спосіб може мати якісь недоліки.
Жоден з перерахованих варіантів не є правильним. Те, що ви описуєте, є domain specific module.
Ось начебто і label вірний варто, і думки щодо ізоляції вірні, але по-моєму, вам для початку необхідно розібратися, що є - framework. а також - чому тести і сторінки не мають ніякого відношення до цього поняття. А далі можна поговорити і про те, де ж власне повинен бути ізольований WebDriver.
Про framework прийнято. Насправді я встановив такий лейбл тому, що він був найбільш близький до питання (найбільш близький тут варто розуміти так, що інші були взагалі не релевантні
Я згоден з положенням, що тести і сторінки не є частиною framework.
Вірно, каркас. Тепер давайте спробуємо зрозуміти, з чого ж повинен складатися каркас, щоб забезпечити згадану швидкість і зручність в розробці, а також - надійність вашим тестів, незалежно від AUT?
Метод Сократа це серйозно
Саме це мені й не зрозуміло, ми все одно виходить залежимо в наших тестах від драйвера (навіть якщо винести це все в базовий клас).
Дякую за увагу до питання.
А ви не шукайте приклади, що суперечать власним умовиводів.
Покладемо, що у вас є якийсь driver handler. який розташований всередині каркаса.
Виникає ряд питань:
- За яким умові повинна відбуватися ініціалізація / закриття драйвера?
- Чи справді тестів необхідний драйвер в межах розглянутого рівня абстракції?
- Яким модулів каркаса насправді необхідний драйвер?
- Яким чином встановити гнучку зв'язок між модулями, яким необхідний драйвер?
якщо хочеш попарити і витратити мімнімум пів року на написання стабільної обгортки над селениум і утиліт для Проектика з Автотест. То у тебе обов'язково повинні бути класи такі: BrowserFactory - з набором браузерів, властивостей для них, якихось ще діє над браузерами; WebDriverHolder - з інстанси браузера; WebDriverInstances - в якому буде Сетер браузера, гетер вебдрайвера і наприклад "InheritableThreadLocal" для можливості поранити тести багатопоточн.
А якщо часу немає такого для "свобододумія" (хоча костилеклепанія взагалі), краще використовуй готові рішення selenide, JDI (epam), інші готові фрейворкі (обгортки над селениум) або ж в пайтон світі RobotFramework
хоча в пайтон не знаю що краще використовувати, може пітоніст тобі підкаже готові зручні фреймворки
Для початку, Ви відповіли собі на питання про концепцію вашого тест додатки в цілому, як ви будете його будувати і за якими канонами. Можливо щас закрітікуют, але для Автотест краса і гармонія коду, як і його швидкість (перебільшено, так як більшу частину ми не в коді, а в пошуках елементів на сторінці) маю малу частку. Тести повинні в першу чергу бути підтримувані. Так, код теж повинен бути ок, мати структурність, які ніякі патерни (сторінка, елемент), що б Ви самі в ньому не потонули, а значить що код повинен бути не складним, а простим і не важким, а легким (Олександр Соловйов, Привіт тобі)
Тепер про драйвер.
1. Якщо ви не дотримуєтесь якихось Патерно, ідеомам, і досвіду використання DSL підходу, то можете передавати драйвер як завгодно і де завгодно, дивимося правді в очі - багато так починали, і потім самі озонавалі дурість. Власний досвід так само необхідний.
2. Якщо ви розумієте що запуск драйвера є інфраструктурної конфігурується частиною, то ви явно зможете описати Сінглтон для базового класу ваших сторінок / елементів. Проте вам так само доведеться доповнити ваші класи серйозним базовим функціоналом для роботи з елементами, не завжди це зручно, зате дивишся і милуєшся - наскільки прозорий DSL вийшов.
3. Якщо ви прямуєте з композиційної стратегії вашого застосування, то драйвер ви передасте як агрумент головному класу додатка, а для тестів виставите публічні методи і атрибути, передавши додаток як фікстур для тест оболонки, яка буде існувати до кінця тестів - сесійний фікстура.
далі ІМХО: Я вважаю що кожен для себе повинен вибрати будь-який йому зручний підхід, так як писати тести саме йому, і підтримувати теж. Якщо розробка ведеться командою, то з ними це питання так само необхідно вирішувати. У будь-якому випадку, Ви так само повинні розуміти, що рано чи пізно "цегла падає", а робота закінчується, і після Вас хтось інший буде це все підтримувати, так зробіть же таким чином, що б вуха у Вас не горіли.
Що стосується шибко розумних програмістів, і дзен-кодинга, то я думаю що тести потрібно писати, а не писані виражатися за допомогою засобів мови програмування.
Цікава темка завелася
На мобільному (Appium) у мене реалізовано трохи криво, через ApplicationManager:
поки експерементіруйте з Вейт і напевно варто переробити на ENUM змінні і позбутися від такого loadConfigProp
ApplicationManager - тут у мене скріни не започатковано і сам драйвер з Вейт ..
Власне ось сам скрін:
ось власне мій тест:
звичайно Тетс скоротив, там у мене ще контейнери, в яких логіка состредаточена для різних девайсів і різних імен і різних повідомлень, але для прикладу буде зрозуміло ..
Почав писати все це коли ще ничерта не розумів, і тільки починав розбиратися в автоматизації, тому не дуже здорово тут все вийшло, зараз ось переписую так, щоб всі очікування і методи з UI елементами - перенести в окремі класи.
Це так у мене під мобілку для Android, фреймворк такий, зараз вже зрозумів що не так, трохи досвіду піднабрався, переписую. На інтернеті там все складніше буде, там у мене реалізована багатопоточність і купа браузерів і запуск під різними ОС ..
При написанні фреймворка в автоматизації для себе виділив такі речі:
- весь код повинен перевикористати так, щоб в Пейдж були тільки елементи і робота з ними
- при читанні тестів все повинно бути гранично зрозуміло, що відбувається
- драйвер і очікування не повинні бути в тестах і не повинні бути в Пейдж
- всі методи стосуються елемнтов - повинні знаходитися в своєму класі
- всі методи за очікуваннями - повинні знаходиться в своєму класі
- фреймворк повинен писатися так, щоб я спочатку проектував тест, а з нього вже генерував методи. Простіше придумати тест, яким він повинен бути, а потім вже писати методи для тесту
- всюди повинні дотримуватися рівні доступу
А я не започатковано драйвер в TestBase класі, від якого успадковуються всі тести і при запуску тесту зчитує дані)
Людині потрібно розібратися в концепції для початку. А ви йому ще більше коду кидаєте.
Дак давайте з'ясуємо с, просто на таких прикладах можна показати, що добре, а що погано ..
Дуже поширене рішення, я і сам так робив
а як тепер робите?)
Робив і роблю) Так же спробую описати ще один цікавий підхід з практики:
Є Singleton дли ініціалізації драйвера (заточений на firefox)
Так само є клас EnvironmentConfiguration звідки береться драйвер для подальших потреб
Далі йде абстрактний Page в якому зібрані загальні методи по роботі зі сторінками і в конструкторі створюється конфиг, який в свою чергу підтягує драйвер
Потім від цього Page успадковуються всі сторінки. У тесті створюється сторінка і в неї віддається конфиг.
Так як я користувався jbehave то в базовому тестовому класі конфиг піднімався так
в загальному ініціалізацію драйвера треба робити виключно за межами тестів і об'єктів сторінок або компонентів, але при цьому робити це так, щоб цей самий драйвер юзати не тільки в BaseScreen. але також можна було його юзати і в інших класах. Підходів є купа різних.
Найбільша проблема, напевно - це те, що в BasePage доводиться накопичувати все методи по роботі з Пейдж, часто туди лягають методи очікувань, методи пов'язані з кліком і іншими речами, що не є добре, оскільки краще розділяти за таким принципом:
- методи по роботі з елементами лежать в своєму класі
- методи очікувань в своєму
- методи які узагальнені для перевикористання на інших всіх скронях або більшості - лежати в BasePage
в Джаві немає множинного спадкоємства, тому ти можеш наслідувати тільки BasePage. в якому будуть лежати тільки загальні методи для всіх скроневої. Методи по роботі з елементами вже туди не складеш. Виходить треба або ухіщряются, або робити каскадне спадкування: - UiElements успадковується від WaitingElementsts. WaitingElements в свою чергу успадковується від BasePage в якому реалізований Driver і так драйвер переходить в тести.
На допомогу ще можуть прийти хелпери, але доведеться їх смикати, що тест робить не дуже красивою ..
Ось напевно чому driver повинен бути ізольований від тестів і сторінок, тому що його ти будеш форматувати в різних класах свого застосування і всюди він повинен працювати ..
Навіть щоб зробити скріншот лістенером, тобі доведеться використовувати там драйвер. А самі тести вже будуть юзати реалізацію з цим драйвером. Тобто не доведеться піклуватися про драйвер, тому що це буде робити framework за тебе ..
Ініціалізація драйвера - це ж по суті виклик getDriver
Соррі, за незаплановану перерву.
Все таки хотілося б довести обговорення до какой то логічної точки.
Отже, на мою думку:
Умова для ініціалізації драйвера це запуск тесту або групи тестів
Тестів драйвер взагалі не потрібен.
Драйвер потрібен Поиде сторінок і тих компонентів, які зі сторінками працюють, і драйвер можливо туди варто просто передавати.
Міркування більш менш вірні?
Умова для ініціалізації драйвера це запуск тесту або групи тестів
Почнемо з того, що драйвер не запускається тести, а браузер. Тести запускає unit framework (наприклад, testng / junit). Для драйвера важливо не "що", а "де і коли". При цьому, "де" - в ізольованому потокобезпечна контексті. "Коли" - наприклад, перед [suite, test, class, method]. Ось тут вам відразу і завдання - зрозуміти, коли краще за все слід піднімати драйвер.
Драйвер потрібен Поиде сторінок
А навіщо сторінок потрібен драйвер? Сторінки - це шар вашого домену, а драйвер - фреймворка. Якщо ви виносите драйвер на рівень сторінок, це нічим не краще його використання в самих тестах.
Почнемо з того, що драйвер не запускається тести, а браузер.
Так, я розумію, що драйвер не запускається тести :). Я хотів написати, що умова для ініціалізації драйвера - запуск тестів. Ми запустили тести і драйвер повинен теж запуститися. Яким чином поки не важливо.
А навіщо сторінок потрібен драйвер? Сторінки - це шар вашого домену, а драйвер - фреймворка. Якщо ви виносите драйвер на рівень сторінок, це нічим не краще його використання в самих тестах.
Сторінках потрібен драйвер, тому що методи сторінок за допомогою драйвера щось роблять на базовому рівні - методи дозволяють працювати з елементами сторінки і здійснювати якісь дії. Яким чином можна мінімізувати залежність сторінки від драйвера?
Сторінках потрібен драйвер, тому що методи сторінок за допомогою драйвера щось роблять на базовому рівні
Тобто якщо у вас є 10 сторінок, і у всіх потрібно вводити якісь значення в input поля, ви в кожній сторінці будете дублювати driver.findElement (locator) .sendKeys (text) по відношенню до кожного полю, так?