Comment corriger les échecs de tests Apex et les erreurs de couverture de code dans les déploiements Salesforce

Les déploiements en production exigent des tests Apex réussis et au moins 75% de couverture de code, et Salesforce bloque la release tant que ces deux conditions ne sont pas remplies.

Se produit lors de : un déploiement en production ou un rafraîchissement complet de sandbox

Ce que cela signifie

Salesforce exige que les déploiements en production exécutent les tests Apex et atteignent une couverture de code moyenne d'au moins 75% sur l'ensemble des classes et des triggers, chaque trigger devant présenter une couverture minimale. Un déploiement échoue, en listant l'assertion ou l'exception de chaque test en échec, dès qu'un test lève une exception non gérée, qu'une assertion échoue, ou que la couverture moyenne de l'org descend sous ce seuil.

Cette exigence ne s'applique qu'aux déploiements en production et en sandbox complète avec RunLocalTests ou RunAllTestsInOrg ; les déploiements vers des sandbox Developer ou des scratch orgs avec NoTestRun s'en affranchissent totalement, ce qui explique précisément pourquoi les lacunes de couverture passent inaperçues jusqu'au jour de la release.

Diagnostic

Causes courantes

Un test fait une assertion sur des données modifiées par un code sans rapport

Un trigger ou un Flow récemment déployé modifie un champ sur lequel le test fait une assertion, si bien que la valeur attendue du test ne correspond plus, même si le test lui-même n'a pas été modifié.

Nouveau code livré sans tests pour le couvrir

Une classe ou un trigger a été ajouté ou étendu sans méthode de test correspondante, ce qui fait chuter la couverture moyenne de l'org sous 75%.

Le test dépend de données ou d'une configuration propres à l'org

Le test interroge des enregistrements, des record types ou des paramètres existants au lieu de créer ses propres données, si bien qu'il réussit dans une org et échoue dans une autre où ces données n'existent pas.

La solution

Reproduisez d'abord l'échec en local
Exécutez la suite de tests locale complète avec couverture sur votre sandbox avant de toucher au code, afin de déboguer le véritable échec et non un log de déploiement obsolète.
```
sf apex run test --test-level RunLocalTests --code-coverage --result-format human --wait 20
```
Écrivez des tests pour tout nouveau code avant de déployer
Ajoutez des méthodes de test qui exercent les nouvelles classes et triggers afin que la couverture moyenne de l'org dépasse 75% avant la release.
Rendez les tests autonomes
Réécrivez les tests pour qu'ils créent leurs propres données de test avec @TestSetup ou Test.startTest(), plutôt que de dépendre d'enregistrements qui existent par hasard dans l'org cible.

En pratique

Comment Serpent évite cela

L'extension VS Code de Serpent affiche les résultats de tests et la couverture directement sur la tâche, afin qu'une lacune de couverture ou une assertion en échec soit visible avant la soumission de la tâche, et non découverte lors d'un déploiement en production. Voir la bibliothèque des erreurs de déploiement Salesforce.

Releases

Tâches

Orgs

v2.8.3 · Production

Composants

○

AccountTrigger

○

OpportunityFlow

○

DashboardLWC

○

PermissionSet_A

○

EmailTemplate

0 sur 5 prêts

Revue IA Serpent

Analyse…

○

Aucun changement cassant

○

Couverture de tests : 94%

○

Dépendances cartographiées

○

Delta validé

En attente de la revue IA…

✓ Déployé en production · à l'instant

Prévention

Conditionnez les merges à la couverture, pas seulement au succès/échec

Faites échouer la CI sur toute pull request qui fait passer la couverture globale de l'org sous 75%, pas uniquement en cas d'échec de test net, afin que la lacune n'atteigne jamais une release.

Ne faites jamais d'assertion sur un nombre d'enregistrements sans clause WHERE

Restreignez chaque requête d'assertion aux enregistrements créés par le test lui-même, afin qu'une automatisation sans rapport ajoutée plus tard ne casse pas silencieusement l'assertion.

Exécutez une validation RunLocalTests avant chaque release en production

Lancez un déploiement check-only avec RunLocalTests avant la release réelle afin que les échecs apparaissent avec le temps de les corriger, pas pendant la fenêtre de déploiement.

Erreurs associées

MIXED_DML_OPERATIONUn échec de test Apex courant dû au mélange de DML sur un objet setup et un objet business dans une même transaction.LIMIT_EXCEEDEDUne configuration de test qui fait trop de choses en une seule transaction déclenche les governor limits.REQUIRED_FIELD_MISSINGUne cause fréquente lorsqu'une factory de données de test prend du retard sur un changement de schéma.

Questions fréquentes

APEX TEST FAILURES, les réponses

Une couverture de 75% garantit-elle qu'un déploiement réussira ?

Non. La couverture est un seuil minimum, pas un critère de qualité. Chaque test doit toujours réellement réussir ; une suite peut atteindre 75% de couverture et faire échouer le déploiement si un seul test lève une exception non gérée ou une assertion en échec.

Chaque classe individuelle doit-elle atteindre 75% de couverture ?

Non, le seuil de 75% est une moyenne à l'échelle de l'org. Des classes individuelles peuvent être en dessous tant que la moyenne globale dépasse la barre, bien que chaque trigger ait toujours besoin d'au moins un peu de couverture.

Pourquoi un test qui n'a jamais changé s'est-il mis à échouer ?

Autre chose a changé dans la même transaction : un nouveau trigger, Flow ou une validation rule touche désormais des données sur lesquelles le test fait une assertion. Vérifiez ce qui a été déployé en même temps que le test en échec.

Commencez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.

Commencer gratuitement Réserver une démo