Test-Driven Development (TDD) — dastur xatti-harakatini ifodalovchi avtomatik testni production koddan oldin yozish va kichik Red–Green–Refactor sikllarida rivojlantirish usuli. Avval yiqiladigan test talabni aniq ko‘rsatadi, keyin testdan o‘tadigan eng sodda kod yoziladi, so‘ng xatti-harakatni o‘zgartirmasdan tuzilma yaxshilanadi.
Red bosqichi
Developer navbatdagi kichik behavior uchun test yozadi va uni bajarib failure’ni ko‘radi. Test to‘g‘ri sabab bilan yiqilishi kerak. Syntax error, noto‘g‘ri setup yoki database ulanishi yo‘qligi “red” maqsadini bajarmaydi, chunki u kerakli xatti-harakat yetishmasligini ko‘rsatmaydi.
Test nomi scenario va natijani bildiradi. Masalan, “expired token rad etiladi” bitta aniq behavior. Juda katta use case uchun birinchi test yozilsa implementatsiya sikli uzoq va sabab noaniq bo‘ladi.
Green bosqichi
Testni o‘tkazadigan eng kichik to‘g‘ri kod yoziladi. “Eng kichik” qasddan yomon kod degani emas; hozirgi misol uchun ortiqcha kelajak abstraksiyasi qurilmaydi. Barcha avvalgi testlar ham yashil qoladi.
Hard-code qilish ba’zan triangulation uchun vaqtinchalik qadam bo‘lishi mumkin. Ikkinchi va uchinchi misol umumiy qoida talab qilganda kod generalizatsiya qilinadi. Faqat bitta literal bilan yakunlash production requirementni bajarmaydi.
Refactor bosqichi
Yashil testlar himoyasida duplication, nomlash, responsibility va dependency tuzilmasi yaxshilanadi. Refactor observable behaviorni o‘zgartirmaydi. Har kichik o‘zgarishdan keyin suite ishlatiladi.
Test kodi ham refactor qilinadi: fixture soddalashtiriladi, ma’noli helper yaratiladi va takror kamaytiriladi. Haddan tashqari abstrakt test helper scenario’ni yashirmasligi kerak.
| Bosqich | Asosiy savol |
|---|---|
| Red | Kerakli behaviorni test aniq ifodaladimi |
| Green | Eng kichik to‘g‘ri yechim testdan o‘tdimi |
| Refactor | Tuzilma yaxshilandimi va behavior saqlandimi |
Dizaynga ta’siri
Test first dependency’larni explicit qilish, kichik interface va ajratilgan responsibility’ni rag‘batlantiradi. Test yozish juda qiyin bo‘lsa class ko‘p global state yoki tashqi I/Oga qattiq bog‘langan bo‘lishi mumkin. Bu dizayn signali, lekin har qiyin test yomon production design degani emas.
Faqat test qulayligi uchun public API’ni buzish yoki production methodlarni ochish to‘g‘ri emas. Behavior public boundary yoki mos collaborator orqali tekshiriladi.
TDD va test darajalari
TDD faqat mayda unit test bilan cheklanmaydi. Outside-in usul acceptance testdan boshlanib, ichki unit sikllarga o‘tadi. Integration boundary uchun database yoki message broker bilan test ham kerak.
Mock barcha dependency’ni almashtirsa noto‘g‘ri contract yashirinishi mumkin. Consumer-driven contract va tanlangan integration testlar unit siklini to‘ldiradi.
Legacy kod
Testsiz mavjud kodda behavior noma’lum bo‘lishi mumkin. Characterization test hozirgi xatti-harakatni qayd etadi, so‘ng kichik o‘zgarish TDD siklida qilinadi. Hozirgi behaviorning o‘zi defect bo‘lsa test uni doimiy requirement sifatida muzlatmasligi kerak.
Seam yaratish, dependency injection va strangler usuli eski modulni bosqichma-bosqich testlanadigan qiladi. Butun tizimni birdan qayta yozish TDDning sharti emas.
Cheklovlar
TDD requirement to‘g‘riligini, usability yoki performance’ni avtomatik kafolatlamaydi. Noto‘g‘ri expected bilan yozilgan test noto‘g‘ri kodni boshqaradi. Exploratory prototipda muammo maydoni hali noma’lum bo‘lsa avval tadqiqot, keyin topilgan behaviorni test bilan mustahkamlash mumkin.
Jamoaviy qo‘llanish
TDD sikli commit va code review’dan oldingi lokal dizayn faoliyatidir. Jamoa test nomlari, fixture usuli va integration chegaralari bo‘yicha umumiy kelishuvga ega bo‘lsa, yangi testlar yagona suite ichida tushunarli qoladi. Pair programming’da test navbatdagi kichik maqsadni ikki dasturchi uchun ham ko‘rinadigan qiladi.
Bog‘liq tushunchalar
Red-Green-Refactor, Test first, Unit testing, Refactoring, Characterization test, Acceptance testing, Continuous integration