Red-Green-Refactor — Test-Driven Development’ning uch bosqichli qisqa sikli: avval kerakli xatti-harakatni ko‘rsatuvchi yiqiladigan test yoziladi, keyin testni o‘tkazuvchi kod yaratiladi, so‘ng testlar yashil holatda qolgan holda kod tuzilmasi yaxshilanadi. Siklning kichikligi feedbackni tez va xato manbasini aniq qiladi.
Red
Red bosqichida yangi test bajarilib, kutilgan sabab bilan yiqilishi tekshiriladi. Agar test birinchi urinishdayoq o‘tsa, behavior allaqachon mavjud, test hech narsani tekshirmayapti yoki scenario noto‘g‘ri tuzilgan bo‘lishi mumkin.
Failure xabari kutilgan va actual natijani ko‘rsatadi. Setup error, import muammosi yoki test infratuzilmasi buzilishi haqiqiy Red emas. Avval test harness to‘g‘rilanadi.
Green
Green bosqichining maqsadi barcha testni tez yashil qilish. Faqat yangi test emas, regression suite ham o‘tishi kerak. Kod hozirgi requirementni to‘liq bajaradi, ammo kelajak ehtimollari uchun keraksiz framework qurmaydi.
Minimal implementatsiya boundary misolini hard-code qilishi mumkin, keyingi test esa umumlashtirishga majbur qiladi. Triangulation bir nechta misol orqali asl qoida paydo bo‘lishiga yordam beradi. Hard-code productionda qolib ketmasligi uchun testlar requirementni yetarli qamraydi.
Refactor
Refactor behaviorni o‘zgartirmasdan internal designni yaxshilaydi. Duplication olib tashlanadi, nomlar aniqlashtiriladi, uzun method bo‘linadi va dependency boundary yaxshilanadi. Har qadam kichik bo‘lib, suite tez-tez ishlaydi.
| Refactor obyekti | Misol |
|---|---|
| Production kod | Method ajratish, nomlash, duplication |
| Test kodi | Fixture builder, assertion helper |
| Interface | Responsibility’ni toraytirish |
| Data model | Type va invariantni ifodalash |
Refactor vaqtida yangi behavior topilsa alohida Red sikl boshlanadi. “Refactor” nomi ostida feature qo‘shish failure sababini aralashtiradi.
Sikl hajmi
Bir sikl bir necha daqiqa bo‘lishi mumkin, lekin qat’iy vaqt talabi yo‘q. Muhim mezon — failure yuz bersa oxirgi kichik o‘zgarishlar ichida sababni topish. Bir kunlik Green bosqichi testning juda katta behavior tanlaganini ko‘rsatishi mumkin.
Katta feature vertikal kichik slice’larga bo‘linadi: parserning bitta qoidasi, API’ning bitta error holati yoki calculationning bitta boundary’si. Faqat database schema, keyin service, keyin UI kabi uzun gorizontal qatlamlar uzoq vaqt integratsiyalanmagan qolishi mumkin.
Testlarning roli
Testlar refactoring safety net beradi, ammo faqat tekshirilgan behavior uchun. Coverage bo‘shlig‘i bo‘lsa refactor o‘sha joyda regression keltirishi mumkin. Characterization test legacy behaviorni oldin qayd etadi.
Implementation detailga bog‘langan test refactorda xatti-harakat o‘zgarmasa ham yiqiladi. Public output, state transition va muhim collaborator contractiga qaratilgan testlar tuzilma o‘zgarishiga chidamliroq.
CI bilan ishlashi
Lokal sikl tez unit testlardan foydalanadi. Commitdan oldin kengroq suite, CI’da integration va contract testlar bajariladi. Faqat lokal selected test yashil bo‘lgani main branch xavfsizligini isbotlamaydi.
Kichik commitlar sikl tarixini tushunarli qiladi, ammo har Red holat main branchga yuborilmaydi. Integratsiya nuqtasida build yashil bo‘lishi kerak.
Noto‘g‘ri talqinlar
Green “eng tez hack, sifat ahamiyatsiz” degani emas. Kod xavfsiz va requirementga to‘g‘ri bo‘ladi; faqat hali kerak bo‘lmagan abstraksiya qurilmaydi. Refactor esa kosmetik formatlash bilan cheklanmay, design qarzini faol boshqaradi.
Red test sonini ko‘paytirish uchun emas, navbatdagi behaviorni ifodalash uchun yoziladi. Noto‘g‘ri test production kodni noto‘g‘ri tomonga boshqaradi, shu sabab expected requirementdan olinadi.
Bog‘liq tushunchalar
Test-Driven Development, Test first, Refactoring, Regression testing, Characterization test, Unit testing, Triangulation