➡️ЯК МОЖНА ПЕРЕВИКОРИСТОВУВАТИ ТЕСТОВІ АККАУНТИ НА CI?
Хочу поділитися тим, як я зазвичай роблю, можливо комусь буде корисно🫰
У тестуванні часто стикаємося з ситуацією, коли потрібні тестові користувачі, але іноді ми НЕ можемо їх постійно створювати наприклад через обмеження інфраструктури.
🔹Наприклад, фізично неможливо створювати нових користувачів через те, що потрібна двофакторна аутентифікація.
🔹Або, новий користувач може вимагати великої кількості апрувів - що робить процес автоматичного створення скриптом майже неможливим
🔹Деякі системи мають ліміти на кількість реєстрацій, або ж є технічні складнощі
Що часто робила я в такому випадку? - Це pool тестових юзерів.
Тобто:
▪️Тестові юзери створюються заздалегідь (один раз)
▪️Їхній статус відслідковується через спеціальний API чи базу даних.
▪️У тестах "беремо" доступного користувача, позначаємо його як "зайнятого", а після завершення тестів – повертаємо у статус "доступний".
Це може бути любий сервіс, який вам комфортний. У моєму випадку це була AWS Lambda
Приклад запиту для отримання юзера:
Приклад запиту для повернення юзера:
————
Так ми:
▪️Мінімізуємо витрати на створення нових користувачів.
▪️Уникаємо складних процесів із реєстрацією та підтвердженнями.
▪️Можемо паралелізувати тести
▪️Контролюємо використання тестових ресурсів.
Сууупер важливо пам‘ятати що тестового юзера після тестів треба завжди покласти назад.
Зажди, не важливо, тести пройшли, впали, чи щось інше. Завжди повертаємо юзера - бо інакше, вони в якийсь момент всі «будуть зайняті»
Тому сууупер важливо завжди робити always в кінці пайплайна:
Хочу поділитися тим, як я зазвичай роблю, можливо комусь буде корисно🫰
У тестуванні часто стикаємося з ситуацією, коли потрібні тестові користувачі, але іноді ми НЕ можемо їх постійно створювати наприклад через обмеження інфраструктури.
🔹Наприклад, фізично неможливо створювати нових користувачів через те, що потрібна двофакторна аутентифікація.
🔹Або, новий користувач може вимагати великої кількості апрувів - що робить процес автоматичного створення скриптом майже неможливим
🔹Деякі системи мають ліміти на кількість реєстрацій, або ж є технічні складнощі
Що часто робила я в такому випадку? - Це pool тестових юзерів.
Тобто:
▪️Тестові юзери створюються заздалегідь (один раз)
▪️Їхній статус відслідковується через спеціальний API чи базу даних.
▪️У тестах "беремо" доступного користувача, позначаємо його як "зайнятого", а після завершення тестів – повертаємо у статус "доступний".
Це може бути любий сервіс, який вам комфортний. У моєму випадку це була AWS Lambda
Приклад запиту для отримання юзера:
Отримати доступного користувача:
curl --silent --show-error --location --request GET \
"https://a2sgsj4bz0.execute-api.ap-southeast-1.amazonaws.com/prod/code" \
--header "x-api-key: $DISPENSER_API_KEY"
Відповідь:
{
"ID": "user1",
"Code": "12345",
"Email": "user1@test.com",
"Status": "in-use"
}
Приклад запиту для повернення юзера:
curl --silent --show-error --location --request PUT \
"https://a2sgsj4bz0.execute-api.ap-southeast-1.amazonaws.com/prod/user/cleanup" \
--header "Content-Type: application/json" \
--header "x-api-key: $DISPENSER_API_KEY" \
--data-raw '{
"user_id": "user1"
}'
Відповідь:
{
"message": "User user1 is now available.",
"updated_user": {
"ID": "user1",
"Code": "12345",
"Email": "user1@test.com",
"Status": "available"
}
}
————
Так ми:
▪️Мінімізуємо витрати на створення нових користувачів.
▪️Уникаємо складних процесів із реєстрацією та підтвердженнями.
▪️Можемо паралелізувати тести
▪️Контролюємо використання тестових ресурсів.
Сууупер важливо пам‘ятати що тестового юзера після тестів треба завжди покласти назад.
Зажди, не важливо, тести пройшли, впали, чи щось інше. Завжди повертаємо юзера - бо інакше, вони в якийсь момент всі «будуть зайняті»
Тому сууупер важливо завжди робити always в кінці пайплайна:
Приклад:
- run:
name: Cleanup Users
when: always