Conseils et bonnes pratiques pour tester les intégrations Salesforce

intégration salesforce

Les tests Salesforce vous aideront à valider votre Intégrations Salesforce et fonctionnalités avec d'autres applications d'entreprise. Un bon test couvre tous les modules Salesforce, des comptes aux prospects, des opportunités aux rapports et des campagnes aux contacts. Comme c'est le cas pour tous les tests, il existe un bon moyen (efficace et efficient) de faire un test Salesforce et un mauvais moyen. Alors, quelles sont les bonnes pratiques de test Salesforce?

  • Utilisez les bons outils de test - Les tests Salesforce ont lieu dans le navigateur ou dans un environnement basé sur une éclipse. Les derniers navigateurs et eclipse ont d'excellents outils de débogage et vous pouvez les combiner avec des classes de test pour des résultats très utiles. Cependant, si vous avez besoin de plus, le débogueur interactif Apex (ou simplement Apex) de Force.com doit être utilisé. Notez que vous pouvez également utiliser Salesforce Lightning Inspector, une extension Chrome, pour tester spécifiquement Salesforce Lightning. Apex est un Force.com langage de programmation propriétaire de la plate-forme qui présente de grandes similitudes avec Java. Il s'agit d'un langage de programmation orienté objet, insensible à la casse, fortement typé qui suit la syntaxe des accolades et de la notation par points. Vous pouvez utiliser Apex pour exécuter des fonctions programmées pendant la plupart des processus Force.com, y compris des liens et des boutons personnalisés, des mises à jour, des suppressions et des gestionnaires d'événements d'insertion d'enregistrements via les contrôleurs ou la planification personnalisés de la page Visualforce.
  • Utilisez des conventions de dénomination appropriées - Il est très important de nommer correctement vos méthodes de test avant de commencer à écrire des tests. Le nom de la méthode de test doit comporter trois parties. Il s'agit de nameOfMethod (nom de la méthode individuelle que vous testez, telle que insérer / mettre à jour / supprimer / annuler la suppression lors du test d'un déclencheur, des informations sur TestPath qui sont flexibles telles qu'un contact nul si vous testez que le contact est nul et valide lors du test un chemin positif / négatif.
  • Assurer une couverture à 100% - Bien que la directive standard de Salesforce stipule que le test unitaire doit couvrir 75% de votre code (moins les classes de test, les appels à System.debug et les méthodes de test) et que vous ne pourrez pas déployer du code Apex ou mettre en package des applications AppExchange, vous devez notez qu'il ne s'agit que d'une norme et que votre objectif doit être une couverture à 100%. Testez tous les cas positifs / négatifs et les données présentes et non présentes. D'autres conseils importants concernant la couverture du code sont:
    • Vous devez exécuter des tests pour actualiser les numéros de couverture de code, car ces chiffres ne sont pas actualisés lorsque le code Apex est mis à jour jusqu'à ce que les tests soient réexécutés.
    • S'il y a eu une mise à jour dans l'organisation depuis le dernier test, il y a un risque que les numéros de couverture de code soient incorrects. Relancez les tests pour obtenir la bonne estimation.
    • Le pourcentage de couverture de code n'inclut pas la couverture de code des tests de packages gérés, la seule exception étant lorsque ces tests provoquent le déclenchement des déclencheurs.
    • La couverture dépend du nombre total de lignes de code. Si vous ajoutez ou supprimez des lignes de code, vous affecterez le pourcentage.
  • Cas de test dans les classes et les contrôleurs - Dans le développement Salesforce, la plupart des développeurs créent des classes et des fichiers de contrôleur distincts pour chaque fonction. Ceci est fait pour rendre le codage plus organisé, plus facile, réutilisable et portable. Vous devez cependant noter que si cela est plus facile, ce n'est pas plus efficace. Vous obtiendrez la portabilité si le code de test est dans la classe d'origine et le code du contrôleur lui-même, car vous ne manquerez aucune classe de test lors de la migration du bac à sable vers la production.
  • Utilisez System.assert () - Dans Apex, System.assert() est utilisé pour vérifier les conditions. Il s'agit d'une fonctionnalité importante car elle vous permet de déterminer si une fonction particulière a été exécutée par la méthode comme prévu. Vous devez utiliser System.assertEquals () et System.assertNotEquals () entre les fonctionnalités critiques non seulement vous aide à déterminer si le code a été exécuté comme il se doit, mais également à vous assurer qu'aucune donnée n'est écrite de manière erronée si le code tourne mal.
  • Test complet - Les tests doivent tout couvrir. Vous devez effectuer des tests fonctionnels, des tests de charge, des tests de sécurité et des tests de déploiement.
  • Tests unitaires - Vous devez avoir des tests unitaires pour vérifier que les enregistrements individuels produisent le résultat correct et attendu. Bien que l'utilisation d'un test géant couvrant l'intégralité du code puisse sembler une bonne idée, notez que les résultats générés seront plus difficiles à déboguer et que l'échec sera plus difficile à comprendre. Un test unitaire doit couvrir un petit sous-ensemble de la fonctionnalité testée.
  • Tester les caisses en vrac - Un bon code de test (déclencheur, exception ou classe) peut être impliqué pour plusieurs centaines d'enregistrements (200 pour Apex). Vous devez en profiter et tester non seulement les enregistrements individuels, mais également les cas en vrac.
  • Tests positifs - Tester pour s'assurer que le comportement attendu se produit pendant toutes les permutations attendues. Le test doit vérifier que l'utilisateur a correctement rempli le formulaire et qu'il n'a pas dépassé les limites.
  • Tests négatifs - Testez les cas négatifs pour vous assurer que les messages d'erreur sont générés correctement. Des exemples de tels cas négatifs sont l'impossibilité de spécifier des montants négatifs et l'impossibilité d'ajouter des dates futures. Les tests négatifs sont importants car une manipulation correcte lorsque les choses tournent au sud peut faire toute la différence.
  • Automatiser les tests - Traditionnellement, les tests Salesforce étaient manuels. Vous devriez envisager des tests automatisés car cela offre plus d'avantages. Ceux-ci inclus:
    • Les tests manuels vous exposent aux erreurs, car les tests sont effectués par des humains et non par des robots. Les robots excellent dans les activités répétitives tandis que les humains font des erreurs en raison de l'ennui, d'une concentration et d'une cohérence réduites et d'une tendance à couper les coins ronds.
    • Les tests manuels sont répétitifs, formulés et fatigants. Il est préférable que l'équipe de test fasse un travail plus exploratoire.
  • Exécutez chaque branche de code logique - Lorsque vous utilisez la logique conditionnelle (lorsque vous avez inclus des opérateurs ternaires), chaque branche de la logique de code doit être exécutée.
  • Utiliser des entrées non valides et valides pour les appels aux méthodes - Les appels aux méthodes doivent être effectués à l'aide d'entrées non valides et valides.
  • Tests complets - Assurez-vous que les tests se terminent avec succès - ils ne doivent passer par aucune exception à moins que les erreurs ne soient attendues. Gérez toutes les exceptions capturées - les attraper n'est pas suffisant.
  • Utiliser les mots clés ORDER BY - Pour vous assurer que vos enregistrements sont renvoyés dans l'ordre dans lequel vous les attendez, utilisez les mots-clés ORDER BY.
  • Ne présumez pas que les ID d'enregistrement sont organisés de manière séquentielle - Évitez l'erreur courante de supposer que les ID d'enregistrement sont disposés dans un ordre séquentiel. Les ID ne sont pas dans l'ordre croissant, sauf si vous avez inséré plusieurs enregistrements avec la même demande.
  • Appelez Test.startTest () et Test.stopTest () - Lorsque vous exécutez un test unitaire Apex, vous obtenez une couverture de code supérieure à 75% qui est obligatoire dans Salesforce. Vous devez appeler stopTest avant les assertions pour forcer la fin des codes asynchrones qui peuvent encore être en cours d'exécution. Exécutez de nouvelles requêtes pour les résultats finaux car un autre code peut modifier les données. UsingTest.startTest () et Test.stopTest () vous assure de bac à sable le test dans ses limites de gouverneur. De cette façon, le code de configuration que vous utilisez n'interférera pas et ne vous donnera pas de faux négatifs ou positifs entourant les limites du gouverneur. Test.stopTest () garantit également que les appels @future se termineront pour les tests.
  • Lisibilité - La lisibilité est très importante dans les tests unitaires. Les noms des tests doivent inclure l'action spécifique à entreprendre et le résultat attendu. La méthode doit être descriptive et courte. La méthode doit être telle qu'elle puisse être réutilisable à travers différents tests.
  • Construire de grands ensembles de données de test avant le startTest - Étant donné que vos tests seront exécutés dans différents environnements de bac à sable et de production, créez de grands ensembles de données de test avant d'appeler startTest pour vous assurer que le test a des limites d'exécution complètes. Par défaut, Salesforce Github exécute des tests isolés des données de production. Lorsque vous avez besoin de données système telles qu'un profil, faites une requête pour obtenir la bonne chose pour cet environnement spécifique.
  • Générez vos propres données de test - Les données de test que vous utilisez doivent être générées dans le test. Vous pouvez générer ces données à l'aide de l'annotation @testSetup et d'une classe TestUtils non seulement pour vous assurer que vous disposez des bonnes données, mais également pour vous assurer que tous les tests sont exécutés sur un sandbox de développeur sans aucune exigence de données.
  • Évitez les opérations nulles AKA sans opération - De nombreux testeurs utilisent des opérations nulles AKA sans opération. Ce sont des codes inutiles qui ne font rien. Puisqu'ils sont déjà dans votre base de code, ils s'ajouteront à votre pourcentage de couverture.
  • Exécution de tests parallèles - Lorsque vous démarrez des tests à partir de l'interface utilisateur de Salesforce ou de la Developer Console, les tests s'exécutent en parallèle. Il s'agit d'une fonctionnalité importante car elle accélère le temps d'exécution des tests. Vous devez cependant noter que cela peut entraîner des problèmes de contention de données et si vous pensez que cela pourrait se produire, désactivez l'exécution parallèle. Les causes les plus courantes de problèmes de conflit de données qui entraînent souvent des erreurs UNABLE_TO_LOCK_ROW sont:
    • Lorsque les tests sont destinés à mettre à jour les mêmes enregistrements en même temps. La mise à jour des mêmes enregistrements se produit généralement lorsque les tests ne créent pas leurs propres données.
    • Lorsqu'il y a un blocage dans les tests qui s'exécutent en parallèle et qu'ils essaient de créer des enregistrements qui ont des valeurs de champ d'index correspondantes. Un blocage se produit lorsque 2 tests en cours d'exécution ont mis en file d'attente pour restaurer des données (cela se produit lorsque 2 tests entrent des enregistrements qui ont les mêmes valeurs de champ d'index unique dans des ordres différents).
    • Pour désactiver l'exécution de tests parallèles, accédez à Configuration, entrez Apex Test, accédez à la boîte de dialogue Options d'exécution des tests Apex, sélectionnez Désactiver les tests Apex parallèles, cliquez sur OK.

Désactiver les tests Apex parallèles

Engagez un pro pour le poste car il aura l'expérience et la formation nécessaires pour faire un bon test, ce qui vous donne également la tranquillité d'esprit. L'embauche d'un pro vous permet de vous concentrer sur votre cœur de métier. Cela vous permet également d'économiser de l'argent puisque vous n'aurez pas besoin d'une équipe interne pour le travail.

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..