Як перевірити використання підроблених даних на iOS

Щоб забезпечити якісне програмне забезпечення та уникнути регресу, впровадження тестування одиниць є обов'язковим для кожної програми iOS.
Знущання з об’єктів - це техніка в одиничному тестуванні, яка створює підроблені об'єкти, використовуючи ті самі API, що і реальні.
Ця стаття є вдосконаленою, щоб запропонувати вам найкращі практики щодо використання підроблених даних та написання тестових одиниць для найбільш запущених сценаріїв у додатках iOS.

Під час написання одиничних тестів завжди слід уникати зміни реальних даних цілі програми, а замість цього використовувати фальшиві дані лише для цілей тестування.

У наступних частинах буде обговорено, як писати тести, використовуючи підроблені дані для широко використовуваних API iOS.

За замовчуванням користувача

У розробці ПЗ завжди є хорошою практикою зменшення залежностей Об'єктів. Залежності в кращому випадку слід вводити в класи, які ними користуються.

Але якщо ми перевіримо сценарії розвитку iOS в реальному житті, майже кожен проект використовує UserDefaults, викликаючи його API безпосередньо для зберігання або отримання будь-яких даних.

Тому ми спробуємо запропонувати практичне рішення для тестування UserDefaultsrather, ніж абстрагування його API протоколами.

Ми можемо створити дві нові функції на UserDefaults

Завжди є хорошою практикою не змінювати дані програми від одиниці тестової цілі, тому ми повинні створити інше місце збереження даних користувачів для нашої тестової цілі.

У цьому випадку ми ініціалізуємо новий об’єкт UserDefaults з suiteName - testDefaults, що він повністю не залежить від стандартних UserDefaults.

Спробуємо написати простий тест, який використовує UserDefaults

Оскільки ці дані в основному використовуються лише для тестування, ми не повинні залишати ці дані вивішеними у наших файлах додатків, тому ми створюємо функцію, відповідальну за скидання цього сховища після того, як ми закінчимо тест.

Найкращим місцем для очищення цих даних буде, звичайно, функція tearDown в нашому класі тестування одиниць.

Об'єкти Сінгелтона

Об'єкти Singletons широко використовуються на iOS у багатьох API, їх можна знайти в NSFileManager, NSApplication, UIApplication та в багатьох інших місцях.

Знання, як протестувати одиночні кнопки - корисна річ, яку слід знати розробникам iOS.

У нашому прикладі ми будемо використовувати iAd Framework Apple. Ми створимо файл, щоб отримати локальну відповідь JSON замість реальних даних про запит даних про атрибуцію оголошення.

Приємною особливістю в iOS є те, що розширення у швидкому режимі дозволяють нам не тільки додавати нові функції для заздалегідь визначеного API, але й приводити їх у відповідність до наших власних власних протоколів.

Давайте визначимося з протоколом AdvertisingClient

Після цього ми відповідаємо цьому протоколу як ADClient за замовчуванням, так і наш підроблений клієнт, наприклад, наступний

Потім ми змінюємо залежність до будь-якого

приватний var adClient: AdvertisementClient = ADClient.shared ()

або

приватний var adClient: AdvertisementClient = MockAdClient ()

і використовувати його наступним чином

Таким чином, ми можемо легко вирішити, коли використовувати реальні дані та коли тестувати, залежно від того, чи ми перевіряємо одиницю чи викликаємо API з нашої цільової програми.

Основні дані

Основні дані все ще широко використовуються в iOS для кешування даних. Тестування основних об'єктів даних може бути складним. Нижче ми пояснимо належну практику організації основних служб даних та підроблених даних.

Загалом у більшості випадків завжди добре створити сервісний клас, який відповідає за отримання та запис конкретних даних у базу даних, а не за допомогою базового коду даних у всьому проекті.

В основному це має дві переваги:

  • Він відокремлює вас від базової бази даних, яка використовується, якщо ви хочете в майбутньому замінити основні дані будь-якою іншою базою даних, вам доведеться вносити зміни лише в одному класі.
  • Роблячи це, ми можемо легко вирішити, який CoreDataStack звикне або будь-яку іншу установку, яка нам може знадобитися в деяких інших рамках.

