Kā pārbaudīt, izmantojot viltotus datus iOS

Lai nodrošinātu augstas kvalitātes programmatūru un izvairītos no regresijas, katrā iOS lietojumprogrammā obligāti jāveic vienības testēšana.
Objektu izsmiešana ir vienību testēšanas paņēmiens, kas rada viltus objektus, izmantojot tādas pašas API kā reālās.
Šis raksts ir izstrādāts, lai sniegtu jums paraugpraksi, kā izmantot viltotus datus un uzrakstīt vienību testus visizplatītākajiem scenārijiem iOS lietotnēs.

Rakstot vienības testus, mums vienmēr vajadzētu izvairīties no reālu lietojumprogrammas mērķa datu mainīšanas un tā vietā viltotus datus izmantot tikai testēšanas nolūkos.

Turpmākajās daļās tiks runāts par to, kā rakstīt testus, izmantojot viltotus datus par parasti izmantotajām iOS API.

Lietotāja noklusējumi

Programmatūras izstrādē vienmēr ir laba prakse samazināt Objektu atkarības. Atkarības labākajā gadījumā jāinjicē klasēs, kuras tās izmanto.

Bet, ja mēs pārbaudām reālās dzīves iOS attīstības scenārijus, gandrīz katrs projekts izmanto UserDefaults, izsaucot to uz API tieši datu glabāšanai vai izguvei.

Tāpēc mēs centīsimies piedāvāt praktisku risinājumu UserDefaultsrather pārbaudei, nevis tā abstrahēšanai ar protokoliem.

Vietnē UserDefaults mēs varam izveidot divas jaunas funkcijas

Vienmēr ir laba prakse nemainīt lietojumprogrammu datus no vienības testa mērķa, tāpēc mums vajadzētu izveidot citu vietu, kur lietotāja dati tiktu saglabāti mūsu testēšanas mērķim.

Šajā gadījumā mēs inicializējam jaunu UserDefaults objektu ar suiteName - testDefaults, ka tas ir pilnīgi neatkarīgs no standarta UserDefaults.

Mēģināsim uzrakstīt vienkāršu testu, kurā tiek izmantota UserDefaults

Tā kā šie dati pamatā tiek izmantoti tikai pārbaudei, mēs nedrīkstam atstāt šos datus piekārtus mūsu lietojumprogrammu failos, tāpēc mēs izveidojam funkciju, kas ir atbildīga par šīs krātuves nomaiņu pēc testa pabeigšanas.

Labākā vieta šo datu dzēšanai, protams, būs “tearDown” funkcija mūsu vienības testēšanas klasē.

Singeltona objekti

Objekti Singletons tiek ļoti izmantoti iOS daudzās API, mēs tos varam atrast NSFileManager, NSApplication, UIApplication un daudzās citās vietās.

Zināt, kā pārbaudīt singletonus, ir noderīga lieta, kas jāzina iOS izstrādātājiem.

Šajā piemērā mēs izmantosim ābolu iAd sistēmu. Mēs izveidosim failu, lai saņemtu vietējo JSON atbildi, nevis reālus datus par reklāmas piešķiršanas informācijas pieprasīšanu.

Jauka iOS iezīme ir tā, ka ātri veiktie paplašinājumi ļauj mums ne tikai pievienot jaunas funkcijas iepriekš definētai API, bet arī padarīt tās atbilstošas ​​mūsu pašu pielāgotajiem protokoliem.

Definēsim protokolu AdvertismentClient

Pēc tam mēs ievērojam šo protokolu gan noklusējuma ADClient, gan arī mūsu viltotajam reklāmas klientam, piemēram, sekojot

Pēc tam mēs mainām atkarību no abiem

privāts var adClient: AdvertismentClient = ADClient.shared ()

vai

privāts var adClient: AdvertismentClient = MockAdClient ()

un izmantojiet to šādi

Šādā veidā mēs varam viegli izlemt, kad izmantot reālus datus un kad - tos, atkarībā no tā, vai mēs testējam vienību vai izsaucam API no mūsu aktīvās lietojumprogrammas mērķa.

Pamatdati

Pamatinformācija joprojām tiek izmantota iOS datu kešatmiņā. Pamatdatu entītiju pārbaude var būt sarežģīta. Zemāk mēs izskaidrosim labo praksi gan pamatdatu pakalpojumu organizēšanā, gan datu sniegšanā.

Kopumā lielākajā daļā gadījumu vienmēr ir laba lieta, lai izveidotu pakalpojumu klasi, kas ir atbildīga par konkrētu datu atgūšanu un ierakstīšanu datu bāzē, nevis visā projektā izmanto pamatdatus.

Tam galvenokārt ir divas priekšrocības:

  • Tas atsaistīs jūs no izmantotās bāzes datu bāzes, ja nākotnē vēlaties aizstāt pamatdatus ar jebkuru citu datu bāzi, jums būs jāveic izmaiņas tikai vienā klasē.
  • To darot, mēs viegli varam izlemt, kurš CoreDataStack pieradīs, vai kāda cita iestatīšana, kas mums varētu būt nepieciešama kādā citā ietvarā.

