IT suhbat

#mock#test Unit test yozishda biror sinfning private modifikatorli maydoniga o'zimizga kerakli qiymat berish uchun org.springframework.test modulining ReflectionTestUtils sinfidan foydalanishimiz mumkin. Aytaylik, biz RateService sinf metodlarini test qilmoqchimiz. U yerda private modifikatorli rateUrl nomli maydon bor va uni @Value annotatsiyasi orqali qiymat o'zlashtiradigan qilib yozganmiz. Bu holda aynan shu maydonga MockWebServer manzilini o'zlashtirish uchun quyidagicha yondoshsak bo'ladi: ReflectionTestUtils.setField(rateService, "rateUrl", String.format("http://%s:%d", mockBackEnd.getHostName(), mockBackEnd.getPort())); Agar bu sinf sizda topilmayotgan bo'lsa, spring-boot-starter-test (spring boot loyihalari uchun) yoki spring-test(spring framework loyihalari uchun) dependency'larini qo'shishingiz kerak bo'ladi. @it_suhbat

#mock vs #spy Mock — sinf yoki interfeysning skletini yasab beradi va unga so'rov bo'lganda o'zini qanday tutishini sozlashimizga, test davomida bu sinf metodlariga qanday so'rovlar bo'lganligini qayd qilib, tekshirishimizga yordam beradi. Spy — sinfning haqiqiy obyektini hosil qiladi va xuddi mock'dagi kabi ta'sirlarni tekshirish imkoniyatini beradi. Savol: Qachon mock ishlatish kerak va qachon spy ishlatish kerak? Javob: Misol uchun, unit test jarayonida qandaydir adapter(tashqi servis bilan bog'lovchi, misol uchun REST) service bor va undan qaytgan natija ObjectMapper yordamida mapping qilinadi. Bu yerda adapter servis mock sifatida ishlatilishi mumkin. Ya'ni u o'zini haqiqiy servisdek tutmaydi, tashqi servisga so'rov yubormaydi. Biz oldindan tayyorlab qo'ygan javobni qaytarib bersa bo'ldi. ObjectMapper esa spy bo'ladi. Sababi u qaytarilgan natijani haqiqatan mapping qilishi kerak. O'zining metodlarini to'laqonli bajarishi kerak. Shu bilan birga biz uning metodlariga murojaat bo'lgan yoki yo'qligini ham bemalol aniqlashimiz mumkin bo'ladi. @it_suhbat

#mock#MANGA#FAANG#Amazon#interview#algorithm Iskandar aka bilan hozirgina suhbatning ikkinchi qismini o'tkazdik. Bu safar texnik suhbat bo'ldi, aynan algoritm bo'yicha. Yarim soatdan ko'proq davom etgan suhbat davomida medium darajadagi masala ishladim. Javobim to'liq accept olmadi, qaysidir testda fail bo'ldi. Lekin bu haqida so'radim, ya'ni agar masala to'liq qabul qilinmasa suhbat muvaffaqiyatsiz bo'ladimi deb. Ular bu qo'rqinchli emasligini va asosan masalani ishlashda quyidagi narsalarga e'tibor qaratishni maslahat berdilar: — masalaning shartini to'g'ri tushunganlikni tasdiqlab olish uchun test holatlarda qanday javob bo'lishini tekshirtirib olish, ya'ni input va output; — way of thinking, ya'ni nima qilmoqchi bo'lganingizni gapirib, tushuntirib, qanday fikrlayotganingizni yetkazib masala ishlash. Men xato qilibman, masala berilganidan keyin qog'oz va qalab olib o'zimcha yechishga kirishib ketdim, bunga tanbex berdilar; — debugging, ya'ni hayolda kodni kompilyatsiya qilib, har bir qatordagi kodga qanaqa qiymat kelayotgani va u nima javob qaytarayotganini tekshirib, suhbat o'tkazuvchiga jonli debugging qilib berish va shu jarayonda aniqlanadigan xato-kamchiliklarni chiroyli bartaraf etish. Demak, masala to'liq qabul qilinmasa, true yoki false bo'lib, o'tdi-o'tmadi hal bo'lmas ekan. Suhbat oluvchi va ishga qabul qiluvchilar uchun dasturchining o'ylash texnikasi, g'oyalari, muxokama qilish qobiliyati va zehni muhim ekan. O'z ustimizda ishlashni davom ettiramiz, keyingi bosqichga chiqish vaqti yaqinlashmoqda :) @it_suhbat