Test Data Builder — test uchun kerakli obyekt yoki ma’lumotlar grafigini tushunarli defaultlar va fluent sozlash metodlari orqali yaratadigan pattern. U har testda uzun constructor, tasodifiy fixture yoki keraksiz maydonlarni takror yozishni kamaytiradi. Test faqat tekshirilayotgan xatti-harakat uchun muhim qiymatlarni ko‘rsatadi.
Asosiy tuzilma
Builder valid obyekt yaratadigan minimal default holatni saqlaydi. withEmail, withoutPermission yoki asExpired kabi metodlar ayrim atributni o‘zgartiradi va builderni qaytaradi. build yakuniy immutable obyektni yaratadi. Misol:
user = UserBuilder().with_role("editor").as_active().build()
Defaultlar deterministik bo‘ladi. Hozirgi vaqt, global random yoki tashqi databasega yashirin bog‘lanish testni beqaror qiladi. Noyob qiymat kerak bo‘lsa seedlangan generator yoki test nomidan hosil qilingan ID ishlatiladi.
Object Mother bilan munosabat
Object Mother validUser() yoki premiumOrder() kabi tayyor named fixture beradi. Builder esa kombinatsiyalarni mayda atributlar orqali tuzadi. Ular birga ishlashi mumkin: Mother domen uchun mazmunli boshlang‘ich builder qaytaradi. Juda ko‘p withX metodi domen ma’nosini yo‘qotsa, withOverdueInvoice kabi intentga yo‘naltirilgan metod yaxshiroq.
Builder production builder bilan bir xil bo‘lishi shart emas. Test builder test source setda turadi va test o‘qilishini optimallashtiradi. Shunga qaramay, domain invariantlarni chetlab o‘tib mumkin bo‘lmagan obyekt yaratish noto‘g‘ri testga olib keladi. Negative test uchun invalid holat ataylab va nomlangan metod bilan quriladi.
Bog‘liq obyektlar
Order customer va itemlarga bog‘liq bo‘lsa builder ichki builderlardan foydalanishi mumkin. Default graph kichik saqlanadi; har user uchun o‘nlab keraksiz record yaratish testlarni sekinlashtiradi. Cycle bo‘lgan domain graphda recursion cheklanadi va associationning faqat kerakli tomoni quriladi.
Database integration testida builder obyektni saqlamasdan yaratishi yoki alohida persist helper bilan repositoryga yozishi mumkin. Build va persistni yashirin birlashtirish unit testni databasega tasodifan bog‘laydi. Transaction rollback va cleanup fixture qatlamida boshqariladi.
Evolyutsiya
Production modelga majburiy maydon qo‘shilsa bitta builder defaultini yangilash ko‘p testni saqlaydi. Biroq default yangi biznes semantikasini yashirishi mumkin: tekshiruv uchun muhim maydon har testda ochiq ko‘rsatiladi. Builderdagi defaultlar dokumentatsiya emas, faqat qulaylik.
Builderning o‘zi testlanishi shart emas degan qarash mutlaq emas. Murakkab hisob yoki persistence bajarsa u xato manbai bo‘ladi; soddalashtirish yoki kichik smoke test kerak. Code review test natijasini builder defaulti tasodifan oldindan belgilab qo‘ymaganini tekshiradi. Masalan, authorization testidagi default admin rol testni yolg‘on muvaffaqiyatli qilishi mumkin.
Vaqt va identifikator
Test builder now()ni ichida chaqirsa yaratilgan va kutilgan vaqt orasida millisekund farqi testni beqaror qiladi. Clock builderga beriladi yoki aniq timestamp default qilinadi. ID generator ham deterministik bo‘lib, parallel testlar database unique constraintida to‘qnashmasligi kerak. Har build bir xil ID qaytarsa bitta testda ikki obyekt yaratish muammo tug‘diradi; builder sequence’ni test scope’da yuritishi mumkin. Shaxsiy ma’lumotga o‘xshash real ism, telefon va karta raqami fixturega ko‘chirilmaydi. Sintetik, aniq fake qiymatlar ishlatiladi. Builder log va snapshotda tasodifan production secretni aks ettirmasligi uchun secret defaultga ega bo‘lmaydi.
Builder odatiy qiymatlarni markazlashtirgani uchun domen modeli o‘zgarganda testlarni saqlash osonlashadi. Yangi majburiy maydon qo‘shilsa, ko‘pincha faqat builder yangilanadi; alohida testlar esa o‘z maqsadini saqlab qoladi.
Bog‘liq tushunchalar
Builder pattern, Test fixture, Object Mother, Unit test, Factory, Deterministic test