Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

La peur du déploiement

Chaque ingénieur logiciel connaît ce sentiment. Nous sommes vendredi, 16h00. Vous venez de fusionner une Pull Request. Le pipeline de déploiement passe au vert. Tu devrais être heureux. Mais tu transpires. « Est-ce que j’ai interrompu le flux de paiement ? » « Ai-je rompu la réinitialisation du mot de passe ? » “Ai-je testé le menu mobile sur Safari ?” Si vous comptez sur les Tests manuels (en cliquant vous-même sur le site Web), vous vivez dans un état constant de peur. Les humains sont terribles lors des tests de régression. On s’ennuie. Des choses nous manquent. On teste le « Happy Path » et on oublie les cas extrêmes. À mesure que la base de code grandit, le temps nécessaire pour la tester manuellement augmente de manière linéaire. Finalement, vous arrêtez de tester. C’est à ce moment-là que les bugs s’infiltrent dans la production. Et lorsque des bugs fuient, vous perdez des revenus. Vous perdez confiance. Les tests automatisés sont le remède à cette peur. Il transforme le déploiement d’un « événement à haut risque » en un « non-événement ».

Pourquoi Maison Code discute des tests automatisés

Chez Maison Code, nous travaillons avec des marques de luxe à forts enjeux et des plateformes e-commerce à fort trafic. Nos clients génèrent des milliers d’euros par minute lors des pics de ventes (Black Friday, Noël). Un bug « mineur » dans le flux de paiement n’est pas un inconvénient ; c’est une catastrophe financière. Nous avons vu des marques perdre 50 000 € en une heure parce qu’un bouton « AddToCart » était couvert par une erreur Z-Index sur l’iPhone 12. Nous parlons de tests automatisés car La stabilité est un revenu. Nous ne vendons pas de « code ». Nous vendons de la « Fiabilité ». La mise en œuvre d’une suite E2E robuste est souvent la première chose que nous faisons lors de l’audit de la base de code existante d’un client. Cela arrête le saignement et nous permet de refactoriser en toute confiance.

1. La pyramide des tests : un cadre stratégique

Mike Cohn a popularisé le concept de « Testing Pyramid », et il reste la référence en matière de stratégie de test. Il définit la répartition idéale des tests dans votre suite.

Tests unitaires (70%) :
- Portée : fonctions ou classes individuelles.
- Vitesse : millisecondes.
- Coût : bon marché.
- Outil : Jest, Vitest.
- Exemple : add(2, 2) === 4.
Tests d’intégration (20%) :
- Portée : interactions entre les composants (par exemple, le parent transmettant des accessoires à l’enfant).
- Vitesse : secondes.
- Coût : moyen.
- Outil : bibliothèque de tests React.
Tests de bout en bout (E2E) (10 %) :
- Portée : flux d’utilisateurs complets dans un vrai navigateur.
- Vitesse : minutes.
- Coût : cher (calcul lourd).
- Outil : dramaturge, Cypress.

Dans cet article, nous nous concentrerons sur le sommet de la pyramide : E2E Testing. Pourquoi? Parce qu’il offre le coefficient de confiance le plus élevé. Un test unitaire peut réussir même si le bouton “Soumettre” est masqué par un bug CSS z-index. Un test E2E échouera car il essaie de cliquer sur le bouton. Si un test E2E indique « Article acheté par l’utilisateur », vous pouvez être sûr à 99,9 % que les utilisateurs peuvent acheter des articles.

2. L’outil de choix : le dramaturge

Pendant une décennie, Selenium était la norme. C’était lent, basé sur Java et notoirement instable. Puis vint Cyprès. Il s’agissait d’une amélioration considérable, avec une excellente expérience de développement, mais elle présentait des limitations architecturales (exécution dans le bac à sable du navigateur, prise en charge multi-onglets limitée). Aujourd’hui, la norme de l’industrie est Playwright (de Microsoft). Pourquoi dramaturge ?

Vitesse : il exécute des tests en parallèle sur plusieurs processus de travail.
Fiabilité : Il dispose d’une “attente automatique”. Il attend que les éléments soient exploitables avant d’interagir. Plus de « sommeil (1000) ».
Multi-navigateur : il teste nativement sur Chromium, Firefox et WebKit (Safari).
Traçage : il enregistre une vidéo complète et une trace DOM de chaque échec, ce qui rend le débogage trivial.

3. Implémentation : tester un flux de paiement

Regardons un exemple concret. Nous voulons tester qu’un utilisateur invité peut acheter un produit.

// tests/checkout.spec.ts
importer { test, attendre } depuis '@playwright/test' ;

