Як генерувати варіативні test data, передавати типізовану сутність через увесь сценарій і перевіряти цілісність її відображення на кожному API/UI кроці.
Примітка: конспект укладено за автоматичними українськими субтитрами; технічні терміни нормалізовано за контекстом відео.
Після цього уроку ви зможете
Побудувати generator валідної domain-сутності.
Залишити data creation видимим у arrange/preconditions.
Перевірити mapping тієї самої сутності в API та UI checkpoints.
Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.
Термін
Faker seed
Seed робить послідовність generated values відтворюваною в межах зафіксованої версії Faker; сам seed не замінює domain validation.
Приклад коду
Відтворюваний typed test object
from dataclasses import dataclass
from random import Random
rng = Random(42)
@dataclass(frozen=True)
class UserData:
email: str
age: int
def build_user() -> UserData:
return UserData(
email=f"user-{rng.randrange(1_000_000)}@example.test",
age=rng.randint(18, 80),
)
user = build_user()
assert "@" in user.email and 18 <= user.age <= 80
print(user)
Stdlib-приклад показує typed object, valid range і fixed seed без додаткової dependency.
Очікуваний результат: Друкується відтворюваний UserData, а assertion підтверджує базові constraints.
Практика
Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Результат: Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Окремий generator може повертати не одне поле, а цілісний User, Company або Product з усіма значеннями, які тест перевірятиме далі. Частина полів випадкова, частина належить до обмеженого набору, частина приймається як parameter. Такий обʼєкт є очікуваною моделлю даних сценарію; окремі actions використовують його для onboarding, create або update через API чи UI.
Генерацію важливих test data краще явно виконувати на початку тесту й передавати результат у helper, а не непомітно ховати всередині registerUser() чи createCompany(). Так сценарій показує свої preconditions, а той самий expected object доступний для подальших assertions. Business step може повернути оновлену модель, якщо система присвоїла ID, status або інші server-generated поля.
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає undefined, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
Між functions передають типізовані UserDto, ProductDetails, CompanyDetails або інші domain types замість розрізнених primitive values. Це робить required fields видимими, спрощує повторні assertions і зменшує ризик переплутати дані. Конкретні приклади реалізації розгортаються далі в курсі.