Acceptance Test-Driven Development, qisqacha ATDD — funksiyani implementatsiya qilishdan oldin biznes vakili, dasturchi va testchi birgalikda qabul mezonlarini konkret misollar orqali aniqlaydigan ishlab chiqish yondashuvidir. Misollar bajariladigan acceptance testlarga aylanishi mumkin va jamoaga “tayyor” natija qanday ko‘rinishini oldindan kelishishga yordam beradi.
Ish jarayoni
ATDD odatda talab yoki user storyni muhokama qilish bilan boshlanadi. Ishtirokchilar asosiy oqim, chegaraviy holat, xato sharti va kuzatiladigan natijalarni aniqlaydi. Noaniq “tez”, “qulay” yoki “to‘g‘ri” kabi mezonlar o‘lchanadigan yoki tekshiriladigan ifodaga aylantiriladi.
Kelishilgan misollar avval test sifatida yoziladi va hali funksiya yo‘qligi sabab muvaffaqiyatsiz bo‘ladi. Dasturchi zarur kodni yaratadi, testlar o‘tadi va refactoring bajariladi. Test keyingi regressiyada ham ishlaydi. Biroq yondashuvning asosiy qiymati faqat avtomatlashtirish emas, implementatsiyadan oldingi umumiy tushunishdir.
Qabul mezonlari
Acceptance test tizimning foydalanuvchi yoki biznesga ko‘rinadigan xatti-harakatini tekshiradi. Masalan, to‘lov rad etilganda buyurtma tasdiqlanmasligi, mablag‘ yechilmasligi va foydalanuvchiga aniq status qaytishi talab qilinishi mumkin. Test ichki method necha marta chaqirilganiga emas, tashqi natijaga tayanadi.
Mezonlar happy path bilan cheklanmaydi. Limit, ruxsat, takroriy so‘rov, vaqt tugashi va tashqi servis xatosi kabi holatlar riskga qarab tanlanadi. Barcha mumkin bo‘lgan kombinatsiyani acceptance darajasiga joylash sekin va mo‘rt to‘plam yaratadi; past darajadagi variantlar unit yoki component testlarda tekshiriladi.
ATDD, BDD va TDD
ATDD qabul mezonlari va jamoaviy misollarga urg‘u beradi. BDD ubiquitous language va xatti-harakatni Given–When–Then kabi shaklda ifodalashi mumkin. Amaliy loyihada ular kesishadi va bir xil vositalardan foydalanadi. TDD esa ko‘pincha dasturchining kichik kod birliklarini test-first siklida loyihalashiga qaratilgan.
Bir yondashuv boshqasini avtomatik almashtirmaydi. Acceptance test biznes natijani tasdiqlasa, unit test algoritm va komponent chekka holatlarini tez tekshiradi. Testlar piramidasida kamroq, ma’noli acceptance test va ko‘proq tez past darajadagi testlar qayta aloqani muvozanatlashtiradi.
Avtomatlashtirish chegarasi
Qabul testi UI, API yoki domain service darajasida bajarilishi mumkin. Brauzer foydalanuvchi oqimini to‘liq ko‘rsatadi, ammo sekin va selector o‘zgarishiga sezgir. API darajasi tezroq va barqarorroq, lekin rendering yoki client integratsiyasini tekshirmaydi. Daraja test maqsadiga qarab tanlanadi.
Test ma’lumoti mustaqil va takrorlanuvchan bo‘ladi. Har scenario kerakli holatni yaratadi, boshqa test natijasiga bog‘lanmaydi va yakunda iz qoldirmaydi. Vaqt, tasodifiy qiymat va tashqi provider nazorat qilinadi. Production credential va real mijoz ma’lumoti test muhitida ishlatilmaydi.
Living documentation
Test nomi va misol biznes tili bilan yozilsa, to‘plam amaldagi spetsifikatsiya vazifasini bajaradi. O‘tmayotgan yoki doim o‘chirib qo‘yilgan test hujjat sifatida ishonchni yo‘qotadi. Talab o‘zgarganda test, kod va tegishli izoh bir o‘zgarish ichida yangilanadi.
Natija hisobotida qaysi acceptance criterion buzilgani, kutilgan va amaldagi holat hamda diagnostika ko‘rsatiladi. Maxfiy ma’lumot logdan tozalanadi. Flaky test mahsulotdagi regressiya bilan aralashmasligi uchun uning sababi topilib tuzatiladi.
Jamoaviy mas’uliyat
Acceptance mezonini faqat testchi yakka tartibda yozsa, biznes niyati va implementatsiya cheklovi kech aniqlanishi mumkin. Three Amigos deb ataladigan hamkorlikda mahsulot, development va test nuqtayi nazarlari birlashtiriladi. Yakuniy misollar umumiy kelishuv bo‘lib, test natijasi barcha tomon uchun bir xil ma’noni bildiradi.
Bog‘liq tushunchalar
Acceptance test, BDD, TDD, Example mapping, Specification by example, User story, Test automation