Quelles pratiques de code testing les meilleures équipes engineering adoptent-elles ? Tester son code ne se limite pas à écrire des tests unitaires. Les équipes engineering les plus performantes construisent des stratégies de test complètes, adaptées à leur contexte et à leur stade de maturité. TPC a recueilli les témoignages de 6 entreprises tech françaises et internationales. Chacune partage ses outils, ses niveaux de test, son organisation et ses arbitrages. Ce guide compile leurs retours pour vous donner une vision concrète du code testing en startup et scale-up.
1. Pourquoi tester son code est stratégique
Le code testing sert trois objectifs mesurables. Réduire les bugs en production : les tests automatisés détectent les régressions avant le déploiement. Chaque bug évité en amont représente un coût de correction divisé par 10 selon les études IBM.
Accélérer les cycles de livraison : une suite de tests fiable augmente la confiance au moment du déploiement. Les équipes qui testent bien déploient plus souvent, avec des livrables plus petits et moins risqués. Faciliter l'onboarding : les tests servent de documentation vivante.
Un nouveau développeur comprend le comportement attendu du code en lisant les tests, sans dépendre d'un transfert oral.
2. TDD et code review rigoureux
Akeneo développe des logiciels de gestion d'informations produit. Plus de 400 personnes à l'international, 600 clients entreprises. Didier Caroff, VP Engineering, supervise une équipe tech de plus de 100 personnes.
Akeneo applique une approche rigoureuse sur son produit PIM. Chaque modification de code passe par une Pull Request sur GitHub, accompagnée de tests spécifiques. Si un bug est signalé, un test de reproduction est écrit avant la correction.
La PR doit passer une suite complète de tests sur CircleCI : tests statiques, unitaires, d'acceptation, d'intégration et fonctionnels. Le TDD est fortement encouragé. Outils backend : PHP Coupling Detector (outil open source Akeneo), PHP Coding Standard Fixer (norme PSR-2), PHPSpec pour les tests unitaires, PHPUnit pour les tests d'intégration, Behat pour les tests d'acceptation et end-to-end.
Outils frontend : ESLint pour la détection de problèmes JavaScript, Jest + Enzyme pour les tests unitaires et d'intégration, Cucumber.js + Puppeteer pour les tests d'acceptation. Chaque PR est analysée ligne par ligne. L'équipe évalue la conception, l'architecture et la clarté du code.
Les commentaires portent sur les aspects techniques et fonctionnels, jamais sur le formatage. Avant fusion, chaque PR doit être revue et approuvée par au moins 2 pairs. Les tests doivent passer la CI.
Le code doit être déployé dans un environnement de type production et testé par le PM ou le support.
3. Une approche qualité adaptative
Voodoo est une licorne française spécialisée dans les jeux mobiles. 6 milliards de téléchargements, 150 millions d'utilisateurs actifs mensuels, 750 employés. Karim Ammor est Head of Platform Engineering.
Voodoo applique un principe de ROI sur la qualité. Le niveau d'exigence en matière de tests varie selon le stade de maturité du projet. Proof of Concept : pas de tests automatisés.
L'objectif est de valider une hypothèse en quelques jours. Nouvelle application : bases saines, qualité comme pilier. Exploration (nouvelle feature) : standards minimum, livraison rapide d'un MVP.
Itération (feature validée) : qualité maximale, le ROI des tests automatisés est clairement positif. Principe clé : un test valide un comportement, jamais une implémentation. Si un refactoring casse un test, le test est trop couplé au code.
Voodoo place la qualité à chaque étape du cycle de développement. Discovery : entretiens utilisateurs, mock-ups, user tests. Un ingénieur participe systématiquement.
Planification : approche BDD. Les user stories contiennent des critères d'acceptation écrits à plusieurs mains. Développement : TDD, architecture hexagonale, services indépendants testables en isolation.
QA : CI automatique (linter + tests unitaires/API). Chaque PR revue par au moins un pair. Déploiement : en un clic.
Déploiements fréquents, livrables petits. Monitoring : dashboards Grafana, alerting Slack.
4. Le testing Salesforce
Partoo développe une solution tout-en-un pour les parcours d'achat. Sylvain Prudhon est Salesforce Technical Architect. L'équipe Ops compte une dizaine de personnes.
Le déploiement de code APEX exige une couverture de code supérieure à 75%. Partoo vise systématiquement 100%. Pratiques mises en place : code formatting avec doc de nomenclature et Prettier sur VSCode, code coverage objectif 100% sur chaque classe APEX, unit tests avec bibliothèque Assert, multi-environnement (sandbox dev, préprod, prod) avec déploiements via ChangeSet Salesforce, tests fonctionnels E2E réalisés manuellement sur la préprod.
Limites identifiées : pas de merge possible entre ChangeSet, pas de rollback. La communication au sein de l'équipe est critique sur les gros projets. Prochaines étapes : mise en place de SFDX avec Git, GitHub, CI/CD (GitHub Actions ou CircleCI), sandboxes unitaires par projet, automatisation de tests fonctionnels, monitoring via Datadog.
5. Tests multi-niveaux
Stonal développe une plateforme de performance immobilière. Cyril Pham-Le est VP of Engineering. L'équipe engineering comprend 3 squads en feature teams de 4 à 6 full stacks.
Les tests automatisés réduisent les bugs, facilitent l'intégration des nouveaux, donnent confiance dans le code et font émerger des architectures testables. Tests unitaires (back et front) : réflexe de toute l'équipe. Outils : AssertJ, MockK, Jasmine.
Utilisation de factories pour faciliter la lecture. Le TDD permet des architectures émergentes. Tests d'intégration : en back sur les composants d'infrastructure (API, BDD, messaging).
En front, instanciation de contextes Angular. Tests d'acceptation : en back avec JGiven, scénarios complets d'un endpoint API à la base de données. Haute confiance mais longs à écrire et exécuter.
Tests E2E : Playwright. Encore peu développés à ce stade. Tests manuels : pour les nouvelles features et les changements impactants.
6. Tester en production
Algolia (SaaS, moteur de recherche) : une société SaaS doit maintenir un logiciel et une infrastructure fiables tout en innovant. Les tests de résilience en production impliquent de déployer du nouveau code et de le tester avec le trafic réel. Tester exhaustivement tout prend trop de temps.
L'enjeu est de tester en production avec un impact minimal sur les clients. Trois prérequis : infrastructure répliquée, logiciel résilient, stratégie de déploiement sûre. HoneyComb (observabilité) : chaque déploiement en production est un test.
Chaque action utilisateur aussi. Certaines configurations ne peuvent pas être reproduites en dehors de la production. Les risques sont atténués par le canarying, l'automatisation des déploiements, les rollbacks rapides, l'instrumentation et l'observabilité.
La mise en production est une compétence souvent sous-estimée. Les échecs sont inévitables. L'enjeu est de les gérer efficacement.
7. Les enseignements communs
Six pratiques reviennent dans tous les témoignages. 1. Adapter l'exigence au contexte : le niveau de test dépend du stade du projet et de la criticité de la fonctionnalité.
Voodoo et Algolia l'expriment clairement : le bon niveau de test est celui qui offre le meilleur retour sur investissement. 2. Automatiser la CI/CD : toutes les équipes exécutent leurs tests automatiquement à chaque push ou pull request.
CircleCI, GitHub Actions ou des pipelines internes : l'outil importe moins que le réflexe. 3. Écrire des tests qui valident des comportements : les tests couplés à l'implémentation cassent au moindre refactoring.
Les équipes les plus matures testent ce que le code fait, pas comment il le fait. 4. Pratiquer la code review systématique : Akeneo exige 2 reviewers par PR.
Documenter la Definition of Done : un code terminé sans critères partagés génère des malentendus. Akeneo formalise une DoD précise : tests passés, review approuvée, déployé en environnement de type production, documentation mise à jour.
Monitorer après le déploiement : Voodoo suit des métriques via Grafana avec alerting Slack. Le testing ne s'arrête pas au merge : il se prolonge en production.