Kako testirati lažne podatke na iOS-u

Kako bi se osigurao visokokvalitetni softver i izbjeglo regresiranje, provedba testiranja jedinice je neophodna za svaku aplikaciju iOS.
Ruganje objektima je tehnika pri testiranju jedinica koja stvara lažne predmete pomoću istih API-ja kao i pravi.
Ovaj je članak omazan kako bi vam pružio najbolje prakse o korištenju lažnih podataka i pisanju testova jedinice za najčešće događaje u iOS aplikacijama.

Pri pisanju jediničnih testova uvijek bismo trebali izbjegavati mijenjanje stvarnih podataka cilja aplikacije i umjesto toga koristiti lažne podatke samo u svrhu testiranja.

Sljedeći dijelovi raspravljaju o tome kako napisati testove pomoću lažnih podataka za najčešće korištene iOS API-je.

Korisničke zadane postavke

U razvoju softvera uvijek je dobra praksa smanjiti ovisnosti objekata. Ovisnosti u najboljem slučaju trebaju se unijeti u klase koje ih koriste.

Ali ako provjerimo scenarije razvoja iOS-a u stvarnom životu, gotovo svaki projekt koristi UserDefaults tako što ga izravno zovemo API-om za pohranu ili dohvaćanje bilo kakvih podataka.

Stoga ćemo pokušati ponuditi praktično rješenje za testiranje UserDefaultsrather nego apstrahiranje njegovog API-ja protokolima.

Na UserDefaults možemo stvoriti dvije nove funkcije

Uvijek je dobra praksa da se podaci o aplikaciji ne mijenjaju iz jedinice jedinice ispitivanja, stoga bismo trebali stvoriti drugo mjesto za spremanje korisničkih podataka za naš testni cilj.

U ovom slučaju inicijaliziramo novi objekt UserDefaults sa suiteName - testDefaults koji je potpuno neovisan od standardnih UserDefaults.

Pokušajmo napisati jednostavan test koji koristi UserDefaults

Budući da se ovi podaci u osnovi koriste samo za testiranje, trebali bismo izbjegavati da ti podaci ostanu viseći u našim aplikacijskim datotekama, stoga stvaramo funkciju odgovornu za ispuštanje ove pohrane nakon što završimo s testom.

Najbolje mjesto za čišćenje ovih podataka bit će, naravno, funkcija suzavaca u našoj jedinici za testiranje.

Singelton objekti

Singletons objekti se visoko koriste na iOS-u na mnogim API-jevima, možemo ih naći na NSFileManager, NSApplication, UIApplication i na mnogim drugim mjestima.

Znati kako testirati singletons korisno je znati za iOS programere.

U našem primjeru koristit ćemo iAd Framework od jabuka. Napravit ćemo datoteku za dobivanje lokalnog JSON odgovora umjesto stvarnih podataka o traženju detalja o atribuciji oglasa.

Lijepa značajka u iOS-u je što nam brzo proširenja omogućuju ne samo dodavanje novih funkcija unaprijed definiranom API-ju, već i njihovo prilagođavanje vlastitim prilagođenim protokolima.

Definirajmo protokol AdvertisingClient

Nakon toga u skladu s ovim protokolom ispunjavamo i zadani ADClient i naš klijent za lažne reklame poput sljedećeg

Tada mijenjamo ovisnost o bilo kojem

privatni var adClient: AdvertisementClient = ADClient.shared ()

ili

privatni var adClient: AdvertisementClient = MockAdClient ()

i koristite na sljedeći način

Na taj način lako možemo odlučiti kada ćemo koristiti stvarne podatke i kada testirati, ovisno jesmo li testirali jedinicu ili smo pozvali API iz našeg cilja aplikacije uživo.

Osnovni podaci

Osnovni podaci i dalje se visoko koriste u iOS-u za predmemoriranje podataka. Testiranje osnovnih podataka podataka može biti teško. U nastavku ćemo objasniti dobru praksu organiziranja osnovnih podataka i lažnih podataka.

Općenito je u većini slučajeva uvijek dobra stvar stvoriti servisnu klasu koja je odgovorna za dohvaćanje i upisivanje određenih podataka u bazu podataka, a ne za upotrebu temeljnog koda podataka u cijelom projektu.

