Les tests dans le développement mobile : définition, types et organisation

Niveaux de test : Unit, Integration, E2E

Tests unitaires

Les tests unitaires sont la base des tests d'applications mobiles. Ils vérifient la plus petite unité de code — une fonction, méthode ou classe isolée du reste du système. Dans le développement mobile, les tests unitaires sont écrits en JUnit (Android) et XCTest (iOS). Un bon test unitaire doit être rapide, indépendant et reproductible — il ne doit pas dépendre du réseau, de la base de données ou des composants d'interface. Pour l'isolation, on utilise des test doubles : mocks, stubs et fakes.

Mockito (Java/Kotlin) et MockK (Kotlin-first) sont des bibliothèques populaires pour créer des objets mock sur Android. Sur iOS, on utilise OCMock, Cuckoo ou des protocoles manuels. Règle : les tests unitaires doivent couvrir la logique métier et les modèles de données. Les tests d'UI ne doivent pas dupliquer les tests unitaires — ils vérifient l'interaction de l'utilisateur avec l'interface.

Tests d'intégration

Les tests d'intégration vérifient l'interaction entre les composants : dépôt avec base de données, ViewModel avec service API, navigation entre écrans. Contrairement aux tests unitaires, les tests d'intégration utilisent des dépendances réelles ou proches de la réalité (par exemple, base de données en mémoire ou serveur mock). Robolectric est un framework pour exécuter des tests Android sur JVM sans émulateur, accélérant les tests d'intégration de 10 fois.

Les tests de snapshot (Golden Tests) sont un type spécial de test d'intégration qui comparent un composant d'interface rendu avec une image de référence (snapshot). Si l'apparence change, le test échoue — le développeur voit ce qui a changé. Facebook SnapshotTestCase (iOS) et Shot (Android) sont des outils populaires pour les tests de snapshot.

Tests E2E et d'UI

Les tests E2E (end-to-end) vérifient le scénario utilisateur complet du début à la fin : lancement de l'application, connexion, réalisation d'une action, vérification du résultat. Les tests d'UI sont un sous-ensemble des E2E axé sur l'interface. Outils : Espresso (Android), XCUITest (iOS), Detox (React Native). Les tests E2E sont les plus lents, ils sont donc exécutés séparément sur le CI — généralement lors des builds nocturnes.

Outils iOS : XCTest et XCUITest

XCTest

XCTest est le framework intégré d'Apple pour les tests unitaires d'applications mobiles. XCTestRunner exécute les tests sur le simulateur ou un appareil réel. Les tests héritent de XCTestCase, contiennent setUp et tearDown pour la préparation et le nettoyage. XCTest inclut XCTAssert pour les assertions (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) et XCTWaiter pour attendre les opérations asynchrones.

Exemple d'un test XCTest simple : création d'un modèle User, vérification de l'exactitude de l'initialisation, du formatage du nom et du calcul de l'âge. Code Coverage dans Xcode montre quelles lignes de code sont couvertes par les tests — l'objectif pour les projets commerciaux : au moins 70–80 % de couverture de la logique métier. XCTest est intégré avec Xcode Server et les systèmes CI via xcodebuild test.

XCUITest

XCUITest est le framework d'Apple pour les tests d'UI. Il fonctionne via des identifiants d'accessibilité : XCUIElementQuery trouve les boutons, champs de saisie, tableaux par label, identifiant ou type. XCUITest enregistre une séquence d'actions (record/playback) et génère du code de test. Important : tous les éléments d'interface doivent avoir un accessibilityIdentifier pour un fonctionnement stable des tests.

Outils Android : JUnit, Espresso, Robolectric

JUnit et Mockito

JUnit est le framework de base pour les tests unitaires d'applications mobiles en Java/Kotlin. Sur Android, on utilise JUnit 4 (dernière version stable 4.13.2) et JUnit 5 pour les nouveaux projets. Mockito est une bibliothèque pour créer des objets mock : when(mock.method()).thenReturn(value) — un modèle standard pour isoler la classe testée des dépendances.

