"Unit testing" nima? U qanday ishlaydi?
3/20

Mastercarddagi birinchi vazifam unit test yozish va loyiha testlar bilan qoplanganlik darajasini (test coverage) 20% dan 75-80% oshirish ekanini aytgandim oldinroq. Shu vazifani tugatganim (bir oycha oldin) sababli o'zim yaxshiroq tushungan narsalar haqida aytib ketmoqchiman.


"Unit test" o'zi nima?

Rasmiyroq ta'rifga ko'ra "unit testing" — bu dasturni individual tarzda testlash mumkin bo'lgan mayda qismlarga, unitlarga bo'lib, ular to'g'ri ishlashini (avtomatlashtirilgan) testlar orqali tekshirish.

Unit testing yoki Test Driven Development (TDD) nimaligi tushuntirilgan video yoki maqolalarni ko'rsangiz u yerda asosan "uchburchak yuzasini topish", "o'lchovlarni konverstatsiya qilish" kabi oddiy va real loyihalarda juda kam uchraydigan misollarni ko'rasiz. Bu narsadan qochish uchun men o'z ta'rifimni MVC freymvorklar, aniqrog'i Service-Repository Pattern bilan tushuntirib beraman.

Yuqoridagi pattern bo'yicha asosiy biznes logika Service classlar ichida yotadi. Ular o'z navbatida ba'zi kichik kalkulyatsiyalar uchun yordamchi (utility) classlarni chaqirishi yoki bazalar bilan ishlash vaqtida repositorylarga murojaat qilishi mumkin.

Unit testlarni yozishda esa siz o'zingiz uchun "unit" nima ekanini aniqlab olishingiz kerak. Service metodlarini testlamoqchi bo'lsangiz, uni yordamchi classlar bilan qo'shib testlamoqchimisiz yoki faqat metodlar o'zinimi? Lekin, odatda unit testlar ichiga Repository — baza bilan ishlash kiritilmaydi. Sababi unit testlar oddiy, tez va yengil bo'lishi kerak.

O'zingiz uchun unit nima ekanini aniqlab olgandan keyin uni boshqa bog'liqliklardan (dependency) izolatsiyalab, haqiqiy unit holatga keltirib olish kerak. Buning uchun bir yo'la Dependency Injection va Mocking haqida tushuncha olib ketish kerak.

Dependency Injection — bu shunchaki biror class to'liq ishlashi uchun boshqa bir class yoki uning metodiga bog'liqligi bor degani. Masalan Controller class Service classga dependent, Service Class Repositoryga.

Mocking — bu "unit"ning bog'liqliklari o'rniga soxta / mock obyektlar yaratib, ularning metodlarini o'zingiz xohlagan ko'yga solish )

Shulardan kelib chiqib:

Unit Testing — bu dasturingizning siz aniqlab olgan unitlari uchun ularning bog'liklari qanday ishlashini hisobga olmagan holatda (avtomatlashtirilgan) testlash

Unit testing qanday ishlaydi / yoziladi?

Endi qisqacha MVC va Service-Repository Pattern uchun unit test (deyarli) qanday bo'lishini ko'rsatsam:

@Mock
UserRepository userRepository;

@AutoWired
UserService service;

@Test
public void testSave() {
User user = new User(1, "Name", "Surname");
given(userRepository.save(any()).willReturn(user);

User savedUser = service.save(userDto);
assertEquals(userDto.getId(), savedUser.getId());

then(userRepository).should().save();
}

Bu kod to'liq ishlamasa ham, tushunib olish uchun yetarli.

1. Birinchi qismda biz Repository uchun Mock yaratib olyapmiz va uning save() metodi chaqirilganda nima qaytishi kerakligini aytyapmiz. Ya'ni bu yerda real holatda dependency to'g'ri ishlaydimi yo'qmi bizni qiziqtirmaydi. Biz testlayotgan unit — Servicening save() metodi.

2. Shundan keyin, aytaylik request parametrlaridan yasab olinadigan userDto obyektini service save metodiga berib yuboramiz va qaytgan natijani biz bergan parametr bilan mosligini testlab ko'ramiz.

3. Oxirida service class rostdan ham repositoryning save metodini (faqat bir marta) chaqiryaptimi testlab olamiz.

Bu qisqacha Unit Testing nimaligi va u MVC dasturda qanday ko'rinishi haqida edi. Keyingi postda Unit Test, Testing o'zi nima uchun kerakligi haqida qisqacha aytib o'taman.

#softwareengineering

Professional blog | Linkedin | Shaxsiy blog