TDD va birlik testi nima [tarjima]

Ushbu maqola The Complete Software Career Guide kitobining bo'limiga moslashtirilgan. Uning muallifi Jon Sonmez buni yozadi va o'z veb-saytida ba'zi boblarni joylashtiradi.

Yangi boshlanuvchilar uchun qisqacha lug'at

Birlik testi yoki birlik testi - bu dasturning manba kodining alohida modullarini to'g'riligini tekshirish imkonini beruvchi dasturlash jarayoni. G'oya har bir ahamiyatsiz funktsiya yoki usul uchun testlarni yozishdir. Regression test - bu manba kodining allaqachon sinovdan o'tgan sohalarida xatolarni aniqlashga qaratilgan dasturiy ta'minot sinovlarining barcha turlarining umumiy nomi. Bunday xatolar - dasturga o'zgartirishlar kiritilgandan so'ng, ishlashni davom ettirishi kerak bo'lgan narsa ishlamay qolsa - regressiya xatolari deyiladi. Qizil natija, muvaffaqiyatsiz - testning muvaffaqiyatsizligi. Kutilgan natija va haqiqiy natija o'rtasidagi farq. Yashil natija, o'tish - ijobiy test natijasi. Haqiqiy natija olinganidan farq qilmaydi. *** Men sinovdan o'tgan rivojlanish (TDD) va birlik testi bilan juda aralash munosabatdaman, sevgidan nafratga va yana qaytib boraman. Men ashaddiy muxlis edim va shu bilan birga bu va boshqa "eng yaxshi amaliyotlar" dan foydalanishga shubha bilan qarardim. Mening munosabatim sababi dasturiy ta'minotni ishlab chiqish jarayonlarida jiddiy muammo yuzaga kelganiga asoslanadi: ishlab chiquvchilar va ba'zan menejerlar ma'lum vositalar va metodologiyalardan faqat "eng yaxshi amaliyotlar" ga tegishli bo'lgani uchun foydalanadilar. Ulardan foydalanishning haqiqiy sababi noma'lumligicha qolmoqda. Bir kuni men ma'lum bir loyiha ustida ishlay boshladim va bu jarayonda biz juda ko'p birlik testlari bilan qamrab olingan kodni o'zgartirishimiz haqida xabar oldim. Hazil emas, ularning 3000 ga yaqini bor edi.Bu odatda yaxshi belgi, ishlab chiquvchilar ilg'or metodologiyalardan foydalanayotganligidan dalolat beradi. Ushbu yondashuv bilan kod ko'pincha tuzilgan bo'lib, u yaxshi o'ylangan arxitekturaga asoslanadi. Bir so'z bilan aytganda, testlarning mavjudligi meni xursand qildi, chunki bu mening dasturchilar ustozi sifatida ishimni osonlashtirdi. Bizda allaqachon birlik testlari bo'lganligi sababli, men qilishim kerak bo'lgan narsa ularni qo'llab-quvvatlash uchun ishlab chiqish guruhini ulash va o'z kodimizni yozishni boshlash edi. Men IDE (integratsiyalashgan rivojlanish muhiti) ni ochdim va loyihani yukladim. Bu katta loyiha edi! Men "birlik testlari" deb nomlangan papkani topdim. "Ajoyib", deb o'yladim men. - Keling, uni ishga tushiramiz va nima bo'lishini ko'ramiz. Bu bor-yo‘g‘i bir necha daqiqa davom etdi va hayratlanarlisi, barcha testlar o‘tdi, hammasi yashil rangda bo‘ldi ( “yashil” – testning ijobiy natijasi. Kod kutilganidek ishlayotganligidan dalolat beradi. Qizil rang “qobiliyatsizlik” yoki muvaffaqiyatsizlikni bildiradi, keyin kod to'g'ri ishlamagan holat mavjud - tarjimonning eslatmasi ). Ularning barchasi sinovdan o'tdi. Shu payt ichimdagi shubha uyg'ondi. Qanday qilib uch ming birlik sinovlari o'tkazildi va ular bir vaqtning o'zida hammasini oldilar va ijobiy natija berdilar? Uzoq amaliyotimda, kodda bitta salbiy birlik testisiz loyiha ustida ishlashni boshlagan vaqtimni eslay olmadim. Nima qilsa bo'ladi? Qo'lda tekshiring! ChY eng oshkora emas, bitta tasodifiy testni tanladi, lekin u nimani tekshirayotgani darhol aniq bo'ldi. Ammo u bilan ishlashda men bema'ni narsani payqadim: testda kutilgan natija bilan hech qanday taqqoslash yo'q (ta'kidlaydi)! Ya'ni, aslida hech narsa tekshirilmagan ! Sinovda ma'lum qadamlar bor edi, ular amalga oshirildi, ammo test oxirida u haqiqiy va kutilgan natijalarni solishtirish kerak bo'lgan joyda hech qanday tekshiruv yo'q edi. "Test" hech narsani sinab ko'rmadi. Men boshqa testni ochdim. Bundan ham yaxshiroq: natija bilan taqqoslash operatori sharhlandi. Ajoyib! Bu sinovdan o'tishning ajoyib usuli, shunchaki muvaffaqiyatsizlikka olib keladigan kodni izohlang. Men yana bir testni tekshirdim, keyin boshqasi ... Ularning hech biri hech narsani tekshirmadi. Uch ming sinov va ularning barchasi mutlaqo foydasiz. Birlik testlarini yozish va birlik testini tushunish va testga asoslangan rivojlanish (TDD) o'rtasida katta farq bor.

Birlik testi nima?

Birlik testining asosiy g'oyasi kodning eng kichik "birligini" sinab ko'radigan testlarni yozishdir. Birlik testlari odatda dasturning manba kodi bilan bir xil dasturlash tilida yoziladi. Ular ushbu kodni sinash uchun bevosita yaratilgan. Ya'ni, birlik testlari boshqa kodning to'g'riligini tekshiradigan koddir. Men "sinov" so'zini kontekstda juda erkin ishlataman, chunki birlik testlari qaysidir ma'noda test emas. Ular hech narsani boshdan kechirmaydilar. Aytmoqchimanki, siz birlik testini ishga tushirganingizda, odatda, ba'zi kodlar ishlamayotganini topa olmaysiz. Siz buni testni yozish paytida topasiz, chunki test yashil rangga aylanguncha kodni o'zgartirasiz. Ha, kod keyinroq o'zgarishi mumkin va keyin sizning testingiz muvaffaqiyatsiz bo'lishi mumkin. Shu ma'noda birlik testi regressiya testidir. Birlik testi oddiy sinovga o'xshamaydi, unda siz bir necha qadamlarni bajarishingiz kerak va siz dasturiy ta'minot to'g'ri ishlayaptimi yoki yo'qligini ko'rasiz. Birlik testini yozish jarayonida siz kod o'zi bajarishi kerak bo'lgan narsani qiladimi yoki yo'qligini bilib olasiz va test o'tguncha kodni o'zgartirasiz. Nega birlik testini yozmaysiz va u o'tganligini tekshirasiz? Agar siz bu haqda o'ylayotgan bo'lsangiz, birlik testlari juda past darajadagi ma'lum kod modullari uchun mutlaq talablarga aylanadi. Birlik testini mutlaq spetsifikatsiya sifatida o'ylashingiz mumkin . Birlik testi shuni aniqlaydiki, ushbu shartlar ostida ushbu maxsus kirishlar to'plami bilan siz ushbu kod birligidan olishingiz kerak bo'lgan chiqish mavjud. Haqiqiy birlik testi ko'pgina dasturlash tillarida - hech bo'lmaganda ob'ektga yo'naltirilgan - sinf bo'lgan eng kichik kogerent kod birligini aniqlaydi.

Ba'zan birlik testi nima deb ataladi?

Birlik testi ko'pincha integratsiya testi bilan aralashtiriladi. Ba'zi "birlik testlari" bir nechta sinflarni yoki katta kod birliklarini sinab ko'radi. Ko'pgina ishlab chiquvchilar birlik testlarini yozishlarini da'vo qilishadi, lekin ular aslida past darajadagi oq quti testlarini yozadilar. Bu yigitlar bilan bahslashmang. Bilingki, ular aslida integratsiya testlarini yozadilar va haqiqiy birlik testlari kodning eng kichik birligini boshqa qismlardan ajratilgan holda sinab ko'radi. Ko'pincha birlik testi deb ataladigan yana bir narsa bu kutilgan qiymatni tekshirmasdan birlik testlari. Boshqacha qilib aytganda, aslida hech narsani sinab ko'rmaydigan birlik testlari. Birlashtirilgan yoki birlashtirilmagan har qanday test qandaydir tekshirishni o'z ichiga olishi kerak - biz buni haqiqiy natijani kutilgan natija bilan tekshirish deb ataymiz. Aynan shu yarashuv sinovdan o'tish yoki muvaffaqiyatsizligini aniqlaydi. Har doim o'tib ketadigan sinov befoyda. Har doim muvaffaqiyatsiz bo'lgan sinov foydasiz.

Birlik testining qiymati

Nega men birlik sinovi ishqiboziman? Boshqa koddan ajratilgan eng kichik blokni emas, balki kattaroq kod bo'lagini, ya'ni "birlik testini" sinab ko'rishni o'z ichiga olgan umumlashtirilgan testni chaqirish nima uchun zararli? Ba'zi testlarim olingan va kutilgan natijalarni solishtirmasa, muammo nimada? Hech bo'lmaganda ular kodni bajaradilar. Men tushuntirishga harakat qilaman. Birlik sinovini o'tkazishning ikkita asosiy sababi bor. Birinchisi, kod dizaynini yaxshilashdir. Birlik testi haqiqatan ham sinov emasligini qanday aytganimni eslaysizmi? To'g'ri birlik testlarini yozganingizda, siz o'zingizni eng kichik kod birligini ajratishga majbur qilasiz. Ushbu urinishlar sizni kodning tuzilishidagi muammolarni aniqlashga olib keladi. Sinov sinfini ajratish va unga bog'liqliklarni qo'shmaslik juda qiyin bo'lishi mumkin va bu sizning kodingiz juda qattiq bog'langanligini tushunishingizga olib kelishi mumkin. Siz sinab ko'rmoqchi bo'lgan asosiy funksiya bir nechta modullarni o'z ichiga olganligini bilib olishingiz mumkin, bu sizning kodingiz etarli darajada izchil emasligiga ishonishingizga olib keladi. Birlik testini yozish uchun o'tirganingizda, siz to'satdan kod nima qilish kerakligini bilmasligingizni bilib olishingiz mumkin (va menga ishoning, bu sodir bo'ladi!). Shunga ko'ra, siz buning uchun birlik testini yozishingiz mumkin emas. Va, albatta, siz kodni amalga oshirishda haqiqiy xatoni topishingiz mumkin, chunki birlik testi sizni qutidan tashqarida o'ylashga va siz ko'rib chiqmagan turli xil ma'lumotlar to'plamini sinab ko'rishga majbur qiladi. Agar siz birlik testlarini yaratishda "eng kichik kod birligini boshqalardan ajratib sinab ko'ring" qoidasiga qat'iy rioya qilsangiz, siz ushbu kod va modullarning dizayni bilan bog'liq har qanday muammolarni topasiz. Dasturiy ta'minotni ishlab chiqishning hayot tsiklida birlik testi sinovdan ko'ra ko'proq baholash faoliyatidir. Birlik testining ikkinchi asosiy maqsadi dasturiy ta'minot xatti-harakatlarining past darajadagi spetsifikatsiyasi bo'lishi mumkin bo'lgan regressiya testlarining avtomatlashtirilgan to'plamini yaratishdir. Bu nima degani? Xamirni qo'zg'atsangiz, uni buzmaysiz. Shu nuqtai nazardan qaraganda, birlik testlari testlar, aniqrog'i regressiya testlari. Biroq, birlik testining maqsadi shunchaki regressiya testlarini yaratish emas. Amalda, birlik testlari kamdan-kam hollarda regressiyalarni ushlaydi, chunki siz sinab ko'rayotgan kod birligining o'zgarishi deyarli har doim birlik testining o'zida o'zgarishlarni o'z ichiga oladi. Kod “qora quti” sifatida sinovdan o'tkazilganda yuqoriroq darajada regressiya testi ancha samarali bo'ladi, chunki bu darajada kodning ichki tuzilishini o'zgartirish mumkin, tashqi xatti-harakatlar esa bir xil bo'lishi kutiladi. Birlik testlari o'z navbatida ichki tuzilmani tekshiradi, shunda bu struktura o'zgarganda birlik sinovlari muvaffaqiyatsiz bo'lmaydi. Ular yaroqsiz holga keladi va endi ularni o'zgartirish, tashlab yuborish yoki qayta yozish kerak. Endi siz ko'plab tajribali dasturiy ta'minot ishlab chiqaruvchilariga qaraganda birlik testining asl maqsadi haqida ko'proq bilasiz.

