Ako testovať pomocou falošných údajov v systéme iOS

S cieľom poskytnúť vysoko kvalitný softvér a zabrániť regresii je implementácia testovania jednotiek nevyhnutnou súčasťou každej aplikácie pre iOS.
Vysmievacie objekty sú technikou pri testovaní jednotiek, ktorá vytvára falošné objekty pomocou rovnakých rozhraní API ako tie skutočné.
Tento článok je zameraný na to, aby vám poskytol osvedčené postupy o tom, ako používať falošné údaje a písať testy jednotiek pre najbežnejšie scenáre aplikácií pre iOS.

Pri písaní jednotkových testov by sme sa mali vždy vyhýbať zmene skutočných údajov o cieľovom cieli aplikácie a namiesto toho použiť falošné údaje iba na účely testovania.

Nasledujúce časti budú diskutovať o tom, ako písať testy pomocou falošných údajov pre bežne používané API iOS.

Predvolené nastavenia používateľa

Pri vývoji softvéru je vždy dobrým zvykom znižovať závislosti objektov. Závislosti by sa v najlepšom prípade mali vkladať do tried, ktoré ich používajú.

Ak však skontrolujeme scenáre vývoja iOS v reálnom živote, takmer každý projekt používa UserDefaults tak, že nazýva API priamo na ukladanie alebo získavanie akýchkoľvek údajov.

Preto sa pokúsime ponúknuť praktické riešenie na testovanie UserDefaultsrather, než abstraktovať jeho API pomocou protokolov.

Na UserDefaults môžeme vytvoriť dve nové funkcie

Je vždy dobrým zvykom nemeniť aplikačné údaje z cieľového testu jednotky, preto by sme mali vytvoriť ďalšie miesto ukladania užívateľských údajov pre náš testovací cieľ.

V tomto prípade inicializujeme nový objekt UserDefaults pomocou suiteName - testDefaults, že je úplne nezávislý od štandardných UserDefaults.

Skúsme napísať jednoduchý test, ktorý používa UserDefaults

Keďže sa tieto údaje v podstate používajú iba na testovanie, mali by sme sa vyhnúť tomu, aby tieto údaje zostali visieť v našich súboroch aplikácií, preto po ukončení testu vytvoríme funkciu zodpovednú za vyradenie tohto úložiska.

Najlepším miestom na vyčistenie týchto údajov bude samozrejme funkcia tearDown v našej triede testovania jednotiek.

Singeltonove objekty

Singletons Objects sa v iOS používajú na mnohých API, nájdeme ich na NSFileManager, NSApplication, UIApplication a na mnohých ďalších miestach.

Vedieť, ako testovať singlety, je užitočné vedieť pre vývojárov iOS.

V našom príklade použijeme rámec iAd pre jablká. Vytvoríme súbor na získanie miestnej odpovede JSON namiesto skutočných údajov o požiadavkách na podrobnosti priraďovania reklám.

Príjemnou vlastnosťou v systéme iOS je to, že rýchle rozšírenia nám umožňujú nielen pridávať nové funkcie pre preddefinované API, ale tiež ich prispôsobovať vlastným protokolom.

Definujme protokol AdsmentClient

Potom sa prispôsobíme tomuto protokolu ako predvolenému ADClientovi, tak aj nášmu falošnému reklamnému klientovi

Potom zmeníme závislosť buď

private var adClient: AdvertismentClient = ADClient.shared ()

alebo

private var adClient: AdvertismentClient = MockAdClient ()

a použite ho nasledovne

Týmto spôsobom sa môžeme ľahko rozhodnúť, kedy sa majú použiť skutočné údaje a kedy sa majú testovať. Závisí to od toho, či testujeme jednotky alebo voláme API z nášho živého cieľa aplikácie.

Základné údaje

Základné údaje sa stále používajú v systéme iOS na ukladanie údajov do vyrovnávacej pamäte. Testovanie základných dátových jednotiek môže byť zložité. Ďalej uvádzame osvedčený postup organizácie základných dátových služieb a falošných údajov.

Vo väčšine prípadov je vo všeobecnosti vždy dobré vytvoriť triedu služieb, ktorá je zodpovedná za načítanie a zapisovanie konkrétnych údajov do databázy, a nie za použitie kódu základných údajov v celom projekte.

To má hlavne dve výhody:

  • Oddeľuje vás od používanej základnej databázy, ak chcete v budúcnosti nahradiť základné údaje inou databázou, budete musieť vykonať zmeny iba v jednej triede.
  • Týmto môžeme ľahko rozhodnúť, ktorý CoreDataStack sa použije alebo akékoľvek iné nastavenie, ktoré budeme potrebovať v inom rámci.

