IOS-da soxta ma'lumotlardan qanday foydalanishni sinab ko'rish

Yuqori sifatli dasturiy ta'minotni taqdim etish va regressiyadan saqlanish uchun har bir iOS ilovasi uchun sinov sinovlarini o'tkazish majburiydir.
Ob'ektlarni masxara qilish - bu haqiqiy API bilan bir xil API-dan foydalangan holda soxta ob'ektlarni yaratadigan birliklarni tekshirish uslubidir.
Ushbu maqola sizga soxta ma'lumotlardan foydalanish bo'yicha eng yaxshi amaliyotlarni taqdim etish va iOS-dagi eng ko'p uchraydigan stsenariylar uchun birlik testlarini yozish uchun foydalidir.

Birlik-testlarni yozishda biz har doim dastur maqsadining haqiqiy ma'lumotlarini o'zgartirishdan qochishimiz kerak va buning o'rniga faqat sinov maqsadlari uchun soxta ma'lumotlardan foydalanishimiz kerak.

Keyingi qismlarda tez-tez ishlatiladigan iOS API-lar uchun soxta ma'lumotlardan foydalanib testlarni qanday yozishni muhokama qilamiz.

Foydalanuvchi parametrlari

Dasturiy ta'minotni ishlab chiqishda har doim Ob'ektlarga bog'liqlikni kamaytirish yaxshi amaliyot hisoblanadi. Eng yaxshi holatda bog'liqlik ularni ishlatadigan sinflarga kiritilishi kerak.

Ammo agar biz real hayotda ishlab chiqiladigan iOS Development stsenariylarini tekshirsak, deyarli har bir loyiha foydalanuvchi ma'lumotlarini to'g'ridan-to'g'ri har qanday ma'lumotlarni saqlash yoki olish uchun API deb atash orqali foydalanadi.

Shuning uchun biz API API-ni protokollar bilan mavhumlashtirishdan ko'ra, testlarni o'tkazish uchun amaliy echimni taklif qilishga harakat qilamiz.

Biz UserDefaults-da ikkita yangi funktsiyani yaratishimiz mumkin

Ilova ma'lumotlarini birlik sinov maqsadidan o'zgartirmaslik har doim yaxshi tajriba hisoblanadi, shuning uchun biz sinov maqsadimiz uchun foydalanuvchi ma'lumotlarini saqlashning boshqa joyini yaratishimiz kerak.

Bunday holda, biz suiteName - TestDefaults bilan UserDefaults-ning yangi ob'ektini, u standart UserDefaults-dan mutlaqo mustaqil ekanligini ishga tushiramiz.

Keling, UserDefaults-dan foydalanadigan oddiy test yozishga harakat qilaylik

Ushbu ma'lumotlar asosan faqat sinov uchun ishlatilganligi sababli, biz ushbu ma'lumotlarning ilova fayllarimizga osib qo'yilishining oldini olishimiz kerak, shuning uchun testni tugatgandan so'ng biz ushbu xotirani tashlab yuborish uchun javobgar bo'lgan funktsiyani yaratamiz.

Ushbu ma'lumotlarni tozalash uchun eng yaxshi joy, shubhasiz, bizning blok sinov sinfimizdagi tearDown funktsiyasi bo'ladi.

Singelton ob'ektlari

Singletons Objects juda ko'p API-larda iOS-da qo'llaniladi, biz ularni NSFileManager, NSApplication, UIApplication va boshqa ko'plab joylarda topishingiz mumkin.

Singletonlarni qanday sinashni bilish, bu iOS dasturchilarini bilish foydali narsa.

Bizning misolimizda biz olmaning iAd ramkasidan foydalanamiz. Mualliflik tafsilotlarini so'rashda haqiqiy ma'lumot o'rniga mahalliy JSON javobini olish uchun fayl yaratamiz.

IOS-ning yoqimli xususiyati shundaki, tezkor kengaytmalar bizga nafaqat oldindan belgilangan API uchun yangi funktsiyalarni qo'shish, balki ularni shaxsiy protokollarimizga moslashtirishga imkon beradi.

ReklamaClient protokolini aniqlaylik

Shundan so'ng, biz ushbu protokolga odatiy ADClient va soxta reklama mijozimiz tomonidan quyidagicha mos kelamiz

Keyin, ikkinchisiga bog'liqlikni o'zgartiramiz

xususiy var adClient: AdvertismentClient = ADClient.shared ()

yoki

xususiy var adClient: AdvertismentClient = MockAdClient ()

va quyidagicha foydalaning

Shu tarzda, biz haqiqiy ma'lumotlarni qachon ishlatishni va sinov ma'lumotlarini qachon tanlashni osongina qaror qilishimiz mumkin, agar biz sinov o'tkazayotgan bo'lsak yoki API-ni jonli dastur maqsadimizdan chaqirsak.

Asosiy ma'lumotlar

Ma'lumotlar keshlash uchun asosiy ma'lumotlar hali ham iOS-da keng qo'llaniladi. Ma'lumotlarning asosiy ob'ektlarini sinovdan o'tkazish murakkab bo'lishi mumkin. Quyida biz Core Data Services va Fakes Data-ni tashkil qilishning yaxshi amaliyotini tushuntirib beramiz.

Umuman olganda, aksariyat hollarda butun loyiha davomida asosiy ma'lumotlar kodini ishlatishdan ko'ra ma'lumotlar bazasiga ma'lum bir ma'lumotlarni olish va yozish bilan shug'ullanadigan xizmat sinfini yaratish har doim yaxshi narsa.

