Fixture

Fixture — test ishlashi uchun oldindan tayyorlanadigan ma’lumot, obyekt, fayl, database holati yoki environment. Fixture test boshlanishida kerakli sharoitni yaratadi va test tugagach resurslarni tozalashi mumkin. Atama test frameworklarga qarab data yoki setup-teardown mexanizmini anglatadi.

Masalan, aktiv user, vaqtinchalik database, API client yoki tayyor JSON fayl fixture bo‘lishi mumkin.

Data fixture

Oldindan yozilgan test ma’lumoti:

user.json
products.yaml
sample.csv

Test file’ni yuklab, realga yaqin input bilan ishlaydi.

Data fixture katta va tushunarsiz bo‘lsa test nima sababdan o‘tganini aniqlash qiyinlashadi.

Setup fixture

Test oldidan resurs yaratadi:

• database connection;
• temporary directory;
• authenticated client;
• mock server;
• application instance;
• test user.

Framework fixture qiymatini test functionga parameter sifatida berishi mumkin.

Teardown

Fixture yaratgan resurs test tugagach tozalanadi.

Masalan:

• file o‘chiriladi;
• transaction rollback qilinadi;
• server to‘xtatiladi;
• connection yopiladi;
• environment variable tiklanadi.

Test exception bilan tugasa ham teardown ishlashi kerak.

Scope

Fixture qancha vaqt yashashini scope belgilaydi.

Keng turlar:

• function;
• class;
• module;
• session.

Function scope eng yaxshi izolyatsiya beradi.

Session scope qimmat setupni bir marta bajaradi, lekin shared state xavfini oshiradi.

Dependency

Bir fixture boshqasiga bog‘lanishi mumkin.

Masalan:

database
→ user_repository
→ active_user
→ authenticated_client

Framework dependency graph bo‘yicha ularni kerakli tartibda yaratadi.

Circular dependencyga yo‘l qo‘yilmaydi.

Factory fixture

Bitta tayyor user o‘rniga user yaratadigan function qaytaradi.

Test turli parametr bilan bir nechta obyekt yaratishi mumkin:

make_user(active=True)
make_user(active=False)

Bu duplicationni kamaytiradi va test maqsadini aniq qiladi.

Database fixture

Database test uchun schema va sample record tayyorlanadi.

Usullar:

• migration;
• transaction;
• seed;
• factory;
• snapshot restore;
• temporary database.

Har testdan keyin holat tiklanadi.

Production database bilan ishlash qat’iyan ajratiladi.

Transaction rollback

Test transaction ichida bajarilib, oxirida rollback qilinadi.

Bu tez cleanup beradi.

Biroq background worker yoki boshqa connection transactiondagi uncommitted ma’lumotni ko‘rmasligi mumkin.

Commit behaviorini test qilish uchun boshqa isolation usuli kerak.

Static fixture

Repositoryda saqlanadigan doimiy fayl.

Afzalligi — ko‘rish va qayta ishlatish oson.

Kamchiligi — schema o‘zgarganda ko‘p fayl eskiradi.

Katta JSON ichidagi testga aloqasiz fieldlar maintenance’ni qiyinlashtiradi.

Dynamic fixture

Test vaqtida code orqali yaratiladi.

Factory kerakli minimum fieldlarni beradi.

Dynamic qiymatlar testlar orasida collisionni kamaytiradi.

Random data ishlatilsa seed va failure holatidagi qiymatlar log qilinadi.

Golden fixture

Expected output file sifatida saqlanadi.

Masalan:

• rendered HTML;
• JSON response;
• compiler output;
• screenshot;
• generated document.

Test yangi outputni golden file bilan solishtiradi.

Yangilash jarayoni code reviewdan o‘tishi kerak.

Parametrli fixture

Bir fixture bir nechta configuration bilan testni takror ishga tushiradi.

Masalan:

• SQLite va PostgreSQL;
• admin va oddiy user;
• light va dark theme;
• turli locale.

Bu test matrix yaratadi.

Kombinatsiyalar soni haddan tashqari ko‘paymasligi kerak.

Autouse fixture

Ayrim frameworklarda test parameter sifatida so‘ramasa ham fixture avtomatik ishlaydi.

Masalan, har testda timezone yoki environmentni reset qilish.

Autouse yashirin setup yaratadi.

Faqat barcha testlar uchun zarur bo‘lgan holatlarda ishlatiladi.

Fixture va mock

Fixture test environment yoki data tayyorlaydi.

Mock dependency behaviorini almashtiradi va interactionni tekshirishi mumkin.

Mockning o‘zi fixture orqali yaratilishi mumkin.

Ular qarama-qarshi tushunchalar emas.

Fixture va seed

Seed application yoki test database’ga boshlang‘ich ma’lumot yozadi.

Fixture aniq testga kerakli holatni ifodalaydi.

Global katta seed testlarni yashirin dependencyga bog‘laydi.

Har testga minimum kerakli data yaratiladi.

Izolyatsiya

Shared fixture mutable bo‘lsa testlar tartibga bog‘lanadi.

Bir test obyektni o‘zgartirib, keyingisiga ta’sir qiladi.

Immutable data, copy yoki function scope ishlatiladi.

Parallel run alohida database schema yoki tenantdan foydalanishi mumkin.

Performance

Database va browserni har testda qayta ishga tushirish sekin.

Kengroq scope performance’ni yaxshilaydi.

Biroq tezlik uchun isolation yo‘qotilsa flaky testlar paydo bo‘ladi.

Qimmat immutable resurs session, mutable data function scope’da saqlanishi mumkin.

Nomi va o‘qilishi

Fixture nomi texnik implementationni emas, ma’noli holatni ifodalasa test tushunarli bo‘ladi:

blocked_user
empty_cart
expired_token

fixture1 yoki data2 test maqsadini yashiradi.

Maxfiy ma’lumot

Real production dump fixture sifatida ishlatilsa personal va secret data test repositoryga tushishi mumkin.

Data synthetic yoki anonymized bo‘ladi.

Token, email va telefonlar haqiqiy userga tegishli bo‘lmaydi.

Builder

Murakkab obyekt uchun builder default valid qiymatlar beradi va test faqat o‘zgartiradigan fieldni ko‘rsatadi:

OrderBuilder().expired().with_total(100000).build()

Bu katta constructor va keraksiz fieldlarni testdan yashiradi, lekin defaultlar business ma’nosini buzmasligi kerak.

Migration bilan moslik

Static database fixture schema yangilanganda ishlamay qolishi mumkin. Fixturelar migration pipeline orqali yaratilsa production schema bilan yaqinroq bo‘ladi. Eski serialized fixture uchun version converter kerak bo‘lishi mumkin.

Bog‘liq tushunchalar

Test fixture, Setup, Teardown, Test data, Factory, Database seed, Golden file, Parametrized testing, Pytest fixture, Test isolation, Temporary resource