Jak testovat pomocí falešných dat v systému iOS

Aby bylo možné poskytovat vysoce kvalitní software a zabránit regresi, je pro každou aplikaci iOS nezbytnou implementací testování jednotek.
Vysmívat se objekty je technika při testování jednotek, která vytváří falešné objekty pomocí stejných API jako skutečných.
Tento článek je zaměřen na to, aby vám poskytl doporučené postupy, jak používat falešná data a psát testy jednotek pro nejrůznější scénáře v aplikacích pro iOS.

Při psaní jednotkových testů bychom se měli vždy vyhýbat změně reálných dat cíle aplikace a místo toho používat falešná data pouze pro účely testování.

Následující části budou diskutovat o tom, jak psát testy pomocí falešných dat pro běžně používaná rozhraní iOS API.

Výchozí nastavení uživatele

Při vývoji softwaru je vždy dobrým zvykem snižovat závislosti objektů. Závislosti by v nejlepším případě měly být aplikovány do tříd, které je používají.

Pokud však zkontrolujeme scénáře vývoje v reálném životě iOS, téměř každý projekt používá UserDefaults tak, že volá API přímo pro ukládání nebo načítání dat.

Proto se pokusíme nabídnout praktické řešení pro testování UserDefaultsrather, než abstraktovat jeho API s protokoly.

Na UserDefaults můžeme vytvořit dvě nové funkce

Je vždy dobrým zvykem neměnit aplikační data z cíle testování jednotky, proto bychom měli vytvořit další místo uložení uživatelských dat pro náš cíl testování.

V tomto případě inicializujeme nový objekt UserDefaults pomocí suiteName - testDefaults, že je zcela nezávislý na standardních UserDefaults.

Zkusme napsat jednoduchý test, který používá UserDefaults

Protože tato data jsou v zásadě používána pouze pro testování, neměli bychom ponechat tato data visící v našich aplikačních souborech, proto jsme vytvořili funkci zodpovědnou za vyřazení tohoto úložiště po dokončení testu.

Nejlepší místo pro vymazání těchto dat bude samozřejmě funkce tearDown v naší třídě testování jednotek.

Singelton Objects

Objekty Singletons jsou v systému iOS velmi používány v mnoha API, můžeme je najít na NSFileManager, NSApplication, UIApplication a na mnoha dalších místech.

Vědět, jak testovat singletony, je pro vývojáře iOS užitečné vědět.

V našem příkladu použijeme rámec Apple iAd. Vytvoříme soubor, abychom získali místní odpověď JSON namísto skutečných údajů o požadavcích na podrobnosti přiřazování reklam.

Příjemnou funkcí v systému iOS je to, že rozšíření v rychlé podobě nám umožňují nejen přidávat nové funkce pro předdefinované API, ale také je přizpůsobovat našim vlastním protokolům.

Definujme protokol AdsmentClient

Poté jsme v souladu s tímto protokolem jak výchozím ADClientem, tak našim falešným reklamním klientem, jako je následující

Pak změníme závislost na jednom

private var adClient: AdvertismentClient = ADClient.shared ()

nebo

private var adClient: AdvertismentClient = MockAdClient ()

a použijte ji následovně

Tímto způsobem se můžeme snadno rozhodnout, kdy použít reálná data a kdy testovací data, v závislosti na tom, zda testujeme jednotky nebo voláme API z našeho živého cíle aplikace.

Základní data

Základní data se v iOS stále používají pro ukládání dat do mezipaměti. Testování základních datových entit může být složité. Níže vysvětlíme osvědčený postup organizace základních datových služeb a předstírání dat.

Obecně je ve většině případů vždy dobré vytvořit třídu služeb, která je zodpovědná za načítání a zápis konkrétních dat do databáze, namísto použití kódu základních dat v celém projektu.

To má hlavně dvě výhody:

  • Oddělí vás od používané základní databáze, pokud chcete v budoucnu nahradit základní data jinou databází, musíte provést změny pouze v jedné třídě.
  • Tímto způsobem se můžeme snadno rozhodnout, který CoreDataStack se použije, nebo jakékoli jiné nastavení, které můžeme potřebovat v jiném rámci.

