Як уникати повторення коду в автоматизації?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Я QA Manual, але керівництво вирішило, що автомейшином мені буде стати не складно) Тому попросили у мене автоматизувати тести на маркетплейс. Я використовую playwright, пишу UI тести і зіштовхнувся з першою проблемою: код повторюється в багатьох місцях.

Наприклад: мені потрібно написати тести на сторінку Payment history. Для цього мені потрібно кожного тесту створювати нового юзера, додавати продукт в корзину, робити оплату. Чи можливо якось уникати цього повторення? Надсилати запити по API? Підкажіть, будь ласка)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

З тестами та DRY не завжди так очевидно.
Що я маю на увазі. Припустимо я написав 10 тестів, а для 11го треба трошки змінити «універсальну функцію створення юзера». Не проблема, можна додати параметр. Але з часом кількість параметрів може зростати і в якісь момент ми отримаємо ситуацію, коли перші 10 тестів (які теж мають працювати) вже зовсім не ті і тестують не те, що на початку.
Як на мене, іноді простіше копіювати, ніж виносити в функції. Особливо в тестах, бо кожен тест має бути самодостатнім.

Для себе знайшов такий вихід з подібної ситуації:
1. Маєш універсальну функу, яка може створити будь-якого юзера з купую опціональних аргументів в додачу до обов’язкових
2. Маєш набір інших функцій: createFreeUser, createTrialUser, createPayedUser і бла-бла-бла, які по суті просто викликають універсальну функу з різними наборами аргументів

З мінусів — неймінг цих специфічних функцій =)

Звісно це все добро можна загорнути у фабрику чи білдер, кому як більше подобається

А де гарантія того, що умовна

createFreeUser

буде робити так само, коли треба буде додати ще 1 функцію типу createFreeUserException1 ?
Я розумію про що це, просто універсальність — не завжди вихід. Я не кажу, що це погано, просто не варто робити принцип DRY релігійним.

Не вловив суть питання. Якщо додається createFreeUserException1, то createFreeUser ніяк не міняється і створює такого самого юзера як і створювала. Відповідно у старих тестах не вилазять випадкові артефакти

Ви ж все одно додаєте код та параметри десь до універсальної функції, тобто де гарантія що додавання

createFreeUserException1

ніяк не вплине на

createFreeUserException1

? Бо це ж по факту обгортка над деякою createUserUniversal.

1. Нові параметри додаються в

createUserUniversal

вкінець і як опціональні
2. іменовані параметри взагалі супер допомагають =)

От про те я й кажу. В якійсь момент ця сама

createUserUniversal

буде просто мішаниною з if’aми і зрозуміти що воно таке без автора та пляшки буде нереально.

Для цього мені потрібно кожного тесту створювати нового юзера, додавати продукт в корзину, робити оплату. Чи можливо якось уникати цього повторення? Надсилати запити по API?

Це виноситься в метод, який раниться перед кожним тестом. Можна і через API робити сетап необхідної інфраструктури, чому ні

Я не знаю про

playwright

. Але це легко робити з Cucumber. Можна з BDD а можна і без.

Але використовуючи

Cucumber

всі ті дії (

створювати нового юзера, додавати продукт в корзину, робити оплату

) будуть повторюватись, хіба ні?

Ти робиш функції які виконують ці кроки. Потім робиш одну функцію , наприклад
def prepare_test_environment
і викликаєш її перед кожним тестом.
в тебе може бути декілька функцій для різних типів початкових станів.

Він, наче, хотів створювати юзера всього один раз. Але він це робить через playwright.
Виглядає так, що треба
1) запустити тести по тегу для створення юзера та додавання товарів. Дочекатись завершення
2) запустити всі інші тести

Якщо один раз то створити вручну і використовувати готового юзера. Але в такому разі треба якось очищати перед кожним тестом, переконатися, що нічого не лишилося після попередніх тестів.
Або робити нового юзера для кожного запуску і в кінці видаляти. Для цього має бути нормальне АПІ для створенні і видалення юзерів

це легко робити з Cucumber

Нащо тут ця зайва абстракцiя? Можна обiйтись запитами до API

Підписатись на коментарі