Test first — production koddagi o‘zgarishdan oldin kutilgan xatti-harakatni avtomatik test shaklida yozish yondashuvi. Test yangi API qanday ishlashi, qaysi input qabul qilinishi va qanday natija qaytishini oldindan aniqlashtiradi. Test first TDDning muhim qismi, biroq har test-first jarayon to‘liq Red-Green-Refactor intizomiga ega bo‘lishi shart emas.
Contractni oldindan ifodalash
Kod mavjud bo‘lmaganda test implementationga emas, iste’molchi nuqtai nazariga qarashga majbur qiladi. Method nomi, argument, return type va error semantics testda ishlatiladi. Bu API usability’sini erta ko‘rsatishi mumkin.
Masalan, expired credential uchun test oldin AuthenticationExpired errorini kutsa, production kod aniq domain contract yaratadi. Keyin driverning tasodifiy exceptionini tashqariga chiqarish testdan o‘tmaydi.
Ish jarayoni
- Kichik behavior yoki defect tanlanadi.
- Shu behaviorni ko‘rsatuvchi test yoziladi.
- Testning kerakli sabab bilan yiqilishi tekshiriladi.
- Production kod testni o‘tkazadi.
- Barcha testlar bajariladi va kod tuzilmasi yaxshilanadi.
Defect uchun avval reproducing test yozilishi tuzatishning muammoni haqiqatan qamraganini ko‘rsatadi. Test tuzatishdan oldin qizil, keyin yashil bo‘ladi.
Test after bilan farqi
Test after mavjud implementatsiyani ko‘rib yozilgani uchun uning strukturasini takrorlash yoki faqat baxtli yo‘lni tasdiqlash ehtimoli yuqori. Test first expectedni requirementdan olishga yordam beradi. Biroq yaxshi test after ham mustaqil contract va edge case’larni tekshirishi mumkin.
| Yondashuv | Odatdagi boshlanish nuqtasi |
|---|---|
| Test first | Kutilgan behavior va API |
| Test after | Mavjud implementation |
| Characterization | Hozirgi noma’lum behavior |
| Acceptance-first | Tashqi foydalanuvchi ssenariysi |
Yondashuvning nomi test sifatini avtomatik kafolatlamaydi.
Dizayn feedbacki
Test setup’i o‘nlab global dependency talab qilsa production unit haddan tashqari bog‘langan bo‘lishi mumkin. Test first dependency injection, pure function va kichik responsibility’ni rag‘batlantiradi. Shunga qaramay, faqat mock qulayligi uchun real domainni sun’iy interface’lar bilan parchalash ham ortiqcha design.
Test public behaviorni oson ifodalasa API ko‘pincha iste’molchi uchun ham tushunarli bo‘ladi. Internal private methodni testlash uchun visibility’ni oshirish design feedbackini noto‘g‘ri hal qiladi.
Noaniq talablar
Requirement noaniq bo‘lsa test yozish savollarni yuzaga chiqaradi: empty input natijasi nima, rounding qaysi qoida, timeout retry qilinadimi. Bu savollar product yoki domain owner bilan aniqlashtiriladi. Taxminni testga yozish uni avtomatik to‘g‘ri qilmaydi.
Exploratory kod orqali yangi algoritm yoki API imkoniyati o‘rganilishi mumkin. Spike tashlab yuboriladi yoki keyin topilgan contract test-first bilan qayta yoziladi. Tadqiqot va production design ikki xil maqsad.
Integration boundary
Database, browser yoki tashqi API bilan testni oldin yozish sekinroq bo‘lishi mumkin. Controlled fake yoki contract test tashqi behaviorni ifodalaydi, tanlangan integration test real semantikani tasdiqlaydi. Barcha dependency’ni mock qilish integratsiya xatosini yashirmaydi.
Schema migration test first yozilganda oldingi va yangi application version bir vaqtda ishlash holati qamraladi. Faqat yakuniy schema happy path’i yetarli emas.
Cheklovlar
Test first usability research, security review, performance profiling va formal verification o‘rnini bosmaydi. Noto‘g‘ri oracle noto‘g‘ri behaviorni mustahkamlaydi. Test faqat ifodalangan misol va property doirasida signal beradi.
Bog‘liq tushunchalar
Test-Driven Development, Red-Green-Refactor, Test after, Acceptance testing, Characterization test, Regression test, Test oracle