Tests Automatisés : Garantir la Qualité Logicielle

Les tests automatisés sont le filet de sécurité qui permet aux équipes de livrer du code avec confiance. Sans tests, chaque modification est un pari : le changement fonctionne-t-il ? A-t-il cassé autre chose ? Les tests manuels sont trop lents et trop coûteux pour être exécutés à chaque commit. Chez MapWay, nos suites de tests protègent les fonctionnalités critiques de TMaps — un bug dans un calcul de distance ou un géocodage erroné pourrait avoir des conséquences concrètes pour nos utilisateurs.

La pyramide des tests

La pyramide des tests, conceptualisée par Mike Cohn, définit la répartition idéale entre les différents types de tests :

• Base : tests unitaires (70%) — rapides, isolés, testent une seule fonction ou composant. Ils forment la majorité des tests.
• Milieu : tests d'intégration (20%) — vérifient les interactions entre modules, les appels API et les requêtes de base de données.
• Sommet : tests E2E (10%) — simulent le parcours complet de l'utilisateur dans un navigateur réel. Lents mais essentiels pour valider les flux critiques.

Cette répartition n'est pas une règle absolue mais un guide. Certains projets bénéficient de plus de tests d'intégration, notamment les API backends où la logique métier implique souvent des interactions avec la base de données. L'essentiel est de trouver l'équilibre entre confiance, vitesse d'exécution et coût de maintenance.

Tests unitaires avec Jest et Vitest

Les tests unitaires vérifient le comportement d'une unité de code isolée — une fonction, une classe, un composant React — en mockant ses dépendances. Jest, développé par Meta, est le framework de test le plus populaire dans l'écosystème JavaScript. Vitest, plus récent, offre une compatibilité API avec Jest mais avec des performances nettement supérieures grâce à son utilisation de Vite.

Un bon test unitaire suit le pattern AAA : Arrange (préparer les données), Act (exécuter l'action testée), Assert (vérifier le résultat). Chez MapWay, nos tests unitaires couvrent tous les calculs géographiques : conversion de coordonnées, calcul de distances haversine, validation de géométries GeoJSON, transformation de projections. Un bug dans ces fonctions pourrait affecter des milliers d'utilisateurs.

Tests d'intégration

Les tests d'intégration vérifient que les modules fonctionnent correctement ensemble. Pour une API, cela signifie tester les endpoints avec une vraie base de données (ou un conteneur Docker éphémère) plutôt que des mocks. Supertest est l'outil de référence pour tester les API Express.

Pour nos API cartographiques chez MapWay, les tests d'intégration sont cruciaux. Ils vérifient que les requêtes PostGIS retournent les bons résultats, que le géocodage fonctionne de bout en bout, et que les permissions d'accès sont correctement appliquées. Nous utilisons des conteneurs Docker Testcontainers pour créer des instances PostgreSQL/PostGIS éphémères à chaque exécution des tests, garantissant un environnement propre et reproductible.

Tests E2E avec Playwright

Les tests end-to-end simulent les actions d'un utilisateur réel dans un navigateur : cliquer sur des boutons, remplir des formulaires, naviguer entre les pages. Playwright, développé par Microsoft, est devenu la référence en 2025-2026, surpassant Cypress en performance, en fiabilité et en support multi-navigateurs.

Playwright supporte Chrome, Firefox et Safari, s'exécute en mode headless pour la CI, et offre des fonctionnalités avancées comme l'interception de requêtes réseau, les captures d'écran automatiques en cas d'échec, et le test de composants isolés. Pour nos applications cartographiques, nous testons les interactions avec la carte : zoom, déplacement, clic sur un marqueur, recherche d'adresse et affichage d'itinéraire.

TDD : Test-Driven Development

Le TDD inverse le cycle habituel : vous écrivez d'abord le test (qui échoue), puis le code minimal pour le faire passer, puis vous refactorez. Ce cycle Red-Green-Refactor produit un code bien testé par construction et favorise un design modulaire et découplé.

Le TDD est particulièrement efficace pour la logique métier complexe. Chez MapWay, nous l'utilisons systématiquement pour les algorithmes de géocodage et de calcul d'itinéraires. Les cas limites (adresse ambiguë, coordonnées aux limites des fuseaux horaires, routes sans issue) sont identifiés avant même l'écriture du code, réduisant considérablement les bugs en production.

Couverture de code : un indicateur, pas un objectif

La couverture de code mesure le pourcentage de lignes exécutées par les tests. Un chiffre élevé (80%+) est rassurant mais ne garantit pas la qualité des tests. Il est possible d'atteindre 100% de couverture avec des tests qui ne vérifient rien de significatif. À l'inverse, un code critique peut ne pas être testé malgré une couverture globale élevée. Utilisez la couverture comme un indicateur pour identifier les zones non testées, pas comme un objectif à maximiser aveuglément. Concentrez vos efforts de test sur la logique métier critique et les flux utilisateur principaux.

Intégration dans le pipeline CI/CD

Les tests automatisés prennent toute leur valeur lorsqu'ils sont intégrés dans le pipeline CI/CD. Notre pipeline chez MapWay exécute les tests en trois étapes parallèles :

• Étape 1 (30s) : lint, vérification des types TypeScript, tests unitaires
• Étape 2 (2min) : tests d'intégration avec base de données Docker
• Étape 3 (5min) : tests E2E sur les parcours utilisateur critiques

Un échec à n'importe quelle étape bloque le merge de la pull request. Les rapports de couverture sont automatiquement commentés sur la PR, permettant au reviewer de vérifier que les nouvelles fonctionnalités sont correctement testées. Cette discipline nous permet de maintenir la fiabilité de nos applications cartographiques tout en déployant plusieurs fois par semaine.