Mitmproxy dans les autotests UI : gestion du trafic pour QA

Intégrer mitmproxy dans les autotest UI : Contrôle du trafic pour les ingénieurs QA

Proxyfier le trafic réseau révolutionne l'efficacité des autotest UI. Contrairement au test manuel avec des outils comme Charles Proxy ou Fiddler, l'automatisation exige des solutions programmables. Mitmproxy, avec son API Python et son mode sans interface, permet d'intégrer une couche réseau contrôlable directement dans votre infrastructure de tests.

Pourquoi les proxies sont essentiels en test automatisé

Les autotest UI souffrent souvent d'une « cécité réseau » : ils ne détectent pas les problèmes d'API, WebSockets ou services backend. Cela entraîne des tests instables, des faux échecs et un débogage ardu. Ajouter un proxy offre une visibilité réseau totale. Principaux cas d'usage :

• Intercepter et analyser les requêtes/réponses HTTP pour vérifier le comportement de l'app.
• Modifier les codes de statut (ex. : 200 → 404) pour tester la gestion d'erreurs côté client.
• Remplacer des données dans les réponses JSON/XML pour simuler des scénarios sans environnement de dev.
• Journaliser le trafic et suivre les séquences de requêtes.
• Gérer les messages WebSocket, y compris injection et modification en temps réel.

Pourquoi mitmproxy est le meilleur choix

Des outils comme Charles, Proxyman ou Fiddler ne conviennent pas à l'automatisation faute d'API de contrôle externe. L'open source mitmproxy excelle avec :

• API Python pour scripter interception et modification du trafic.
• Mode headless pour les pipelines CI/CD sans interface graphique.
• Support WebSocket, indispensable pour les apps web et mobiles modernes.
• Multiplateforme (Windows, Linux, macOS).

Mitmproxy fonctionne en trois modes : mitmproxy (CLI interactif), mitmweb (interface web) et mitmdump (dump non interactif). Pour les autotest, utilisez mitmdump ou mitmweb avec des scripts personnalisés.

Architecture d'intégration avec les frameworks de test

Lancez mitmproxy comme processus indépendant de votre framework de test. Ils communiquent via un fichier de config (ex. : config.json) et un module Python (proxy_handler.py). Flux de travail de base :

• Installer mitmproxy (ex. : brew install mitmproxy).
• Configurer les certificats sur les appareils de test pour intercepter HTTPS.
• Lancer avec mitmweb -s proxy_handler.py.
• Contrôler dynamiquement le proxy en mettant à jour config.json depuis les tests.

Mocking de codes de statut : Exemple concret

Mockons des codes de statut HTTP pour des API spécifiques. Définissez dans config.json :

{
    "status": {"api/v1/user": 404, "api/v2/settings": 500}
}

Utilisez un nombre pour un mock unique, ou une liste (ex. : [404]) pour persistant. Le module proxy_handler.py gère cela :

import re
import mitmproxy.ctx as ctx
from mitmproxy import http
from file_worker import FileWorker

file_worker = FileWorker()

def response(flow: http.HTTPFlow) -> None:
    url = flow.request.url
    if not flow.response.content:
        return
    cfg = file_worker.get_proxy_params()
    cfg_status = cfg.get("status")
    for api, sc in list(cfg_status.items()):
        if bool(re.compile(api).search(url)):
            flow.response.status_code = int(sc[0] if isinstance(sc, list) else sc)
            ctx.log.info(f"Status code was mocked '{api}' -> {sc}")
            if not isinstance(sc, list):
                del cfg_status[api]
                file_worker.set_proxy_param("status", cfg_status)
                cfg["status"] = cfg_status
            break

Points clés d'implémentation :

• Regex (module re) pour un matching d'URI flexible.
• Support des mocks uniques et persistants.
• Journalisation pour un débogage aisé.
• Opérations fichier dans une classe FileWorker dédiée pour un code propre.

Étendre les capacités : Mocking de données et journalisation

De même, mockez les corps de réponses. Ajoutez une section « mock » dans config.json :

{
    "mock": {"api/v1/data": {"field": "new_value"}}
}

Dans proxy_handler.py :

cfg_mock: dict = cfg.get("mock")
if cfg_mock:
    for mock_api, params in list(cfg_mock.items()):
        if bool(re.compile(mock_api).search(url)):
            data = flow.response.content.decode()
            modified = file_worker.mock(params[0] if isinstance(params, list) else params, data)
            if modified:
                flow.response.content = modified.encode()
                ctx.log.info(f"Param {params} were mocked for '{mock_api}'")
            if not isinstance(params, list):
                del cfg_mock[mock_api]
                file_worker.set_proxy_param("mock", cfg_mock)
                cfg["mock"] = cfg_mock
            break

Pour sauvegarder les réponses serveur en fichiers (idéal pour l'analyse), utilisez une section « get_response » dans config.json. Parfait pour :

• Valider les structures de données dans les checks automatisés.
• Construire des réponses de référence pour les tests de régression.
• Déboguer des interactions backend complexes.

Points clés à retenir

• Visibilité réseau : Les proxies corrigent les angles morts des autotest face aux problèmes réseau, améliorant diagnostics et fiabilité.
• Flexibilité mitmproxy : API Python et support WebSocket pour des scénarios trafic complexes sans dépendance GUI.
• Contrôle par config : Les configs JSON rendent les ajustements proxy dynamiques fluides pour les frameworks de test.
• Performance : Optimisez les handlers pour ne pas ralentir proxy ou tests.
• Extensibilité : Design modulaire (proxy_handler.py, FileWorker) facilite l'ajout de fonctionnalités comme le throttling ou l'analyse WebSocket.

Conclusion

Intégrer mitmproxy dans les autotest UI transforme les proxies d'outils manuels en machines automatisées puissantes. Cela booste les tests côté client, surtout pour les simulations backend et la surveillance réseau approfondie. Équilibrez flexibilité de config et performance des handlers pour réussir.

— Editorial Team