Інтеграційне тестування в мобільній розробці — суть, види та як проводиться

Що таке інтеграційне тестування?

Інтеграційне тестування — це етап перевірки програмного забезпечення, на якому оцінюється коректність взаємодії між окремими модулями або підсистемами додатка. Якщо модульні тести перевіряють кожен компонент ізольовано, то інтеграційні тести збирають ці компоненти разом і перевіряють, як вони працюють у зв’язці. Типові сценарії включають передачу даних між мережевим рівнем та репозиторієм, запис у базу даних через ORM та обробку відповідей від сторонніх API.

У контексті мобільної розробки інтеграційні тести охоплюють взаємодію між UI-шаром, бізнес-логікою та джерелами даних. Наприклад, тест може перевірити, що після натискання кнопки «Увійти» додаток надсилає запит на сервер, отримує токен та зберігає його в локальному сховищі. Така перевірка підтверджує, що ланцюг компонентів працює без збоїв.

За даними звіту World Quality Report 2023, компанії, які регулярно застосовують інтеграційне тестування, зменшують кількість виробничих інцидентів на 35% порівняно з проєктами, що покладаються лише на модульні тести. Це робить інтеграційні перевірки обов’язковим елементом стратегії забезпечення якості в комерційній розробці.

Навіщо потрібне інтеграційне тестування в мобільних додатках

Мобільні додатки складаються з багатьох взаємопов’язаних компонентів: мережевих запитів, локальних баз даних, push-повідомлень, системних сервісів та сторонніх SDK. Кожен з цих компонентів розробляється окремо, але в часі виконання вони обмінюються даними в реальному часі. Інтеграційне тестування виявляє дефекти, які неможливо виявити при ізольованій перевірці модулів.

До числа типових проблем, що виявляються інтеграційними тестами, належать невідповідність типів даних між API та моделлю додатка, помилки серіалізації JSON, некоректна обробка мережевих таймаутів та збої при паралельному доступі до бази даних через Room або Core Data. Без інтеграційних перевірок такі дефекти потрапляють у виробництво та проявляються лише у реальних користувачів.

Дослідження Google Testing Blog (2021) показує, що вартість виправлення дефекту, виявленого на етапі інтеграційного тестування, в 5 разів нижча, ніж після релізу. Це пояснюється тим, що на ранніх стадіях розробник має повний контекст помилки і може виправити її без термінового циклу hotfix. Інвестування часу в написання інтеграційних тестів окупається зниженням витрат на супровід та підвищенням довіри користувачів.

Підходи до інтеграційного тестування

Існує три основні підходи до організації інтеграційних тестів: Big Bang, Bottom-Up та Top-Down. Вибір стратегії залежить від розміру проєкту, архітектури додатка та доступності компонентів на момент написання тестів. Кожен підхід має свої переваги та обмеження, які важливо враховувати при плануванні тестового покриття.

Big Bang

Big Bang — підхід, коли всі компоненти системи з’єднуються одночасно, після чого виконується загальний тестовий прогін. Цей метод простий у реалізації: не потрібно писати заглушки чи емулювати окремі модулі. Однак при виявленні помилки складно визначити, який саме компонент став її джерелом. Big Bang виправданий у невеликих проєктах з простою архітектурою, де кількість модулів не перевищує п’яти.

Bottom-Up

Bottom-Up — стратегія, коли інтеграційне тестування починається з низькорівневих компонентів: бази даних, мережевого рівня, системних сервісів. Після перевірки кожного рівня тести поступово підключають вищостоячі модулі — репозиторії, Use Case-класи та ViewModel. Головна перевага — раннє виявлення дефектів у фундаментальних шарах додатка, що знижує ризик каскадних помилок на пізніх етапах розробки.

Top-Down

Top-Down — підхід, коли тестування починається з компонентів верхнього рівня — UI-екранів та навігації, а нижчостоячі модулі імітуються за допомогою заглушок або моків. Це дозволяє перевіряти користувацькі сценарії до того, як серверна частина або база даних повністю реалізовані. Top-Down особливо корисний при паралельній розробці клієнтської та серверної частин, коли бекенд ще не готовий до реальної інтеграції.

Інструменти для інтеграційного тестування

