Тестування в мобільній розробці: що це, які види та як організувати

Рівні тестування: Unit, Integration, E2E

Unit-тестування

Unit-тести — основа тестування мобільних додатків. Вони перевіряють найменшу одиницю коду — одну функцію, метод або клас в ізоляції від решти системи. У мобільній розробці unit-тести пишуться на JUnit (Android) та XCTest (iOS). Хороший unit-тест має бути швидким, незалежним і повторюваним — він не повинен залежати від мережі, бази даних або UI-компонентів. Для ізоляції використовуються test doubles: моки, стаби та фейки.

Mockito (Java/Kotlin) та MockK (Kotlin-first) — популярні бібліотеки для створення мок-об'єктів на Android. На iOS для мокінгу використовуються OCMock, Cuckoo або ручні протоколи. Правило: unit-тести повинні покривати бізнес-логіку та моделі даних. UI-тести не повинні дублювати unit-тести — вони перевіряють взаємодію користувача з інтерфейсом.

Інтеграційне тестування

Інтеграційні тести перевіряють взаємодію між компонентами: репозиторій з базою даних, ViewModel з API-сервісом, навігація між екранами. На відміну від unit-тестів, інтеграційні використовують реальні або наближені до реальності залежності (наприклад, in-memory база даних або mock-сервер). Robolectric — фреймворк для запуску Android-тестів на JVM без емулятора, що прискорює інтеграційні тести в 10 разів.

Snapshot-тести (Golden Tests) — особливий вид інтеграційних тестів, які порівнюють відрендерений UI-компонент з еталонним зображенням (snapshot). Якщо зовнішній вигляд змінився, тест падає — розробник бачить, що змінилося. Facebook SnapshotTestCase (iOS) та Shot (Android) — популярні інструменти для snapshot-тестування.

E2E та UI-тестування

E2E-тести (end-to-end) перевіряють повний користувацький сценарій від початку до кінця: запуск додатку, логін, виконання дії, перевірка результату. UI-тести — підмножина E2E, зосереджена на інтерфейсі. Інструменти: Espresso (Android), XCUITest (iOS), Detox (React Native). E2E-тести найповільніші, тому їх запускають окремо на CI — зазвичай на нічних збірках.

Інструменти iOS: XCTest та XCUITest

XCTest

XCTest — вбудований фреймворк Apple для unit-тестування мобільних додатків. XCTestRunner запускає тести на симуляторі або реальному пристрої. Тести успадковуються від XCTestCase, містять setUp та tearDown для підготовки та очищення. XCTest включає XCTAssert для перевірок (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) та XCTWaiter для очікування асинхронних операцій.

Приклад простого XCTest-тесту: створення моделі User, перевірка коректності ініціалізації, форматування імені та підрахунку віку. Code Coverage в Xcode показує, які рядки коду покриті тестами — ціль для комерційних проєктів: мінімум 70–80% покриття бізнес-логіки. XCTest інтегрований з Xcode Server та CI-системами через xcodebuild test.

XCUITest

XCUITest — фреймворк Apple для UI-тестування. Працює через accessibility-ідентифікатори: XCUIElementQuery знаходить кнопки, поля введення, таблиці за label, identifier або типом. XCUITest записує послідовність дій (record/playback) та генерує код тесту. Важливо: всі UI-елементи повинні мати accessibilityIdentifier для стабільної роботи тестів.

Інструменти Android: JUnit, Espresso, Robolectric

JUnit та Mockito

JUnit — базовий фреймворк для модульного тестування мобільних додатків на Java/Kotlin. На Android використовується JUnit 4 (остання стабільна версія 4.13.2) та JUnit 5 для нових проєктів. Mockito — бібліотека для створення мок-об'єктів: when(mock.method()).thenReturn(value) — стандартний патерн для ізоляції тестованого класу від залежностей.

Приклад JUnit-тесту для Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso та UI Automator

Espresso — фреймворк Google для UI-тестів Android. Espresso автоматично синхронізується з UI-потоком: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso простий у написанні та стабільний завдяки вбудованому очікуванню ідл-стану додатку. UI Automator — фреймворк для кросспрограмних тестів, який може взаємодіяти з системними елементами (діалогами дозволів, шторкою сповіщень).

Кроссплатформенні інструменти: Detox, Appium

Detox для React Native

Detox — сіро-сірий E2E-фреймворк для тестування React Native мобільних додатків від Wix. Detox працює на обох платформах з однієї кодової бази тестів, використовуючи Espresso (Android) та XCUITest (iOS) під капотом. Detox автоматично чекає, поки додаток стане ідл (немає анімацій, мережевих запитів, таймерів), і лише тоді виконує наступну дію.

Appium

Appium — універсальний кроссплатформенний фреймворк, що підтримує Android, iOS, Web та гібридні додатки. Appium використовує WebDriver протокол і підходить для будь-яких мов програмування (Java, Python, JS, Ruby). Appium Server працює як HTTP-сервер, який транслює команди в нативні UI Automator / XCUITest команди. Основний недолік Appium — швидкість: тести виконуються повільніше, ніж нативні Espresso або XCUITest.

TDD та BDD: методології тестування

TDD: Test-Driven Development

TDD — методологія тестування мобільних додатків, при якій тест пишеться до реалізації коду. Цикл Red-Green-Refactor: (1) написати тест, який не проходить (Red), (2) написати мінімальний код, щоб тест пройшов (Green), (3) відрефакторити код, зберігаючи проходження тесту. TDD дає 100% покриття тестами нової функціональності та чисту архітектуру, оскільки тест — це перша специфікація вимоги.

BDD: Behaviour-Driven Development

BDD — розширення TDD, де тести пишуться природною мовою у форматі Given-When-Then. Given (контекст) — When (дія) — Then (очікуваний результат). BDD-тести зрозумілі всім учасникам команди: розробникам, тестувальникам, аналітикам та замовникам. Mock vs Stub vs Fake: Mock перевіряє взаємодію (чи був викликаний метод), Stub повертає фіксовані дані, Fake — спрощена робоча реалізація (наприклад, in-memory БД). В IT Sectr ми використовуємо TDD для критичної бізнес-логіки та BDD для приймальних сценаріїв.

Test Doubles — загальна назва для об'єктів, що замінюють реальні залежності в тестах. Їх чотири типи: Dummy (об'єкт для заповнення параметрів, не використовується), Stub (повертає задані значення), Spy (записує виклики для перевірки), Mock (визначає очікувані виклики). Розуміння різниці критично важливе для правильного проєктування тестів.

CI/CD та Device Farm

Автоматизація тестів в CI/CD

CI/CD — Continuous Integration та Continuous Delivery: практика автоматичної збірки та тестування мобільних додатків при кожній зміні коду. У мобільній розробці CI/CD пайплайн включає: лінтинг, unit-тести, інтеграційні тести, збірку APK/IPA та UI-тести. GitHub Actions та Bitrise — популярні платформи для мобільного CI/CD. Тести повинні виконуватися швидко: unit-тести за 1–2 хвилини, інтеграційні за 5–10, UI-тести за 15–30 хвилин.

Device Farm

Device Farm — ферма реальних пристроїв для тестування. Firebase Test Lab (Android) та Xcode Cloud (iOS) надають хмарний доступ до сотень моделей пристроїв. Device Farm виявляє проблеми, які не видно на емуляторах: особливості екранів різних розмірів, продуктивність на старих пристроях, проблеми з сумісністю. В IT Sectr ми використовуємо Firebase Test Lab для Android та Xcode Cloud для iOS на регулярній основі.