La règle, et sa raison d'être
Pour déployer du code Apex en production, Salesforce exige qu'au moins soixante-quinze pour cent des lignes soient exécutées par des tests automatiques, et que ces tests passent. Sans cela, le déploiement est refusé.
Cette exigence surprend souvent, parce qu'elle n'existe presque nulle part ailleurs sous forme de blocage technique. Sa raison est simple : votre org partage une infrastructure avec d'autres clients. Un code défaillant n'a pas seulement des conséquences chez vous, et la plateforme impose donc un minimum de vérifications avant toute mise en production.
La conséquence directe pour vous est budgétaire. Toute fonctionnalité développée en code s'accompagne obligatoirement de l'écriture de tests, et cette couverture de test représente une part réelle de la charge. C'est l'une des raisons pour lesquelles un besoin couvert par le déclaratif coûte nettement moins cher qu'un besoin équivalent en développement.
Ce que la couverture mesure, et ce qu'elle ne mesure pas
C'est le point que je tiens le plus à faire comprendre, parce qu'il est contre-intuitif.
La couverture mesure la part de code parcourue par les tests. Elle ne mesure pas la pertinence de ce qui est vérifié.
Il est parfaitement possible d'écrire un test qui exécute cent pour cent du code sans jamais contrôler que le résultat est correct. Le test appelle la fonction, la fonction s'exécute, la couverture monte, et personne ne vérifie que le calcul donne le bon montant. Ce test passera toujours, y compris le jour où la logique sera cassée.
Ce qui distingue un vrai test, ce sont les assertions : les vérifications explicites du type « après cette opération, ce champ doit valoir ceci ». Sans assertions, vous avez un chiffre qui rassure et rien derrière.
Une couverture de test de quatre-vingt-quinze pour cent sans assertions vaut moins qu'une couverture de quatre-vingts pour cent avec des cas métier bien choisis.
Les cas qu'un bon test doit couvrir
Vous n'avez pas à lire le code pour juger. Demandez simplement quels cas sont testés, et écoutez la réponse.
- Le cas nominal. Le fonctionnement attendu, avec des données normales. C'est le minimum, et c'est souvent le seul cas couvert.
- Les cas limites. Enregistrement incomplet, champ vide, valeur extrême, date incohérente.
- Le traitement en masse. La plateforme traite les enregistrements par lots. Un code testé sur un seul enregistrement peut échouer sur deux cents, et c'est l'une des pannes les plus fréquentes en production.
- Les droits. Le comportement pour un utilisateur qui n'a pas les mêmes accès que l'administrateur.
- Les erreurs attendues. Quand le code doit refuser quelque chose, le test doit vérifier qu'il refuse bien, et avec le bon message.
Un intervenant qui répond « on a la couverture nécessaire » sans pouvoir citer les cas testés vous dit qu'il a écrit des tests pour passer le seuil, pas pour protéger votre org.
Ce que cela change dans un devis
Trois conséquences concrètes, à vérifier avant de signer.
Les tests ne sont pas une option. Ils ne doivent pas apparaître comme une ligne que l'on pourrait retirer pour faire baisser le montant. Techniquement, sans eux, rien ne part en production.
La reprise d'un code existant coûte plus cher qu'il n'y paraît. Modifier une classe existante peut faire tomber la couverture globale sous le seuil, et il faut alors reprendre des tests écrits par quelqu'un d'autre, parfois mal écrits. C'est une charge que le devis découpé en lots doit anticiper, faute de quoi elle arrivera en avenant.
Les tests sont un livrable. Au même titre que le code et la documentation. Ils vous appartiennent, et ils sont ce qui permettra à quelqu'un d'autre de modifier ce code sans tout casser.
Le piège de la dette de tests
Voici comment le problème s'installe, et je le retrouve dans beaucoup d'orgs reprises.
Un prestataire écrit des tests minimaux, juste assez pour dépasser le seuil. Un deuxième ajoute du code et fait de même. Au bout de quelques années, l'org affiche une couverture globale à peine suffisante, avec des tests qui ne vérifient presque rien.
Le jour où vous voulez faire évoluer une fonctionnalité, deux mauvaises surprises arrivent ensemble. Le déploiement échoue parce que la couverture passe sous le seuil, et personne ne sait si la modification casse quelque chose, puisque les tests existants ne vérifiaient rien.
C'est un chantier de rattrapage classique, et il se mesure lors d'un audit d'org : couverture globale, couverture classe par classe, et présence réelle d'assertions.
Ce que vous pouvez exiger, sans être technique
Quatre demandes suffisent à vous protéger.
- La liste des cas métier testés, en français, dans la documentation du livrable
- Le chiffre de couverture avant et après l'intervention, pour vérifier qu'elle ne dégrade pas l'existant
- La confirmation que le traitement en masse est testé, pas seulement l'enregistrement unique
- Le résultat de l'exécution des tests dans la sandbox avant la mise en production
Ces quatre éléments ne demandent aucune compétence de développement pour être lus, et ils changent radicalement la qualité de ce que vous recevez.
Et si votre org ne contient aucun code ?
C'est le cas de beaucoup de PME, et c'est une bonne nouvelle : sans Apex, la question de la couverture de test ne se pose pas, et vos déploiements s'en trouvent nettement simplifiés.
Deux réflexes valent malgré tout d'être pris.
Le premier est de vérifier ce que contient réellement votre org. Beaucoup d'orgs « sans développement » contiennent en fait du code hérité d'un ancien projet, ou installé par une application tierce. Un audit d'org le révèle en quelques minutes, et il vaut mieux le savoir avant qu'au moment où un déploiement échoue.
Le second est de garder cette situation aussi longtemps que possible. Chaque fonctionnalité couverte par le paramétrage plutôt que par du code est une fonctionnalité que vous déployez sans contrainte de couverture, que vous modifiez sans développeur, et qui suit automatiquement les mises à jour de la plateforme. C'est un avantage réel, et il se perd dès la première ligne d'Apex ajoutée sans nécessité.
Ce qu'il faut retenir
Les soixante-quinze pour cent sont un seuil réglementaire de la plateforme, pas un objectif de qualité. C'est un plancher, et le franchir ne prouve rien d'autre que le droit de déployer.
La vraie question à poser n'est donc jamais « quelle est la couverture », mais « qu'est-ce qui est vérifié ». Un développement bien testé vous coûte un peu plus cher aujourd'hui et vous évite des reprises complètes demain. C'est exactement le même raisonnement que pour la documentation : ce que vous payez doit rester modifiable par quelqu'un d'autre que celui qui l'a écrit.
Questions fréquentes
Pourquoi Salesforce impose-t-il 75 % de couverture de test ?
Parce que votre org partage une infrastructure avec d'autres clients. Un code qui échoue ne dégrade pas que votre environnement, et le seuil garantit qu'un minimum de vérifications automatiques existe avant tout déploiement en production.
Une couverture de 100 % signifie-t-elle que le code est bon ?
Non. La couverture mesure la part de code parcourue par les tests, pas la pertinence de ce qui est vérifié. Un test peut exécuter tout le code sans jamais contrôler que le résultat est correct. Ce qui compte, ce sont les assertions et les cas testés.