Test fixture — testni ma’lum va takrorlanadigan boshlang‘ich holatda bajarish uchun kerak bo‘ladigan ma’lumot, obyekt, konfiguratsiya va resurslar to‘plami. Fixture oddiy input obyektidan database yozuvlari, vaqtinchalik katalog yoki ishga tushirilgan test serverigacha bo‘lishi mumkin. Uning vazifasi har test uchun nazorat qilinadigan context yaratishdir.
Fixture tarkibi
Fixture quyidagilarni o‘z ichiga olishi mumkin:
- model obyektlari va ularning bog‘lanishlari;
- test database schema va seed yozuvlari;
- konfiguratsiya va environment qiymatlari;
- mock, fake yoki stub dependencylar;
- vaqtinchalik fayl va kataloglar;
- server, container yoki message broker instance’i.
Fixture testning Arrange bosqichini standartlashtiradi. Test faqat scenario uchun muhim farqlarni ko‘rsatadi.
Scope
Function-scoped fixture har test uchun yangi yaratiladi va kuchli isolation beradi. Class yoki module scope qimmat resursni bir nechta testga bo‘lishadi. Session scope butun test run davomida bitta instance ishlatadi. Scope kattalashgan sari tezlik oshishi mumkin, lekin shared mutable state va test tartibiga bog‘liqlik xavfi ortadi.
Read-only service container session scope bo‘lishi, har test uchun database transaction alohida ochilishi mumkin. Scope dependency graphga mos bo‘lishi kerak: qisqa fixture uzoq fixturega tayana oladi, teskarisi frameworkda muammo tug‘dirishi mumkin.
Ma’lumot yaratish usullari
Statik fixture fayli aniq va ko‘rish oson, ammo schema o‘zgarsa ko‘p fayl yangilanadi. Factory yoki builder faqat kerakli fieldlarni berib, qolganiga valid default yaratadi. Random generator edge-case topishi mumkin, lekin seed va failure inputi saqlanmasa test qayta ishlab chiqarilmaydi.
Katta production dump fixture sifatida sekin, maxfiy va tushunarsiz. Test maqsadiga mos minimal representative data ishlatiladi. Integration performance testi uchun data hajmi alohida generator bilan yaratiladi.
Database fixture
Har test transaction ichida bajarilib, teardown’da rollback qilinishi mumkin. Bu tez isolation beradi, lekin production kodining commitdan keyingi hooklari yoki alohida connectionlari rollback chegarasidan tashqarida qolishi mumkin. Truncate to‘liqroq, ammo sekin va foreign key tartibini talab qiladi.
Migration bilan schema yaratish productionga yaqin. Tayyor schema snapshot tezroq, lekin migration drift xavfi bor. CI davriy ravishda noldan migration yo‘lini ham tekshiradi.
Setup va teardown
Fixture setup resursni yaratadi, testga beradi va yakunda teardown qiladi. Setup o‘rtada xato qilsa ham allaqachon yaratilgan resurslar tozalanishi kerak. Context manager yoki framework yield fixture cleanupni finally semantikasiga bog‘laydi.
Teardown assertion xatosini yashirmasligi kerak. Cleanup xatosi alohida report qilinadi. Tashqi cloud resursiga noyob test ID va TTL tag berish uzilgan testdan qolgan resursni keyinchalik yig‘ishga yordam beradi.
Fixture smell
Har test uchun ulkan “universal” fixture qaysi ma’lumot muhimligini yashiradi. Bir fieldni o‘zgartirish kutilmagan o‘nlab bog‘lanishni buzadi. Scenario-specific builder va kichik kompozitsion fixturelar aniqroq.
Test fixture production kodi bilan bir xil business helperdan foydalansa, ikkalasi bir xil xatoni takrorlashi mumkin. Kutilgan qiymat mustaqil va o‘qilishi oson shaklda beriladi.
Fixture dependency
Fixture boshqa fixture’dan foydalanib composition yaratishi mumkin: database fixture transaction fixture’ga, API client esa running serverga tayanadi. Dependency graph setup tartibini, teskari graph teardown tartibini belgilaydi. Circular dependency frameworkda xato bo‘ladi. Yashirin autouse fixture barcha testga ta’sir qilsa, uning mavjudligi o‘qishni qiyinlashtiradi; global xavfsiz sozlamalar bilangina cheklanadi.
Bog‘liq tushunchalar
Setup, Teardown, Factory, Test data, Test isolation, Temporary resource