Sinovga asoslangan rivojlanish (TDD) nima?

Dasturiy ta'minotni ishlab chiqish jarayonida yaxshi spetsifikatsiya oltinga teng. TDD yondashuvi shundan iboratki, siz biron bir kod yozishdan oldin, avvalo, spetsifikatsiya sifatida xizmat qiladigan testni yozasiz, ya'ni kod nima qilishi kerakligini aniqlang. Bu juda kuchli dasturiy ta'minot ishlab chiqish kontseptsiyasi, lekin u ko'pincha noto'g'ri ishlatiladi. Odatda, testga asoslangan ishlab chiqish dastur kodini yaratishga rahbarlik qilish uchun birlik testlaridan foydalanishni anglatadi. Lekin, aslida, bu yondashuv har qanday darajada qo'llanilishi mumkin. Biroq, ushbu maqolada biz ilovamiz uchun birlik testidan foydalanamiz deb taxmin qilamiz. TDD yondashuvi hamma narsani o'zgartiradi va avval kod yozish va keyin ushbu kodni sinab ko'rish uchun birlik testlarini yozish o'rniga siz avval birlik testini yozasiz va keyin ushbu testni yashil qilish uchun kod yozasiz. Shu tarzda, birlik testi kodni ishlab chiqishni "haydovchi" qiladi. Bu jarayon qayta-qayta takrorlanadi. Siz kod nima qilishi kerakligi haqida ko'proq funksionallikni belgilaydigan boshqa testni yozasiz. Keyin test muvaffaqiyatli yakunlanishiga ishonch hosil qilish uchun kodni yozasiz va o'zgartirasiz. Yashil natijaga ega bo'lganingizdan so'ng, siz kodni qayta ishlashni boshlaysiz, ya'ni uni qisqaroq qilish uchun uni qayta ishlash yoki tozalash. Ushbu jarayonlar zanjiri ko'pincha "Qizil-yashil-refaktoring" deb nomlanadi, chunki birinchi navbatda birlik testi muvaffaqiyatsiz tugadi (qizil), keyin kod testga moslashish uchun yoziladi, muvaffaqiyatli bo'lishiga ishonch hosil qiladi (yashil) va nihoyat kod optimallashtiriladi ( refaktoring).

