Les tests d’intégration dans le développement mobile — définition, types et déroulement

Qu’est-ce que les tests d’intégration ?

Les tests d’intégration sont une étape de vérification logicielle où l’on évalue la pertinence de l’interaction entre des modules ou sous-systèmes individuels d’une application. Alors que les tests unitaires vérifient chaque composant de manière isolée, les tests d’intégration rassemblent ces composants et vérifient comment ils fonctionnent ensemble. Les scénarios typiques incluent le transfert de données entre la couche réseau et le référentiel, l’écriture dans une base de données via ORM et le traitement des réponses d’API tierces.

Dans le contexte du développement mobile, les tests d’intégration couvrent les interactions entre la couche UI, la logique métier et les sources de données. Par exemple, un test peut vérifier qu’après avoir cliqué sur le bouton « Connexion », l’application envoie une requête au serveur, reçoit un jeton et le sauvegarde dans le stockage local. Cette vérification confirme que la chaîne de composants fonctionne sans défaillance.

Selon le World Quality Report 2023, les entreprises qui appliquent régulièrement les tests d’intégration réduisent le nombre d’incidents de production de 35% par rapport aux projets ne s’appuyant que sur des tests unitaires. Cela fait des vérifications d’intégration un élément obligatoire de la stratégie d’assurance qualité dans le développement commercial.

Pourquoi les tests d’intégration sont importants dans les applications mobiles

Les applications mobiles sont constituées de nombreux composants interconnectés : requêtes réseau, bases de données locales, notifications push, services système et SDK tiers. Chacun de ces composants est développé séparément, mais au moment de l’exécution, ils échangent des données en temps réel. Les tests d’intégration détectent les défauts impossibles à trouver lors de la vérification isolée des modules.

Parmi les problèmes typiques découverts par les tests d’intégration figurent l’inadéquation des types de données entre l’API et le modèle de l’application, les erreurs de sérialisation JSON, le traitement incorrect des délais d’attente réseau et les échecs lors de l’accès simultané à la base de données via Room ou Core Data. Sans vérifications d’intégration, ces défauts atteignent la production et ne se manifestent qu’auprès des utilisateurs réels.

Les recherches du Google Testing Blog (2021) montrent que le coût de correction d’un défaut découvert lors des tests d’intégration est 5 fois inférieur à celui après le lancement. Cela s’explique par le fait qu’aux premiers stades, le développeur a le contexte complet de l’erreur et peut la corriger sans cycle urgent de hotfix. Investir du temps dans l’écriture de tests d’intégration est rentabilisé par la réduction des coûts de maintenance et l’augmentation de la confiance des utilisateurs.

Approches des tests d’intégration

Il existe trois approches principales pour organiser les tests d’intégration : Big Bang, Bottom-Up et Top-Down. Le choix de la stratégie dépend de la taille du projet, de l’architecture de l’application et de la disponibilité des composants au moment de la rédaction des tests. Chaque approche a ses avantages et ses limites qu’il est important de prendre en compte lors de la planification de la couverture des tests.

Big Bang

Big Bang — approche où tous les composants du système sont connectés simultanément, après quoi une exécution de test générale est effectuée. Cette méthode est simple à mettre en œuvre : il n’est pas nécessaire d’écrire de stubs ou d’émuler des modules individuels. Cependant, lorsqu’une erreur est détectée, il est difficile de déterminer quel composant en est la cause. Big Bang se justifie dans les petits projets avec une architecture simple où le nombre de modules ne dépasse pas cinq.

Bottom-Up

Bottom-Up — stratégie où les tests d’intégration commencent par les composants de bas niveau : base de données, couche réseau, services système. Après avoir vérifié chaque niveau, les tests connectent progressivement les modules de niveau supérieur — référentiels, classes Use Case et ViewModels. Le principal avantage est la détection précoce des défauts dans les couches fondamentales de l’application, ce qui réduit le risque d’erreurs en cascade dans les étapes ultérieures du développement.

