Stub — test qilinayotgan kodga oldindan belgilangan javoblarni beradigan sodda test double. U haqiqiy database, API, clock yoki boshqa dependency o‘rnida ishlashi mumkin. Stubning asosiy vazifasi test uchun kerakli input sharoitini yaratishdir; method necha marta chaqirilganini tekshirish odatda ikkinchi darajali.
Stub yordamida test tashqi tizim holatiga bog‘lanmaydi va deterministic bo‘ladi.
Oddiy misol
User service tashqi repositorydan ma’lumot oladi.
Test stub repository yaratadi:
find_user(7) → User(id=7, active=True)
Service shu javob asosida ishlaydi.
Test yakuniy natijani tekshiradi.
Canned response
Stub ko‘pincha oldindan yozilgan javob qaytaradi.
Misollar:
Har test o‘z ssenariysiga mos javobni tanlaydi.
Stub va mock
Stub nima qaytarishga urg‘u beradi.
Mock esa qanday chaqirilganini tekshiradi.
Masalan, stub payment provider success qaytaradi; mock esa charge(100) bir marta chaqirilganini tasdiqlaydi.
Frameworkda bir obyekt ikkala rolni bajarishi mumkin.
Stub va fake
Fake soddalashtirilgan, ammo ishlaydigan implementation.
Masalan, in-memory repository create, update va searchni bajaradi.
Stub esa ko‘pincha aniq input uchun fixed javob beradi.
Katta behavior kerak bo‘lsa fake tushunarliroq bo‘lishi mumkin.
Function stub
Eng sodda stub oddiy function:
def current_time():
return fixed_time
Dependency callable sifatida uzatiladi.
Maxsus mocking framework shart emas.
Oddiy stub testni o‘qishni osonlashtiradi.
Class stub
Interface’ga mos kichik class yoziladi.
Masalan:
StubEmailSender
StubPaymentGateway
StubUserRepository
Class testlar orasida qayta ishlatilishi mumkin.
Juda ko‘p konfiguratsiya qo‘shilsa u murakkab fake’ga aylanadi.
Error ssenariysi
Haqiqiy servisdagi xatoni kutish noqulay.
Stub kerakli xatoni darhol beradi:
Shu orqali fallback va error handling test qilinadi.
Ketma-ket javob
Retry logic uchun stub birinchi chaqiriqda xato, keyin muvaffaqiyat qaytarishi mumkin.
Masalan:
[TimeoutError, TimeoutError, Success]
Chaqiriqlar soni oshsa default natija yoki aniq xato belgilanadi.
Parameterga bog‘liq javob
Stub barcha inputga bir xil natija bermasligi mumkin.
Masalan:
id=1 → active user
id=2 → blocked user
boshqa → not found
Bu mapping yoki kichik callback bilan amalga oshiriladi.
Behavior real contractdan ortiq murakkablashmasligi kerak.
Clock stub
Vaqtga bog‘liq testlar uchun fixed clock ishlatiladi.
Test:
holatlarini aniq boshqaradi.
System clockni kutish yoki sleep qilish talab qilinmaydi.
Random stub
Random generator fixed qiymat yoki oldindan belgilangan ketma-ketlik qaytaradi.
Bu ID, token yoki tanlovga bog‘liq testni deterministic qiladi.
Security testda haqiqiy randomness sifati alohida tekshiriladi.
Stub cryptographic generator o‘rnida productionga chiqmasligi kerak.
HTTP stub
API client o‘rniga fixed HTTPga o‘xshash response beriladi.
Body, status va header saqlanadi.
Agar code actual serialization va URLni tekshirishi kerak bo‘lsa, mock HTTP server kuchliroq integration testi beradi.
Client methodini stub qilish faqat yuqori qatlamni test qiladi.
File system stub
File o‘qish methodi tayyor content qaytaradi.
Bu real diskga bog‘liqlikni kamaytiradi.
Path normalization, permission va disk-full holatlari uchun temporary directory yoki fake file system kerak bo‘lishi mumkin.
Har test darajasiga mos double tanlanadi.
Minimal behavior
Yaxshi stub faqat testga kerak bo‘lgan behaviorni implement qiladi.
Real dependency’ning barcha imkoniyatini ko‘chirishga urinish maintenance xarajatini oshiradi.
Stub production classning yashirin ikkinchi nusxasiga aylanmasligi kerak.
Contractga moslik
Stub return type, nullability va exception behavior bo‘yicha real interface’ga mos bo‘lishi kerak.
Real API yangi required field qo‘shsa eski stub testlarni noto‘g‘ri o‘tkazishi mumkin.
Shared contract schema, type check va integration test qo‘llanadi.
Test setup
Stub testning arrange bosqichida yaratiladi.
Masalan:
- blocked user qaytaradigan stub;
- service instance;
- method chaqiruvi;
- access rad etilganini tekshirish.
Setup ssenariy sababini aniq ko‘rsatadi.
Global stub xavfi
Barcha testlar uchun bitta global mutable stub ishlatilsa bir test settingi boshqasiga qolishi mumkin.
Har test yangi instance yaratadi yoki holat reset qilinadi.
Parallel testlarda shared state race condition yaratadi.
Stub server
Tashqi service’ga o‘xshash lokal HTTP server ham stub deb atalishi mumkin.
U route va response’larni boshqaradi.
Bunda applicationning haqiqiy HTTP clienti, serialization va timeout ishlaydi.
Bu oddiy method stubdan ko‘ra integrationga yaqin.
Test piramidasidagi o‘rni
Unit testda function yoki class stub keng ishlatiladi.
Integration testda fake service yoki containerized dependency kuchliroq signal beradi.
E2E testda real yoki sandbox integration ishlatilishi mumkin.
Bir xil vazifa uchun barcha test darajasida stub ishlatish real integration xatolarini yashiradi.
Default behavior
Stub kutilmagan input olsa jim null qaytarish o‘rniga aniq xato berishi mumkin. Bu test setup’dagi xatoni tez topadi. Agar real dependency default javobga ega bo‘lsa, stub shu contractni takrorlaydi.
Stublarni qayta ishlatish
Umumiy stub helperlar foydali, ammo barcha testlar uchun ulkan universal stub yaratish yomon. Har domain boundary uchun kichik, ma’noli va minimal implementation saqlanadi.
Bog‘liq tushunchalar
Stub, Test double, Mock, Fake, Spy, Unit testing, Dependency injection, Canned response, HTTP stub, Contract testing