Како тестирати лажне податке на иОС-у

Да би се обезбедио квалитетан софтвер и избегла регресија, спровођење тестирања јединице је обавезно за сваку апликацију иОС.
Ругање објектима је техника у јединственом тестирању која ствара лажне објекте користећи исте АПИ-је као и праве.
Овај чланак је добар да вам пружи најбољу праксу о коришћењу лажних података и писању тестова јединице за најчешће појављујуће се сценарије у иОС апликацијама.

При писању јединица-тестова увек треба избегавати измене стварних података циља апликације и уместо тога користити лажне податке само у сврху тестирања.

Следећи делови ће говорити о томе како написати тестове користећи лажне податке за најчешће коришћене иОС АПИ-је.

Корисничке задане поставке

У развоју софтвера увек је добра пракса да се смање зависности објеката. У најбољем случају зависности треба унети у класе које их користе.

Али ако проверимо сценарије развоја иОС-а у стварном животу, скоро сваки пројекат користи УсерДефаултс тако што директно зове АПИ за чување или преузимање било каквих података.

Стога ћемо покушати да понудимо практично решење за тестирање УсерДефаултсратхер него апстрахирање његовог АПИ-ја протоколима.

На УсерДефаулт-у можемо да створимо две нове функције

Увек је добра пракса да се подаци о апликацији не мењају из јединице тестног циља, па бисмо зато требали да створимо друго место за чување корисничких података за наш тестни циљ.

У овом случају, иницијализирамо нови објект УсерДефаултс са суитеНаме - тестДефаултс који је потпуно неовисан од стандардних УсерДефаултс.

Покушајмо написати једноставан тест који користи УсерДефаултс

Будући да се ови подаци у основи користе само за тестирање, требало би да избегнемо да те податке оставимо у нашим апликацијским датотекама, па тако креирамо функцију одговорну за испуштање ове меморије након што завршимо с тестом.

Најбоље место за чишћење ових података биће, наравно, сузавачка функција у нашој класи за тестирање јединица.

Сингелтон Објецтс

Синглетонс објекти се високо користе на иОС-у на многим АПИ-јевима, можемо их наћи на НСФилеМанагер, НСАпплицатион, УИАпплицатион и на многим другим местима.

Знати како тестирати синглетонс корисно је знати за иОС програмере.

У нашем примјеру користићемо иАд оквира Аппле-а. Направићемо датотеку да добијемо локални ЈСОН одговор уместо стварних података о тражењу детаља о атрибуцији огласа.

Лепа карактеристика у иОС-у је што нам брзо проширење омогућава не само додавање нових функција унапред дефинисаног АПИ-ја, већ и њихово прилагођавање нашим прилагођеним протоколима.

Дефинишите протокол рекламирања клијента

Након тога, овај протокол уважавамо и подразумевани АДЦлиент и наш лажни клијент за рекламирање као што је следеће

Затим мењамо зависност било од другог

приватни вар адЦлиент: АдвертисементЦлиент = АДЦлиент.схаред ()

или

приватни вар адЦлиент: АдвертисементЦлиент = МоцкАдЦлиент ()

и користите га на следећи начин

На овај начин лако можемо одлучити када ћемо користити стварне податке и када тестирати, у зависности да ли тестирамо јединицу или зовемо АПИ из нашег циља апликације уживо.

Основни подаци

Основни подаци се и даље високо користе у иОС-у за кеширање података. Тестирање основних података података може бити тешко. У наставку ћемо објаснити добру праксу организације основних података и лажних података.

Опћенито је у већини случајева увијек добра ствар створити сервисну класу која је одговорна за дохваћање и уписивање одређених података у базу података, а не за употребу главног кода података у цијелом пројекту.

То углавном има две предности:

  • Повезује вас са основном базом података која се користи, ако желите да у будућности замените основне податке било којом другом базом података, мораћете да извршите промене само у једној класи.
  • Радећи ово лако можемо одлучити која ће се ЦореДатаСтацк навикнути или било која друга подешавања која ће нам можда требати у неком другом оквиру.