Ми створимо протокол CoreDataStack, після чого два CoreDataStack, які відповідають цьому протоколу, один MainCoreDataStack та один MockCoreDataStack.

Потім наша База даних Сервісу може бути ініціалізована будь-якою з них, залежно від того, чи використовуємо ми її в цільовій програмі або на нашій цільовій одиниці тестування.

Наш основний стек основних даних матиме налаштування за замовчуванням, як описано нижче

Під час тестування одиниць завжди слід уникати зміни стану поточних "реальних" об'єктів при їх тестуванні.

Тож, коли ми хочемо створити підроблені суті основних даних, у нас повинна бути окрема стійка система зберігання та використання сховища в пам'яті, щоб внесені зміни не були збережені на диску, і вони будуть повністю відокремлені від даних, що зберігаються в даний час.

Тепер ми зможемо створити нашу службу баз даних, яка буде ініціалізована за замовчуванням з MainCoreDataStack.

І в нашому тестовому класі ми можемо ініціалізувати його підробленим стеком даних

Тепер ми можемо написати кілька простих тестів так:

Використовуючи такий підхід, ми можемо легко протестувати нашу DatabaseService, не впливаючи на будь-які дані, що зберігаються цільовою програмою.

Мережеві запити

Під час тестування мережевого шару ми можемо використовувати підхід, орієнтований на протокол, щоб створити протокол і відповідати йому як реальними NetworkService, так і MockNetworkService, а після цього ввести залежності, використовуючи реальний або глузливий сервіс.

У цій статті, хоча ми будемо використовувати справді приємну бібліотеку з відкритим кодом під назвою OHHTTPStubs, яка ще краще впорається з глузуванням та заглушкою.

Хороша річ у цій бібліотеці полягає в тому, що вона чудово працює з відомою мережевою бібліотекою iOS Alamofire.

Запит на заглушку мережі дуже просто за допомогою OHHTTPStubs ви можете замінити будь-яку відповідь для певного шляху або хоста, надавши власну відповідь зі словником.

Після цього кожен запит, який переходить від програми до наступної URL-адреси, натомість поверне нашу власну відповідь.

нехай завданняURL = URL (рядок: "https://jsonplaceholder.typicode.com/todos")!

Що також дуже цікаво щодо користувацьких відповідей, це те, що ви можете легко перевірити, чи випадки помилок та крайових випадків обробляються правильно, просто повернувши помилку у відповіді.

Створення словника для відповіді вручну є чудовою особливістю, але коли ми хочемо повернути великі дані JSON з великою кількістю властивостей, він може стати безладним і навряд чи реальним у наших тестових класах.

У цих випадках ми можемо використовувати файл JSON, щоб заглушити відповідь, як описано нижче.

Тепер, коли наша програма надсилає запит, ми отримаємо відповідь з файлу myResponse.json, який ми зберегли у своїх файлах.

Ми повинні пам’ятати, щоб уникнути збереження конфіденційної інформації у цих файлах JSON, оскільки якщо ми доставляємо ці файли разом із програмою, їх можна легко переглядати.

Ви можете переглянути мою статтю на тему безпеки, щоб отримати докладнішу інформацію.

У висновку

Тестування нашого додатку є обов'язковим, якщо ми хочемо максимально уникнути регресу, а також намагатися надати бездоганну програму.

У цій статті ми обговорили, як забезпечити тестування на поширені випадки, які виникають під час розробки iOS.

Ми обговорили, як перевірити UserDefaults, Singeltons, Core Data та Network Requests.

Якщо вам сподобалася ця стаття, обов'язково плескайте, щоб показати свою підтримку.

Дотримуйтесь мене, щоб переглянути ще багато статей, які можуть перенести ваші навички розробника iOS на новий рівень.

Якщо у вас є запитання чи коментарі, не соромтесь залишити тут записку або надіслати електронною поштою arlindaliu.dev@gmail.com.