Mēs izveidosim CoreDataStack protokolu, un pēc tam divi CoreDataStacksthat, kas atbilst šim protokolam, viens MainCoreDataStack un viens MockCoreDataStack.

Tad mūsu DatabaseService var inicializēt katrs no tiem atkarībā no tā, vai mēs to izmantojam mūsu lietojumprogrammas mērķim vai vienības testēšanas mērķim.

Mūsu galvenajam pamatdatu krājumam būs noklusējuma iestatīšana, kā norādīts tālāk

Pārbaudot vienības vienmēr, mums vajadzētu izvairīties no pašreizējo “reālo” objektu stāvokļa maiņas, tos testējot.

Tātad, kad mēs vēlamies izveidot viltotus pamatdatu subjektus, mums ir jābūt atsevišķam pastāvīgam krājumam un jāizmanto atmiņā esošā tipa konfigurācija, lai veiktās izmaiņas netiktu saglabātas diskā un tās tiktu pilnībā atdalītas no pašlaik saglabātajiem datiem.

Tagad mēs varēsim izveidot savu datu bāzes pakalpojumu, kas pēc noklusējuma tiek inicializēts ar MainCoreDataStack.

Un mūsu testa klasē mēs to varam inicializēt ar viltus datu kaudzīti

Tagad mēs varam uzrakstīt dažus vienkāršus testus:

Izmantojot šo pieeju, mēs varam viegli pārbaudīt mūsu DatabaseService, neietekmējot datus, kas tiek saglabāti lietojumprogrammas mērķī.

Tīkla pieprasījumi

Pārbaudot tīkla slāni, mēs varam izmantot uz protokolu orientētu pieeju, lai izveidotu protokolu un to ievērotu gan ar reālu NetworkService, gan MockNetworkService palīdzību un pēc tam ievadītu atkarības, izmantojot vai nu reālu, vai izsmietotu pakalpojumu.

Tomēr šajā rakstā mēs izmantosim patiešām jauku atvērtā pirmkoda bibliotēku ar nosaukumu OHHTTPStubs, kas vēl labāk tiks galā ar ņirgāšanos un spītēšanu.

Šīs bibliotēkas labā lieta ir tā, ka tā lieliski darbojas ar slaveno iOS tīkla bibliotēku Alamofire.

Tīkla pieprasījuma pieprasīšana ir patiešām vienkārša, izmantojot OHHTTPStubs. Jūs varat aizstāt jebkuru reakciju uz noteiktu ceļu vai resursdatoru, piešķirot pielāgotu atbildi ar vārdnīcu.

Pēc tam katrs pieprasījums, kas tiek pārvietots no lietotnes uz šo URL, tā vietā sniegs mūsu pielāgoto atbildi.

ļaujiet uzdevumiemURL = URL (virkne: “https://jsonplaceholder.typicode.com/todos”)!

Īpaši patīkami ir arī tas, ka pielāgotās atbildes ir tādas, ka jūs varat viegli pārbaudīt, vai kļūdu un malu gadījumi tiek apstrādāti pareizi, vienkārši atdodot kļūdu atbildē.

Atbildes vārdnīcas manuāla veidošana ir lieliska īpašība, taču, ja mēs vēlamies atgriezt lielu JSON datu daudzumu ar daudzām īpašībām, tas mūsu testdarbos var kļūt nekārtīgs un grūti uzturējams.

Šādos gadījumos mēs varam izmantot JSON failu, lai aizkavētu atbildi, piemēram, sekojot.

Tagad katru reizi, kad mūsu lietotne nosūta pieprasījumu, mēs saņemsim atbildi no faila myResponse.json, ko mēs saglabājām savos failos.

Tomēr mums vajadzētu atcerēties, ka šajos JSON failos nevajadzētu saglabāt sensitīvu informāciju, jo, ja mēs šos failus piegādājam kopā ar lietojumprogrammu, tos var viegli apskatīt.

Lai uzzinātu vairāk, skatiet manu rakstu par drošības tēmu.

Noslēgumā

Vienības pārbaude mūsu lietojumprogrammai ir obligāta, ja mēs vēlamies pēc iespējas izvairīties no regresijas un arī cenšamies nodrošināt nevainojamu lietojumprogrammu.

Šajā rakstā mēs esam apsprieduši, kā nodrošināt testēšanu biežiem gadījumiem, kas rodas iOS izstrādes laikā.

Mēs apspriedām, kā pārbaudīt UserDefaults, Singeltons, Core Data un Network Requests.

Ja jums patika šis raksts, noteikti aplaudējiet, lai parādītu savu atbalstu.

Sekojiet man, lai apskatītu vēl daudzus rakstus, kas var uzlabot jūsu iOS izstrādātāja prasmes nākamajā līmenī.

Ja jums ir kādi jautājumi vai komentāri, droši atstājiet piezīmi šeit vai rakstiet man uz e-pastu arlindaliu.dev@gmail.com.