To uglavnom ima dvije prednosti:

  • Povezuje vas s osnovnom bazom podataka koja se koristi, ako želite ubuduće zamijeniti osnovne podatke s bilo kojom drugom bazom podataka, morat ćete izvršiti promjene samo u jednoj klasi.
  • Radeći to lako možemo odlučiti na koji će se CoreDataStack naviknuti ili na bilo koje drugo postavljanje koje će nam možda trebati u nekom drugom okviru.

Napravit ćemo CoreDataStack protokol i nakon toga dva CoreDataStack koja su u skladu s ovim protokolom jedan MainCoreDataStack i jedan MockCoreDataStack.

Našu DatabaseService tada može bilo inicijalizirati bilo koja od njih, ovisno o tome koristimo li je u aplikativnom cilju ili na našem jedinici za testiranje jedinice.

Naša glavna jezgra podataka će imati zadanu postavku kao što slijedi

Kad je jedinica testiranje uvijek, trebali bismo izbjegavati promjenu stanja trenutnih 'stvarnih' objekata prilikom testiranja.

Dakle, kada želimo stvoriti lažne jezgre podataka, trebali bismo imati zasebnu trajnu pohranu i koristiti konfiguraciju spremišta u memoriji, tako da se izmjene ne spremaju na disk i one će biti u potpunosti odvojene od trenutno postojećih podataka.

Sada ćemo moći stvoriti našu uslugu baze podataka koja se po početnim postavkama inicijalizira s MainCoreDataStack.

I u našem ispitnom razredu možemo ga inicijalizirati pomoću lažne stope podataka

Sada možemo napisati nekoliko jednostavnih testova kako slijedi:

Korištenjem ovog pristupa lako ćemo testirati našu DatabaseService bez utjecaja na podatke pohranjene u aplikacijskom cilju.

Mrežni zahtjevi

Prilikom testiranja mrežnog sloja možemo koristiti protokol orijentirani pristup da stvorimo protokol i u skladu smo ga s realnim NetworkService i MockNetworkService, a nakon toga ubrizgavamo ovisnosti pomoću stvarne ili ismijane usluge.

U ovom ćemo članku, iako ćemo koristiti zaista lijepu biblioteku otvorenog koda koja se zove OHHTTPStubs koja će još bolje podnijeti ismijavanje i štucanje.

Dobra stvar ove biblioteke je da izvrsno surađuje s poznatom iOS mrežnom bibliotekom Alamofire.

Zahtjev za ubodnom mrežom je vrlo jednostavan. OHHTTPStubs možete zamijeniti bilo koji odgovor za određeni put ili domaćin davanjem prilagođenog odgovora sa rječnikom.

Nakon toga, svaki zahtjev koji krene iz aplikacije na sljedeći URL umjesto toga vraća naš prilagođeni odgovor.

neka zadaciURL = URL (string: "https://jsonplaceholder.typicode.com/todos")!

Ono što je također u redu u prilagođenim odgovorima je da možete lako provjeriti ispravno li se postupaka s pogreškama i rubom jednostavnim vraćanjem pogreške u odgovoru.

Ručna izrada rječnika za odgovor je sjajna značajka, ali kada želimo vratiti veliki JSON podatak s puno svojstava, on može postati neuredan i teško održiv u našim testnim klasama.

U tim slučajevima možemo upotrijebiti JSON datoteku za uklanjanje odgovora na sljedeći način.

Sada svaki put kada naša aplikacija pošalje zahtjev, dobit ćemo odgovor iz datoteke myResponse.json koju smo spremili u naše datoteke.

No trebali bismo zapamtiti kako izbjegavamo spremanje osjetljivih podataka u ove JSON datoteke jer ako te datoteke zajedno s aplikacijom pošaljemo, one se lako mogu vidjeti.

Možete pogledati moj članak o sigurnosnoj temi za više.

U zaključku

Jedinstveno testiranje naše aplikacije je neophodno ako želimo što više izbjeći regresiju i pokušati pružiti besprijekornu aplikaciju.

U ovom smo članku raspravljali o tome kako osigurati testiranje na uobičajene slučajeve koji se događaju tijekom razvoja iOS-a.

Raspravljali smo o tome kako testirati UserDefaults, Singeltons, Core Data i Network Requests.

Ako vam se ovaj članak svidio, zasigurno pljeskajte kako biste pokazali svoju podršku.

Slijedite me da biste pogledali još mnogo članaka koji će vaše vještine iOS Developer-a podići na novu razinu.

Ako imate bilo kakvih pitanja ili komentara, slobodno ovdje ostavite bilješku ili mi pošaljite e-poštu na arlindaliu.dev@gmail.com.