Tests automatisés Salesforce en CI : quoi lancer à chaque pull request, quoi lancer la nuit

Réponse courte : sur chaque pull request, ne lancez que les contrôles rapides et déterministes : analyse statique du diff, LWC Jest, et un déploiement delta en validation seule qui n'exécute que les tests Apex couvrant le code modifié. Renvoyez tout ce qui est lent ou instable, exécutions complètes de tests, parcours UI et intégrations externes, vers un job nocturne. Visez un verdict en moins de dix minutes, au-delà plus personne ne le lit.

Que faut-il lancer sur chaque pull request ?

• L'analyse statique du diff. Quelques secondes, sans org, elle attrape les problèmes mécaniques avant qu'un humain lise le code.
• Les tests Jest des LWC. Ils tournent hors plateforme dans Node et ne demandent aucune org.
• Un déploiement delta en validation seule contre une org à l'image de la cible, avec un niveau de test limité aux classes qui couvrent la modification.
• Des contrôles de métadonnées. Aucune suppression involontaire, aucune entrée de profil ou de permission set qui disparaît en silence.

Une règle gouverne cette liste : tout ce qui est sur la porte de pull request doit être déterministe. Un seul test instable apprend à l'équipe à relancer, et une porte que l'on relance jusqu'au vert est un décor.

Que faut-il mettre dans le job nocturne ?

• Une exécution complète des tests locaux contre la sandbox d'intégration. C'est elle qui attrape la classe que votre changement touchait sans que vous le sachiez.
• Les parcours UI sur les processus métier centraux.
• Les tests d'intégration qui appellent des systèmes externes, dont vous ne maîtrisez ni la latence ni la disponibilité.
• Un contrôle de dérive entre l'org d'intégration et la branche, pour que celui qui modifie directement dans Setup soit visible le lendemain matin.
• La tendance de couverture au niveau de l'org, sous forme de rapport et non de porte.

Les échecs nocturnes se trient au café. C'est précisément l'objectif : ils ne s'interposent pas entre un développeur et son merge.

Que réserver à la veille de release ?

• La suite de régression complète et la recette utilisateur.
• Les tests de performance et de volume, qui exigent des données qu'une scratch org n'a pas.
• Un déploiement en validation seule contre la production, suivi d'un quick deploy, pour ne pas passer la fenêtre de release à attendre des tests.

Comment les niveaux de test Salesforce s'y rattachent-ils ?

Quatre niveaux, et le choix par étape constitue l'essentiel de la conception (guide Metadata API).

• NoTestRun : acceptable dans une scratch org, jamais sur un chemin vers la production.
• RunSpecifiedTests : votre porte de pull request. Un piège à connaître : à ce niveau, chaque classe et trigger du paquet doit atteindre 75% de couverture individuellement, calculée par composant et non à l'échelle de l'org (documentation Salesforce).
• RunLocalTests : tout sauf les tests des packages managés. C'est ce que lance par défaut un déploiement en production contenant de l'Apex.
• RunAllTestsInOrg : y ajoute les tests des packages managés. Rarement souhaitable, et lent.

Les règles de la plateforme ne bougent pas : au moins 75% de votre Apex doit être couvert pour déployer en production, chaque trigger a besoin d'au moins une ligne couverte, et tout test exécuté doit passer, quel que soit le pourcentage (Salesforce Help).

Comment tenir la boucle de pull request sous dix minutes ?

1. Déployez le delta, pas l'org. Validez uniquement ce que la branche a changé.
2. Déduisez la liste de tests. Générez les classes de test à partir des composants modifiés plutôt que d'une liste tenue à la main.
3. Parallélisez. Jest et l'analyse statique doivent tourner à côté de la validation d'org, pas derrière elle.
4. Gardez une org cible chaude. Créer et alimenter une org par pull request est en général le plus gros bloc de temps. Utilisez un pool ou une sandbox de validation durable.
5. Mettez les dépendances en cache entre les exécutions, CLI et modules Node compris.
6. Bouchonnez ou reportez les appels externes. Tout ce dont vous ne maîtrisez pas le temps de réponse appartient au job nocturne.
7. Mesurez la durée et affichez-la. Le temps de pipeline dérive discrètement, et toujours dans le même sens.

Où placer les tests d'interface ?

Pas sur la pull request. Les tests UI sont l'élément le plus lent et le plus fragile d'un pipeline Salesforce : shadow DOM des composants Lightning, identifiants générés et écrans de connexion cassent les sélecteurs pour des raisons sans rapport avec le changement examiné.

Le placement viable : un petit ensemble de fumée de cinq à dix parcours critiques après la fusion vers la branche d'intégration, et la suite complète la nuit. Règle pratique : si un test UI échoue deux fois pour autre chose que le produit, c'est une tâche de maintenance, pas une porte.

Comment régler les seuils de couverture ?

• Jugez la pull request sur la couverture du code modifié, pas sur le chiffre global de l'org. Ce chiffre bouge lentement et masque des classes neuves non testées derrière des années d'anciennes.
• Gardez le plancher global comme porte de release, là où il a sa place.
• Ne faites pas du pourcentage l'objectif. Salesforce recommande de couvrir chaque cas d'usage, positif et négatif, en masse et à l'unité, et de laisser le chiffre suivre.

Ce guide fait partie de nos guides DevOps Salesforce.

FAQ

Quelle vitesse viser pour un contrôle de pull request Salesforce ?

Moins de dix minutes de bout en bout. Au-delà, les développeurs passent à autre chose, ne lisent plus la sortie, et le contrôle ne change plus aucun comportement.

Faut-il exécuter tous les tests Apex sur chaque pull request ?

Non. Exécutez les tests couvrant les classes modifiées avec RunSpecifiedTests, et gardez l'exécution locale complète pour la nuit et la validation de release.

Quelle couverture Salesforce exige-t-il réellement ?

75% d'Apex à l'échelle de l'org pour déployer en production, au moins une ligne couverte par trigger, et tout test exécuté doit passer. Avec RunSpecifiedTests, chaque classe et trigger du paquet doit atteindre 75% seul.

Les tests Jest des LWC ont-ils besoin d'une org ?

Non. Ils tournent hors plateforme dans Node, et c'est exactement pour cela qu'ils ont leur place sur la porte de pull request.

Où exécuter les tests d'interface ?

Un petit ensemble de fumée après la fusion, la suite complète la nuit. Les mettre sur la pull request est le moyen le plus rapide d'apprendre à une équipe à ignorer un build rouge.