Buning asosan ikki foydasi bor:

  • Bu sizni ishlatilayotgan bazadagi ma'lumotlar bazasidan ajratib turadi, agar kelajakda asosiy ma'lumotlarni boshqa ma'lumotlar bazasi bilan almashtirishni xohlasangiz, faqat bitta sinfga o'zgartirish kiritishingiz kerak bo'ladi.
  • Buning yordamida biz CoreDataStack qaysi foydalanilishini yoki boshqa biron-bir tizimga kerak bo'ladigan boshqa o'rnatishni osonlikcha hal qilishimiz mumkin.

Biz CoreDataStack protokolini yaratamiz va shundan so'ng ikkita protokolga mos keladigan CoreDataStack, bitta MainCoreDataStack va bitta MockCoreDataStack.

Keyinchalik bizning DatabaseService xizmatimiz ularni bizning dastur yoki Unit Testing maqsadimizdan foydalanayotganimizga bog'liq holda boshlashi mumkin.

Bizning asosiy yadro ma'lumotlar stack quyidagicha odatiy o'rnatishga ega bo'ladi

Jihozni sinovdan o'tkazishda biz har doim sinovdan o'tkazishda joriy 'haqiqiy' ob'ektlarning holatini o'zgartirishdan saqlanishimiz kerak.

Shunday qilib, biz soxta yadro ma'lumotlarini yaratmoqchi bo'lsak, bizda doimiy saqlanadigan ombor mavjud bo'lishi kerak va kiritilgan o'zgartishlar diskda saqlanmaydi va ular hozirda saqlanayotgan ma'lumotlardan to'liq ajratiladi.

Endi MainCoreDataStack-da standart ravishda ishga tushiriladigan ma'lumotlar bazamiz xizmatini yaratishimiz mumkin.

Va bizning sinov sinfimizda buni soxta ma'lumotlar to'plami bilan boshlashimiz mumkin

Endi bir nechta oddiy testlarni quyidagicha yozishimiz mumkin:

Ushbu yondashuvdan foydalanib, biz maqsadli server tomonidan saqlanadigan ma'lumotlarga ta'sir qilmasdan, DatabaseService-ni osongina sinab ko'rishimiz mumkin.

Tarmoq so'rovlari

Tarmoq qatlamini sinovdan o'tkazishda biz protokolni yaratishda va unga real NetworkService va MockNetworkService tomonidan mos keladigan, so'ngra real yoki istehzo qilingan xizmatdan foydalanib, bog'liqlikni kiritish uchun protokolga asoslangan yondashuvdan foydalanishimiz mumkin.

Ushbu maqolada biz OHHTTPStubs deb nomlangan juda yoqimli va ochiq manbali kutubxonadan foydalanamiz.

Ushbu kutubxonaning yaxshi tomoni shundaki, u mashhur iOS tarmoq kutubxonasi Alamofire bilan juda yaxshi ishlaydi.

Tarmoqni so'ndirish OHHTTPStublari bilan juda oson, siz ma'lum bir yo'l yoki xost uchun har qanday javobni lug'at bilan maxsus javob berish orqali almashtirishingiz mumkin.

Shundan so'ng, ilovadan quyidagi URL manzilga o'tadigan har qanday so'rov o'rniga bizning shaxsiy javobimiz qaytariladi.

taskURL = URL ga ruxsat bering (satr: "https://jsonplaceholder.typicode.com/todos")!

Maxsus javoblarni yoqtiradigan narsa shundaki, agar xato va chekka holatlar to'g'ri bajarilgan bo'lsa, javobda xatoni qaytarish orqali osonlikcha tekshirib ko'rishingiz mumkin.

Javob uchun lug'atni qo'lda yaratish juda yaxshi xususiyatdir, ammo biz juda ko'p xususiyatlarga ega bo'lgan katta JSON ma'lumotlarini qaytarishni xohlasak, bu bizning sinov sinflarimizda tartibsiz va saqlanib qolishi mumkin.

Bunday holatlarda biz javobni quyidagicha tuzatish uchun JSON faylidan foydalanishimiz mumkin.

Endi har safar bizning iltimosimiz yuborilganda, biz javoblar bizning fayllarimizga saqlagan myResponse.json faylidan olamiz.

Ushbu JSON fayllarida maxfiy ma'lumotlarni saqlamaslik kerakligini yodda tutishimiz kerak, chunki agar biz ushbu fayllarni ilova bilan birga jo'natsak, ularni osongina ko'rish mumkin.

Xavfsizlik mavzusidagi maqolamni ko'proq bilib olishingiz mumkin.

Xulosa

Agar iloji boricha regressiyadan qochish va benuqson dasturni taqdim etishni xohlasak, bizning ilovamizni sinab ko'rish birligi kerak.

Ushbu maqolada biz iOS-ni ishlab chiqish paytida yuzaga keladigan keng tarqalgan holatlar uchun sinovni qanday topshirishni muhokama qildik.

Biz UserDefaults, Singeltons, Core Data va Network Requestlarni qanday sinovdan o'tkazishni muhokama qildik.

Agar sizga ushbu maqola yoqqan bo'lsa, uni qo'llab-quvvatlash uchun chapak chalib qo'ying.

IOS Developer ko'nikmalarini keyingi bosqichga olib chiqadigan boshqa ko'plab maqolalarni ko'rish uchun menga ergashing.

Agar biron bir savol yoki sharhingiz bo'lsa, bu erda eslatma qoldiring yoki menga arlindaliu.dev@gmail.com elektron pochta manziliga yuboring.