Top-Down

Top-Down — approche où les tests commencent par les composants de haut niveau — écrans UI et navigation, tandis que les modules de niveau inférieur sont simulés à l’aide de stubs ou de mocks. Cela permet de vérifier les scénarios utilisateur avant que la partie serveur ou la base de données ne soient complètement implémentées. Top-Down est particulièrement utile lors du développement parallèle des parties cliente et serveur lorsque le backend n’est pas encore prêt pour une intégration réelle.

Outils pour les tests d’intégration

Pour les tests d’intégration des applications mobiles, une gamme d’outils spécialisés est utilisée, répartis en trois catégories : les bibliothèques d’émulation de serveurs, les frameworks pour travailler avec les bases de données et les outils de vérification des services système. Le choix de l’outil spécifique dépend de la plateforme — Android ou iOS — et de la pile technologique du projet.

• MockWebServer — bibliothèque Square pour Android qui émule un serveur HTTP dans un environnement de test. Permet de définir des réponses attendues, de vérifier le corps et les en-têtes des requêtes, de simuler des erreurs réseau.
• OHHTTPStubs — bibliothèque pour iOS qui intercepte les requêtes réseau au niveau NSURLProtocol et retourne des réponses préparées à l’avance. Prend en charge les retards et les erreurs de connexion.
• Room Testing — mécanisme intégré d’Android pour tester la base de données : création d’une instance Room en mémoire, exécution d’opérations de lecture et d’écriture, vérification des migrations et des déclencheurs.
• Core Data Testing — approche pour iOS où un conteneur Core Data en mémoire est créé, permettant de tester les requêtes, les relations entre entités et la persistance des données sans stockage permanent.

Exemples de code pour les tests d’intégration

Examinons des exemples pratiques de tests d’intégration pour Android et iOS. Pour la plateforme Android, nous utilisons MockWebServer avec JUnit, pour iOS — XCTest avec la bibliothèque OHHTTPStubs. Les deux exemples vérifient le scénario de réception de données depuis une API et de leur sauvegarde dans un référentiel local.

Android : Tester la couche réseau avec MockWebServer

Ce test vérifie qu’une requête Retrofit au serveur émulé retourne un JSON correct, et que le référentiel convertit la réponse en un modèle de domaine. MockWebServer intercepte la requête et retourne le JSON spécifié, après quoi le test compare le résultat attendu avec le résultat réel.

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 : Tester les requêtes API avec OHHTTPStubs

Pour iOS, un test similaire utilise OHHTTPStubs pour intercepter les requêtes URL. La bibliothèque remplace la réponse du serveur au niveau du framework système URL Loading System, permettant de tester toute bibliothèque réseau — URLSession, Alamofire ou 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)
    }
}

Bonnes pratiques des tests d’intégration

Des tests d’intégration efficaces nécessitent le respect d’un ensemble de pratiques qui augmentent la stabilité des tests et réduisent les coûts de maintenance. Isolez les dépendances externes : utilisez des bases de données en mémoire au lieu d’instances de production et émulez les API tierces à l’aide de bibliothèques de stubs. Cela élimine les échecs non déterministes causés par la disponibilité du réseau ou l’état des services externes.

Maintenez l’indépendance des tests : chaque test d’intégration doit fonctionner de manière isolée, sans dépendre des résultats d’autres tests. Utilisez les annotations @Before et @After dans JUnit ou setUp et tearDown dans XCTest pour préparer et nettoyer l’environnement de test. Cela empêche l’influence mutuelle des tests et simplifie le diagnostic des erreurs.

Couvrez les cas limites : les tests d’intégration doivent vérifier non seulement les scénarios de réussite (happy path) mais aussi le traitement des erreurs — délais d’attente, codes HTTP 4xx et 5xx, réponses vides, JSON malformé. Selon le Google Testing Blog (2022), 60% des incidents de production sont liés à un traitement incorrect des cas limites qui n’étaient pas couverts par les tests.