Exemple d'un test JUnit pour 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 et UI Automator

Espresso est le framework de Google pour les tests d'UI Android. Espresso se synchronise automatiquement avec le thread d'interface : onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso est facile à écrire et stable grâce à l'attente intégrée de l'état inactif. UI Automator est un framework pour les tests inter-applications qui peut interagir avec des éléments système (dialogues d'autorisation, volet de notifications).

Outils multiplateformes : Detox, Appium

Detox pour React Native

Detox est un framework E2E en boîte grise pour tester les applications mobiles React Native de Wix. Detox fonctionne sur les deux plateformes à partir d'une seule base de code de test, utilisant Espresso (Android) et XCUITest (iOS) en interne. Detox attend automatiquement que l'application devienne inactive (pas d'animations, de requêtes réseau, de minuteurs) et seulement ensuite exécute l'action suivante.

Appium

Appium est un framework multiplateforme universel supportant Android, iOS, le Web et les applications hybrides. Appium utilise le protocole WebDriver et supporte tout langage de programmation (Java, Python, JS, Ruby). Appium Server fonctionne comme un serveur HTTP qui traduit les commandes en commandes natives UI Automator / XCUITest. Le principal inconvénient d'Appium est la vitesse : les tests s'exécutent plus lentement que les natifs Espresso ou XCUITest.

TDD et BDD : méthodologies de test

TDD : Test-Driven Development

TDD est une méthodologie de test d'applications mobiles où le test est écrit avant le code d'implémentation. Le cycle Red-Green-Refactor : (1) écrire un test qui échoue (Red), (2) écrire le code minimal pour faire passer le test (Green), (3) refactoriser le code en maintenant le test réussi. TDD offre une couverture de test à 100 % pour les nouvelles fonctionnalités et une architecture propre, car le test est la première spécification de l'exigence.

BDD : Behaviour-Driven Development

BDD est une extension de TDD où les tests sont écrits en langage naturel au format Given-When-Then. Given (contexte) — When (action) — Then (résultat attendu). Les tests BDD sont compréhensibles par tous les membres de l'équipe : développeurs, testeurs, analystes et clients. Mock vs Stub vs Fake : Mock vérifie l'interaction (la méthode a-t-elle été appelée), Stub retourne des données fixes, Fake est une implémentation de travail simplifiée (par exemple, BD en mémoire). Chez IT Sectr, nous utilisons TDD pour la logique métier critique et BDD pour les scénarios d'acceptation.

Les Test Doubles est le nom général des objets qui remplacent les dépendances réelles dans les tests. Il existe quatre types : Dummy (objet pour remplir les paramètres, non utilisé), Stub (retourne des valeurs données), Spy (enregistre les appels pour vérification), Mock (prédéfinit les appels attendus). Comprendre la différence est essentiel pour une conception de test correcte.

CI/CD et Device Farm

Automatisation des tests dans CI/CD

CI/CD — Intégration Continue et Livraison Continue : la pratique de construire et tester automatiquement les applications mobiles à chaque changement de code. Dans le développement mobile, le pipeline CI/CD comprend : linting, tests unitaires, tests d'intégration, build APK/IPA et tests d'UI. GitHub Actions et Bitrise sont des plateformes populaires pour le CI/CD mobile. Les tests doivent s'exécuter rapidement : tests unitaires en 1–2 minutes, d'intégration en 5–10, d'UI en 15–30 minutes.

Device Farm

Device Farm est une ferme d'appareils réels pour les tests. Firebase Test Lab (Android) et Xcode Cloud (iOS) fournissent un accès cloud à des centaines de modèles d'appareils. Device Farm révèle des problèmes non visibles sur les émulateurs : différentes tailles d'écran, performances sur les anciens appareils, problèmes de compatibilité. Chez IT Sectr, nous utilisons régulièrement Firebase Test Lab pour Android et Xcode Cloud pour iOS.