TDDning maqsadi nima?

Sinovga asoslangan ishlab chiqish (TDD), birlik testi kabi, noto'g'ri ishlatilishi mumkin. Qilayotgan ishingizni “TDD” deb atash va hattoki nima uchun bunday qilayotganingizni tushunmasdan amaliyotga amal qilish juda oson. TDD ning eng katta qiymati shundaki, sifat spetsifikatsiyalarini ishlab chiqarish uchun sinovlar o'tkaziladi. TDD aslida kodlash yozilgunga qadar avtomatik ravishda tekshirilishi mumkin bo'lgan aniq spetsifikatsiyalarni yozish amaliyotidir. Sinovlar eng yaxshi texnik xususiyatlardir, chunki ular yolg'on gapirmaydi. Ikki haftalik azob-uqubatlardan so'ng, ular "men buni umuman nazarda tutmaganman" kodini aytmaydilar. Testlar, to'g'ri yozilgan bo'lsa, o'tadi yoki muvaffaqiyatsiz bo'ladi. Sinovlar muayyan sharoitlarda nima bo'lishi kerakligini aniq ko'rsatadi. Shunday qilib, TDD ning maqsadi biz uni amalga oshirishni boshlashdan oldin nima qilishimiz kerakligini to'liq tushunishdir. Agar siz TDD bilan ish boshlayotgan bo'lsangiz va test nimani sinab ko'rishi kerakligini aniqlay olmasangiz, ko'proq savollar berishingiz kerak. TDD ning yana bir muhim roli kodni saqlash va optimallashtirishdir. Kodni saqlash qimmat. Men ko'pincha eng yaxshi dasturchi qandaydir muammoni hal qiladigan eng ixcham kodni yozgan odam deb hazil qilaman. Yoki bu muammoni hal qilishning hojati yo'qligini isbotlovchi va shu bilan kodni butunlay o'chirib tashlagan kishi, chunki aynan shu dasturchi xatolar sonini kamaytirish va dasturni saqlash xarajatlarini kamaytirishning to'g'ri yo'lini topdi. TDD dan foydalanib, siz hech qanday keraksiz kod yozmasligingizga amin bo'lishingiz mumkin, chunki siz faqat testlardan o'tish uchun kod yozasiz. YAGNI deb nomlangan dasturiy ta'minotni ishlab chiqish printsipi mavjud (sizga kerak bo'lmaydi). TDD YAGNI oldini oladi.

Odatda sinovga asoslangan ishlab chiqish (TDD) ish jarayoni

TDDning ma'nosini sof akademik nuqtai nazardan tushunish qiyin. Shunday qilib, keling, TDD seansining misolini ko'rib chiqaylik. Tasavvur qiling-a, stolingizga o‘tirib, foydalanuvchiga ilovaga kirish va parolni unutib qo‘ysa, parolini o‘zgartirish imkonini beruvchi funksiyaning yuqori darajadagi dizayni bo‘lishi mumkin deb o‘ylagan narsangizni tezda chizing. Siz tizimga kirish jarayoni uchun barcha mantiqni boshqaradigan sinfni yaratib, kirish funktsiyasini birinchi amalga oshirishdan boshlashga qaror qilasiz. Siz sevimli muharriringizni ochasiz va "Bo'sh kirish foydalanuvchining tizimga kirishiga to'sqinlik qiladi" deb nomlangan birlik testini yaratasiz. Siz birinchi navbatda Login sinfining (siz hali yaratmagan) namunasini yaratadigan birlik test kodini yozasiz. Keyin bo'sh foydalanuvchi nomi va parolni uzatuvchi Login sinfidagi usulni chaqirish uchun kod yozasiz. Nihoyat, siz kutilgan natijaga qarshi chek yozasiz, bo'sh loginli foydalanuvchi haqiqatda tizimga kirmaganligini tekshirasiz. Siz test o'tkazmoqchisiz, lekin u kompilyatsiya ham qilmaydi, chunki sizda Login sinfi yo'q. Siz ushbu vaziyatni tuzatasiz va tizimga kirish uchun ushbu sinfdagi usul bilan bir qatorda Login sinfini yaratasiz va foydalanuvchining tizimga kirganligini tekshirish uchun boshqasi. Hozirgacha siz ushbu sinfning funksionalligini va bizga kerak bo'lgan usulni amalga oshirmadingiz. Siz shu nuqtada testni o'tkazasiz. Endi u kompilyatsiya qiladi, lekin darhol muvaffaqiyatsiz bo'ladi. Endi siz kodga qaytasiz va testdan o'tish uchun funksiyani amalga oshirasiz. Bizning holatda, bu biz natijani olishimiz kerakligini anglatadi: "foydalanuvchi tizimga kirmagan". Siz testni qaytadan o'tkazasiz va endi u o'tadi. Keling, keyingi testga o'tamiz. Endi tasavvur qilaylik, "Foydalanuvchi to'g'ri foydalanuvchi nomi va parolni kiritgan bo'lsa, tizimga kirdi" deb nomlangan test yozishingiz kerak. Siz Login sinfini yaratadigan va foydalanuvchi nomi va parol bilan tizimga kirishga harakat qiladigan birlik testini yozasiz. Birlik testida siz Login sinfi foydalanuvchi tizimga kirganmi yoki yo'qmi degan savolga ha javob berishi kerakligi haqida bayonot yozasiz. Siz ushbu yangi testni bajarasiz va, albatta, u muvaffaqiyatsiz tugadi, chunki Login sinfingiz har doim foydalanuvchi tizimga kirmaganligini qaytaradi. Siz Login sinfiga qaytasiz va foydalanuvchi tizimga kirganligini tekshirish uchun ba'zi kodlarni kiritasiz. Bunday holda, siz ushbu modulni qanday izolyatsiya qilishni aniqlab olishingiz kerak bo'ladi. Hozircha buni qilishning eng oson yo'li testda ishlatgan foydalanuvchi nomi va parolni qattiq kodlash va agar ular mos kelsa, "foydalanuvchi tizimga kirdi" degan natijani qaytaring. Siz bu o'zgarishlarni amalga oshirasiz, ikkala testni ham bajarasiz va ikkalasi ham o'tadi. Keling, oxirgi bosqichga o'tamiz: siz yaratilgan kodga qaraysiz va uni qayta tashkil etish va soddalashtirish yo'lini qidirasiz. Shunday qilib, TDD algoritmi:

1. Test yaratildi.
2. Biz ushbu test uchun kod yozdik.
3. Kodni qayta tiklandi.

xulosalar

Ushbu bosqichda birlik sinovi va TDD haqida sizga aytmoqchi bo'lgan narsam shu. Aslida, kod modullarini ajratishga urinish bilan bog'liq ko'plab qiyinchiliklar mavjud, chunki kod juda murakkab va chalkash bo'lishi mumkin. Juda kam sonli sinflar to'liq izolyatsiyada mavjud. Buning o'rniga, ular bog'liqliklarga ega va bu bog'liqliklarda bog'liqliklar mavjud va hokazo. Bunday vaziyatlarni hal qilish uchun TDD faxriysi ob'ektlarni qaram modullarda almashtirish orqali alohida sinflarni ajratishga yordam beradigan masxaralardan foydalanadi. Ushbu maqola shunchaki umumiy ko'rinish va birlik sinovi va TDDga biroz soddalashtirilgan kirish, biz qo'g'irchoq modullar va boshqa TDD texnikasi haqida batafsil ma'lumot bermaymiz. G'oya sizga TDD va birlik testining asosiy tushunchalari va tamoyillarini berishdir, umid qilamanki, siz hozir mavjud. Asl - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/