Flaky test — dastur kodi va sinov sharoiti o‘zgarmagan bo‘lsa ham, ayrim ishga tushirishlarda muvaffaqiyatli, boshqalarida esa muvaffaqiyatsiz yakunlanadigan avtomatlashtirilgan test. Bunday test haqiqiy regressiyani barqaror ko‘rsatmaydi: uning natijasi vaqt, bajarilish tartibi, tashqi xizmat, tasodifiy qiymat yoki resurs holatiga bog‘lanib qoladi. Shu sababli flaky test testlar to‘plamiga bo‘lgan ishonchni pasaytiradi.
Beqarorlik manbalari
Ko‘p uchraydigan sabab — vaqtga noto‘g‘ri bog‘lanish. Masalan, test asinxron operatsiya tugashini tekshirish o‘rniga qat’iy ikki soniya kutadi. Tez kompyuterda bu vaqt yetadi, yuklangan CI serverida esa yetmasligi mumkin. Tarmoq kechikishi, DNS javobi yoki uchinchi tomon API xizmatining holati ham natijani o‘zgartiradi.
Umumiy holatning testlar orasida bo‘lishilishi yana bir manbadir. Bir test ma’lumotlar bazasida yozuv qoldirsa, keyingi test boshlang‘ich holat toza deb taxmin qilishi mumkin. Testlar parallel yoki boshqa tartibda bajarilganda xato paydo bo‘ladi. Joriy sana, vaqt zonasi, lokal, tasodifiy sonlar generatori va fayl tizimidagi vaqtinchalik nomlar nazorat qilinmasa, xuddi shunday beqarorlik yuz beradi.
Aniqlash va qayta ishlab chiqarish
Bitta muvaffaqiyatsiz natija testning flaky ekanini isbotlamaydi; kodda haqiqiy nuqson bo‘lishi mumkin. Tashxis uchun bir xil commit ustida test ko‘p marta, alohida va to‘liq to‘plam tarkibida bajariladi. Ishga tushirish tartibi, tasodifiy urug‘ — seed, operatsion tizim, kutubxona versiyasi va resurs yuklamasi qayd etiladi. Xatolik jurnali faqat yakuniy istisnoni emas, hodisalar ketma-ketligini ham ko‘rsatishi lozim.
Quyidagi belgilar beqarorlikka ishora qiladi:
- test qayta ishga tushirilganda kod o‘zgarmasdan o‘tib ketadi;
- xato faqat parallel bajarilishda kuzatiladi;
- muvaffaqiyatsizlik vaqti yoki muhiti doimo bir xil emas;
- kutish muddati oshirilganda xato kamayadi, ammo yo‘qolmaydi;
- test yakka bajarilganda o‘tib, to‘plam ichida yiqiladi.
Barqarorlashtirish usullari
Asinxron jarayonda qat’iy sleep o‘rniga kuzatilayotgan holat ma’lum chegaragacha kutiladi. Test ma’lumotlari har bir holat uchun alohida yaratiladi va yakunda tozalanadi. Tashqi xizmatlar zarur bo‘lmagan birlik testlarida boshqariladigan test dublidan foydalaniladi; integratsion testda esa xizmatning tayyorligi aniq tekshiriladi. Vaqt bilan ishlaydigan kodga boshqariladigan soat, tasodifiy jarayonga qayta ishlatish mumkin bo‘lgan seed beriladi.
Testni ko‘r-ko‘rona qayta urinish bilan yashirish nuqsonni bartaraf etmaydi. Retry mexanizmi vaqtincha diagnostika ma’lumoti berishi mumkin, biroq birinchi muvaffaqiyatsizlik saqlanishi va test beqaror sifatida hisobga olinishi kerak. Aks holda haqiqiy regressiya “ikkinchi urinishda o‘tdi” degan natija ichida yo‘qoladi.
Test jarayoniga ta’siri
Flaky test tez-tez uchrasa, ishlab chiquvchilar qizil natijani jiddiy qabul qilmay qo‘yadi. CI jarayoni asossiz bloklanadi, tekshiruvlar qayta ishga tushiriladi va yetkazib berish vaqti uzayadi. Ba’zi jamoalar bunday testni vaqtincha karantinga ajratadi: u asosiy buildni to‘xtatmaydi, ammo alohida bajarilib, egasi va tuzatish muddati bilan kuzatiladi. Karantin testni o‘chirib yuborish emas, nosoz signalni boshqarish chorasi hisoblanadi.
Beqarorlik darajasi muvaffaqiyatsiz ishga tushirishlar ulushi bilan o‘lchanishi mumkin. Biroq juda kam takrorlanadigan xato ham muhim: u poyga holati yoki resurs sizib chiqishi kabi ishlab chiqarish muammosining belgisi bo‘lishi ehtimol. Shuning uchun baholashda chastota bilan birga xatoning tabiati va qamrab olingan funksiyaning muhimligi ham hisobga olinadi.
Bog‘liq tushunchalar
Test automation, CI, Race condition, Integration testing, Test environment, Retry