Interaction testing — test qilinayotgan komponentning hamkor dependencylar bilan qanday aloqa qilganini tekshiradigan usul. Natijaviy state bilan birga yoki uning o‘rniga metod chaqiruvi, argument, son, tartib va chaqirilmaslik holati assertion qilinadi. Mock object va spy bu turdagi testning asosiy vositalaridir.
Kuzatiladigan protokol
Komponentning muhim xulqi ba’zan uning chiqish qiymatida ko‘rinmaydi. Masalan, audit event publish qilinishi, tranzaksiya rollback qilinishi yoki to‘lov faqat bir marta yuborilishi kerak. Interaction testi shu hamkorlik protokolini tekshiradi.
Assertionlar quyidagilarni ifodalashi mumkin:
- metod aynan bir marta chaqirildi;
- chaqiruv kerakli argumentlarni oldi;
- xato holatida notification yuborilmadi;
begindan keyincommitchaqirildi;- retryda gateway maksimal uch marta chaqirildi.
Tartib faqat biznes semantikasi talab qilsa tekshiriladi. Mustaqil log va metric chaqiruvlarining qat’iy tartibi implementatsiya tafsiloti bo‘lishi mumkin.
London va classical uslub
Mockist yoki London school unitning yaqin hamkorlarini mock qilib, interaction orqali xulqni tavsiflaydi. Classical uslub ichki haqiqiy obyektlardan ko‘proq foydalanib, yakuniy state’ni tekshiradi; faqat tashqi chegaralarni double qiladi. Bu atamalar metodologik yo‘nalish bo‘lib, barcha test biriga qat’iy tegishli bo‘lishi shart emas.
Interaction testi dizayndagi dependencylarni ochiq ko‘rsatadi. Biroq har collaboratorni mock qilish test setupini kattalashtiradi va code structurega bog‘laydi.
Over-specification
Test natija uchun ahamiyatsiz barcha chaqiruvni sanasa, refactor xulqni o‘zgartirmasdan testni buzadi. Masalan, repositorydan o‘qish ikki yordamchi metodga bo‘linsa, tashqi contract o‘zgarmagan. Assertion public port yoki muhim yon ta’sirga qaratiladi.
Strict mock kutilmagan har chaqiruvni xato qiladi. Bu protokol aniq bo‘lganda foydali, lekin logging yoki cache kabi qo‘shimcha collaborator kiritilganda ko‘p shovqin beradi. Lenient spy faqat kerakli interactionni tekshiradi.
Salbiy interaction
“Metod chaqirilmadi” assertioni xato sharoitida muhim bo‘lishi mumkin: validatsiya yiqilganda payment yuborilmasligi kerak. Biroq umumiy no more interactions tekshiruvi kelajakdagi zararsiz kuzatuvni bloklaydi. Salbiy assertion xavfli yon ta’sir bilan chegaralanadi.
Parallel yoki async kodda assertion callback tugashidan oldin bajarilmasligi kerak. Test completion signalini kutadi. Global chaqiruv tartibi schedulerga bog‘liq bo‘lsa, partial order yoki yakuniy chaqiruvlar to‘plami tekshiriladi.
Contract bilan bog‘liqligi
Mock expectation iste’molchining provider haqidagi taxminidir. Agar haqiqiy API boshqa argument, status yoki timeout semantikasiga ega bo‘lsa, interaction test yolg‘on ishonch beradi. Autospec metod signature driftini ushlaydi, ammo protokol ma’nosini to‘liq tekshirmaydi.
Consumer-driven contract real provider yoki stub contractini sinab, bu bo‘shliqni kamaytiradi. Integration testi serialization va tarmoq qatlamini ham qamrab oladi.
Command va query
Qiymat qaytaruvchi query uchun state/result assertion ko‘pincha tabiiy. Yon ta’sir yaratuvchi command uchun interaction muhim bo‘lishi mumkin. Bu qat’iy qoida emas: commanddan keyingi state ham tekshiriladi, query esa cache bilan interaction qilishi mumkin. Test eng barqaror kuzatiladigan contractni tanlaydi.
Verification va xato xabari
Ko‘p mock bir vaqtda tekshirilsa, umumiy “expectation failed” xabari sababni yashiradi. Har muhim collaboratorga ma’noli nom va aniq matcher beriladi. Argumentdagi katta obyekt to‘liq tenglik bilan solishtirilganda xato diffi shovqinli bo‘lishi mumkin; test biznes uchun muhim maydonlarni tekshiradi.
Arxitektura signali
Bir unit test o‘nlab mock talab qilsa, classning mas’uliyati ortiqcha yoki dependency graph juda keng bo‘lishi mumkin. Bu avtomatik refactor buyrug‘i emas, lekin cohesion va boundaryni qayta ko‘rish uchun signal. Facade yoki domain service muhim interactionlarni bitta port ortiga jamlashi mumkin.
Bog‘liq tushunchalar
Mock object, Spy, State-based testing, Test double, Autospec, Contract testing