Vytvoříme protokol CoreDataStack a poté dva CoreDataStacksthat vyhovují tomuto protokolu jeden MainCoreDataStack a jeden MockCoreDataStack.

Naše DatabaseService pak může být inicializována kteroukoli z nich v závislosti na tom, zda ji používáme na cíl aplikace nebo na cíl testování jednotek.

Náš hlavní zásobník dat bude mít výchozí nastavení takto

Když je testování jednotky vždy, neměli bychom při testování stavů aktuálních „skutečných“ objektů měnit.

Když tedy chceme vytvořit falešné základní datové entity, měli bychom mít samostatný trvalý úložiště a používat konfiguraci typu úložiště v paměti, aby provedené změny nebyly uloženy na disk a budou zcela odděleny od aktuálně přetrvávajících dat.

Nyní budeme moci vytvořit naši databázovou službu, která bude ve výchozím nastavení inicializována pomocí MainCoreDataStack.

A v naší testovací třídě to můžeme inicializovat pomocí falešného datového zásobníku

Nyní můžeme napsat několik jednoduchých testů:

Pomocí tohoto přístupu můžeme snadno otestovat naši DatabaseService, aniž by to ovlivnilo některá data uložená v cíli aplikace.

Požadavky na síť

Při testování síťové vrstvy můžeme použít protokolově orientovaný přístup k vytvoření protokolu a jeho přizpůsobení jak skutečnými NetworkService, tak MockNetworkService a poté aplikovat závislosti pomocí skutečné nebo zesměšňované služby.

V tomto článku však budeme používat opravdu pěknou open-source knihovnu s názvem OHHTTPStubs, která zvládne zesměšňování a potahování ještě lépe.

Dobrá věc na této knihovně je, že skvěle funguje se slavnou síťovou knihovnou ilamofire pro iOS.

Požadavek Stubbing Network je u OHHTTPStubs opravdu snadný. Můžete nahradit jakoukoli odpověď na konkrétní cestu nebo hostitele tím, že odpovíte slovníkem.

Poté každý požadavek, který přejde z aplikace na následující adresu URL, vrátí naši vlastní odpověď.

let taskURL = URL (řetězec: „https://jsonplaceholder.typicode.com/todos“)!

Co je také skvělé na vlastních odpovědích, je to, že můžete snadno vyzkoušet, zda jsou případy chyb a okrajů řešeny správně, jednoduše vrácením chyby v odpovědi.

Ruční vytváření slovníku pro odpověď je skvělá funkce, ale pokud chceme vrátit velká data JSON se spoustou vlastností, může se stát, že v našich testovacích třídách bude obtížný a těžko udržovatelný.

V těchto případech můžeme použít soubor JSON k potlačení odpovědi, jako je následující.

Nyní pokaždé, když naše aplikace odešle požadavek, dostaneme odpověď ze souboru myResponse.json, který jsme uložili do našich souborů.

Měli bychom si však pamatovat, abychom se vyhnuli ukládání citlivých informací do těchto souborů JSON, protože pokud tyto soubory dodáváme společně s aplikací, lze je snadno zobrazit.

Další informace najdete v mém článku o tématu zabezpečení.

Závěrem

Jednotkové testování naší aplikace je nezbytné, pokud se chceme co nejvíce vyhnout regresi a také se pokusíme poskytnout bezchybnou aplikaci.

V tomto článku jsme diskutovali, jak provést testování na běžné případy, ke kterým dochází během vývoje systému iOS.

Diskutovali jsme o tom, jak otestovat UserDefaults, Singeltons, Core Data a Network Request.

Pokud se vám tento článek líbil, ujistěte se, že tleskáte, abyste projevili svou podporu.

Následujte mě a prohlédněte si mnoho dalších článků, které mohou vaše dovednosti pro vývojáře iOS posunout na další úroveň.

Pokud máte nějaké dotazy nebo připomínky, neváhejte zde zanechat poznámku nebo napište mi na adresu arlindaliu.dev@gmail.com.