Для інтеграційного тестування мобільних додатків використовується набір спеціалізованих інструментів, які діляться на три категорії: бібліотеки для емуляції серверів, фреймворки для роботи з базами даних та засоби перевірки системних сервісів. Вибір конкретного інструмента залежить від платформи — Android або iOS — та технологічного стеку проєкту.

• MockWebServer — бібліотека Square для Android, що емулює HTTP-сервер у тестовому середовищі. Дозволяє задавати очікувані відповіді, перевіряти тіло та заголовки запитів, симулювати мережеві помилки.
• OHHTTPStubs — бібліотека для iOS, що перехоплює мережеві запити на рівні NSURLProtocol та повертає запопередньо підготовлені відповіді. Підтримує затримки та помилки з’єднання.
• Room Testing — вбудований механізм Android для тестування бази даних: створення екземпляра Room в пам’яті, виконання операцій читання та запису, перевірка міграцій та трігерів.
• Core Data Testing — підхід для iOS, коли створюється контейнер Core Data в пам’яті, що дозволяє тестувати запити, зв’язки між сутностями та збереження даних без постійного сховища.

Приклади коду для інтеграційних тестів

Розглянемо практичні приклади інтеграційних тестів для Android та iOS. Для платформи Android використовуємо MockWebServer разом з JUnit, для iOS — XCTest з бібліотекою OHHTTPStubs. Обидва приклади перевіряють сценарій отримання даних від API та їх збереження в локальному репозиторії.

Android: Тестування мережевого рівня з MockWebServer

Цей тест перевіряє, що Retrofit-запит до емульованого сервера повертає коректний JSON, а репозиторія перетворює відповідь у доменну модель. MockWebServer перехоплює запит та повертає заданий JSON, після чого тест порівнює очікуваний результат з фактичним.

class UserRepositoryTest {
    private val mockServer = MockWebServer()

    @Before
    fun setup() {
        mockServer.start()
    }

    @Test
    fun fetchUser_returnsCorrectData() {
        val json = "{ \`"id\`": 1, \`"name\`": \`"Alice\`" }"
        mockServer.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200))

        val repository = UserRepository(
            createRetrofit(mockServer.url("/").toString()))
        val user = repository.fetchUser(1)

        assertEquals(1, user.id)
        assertEquals("Alice", user.name)
    }

    @After
    fun tearDown() {
        mockServer.shutdown()
    }
}

iOS: Тестування API-запитів з OHHTTPStubs

Для iOS аналогічний тест використовує OHHTTPStubs для перехоплення URL-запитів. Бібліотека підмінює відповідь сервера на рівні системного фреймворку URL Loading System, що дозволяє тестувати будь-яку мережеву бібліотеку — URLSession, Alamofire або Moya.

import XCTest
import OHHTTPStubs
import OHHTTPStubsSwift

class UserRepositoryTests: XCTestCase {
    func testFetchUser_returnsCorrectData() {
        stub(condition: isPath("/users/1")) { _ in
            return HTTPStubsResponse(
                jsonObject: ["id": 1, "name": "Alice"],
                statusCode: 200,
                headers: nil
            )
        }

        let repository = UserRepository()
        let expectation = expectation(description: "fetch user")

        repository.fetchUser(id: 1) { user in
            XCTAssertEqual(user.id, 1)
            XCTAssertEqual(user.name, "Alice")
            expectation.fulfill()
        }

        waitForExpectations(timeout: 2.0)
    }
}

Кращі практики інтеграційного тестування

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

Підтримуйте незалежність тестів: кожен інтеграційний тест повинен працювати ізольовано, без залежності від результатів інших тестів. Використовуйте анотації @Before та @After в JUnit або setUp та tearDown в XCTest для підготовки та очищення тестового середовища. Це запобігає взаємному впливу тестів та спрощує діагностику помилок.

Охоплюйте крайові випадки: інтеграційні тести мають перевіряти не лише успішні сценарії (happy path), але й обробку помилок — таймаути, HTTP-коди 4xx та 5xx, порожні відповіді, некоректний JSON. За даними Google Testing Blog (2022), 60% виробничих інцидентів пов’язані з некоректною обробкою крайових випадків, які не були покриті тестами.