Vytvoríme protokol CoreDataStack a potom dva CoreDataStacksthat vyhovujú tomuto protokolu, jeden MainCoreDataStack a jeden MockCoreDataStack.

Službu DatabaseService potom môže inicializovať ktorákoľvek z nich v závislosti od toho, či ju používame na cieľ aplikácie alebo na cieľ testovania jednotky.

Náš hlavný zásobník údajov bude mať predvolené nastavenie, ako je uvedené nižšie

Keď je testovanie jednotky vždy, nemali by sme pri testovaní zabrániť zmene stavu aktuálnych „skutočných“ objektov.

Ak teda chceme vytvoriť falošné entity základných údajov, mali by sme mať samostatný trvalý ukladací priestor a používať konfiguráciu typu ukladacieho priestoru v pamäti, aby sa vykonané zmeny neuložili na disk a budú úplne oddelené od momentálne pretrvávajúcich údajov.

Teraz budeme môcť vytvoriť našu databázovú službu, ktorá sa predvolene inicializuje s programom MainCoreDataStack.

A v našej testovacej triede ho môžeme inicializovať pomocou súboru falošných údajov

Teraz môžeme napísať niekoľko jednoduchých testov:

Použitím tohto prístupu môžeme ľahko otestovať našu databázovú službu bez ovplyvnenia akýchkoľvek údajov uložených v cieli aplikácie.

Požiadavky na sieť

Pri testovaní sieťovej vrstvy môžeme použiť prístup zameraný na protokoly na vytvorenie protokolu a jeho prispôsobenie skutočnými sieťovými službami a MockNetworkService a následne pomocou závislých riešení buď pomocou reálnej alebo zosmiešňovanej služby.

V tomto článku však budeme používať skutočne peknú otvorenú knižnicu s názvom OHHTTPStubs, ktorá zvládne zosmiešňovanie a potiahnutie ešte lepšie.

Dobrá vec na tejto knižnici je, že funguje skvele so slávnou sieťovou knižnicou iOS Alamofire.

Stubbing Network request with OHHTTPStubs je naozaj jednoduchý, môžete nahradiť akúkoľvek odpoveď na konkrétnu cestu alebo hostiteľa zadaním vlastnej odpovede slovníkom.

Potom každá žiadosť, ktorá prejde z aplikácie na nasledujúcu adresu URL, namiesto toho vráti našu vlastnú odpoveď.

nech úlohyURL = URL (reťazec: „https://jsonplaceholder.typicode.com/todos“)!

Čo je tiež skvelé v prípade vlastných odpovedí, je to, že môžete ľahko otestovať, či sa prípady chýb a okrajov riešia správne jednoduchým vrátením chyby v odpovedi.

Ručné zostavenie slovníka pre odpoveď je vynikajúca funkcia, ale keď chceme vrátiť veľké údaje spoločnosti JSON s množstvom vlastností, môže sa stať v našich testovacích triedach chaotickými a ťažko udržiavateľnými.

V týchto prípadoch môžeme použiť súbor JSON na vloženie odpovede ako je nasledujúca.

Teraz, keď naša aplikácia odošle žiadosť, dostaneme odpoveď zo súboru myResponse.json, ktorý sme uložili do našich súborov.

Mali by sme však pamätať na to, aby sme sa vyhli ukladaniu citlivých informácií do týchto súborov JSON, pretože ak tieto súbory dodávame spolu s aplikáciou, dajú sa ľahko zobraziť.

Ďalšie informácie nájdete v mojom článku venovanom téme zabezpečenia.

Na záver

Jednotkové testovanie našej aplikácie je nevyhnutné, ak sa chceme vyhnúť regresii v maximálnej možnej miere a pokúsime sa tiež poskytnúť bezchybnú aplikáciu.

V tomto článku sme diskutovali o tom, ako poskytnúť testovanie na bežné prípady, ktoré sa vyskytnú počas vývoja systému iOS.

Diskutovali sme o tom, ako otestovať UserDefaults, Singeltons, Core Data a Network Request.

Ak sa vám tento článok páčil, nezabudnite tlieskať, aby ste prejavili svoju podporu.

Nasledujte ma a pozrite si ďalšie články, ktoré môžu posunúť vaše zručnosti pre vývojárov systému iOS na vyššiu úroveň.

Ak máte akékoľvek otázky alebo pripomienky, môžete tu zanechať poznámku alebo napíšte mi na adresu arlindaliu.dev@gmail.com.