test.describe('Flux de paiement', () => {
  
  // Isoler l'environnement de test
  test.beforeEach(async ({ page }) => {
    // Réinitialiser les cookies/stockage
    attendre page.context().clearCookies();
  });

  test('L'utilisateur invité peut acheter un article', async ({ page }) => {
    // 1. Navigation
    console.log('Navigation vers la page produit...');
    attendre page.goto('/products/silk-shirt');
    wait expect(page).toHaveTitle(/Silk Shirt/);
    
    // 2. Ajouter au panier
    // Utiliser des localisateurs destinés à l'utilisateur (Rôle, Étiquette, Texte)
    // Évitez les sélecteurs CSS comme '.btn-primary' (fragile)
    wait page.getByRole('button', { nom : 'Ajouter au panier' }).click();
    
    // 3. Vérifier le tiroir du chariot
    const cartDrawer = page.getByTestId('cart-drawer');
    attendre attendre(cartDrawer).toBeVisible();
    wait expect(cartDrawer).toContainText('Chemise en soie');
    
    // 4. Passer à la caisse
    wait page.getByRole('link', { name: 'Checkout' }).click();
    attendre attendre(page).toHaveURL(/.*\/checkout/);
    
    // 5. Remplir le formulaire (paiement moqueur)
    wait page.getByLabel('Email').fill('test-bot@maisoncode.paris');
    wait page.getByLabel('First Name').fill('Test');
    attendre page.getByLabel('Last Name').fill('Bot');
    wait page.getByLabel('Address').fill('123 Test St');
    
    // 6. Paiement (Stripe Mock)
    // En E2E strict, nous pourrions utiliser une carte de test Stripe.
    wait page.getByLabel('Numéro de carte').fill('4242 4242 4242 4242');
    wait page.getByLabel('Expiry').fill('12/30');
    attendre page.getByLabel('CVC').fill('123');
    
    // 7. Soumettre
    wait page.getByRole('button', { name: 'Pay Now' }).click();
    
    // 8. Affirmer le succès
    // Augmente le délai d'attente car le traitement des paiements prend du temps
    wait expect(page.getByText('Merci pour votre commande')).toBeVisible({ timeout : 15000 });
  });

});

4. Gérer la « flakiness » (The Silent Killer)

Un Flaky Test est un test qui réussit 90 % du temps et échoue 10 % du temps, sans aucune modification de code. La desquamation est l’ennemi. Si les développeurs cessent de faire confiance aux tests (« Oh, réexécutez-le, c’est flou »), la suite de tests devient inutile.

Causes courantes :

Latence réseau : l’API prend 5,1 s lorsque le délai d’expiration est de 5 s.
Animation : cliquer sur un bouton alors qu’il est encore en train de glisser.
Contamination des données : le test A supprime un utilisateur dont le test B a besoin.

Solutions :

Moquerie (interception de réseau) : Au lieu d’appeler la véritable API Contentful (qui peut être lente), interceptez la requête et renvoyez un JSON statique.
```
wait page.route('**/api/products', route => {
  route.fulfill({ chemin : 'mock-data/products.json' });
});
```
Cela rend le test 10 fois plus rapide et 100 % déterministe.
Nouvelles tentatives : Configurez CI pour réessayer automatiquement les tests ayant échoué. nouvelles tentatives : 2. S’il réussit lors d’une nouvelle tentative, c’est instable, mais au moins cela ne bloque pas le déploiement.

5. Tests de régression visuelle (Pixel Perfect)

Le dramaturge vérifie la fonctionnalité (« Le bouton est-il cliquable ? »). Il ne vérifie pas l’esthétique (« Le bouton est-il rose ? »). Si vous supprimez accidentellement « main.css », Playwright peut toujours réussir (le bouton est cliquable, juste invisible). Tests de régression visuelle (instantanés Percy/Chromatique/Playwright) corrige ce problème. attendez expect(page).toHaveScreenshot();

Prenez une capture d’écran de la page.
Comparez-la à « l’image dorée » (ligne de base).
Si les pixels diffèrent de > 1 %, échouez le test. Cela détecte les “régressions CSS” qu’aucun test fonctionnel ne pourrait jamais faire.

6. Actions GitHub : le gardien automatisé

Vous n’exécutez pas de tests sur votre ordinateur portable. Vous les exécutez sur CI (Continuous Integration). Chaque fois que vous effectuez une migration vers GitHub, un workflow s’exécute.

# .github/workflows/e2e.yml
nom : Dramaturge E2E
sur :
  pousser :
    succursales : [principale]
  pull_request :
    succursales : [principale]

emplois :
  tester :
    timeout-minutes : 60
    exécution : ubuntu-latest
    étapes :
      - utilise : actions/checkout@v3
      - utilise : actions/setup-node@v3
        avec :
          version du nœud : 18
      - nom : Installer Deps
        exécuter : npm ci
      - nom : Installer les navigateurs
        exécuter : installation du dramaturge npx --with-deps
      
      - nom : Exécuter le dramaturge
        exécuter : test de dramaturge npx
        env :
          IC : vrai
          BASE_URL : ${{ github.event.deployment.payload.web_url }} // Test de l'URL d'aperçu de Vercel

      - nom : Télécharger le rapport
        utilise : actions/upload-artifact@v3
        si : toujours()
        avec :
          nom : dramaturge-rapport
          chemin : rapport-dramaturge/

7. Le coût du CI (optimisation)

Exécuter 500 tests E2E sur chaque commit coûte cher (minutes GitHub Actions). Stratégies d’optimisation :

Partage : répartissez les tests sur 10 machines, ce qui les rend 10 fois plus rapides. Test du dramaturge npx --shard=1/10.
Projets concernés uniquement : utilisez Nx ou Turbo pour exécuter des tests uniquement pour les applications qui ont changé.
Tests de fumée pour les PR : exécutez un petit sous-ensemble (chemin critique) sur les PR. Exécutez la suite complète sur Main.

8. Conclusion

Les tests automatisés ne constituent pas un « travail supplémentaire ». C’est le travail. C’est la différence entre un prototype et un produit. C’est la différence entre “J’espère que ça marche” et “Je sais que ça marche”. Commencez aujourd’hui. Écrivez UN test. Le test de connexion. Puis le test de paiement. Bientôt, vous dormirez mieux la nuit.

Des releases qui provoquent la panique ?

Nous concevons des suites de tests E2E automatisés à l’aide de Playwright qui détectent les bogues avant les utilisateurs.

Automatiser mon contrôle qualité. Engagez nos Architectes.