Направит ћемо ЦореДатаСтацк протокол и након тога два ЦореДатаСтацк која су у складу с овим протоколом један МаинЦореДатаСтацк и један МоцкЦореДатаСтацк.

Наш ДатабасеСервице тада може бити иницијализиран било који од њих, зависно од тога да ли га користимо на нашем апликацијском циљу или на нашем Циљном тестирању јединице.

Наша главна база података ће имати задану поставку на следећи начин

Кад је тестирање јединице увек, требало би избегавати промену стања тренутних 'стварних' објеката приликом тестирања.

Дакле, када желимо да створимо лажне језгре података, требало би да имамо засебну упорну меморију и употребу конфигурације типа меморије, тако да се промене не сачувају на диску и биће потпуно одвојене од тренутно упорних података.

Сада ћемо моћи да креирамо нашу услугу база података која се подразумевано иницијализује помоћу МаинЦореДатаСтацк.

И у нашем испитном разреду можемо га иницијализирати помоћу лажног скупа података

Сада можемо написати неколико једноставних тестова како следи:

Употребом овог приступа лако можемо тестирати нашу ДатабасеСервице без утицаја на било који податак похрањен у апликативном циљу.

Мрежни захтеви

Приликом тестирања мрежног слоја можемо користити протоколарно прилагођени приступ да креирамо протокол и у складу смо га са стварним НетворкСервице и МоцкНетворкСервице, а након тога убризгавамо зависности помоћу стварне или исмијане услуге.

У овом ћемо чланку, иако ћемо користити заиста лијепу библиотеку отвореног кода која се зове ОХХТТПСтубс која ће се још боље бавити исмијавањем и убодом.

Добра ствар у овој библиотеци је што сјајно сарађује са познатом иОС мрежном библиотеком Аламофире.

Захтјев за ублажавање мреже је врло једноставан. Помоћу ОХХТТПСтубс можете замијенити било који одговор за одређени пут или домаћин давањем прилагођеног одговора рјечником.

Након тога, сваки захтев који оде из апликације на следећу УРЛ адресу ће уместо тога вратити наш прилагођени одговор.

нека задациУРЛ = УРЛ (стринг: "хттпс://јсонплацехолдер.типицоде.цом/тодос")!

Оно што је такође у реду у прилагођеним одговорима је да можете лако тестирати да ли се грешке и рубни случајеви исправно поступају једноставним враћањем грешке у одговору.

Ручна израда речника за одговор је сјајна карактеристика, али када желимо да вратимо велики ЈСОН податак са пуно својстава, он може постати збркан и тешко одржив у нашим тестовима.

У тим случајевима можемо да користимо ЈСОН датотеку да уклонимо одговор на следећи начин.

Сада сваки пут када наша апликација пошаље захтев, добићемо одговор из датотеке миРеспонсе.јсон коју смо сачували у нашим датотекама.

Иако би требало да избегнемо чување осетљивих података у овим ЈСОН датотекама, јер ако те датотеке испоручимо заједно са апликацијом, оне се лако могу видети.

Можете погледати мој чланак о безбедносној теми за више.

У закључку

Јединствено тестирање наше апликације је неопходно ако желимо што је могуће више избјећи регресију и покушати пружити беспријекорну апликацију.

У овом смо чланку расправљали о томе како осигурати тестирање на уобичајене случајеве који се јављају током развоја иОС-а.

Разговарали смо о томе како тестирати УсерДефаултс, Сингелтонс, Цоре Дата и Нетворк Рекуестс.

Ако вам се овај чланак свидео, побрините се да пљескате како бисте показали своју подршку.

Пратите ме да бисте прегледали још много чланака који ће ваше вештине иОС Девелопер-а подићи на нови ниво.

Ако имате било каквих питања или коментара, слободно оставите белешку овде или ми пошаљите е-пошту на арлиндалиу.дев@гмаил.цом.