Tests automatisés : ce qu'on teste vraiment (et ce qu'on ne teste pas)

Tout tester, c'est ne rien tester

On entend souvent : "Il faut 100% de couverture de tests". En théorie, c'est séduisant. En pratique, c'est un piège. Chez Ateia Digital, on préfère une approche pragmatique : tester ce qui compte, pas ce qui rassure.

Un test automatisé coûte du temps à écrire, du temps à maintenir, et du temps quand il casse pour rien. L'enjeu, c'est de maximiser la confiance par minute investie.

Ce qu'on teste systématiquement

La logique métier

C'est le cœur du produit. Si un calcul de prix, une règle de validation ou un workflow métier est buggé, le client le voit immédiatement. Ces fonctions sont pures, isolables, et se testent facilement avec des tests unitaires.

Les intégrations critiques

Paiement, authentification, envoi d'emails transactionnels : tout ce qui implique un tiers ou une action irréversible mérite un test d'intégration. On mocke les APIs externes, mais on teste le flux complet côté application.

Les parcours utilisateur principaux

Inscription, connexion, achat, onboarding : les happy paths critiques sont couverts par des tests end-to-end. Pas tous les scénarios — juste ceux qui, s'ils cassent, bloquent le business.

Ce qu'on ne teste pas (et pourquoi)

Le code de présentation pur

Tester qu'un bouton a la bonne couleur ou qu'un margin vaut 16px, c'est fragile et sans valeur. Le moindre changement de design casse le test. On préfère une review visuelle ou des outils de snapshot utilisés avec parcimonie.

Les getters et setters triviaux

Un getName() qui retourne this.name n'a pas besoin d'un test. Tester du code trivial, c'est ajouter du bruit au rapport de couverture.

Les dépendances tierces

On ne teste pas que axios fait bien un GET ou que dayjs formate une date. C'est le boulot de leurs mainteneurs. On teste notre usage de ces librairies, pas les librairies elles-mêmes.

Les scénarios de bout en bout trop spécifiques

Un test E2E qui vérifie qu'un utilisateur avec un compte créé un mardi, ayant 3 produits dans son panier dont un en promo, voit le bon message... c'est un test qui va casser tous les mois et que personne ne voudra maintenir.

Notre pyramide de tests en pratique

La fameuse pyramide de tests, on l'applique concrètement :

• Base large : tests unitaires — rapides, nombreux, focalisés sur la logique métier. Exécution en quelques secondes.
• Milieu : tests d'intégration — on vérifie que les modules communiquent correctement entre eux. Base de données, APIs internes, services.
• Sommet fin : tests E2E — peu nombreux, mais couvrent les parcours critiques. On les lance avant chaque mise en production.

Les outils qu'on utilise au quotidien

| Type de test | Outils | |---|---| | Unitaires | Vitest, Jest | | Intégration | Supertest, Testing Library | | E2E | Playwright, Cypress | | API | Hoppscotch, Bruno | | Couverture | c8, Istanbul | | CI | GitHub Actions, GitLab CI |

Les 3 règles qu'on s'impose

Règle 1 — Un test doit avoir une raison d'exister. Si on ne peut pas expliquer en une phrase ce que le test protège, on ne l'écrit pas.

Règle 2 — Un test qui casse souvent sans bug réel doit être réécrit ou supprimé. Les faux positifs tuent la confiance dans la suite de tests.

Règle 3 — Les tests tournent en CI, pas "en local quand on y pense". Chaque PR déclenche la suite. Pas de merge sans green.

Ce qu'on retient

Les tests automatisés ne sont pas une fin en soi. C'est un outil de confiance qui permet de livrer vite sans casser. Chez Ateia Digital, on teste avec intention : chaque test a un coût et doit prouver sa valeur.

Si cette approche pragmatique vous parle et que vous cherchez une équipe technique qui livre avec rigueur sans dogmatisme — on est toujours ouverts aux profils qui pensent comme ça.

Écrit par Julien · Ateia Digital · Mars 2026