Додам ще по Tosca. Вірніше, не так по tosca, як по тому, що автор порівнює модуля із pageObject паттерном

До речі, така реалізація (для UI-компонентів) нагадує типовий Page Object Pattern, якби це реалізовувалось, наприклад, на Java

Автор (як і більшість автоматизаторів) спраймає пейдж-обджект модель невірно. Слід розрізняти PageObject з умовним PageFactory. PageObject — це **інтерфейс** до сторінки. Який містить **набір дій**, які можна зробити із сторінкою. Наприклад, «залогінитись» чи «заповнити реєстраційну форму». Пейдж-об`єкт, в якому є метод «дайМеніПолеЮзерНейм» — то вже порушення концепції, бо сторінка не призначена для того, щоб користувачу сайту видавати якісь поля. А от PageFactory — це якраз ота модель, що в тоска. Вона містить(створює) набір UI компонентів і відповідає лише за прив’язку ваших полів класу до відповідних UI елементів/компонентів. Точно так само як PageFactory відповідає за прив’язку елементів сторінки до полів класу. В цьому паттерни PageObject та PageFactory абсолютно протилежні. Бо PageObject відв’язує ваші **тести** від UI, а пейдж фекторі навпаки, робить прив’язку до UI. Обидві ці концепції зазвичай використовуються в межах одного фізичного класу джави. Цей клас має імпелентувати концепцію PageObject (тобто виглядати для інших як інтерфейс до сторінки) але всередині він використовує(чи може використовувати) PageFactory, інкапсулюючи його.
Відповідно до цього, наприклад, одна та сама ЛогінПейджа може мати безліч різних реалізацій. Як для двох схожих, але трохи різних сайтів, які ви зараз тестуєте (форма вводу адреси на сайті US та на сайті AE з різним набором полів), так і для ваших майбутніх фіч, коли з форми логіну зникнуть всі поля «юзернейм» і залишиться лише кнопка, яка вмикає камеру, щоб вам по морді лиця розпізнати та залогінити. І якщо у вас правильні пейдж-об’єкти, то основні флоу у вас будуть продовжувати працювати. бо всі тести будуть просити «залогінитись», а не намагатись ввести юзернейм в неіснуюче поле.
Кому цікаво більш детально — пошукайте в ютубі відео Simon Stewart — Scaling Selenium на каналі Heisenbug . там на 17 хвилині Саймон (хто не знає — автор веб-драйвера та концепції пейдж-об’єктів) пояснює це на прикладах.

Було цікаво коменти почитати, враховуючи, що клієнт нав’язує tosca. Але мені лише одне цікаво — як можна використовувати для автоматизації web-у інструмент, який не вміє шукати елементи по css? який розглядає атрибут class не як набір (set) значень, а як звичайний рядок,
Інструмент, який дозволяє автоматизувати нормальне розпізнавання елементів лише тоді, коли в елемента є унікальний ID. «нормальне» — я маю на увазі ситуацію, коли завтра на тестування зайде нова локалізація. Так. вони там десь прикрутили пошук по xpath, але... спробуйте знайти документацію, як ним правильно скористуватись. Також спробуйте знайти опис, чим відрізняються 2 алгоритми «search by anchor». Майже всі ті, хто пройшов ’сертифікацію’ тоски Сертифікація то окреме питання. Там в ’екзамені’ 5 простеньких питань, які гугляться за 2 хвилини — і година часу на відповідь, ще й з 2-ма спробами. Я сертифікований тоска спеціаліст (за вимогою роботодавця), але це та сертифікація, якої я сам соромлюсь. Бо після неї я максимум зможу автоматизувати їх тестовий сайт, який було створено під ту сертифікацію. Вже поісля початку ’роботи’ в тоска зрозумів, що найважливіший навик — це працювати мишою. Зокрема, ресайзити колонки в табличках, бо там ВСЕ в табличках.репорти, скріншоти... навіть if/then/else займає !!мінімум!! 9 рядків. Таке відчуття, що інструмент робили фанати екселю на лівому коліні, розвернувшись через праве плече. Окрема тема — табличка з пропертями для пошуку елементів. Там їх 100500 штук, з яких працюють біля 5ти.
Щодо середовища запуску. Як при сучасних реаліях дешевої linux-інфраструктури, докерів і тп клієнти погоджуються на оце диво, яке вимагає вінду та максимум один потік на одну машину? Колаборація між тими, хто створює модулі (прив’язку до UI) тут взагалі мінімальна. Є якийсь інструмент по мерджу модулів, але це ЄДИНЕ що тут можна мерджити. (а є ще тести, степи, таблиці з даними, і тп) На про які пейдж-об’єкти тут мова не йде, бо пейдж-об’єкт — то набір методів по роботі із частиною (об’єктом) сторінки, який ховає конкретну імпелементацію UI від тестів, роблячи їх незалежними від змін UI. Тут же модулі — це жорстка прив’язка до UI. Далі... купа різних груп параметрів, до яких абревіатури хз хто придумував. Buffer — B[name]. Але: Business Parameter — PL[], Test design parameter — XL[ ].
Загалом інструмент на стільки незручний, що важко описати. Перший тест, можливо, по гайду, в ньому легко зробити. Але щось пошукати по проекту, підфіксити, адаптувати, повидаляти непортібне — ну дуже важко. Особливо якщо в команди ще немає спільного підходу і бачення, як тести мають бути організовані, де і які параметри слід розміщати.