Comment construire un pipeline d'automatisation des tests Salesforce en CI

Un pipeline d'automatisation des tests Salesforce exécute vos tests Apex et Lightning Web Component automatiquement à chaque commit, avant que le code n'atteigne la production. Une configuration fonctionnelle relie un dépôt git à un runner CI, crée une scratch org ou une sandbox, déploie les métadonnées, exécute les tests et fait échouer le build si la couverture passe sous les 75 pour cent exigés par Salesforce. Ce guide parcourt tout le pipeline, du premier niveau de test aux pièges qui ralentissent les équipes.

Qu'est-ce que l'automatisation des tests Salesforce en CI ?

L'intégration continue (CI) consiste à valider chaque changement dès qu'il arrive, plutôt qu'à une porte de release. Pour Salesforce, cela signifie un pipeline qui exécute vos tests automatisés à chaque push ou pull request et bloque la fusion si quelque chose échoue. Le but est le test shift-left : détecter un trigger cassé ou une assertion en échec en quelques minutes sur une branche, pas lors d'un déploiement de nuit en production.

Salesforce impose une règle stricte qui rend cela incontournable : avant de déployer de l'Apex en production, vos tests doivent passer et vous devez avoir au moins 75 pour cent de couverture de code. La CI est ce qui maintient ce voyant vert en continu au lieu d'improviser au moment du déploiement.

Que faut-il tester à chaque commit ?

Une suite Salesforce utile est en couches. Visez à couvrir, du plus rapide au plus lent :

• Tests unitaires Apex : l'épine dorsale. Couvrez triggers, classes et logique métier avec des assertions significatives, pas seulement du remplissage de couverture.
• Tests LWC Jest : la logique des composants Lightning Web, exécutée avec @salesforce/sfdx-lwc-jest. Rapides et sans org.
• Tests d'intégration et smoke : une fine couche qui vérifie les parcours critiques de bout en bout et les intégrations tierces après le déploiement.

Exécutez Apex et Jest à chaque commit car ils sont rapides, et réservez les vérifications UI de bout en bout plus lentes à une étape nocturne. Notre guide sur quoi lancer à chaque pull request et quoi lancer la nuit détaille ce partage.

Comment mettre en place un pipeline CI pour les tests Salesforce ?

Les éléments sont les mêmes que vous utilisiez GitHub Actions, GitLab CI ou Jenkins. Un pipeline minimal fait ceci à chaque pull request :

1. Authentifiez la Salesforce CLI auprès d'un Dev Hub, généralement via un flux JWT et un certificat stocké.
2. Créez un environnement : lancez une scratch org (ou ciblez une sandbox CI dédiée).
3. Déployez la source avec sf project deploy start.
4. Exécutez les tests avec sf apex run test --test-level RunLocalTests --code-coverage --result-format human, et lancez npm run test:unit pour LWC Jest.
5. Conditionnez le build au résultat, puis supprimez la scratch org pour ne rien laisser traîner.

Salesforce publie un tutoriel officiel sur Salesforce DX avec GitHub Actions qui correspond bien à ces étapes.

Quel niveau de test Apex la CI doit-elle utiliser ?

Le niveau de test contrôle la quantité exécutée et la durée du build :

• RunLocalTests exécute tous les tests de l'org sauf ceux des packages gérés installés, et constitue le choix sûr par défaut pour un pipeline de validation.
• RunSpecifiedTests n'exécute que les classes nommées, utile pour un retour rapide sur branche mais risqué comme porte de production car il peut manquer de la couverture.
• Un niveau plus récent, RunRelevantTests, est arrivé en bêta dans la version Spring '26 pour raccourcir les déploiements en n'exécutant que les tests affectés par un changement ; considérez-le comme une bêta jusqu'à l'avoir validé sur votre suite.

Pour le build bloquant la fusion, préférez RunLocalTests afin que la couverture soit réelle. N'utilisez les tests spécifiés ou pertinents que pour un retour rapide et non bloquant plus tôt sur la branche.

Où les équipes se trompent-elles avec la CI Salesforce ?

Trois erreurs expliquent la plupart des pipelines bloqués :

Courir après le chiffre de 75 pour cent au lieu de vraies assertions. La couverture sans assertions passe la porte et livre quand même des bugs.

Les deux autres sont des données de test instables et une suite devenue trop lente pour tourner à chaque commit. Corrigez la première en créant les données de test dans chaque test avec un pattern factory et @testSetup, sans jamais dépendre des données de l'org. Corrigez la seconde en séparant les tests unitaires rapides des tests de bout en bout lents, pour que le retour reste sous quelques minutes là où cela compte le plus. Les outils de la catégorie Salesforce DevOps, dont Copado, Gearset, Salto, AutoRABIT, Flosum et Blue Canvas, peuvent envelopper ces étapes dans un pipeline géré si vous préférez ne pas écrire le YAML à la main.

Pour plus de guides Salesforce DevOps, consultez notre bibliothèque de ressources.

FAQ

Quelle couverture de code Salesforce exige-t-il pour déployer ?

Au moins 75 pour cent de couverture Apex à l'échelle de l'org, et chaque test doit passer. La CI maintient ce voyant vert en continu plutôt que de découvrir un manque au déploiement.

Ai-je besoin de scratch orgs pour la CI Salesforce ?

Non, mais elles aident. Les scratch orgs offrent à chaque build un environnement propre et jetable. Une sandbox CI dédiée fonctionne aussi si le suivi de source et la réinitialisation sont gérés avec soin.

Comment tester les Lightning Web Components en CI ?

Utilisez le runner @salesforce/sfdx-lwc-jest basé sur Jest. Il exécute les tests de composants localement sans org, assez vite pour tourner à chaque commit.

Quel outil CI est le meilleur pour Salesforce ?

GitHub Actions, GitLab CI et Jenkins fonctionnent tous bien avec la Salesforce CLI. Le runner compte moins qu'un pipeline propre : authentifier, déployer, exécuter les tests, conditionner, nettoyer.