• Accueil / Salesforce / Blog de Bob…
, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce6 minutes de lecture


, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

introduction

Plus tôt cette semaine (6 octobre 2020), un tweet est apparu dans mon flux sur le
Salesforce CLI Scanner, qui a évidemment attiré mon attention car je semble l’avoir
une sorte de vision tunnel sur la CLI et les plug-ins en ce moment. J’avais vu
quelque chose à ce sujet avant, mais à l’époque, on avait l’impression que cela visait davantage
Les éditeurs de logiciels indépendants pour les aider à passer l’examen de sécurité. Ce n’était pas quelque chose que j’avais
besoin immédiat de, donc il est allé sur ma liste mentale interminable de choses à
regarde quand j’ai le temps.

Le tweet lié à un
Article du blog des développeurs Salesforce
et une lecture rapide de ce qui suggérait qu’il y avait beaucoup plus à faire, alors j’ai mis
prendre un peu de temps pour le lire correctement et jeter un œil au code, qui était
vaut bien l’investissement. le Documents sur les plug-ins couvrir l’installation et l’exécution, donc je ne vais pas y entrer ici.

Analyse de code statique

En termes simples, un outil d’analyse de code statique examine le code source avant
le code est exécuté, en l’évaluant par rapport à un ensemble de règles. En supposant que vous ayez créé
vos règles correctement, il trouvera chaque occurrence de code qui casse un
règle. Essentiellement une revue de code effectuée par un Terminator:

« Il ne peut pas être négocié. Ça ne peut pas être
raisonné avec. Il ne ressent ni pitié, ni remords, ni peur.
« 

Le scanner CLI combine un ensemble d’outils d’analyse de code statique en un seul
brancher. La puissance de la CLI réside dans le fait qu’elle peut être installée en un seul
commande en utilisant la CLI elle-même. Comme la CLI est assez omniprésente, c’est
simple pour la plupart d’entre nous d’installer le scanner et de commencer à l’utiliser
immédiatement.

Sommet

Bien que le scanner prenne en charge d’autres langues, je vais m’en tenir à Apex pour
cet article, car c’est là que réside la plupart de mon code en ce moment.

Le scanner évalue Apex à l’aide du
Règles Apex pour PMD créé à l’origine par
Robert Sösemann,
partie de la
analyseur de code source PMD open source. J’avais regardé PMD il y a plusieurs années et j’avais fait fonctionner les bases, mais les choses
n’étaient pas aussi habiles à l’époque alors je n’ai pas continué. J’étais aussi sous
l’impression que je devais écrire des règles personnalisées en Java, ce que je n’étais pas
particulièrement intéressé à l’époque.

Une fois que j’ai fait fonctionner le scanner, j’ai décidé de vérifier à nouveau les règles personnalisées,
car j’allais certainement en avoir besoin pour appliquer les règles de la maison BrightGen. le
Documentation
suggère à nouveau que
Java est la voie à suivre, alors je suis allé au
Site PMD
pour en savoir plus. En lisant la documentation, j’ai été ravi de
trébucher sur ce qui suit:

Les nouvelles règles doivent être déclarées dans un ensemble de règles avant d’être référencées. C’est
le cas des règles XPath et Java. Pour ce faire, le rule élément est utilisé, mais au lieu de mentionner le ref attribut, il mentionne le class attribut, avec la classe d’implémentation de votre règle.

  • Pour les règles Java: ce
    est la classe qui étend AbstractRule (transitivement)
  • Pour les règles XPath: c’est net.sourceforge.pmd.lang.rule.XPathRule

Mon vieil ami XPath – le mécanisme que j’ai utilisé plusieurs fois dans le passé avec
Tests automatisés au sélénium. Dès mars 2019, je disais aux gens de
apprenez-en plus à ce sujet, comme en témoigne le tweet de Don Robin de My London’s Calling
session:

, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

J’avais maintenant l’impression d’avoir une chance de trouver une règle personnalisée dans
commande assez courte, même si évidemment dans PMD je ne travaille pas avec HTML.
Au lieu de cela, le code source est analysé dans un arbre de syntaxe abstraite, que je peux
naviguer de la même manière.

L’un des principaux outils d’aide de Selenium est de pouvoir exécuter des expressions XPath
dans l’inspecteur Chrome et construisez progressivement une règle complexe à partir de
pas. En lisant plus sur la documentation PMD, j’ai été ravi de trouver le
designer – une interface graphique où je pourrais écrire du code Apex, exécuter un XPath
expression contre ce code et voir les matchs en direct. Il a également un
excellente référence interactive où je peux cliquer sur l’un des éléments de l’arbre
et voir ses propriétés. Cela vaut la peine de passer du temps avec:

, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

Exemple de règle

Mon exemple de règle était de vérifier que les instructions SOQL ne sont présentes que dans le test
méthodes ou classes d’accesseurs, où les classes d’accesseurs ont la convention de dénomination
Accesseur.

La règle est un peu longue – la voici dans son intégralité avant de la casser
en sections:

// UserClass[not(ends-with(@Image,
‘Accessor’))]/ Méthode / ModifierNode[@Test=false()]/..//(SoqlExpression |
MethodCallExpression[lower-case(@FullMethodName)=’database.query’])

La première partie vérifie que le nom de la classe ne se termine pas par Accessor – s’il
est, je suis dans une classe d’accesseur et nous pouvons arrêter maintenant:

// UserClass[not(ends-with(@Image, ‘Accessor’))]

si je ne suis pas dans un accesseur, je recherche une méthode qui n’est pas une méthode de test:

/ Méthode / ModifierNode[@Test=false()]

La propriété @Test fait partie de la magie de PMD – l’arbre des modificateurs de méthode
element sait si une méthode est un test ou non, donc je n’ai pas à m’inquiéter
sur les annotations ou les mots-clés.

Je reviens ensuite du ModifierNode à la méthode et considère tout l’enfant
nœuds de toutes les méthodes non testées:

/..//

Vient ensuite la viande de la règle – je cherche l’union des nœuds qui sont SOQL
expressions ou avoir un appel de méthode database.query – notez que je convertis le
Propriété FullMethodName en minuscules pour que je n’ai pas à me soucier de
capitalisation:

(SoqlExpression |
MethodCallExpression[lower-case(@FullMethodName)=’database.query’])

Exécution de cette règle sur un extrait de classe Apex:

class MyClass
{
   void SoqlQuery()
   {
       List contacts=[select id from Contact];
   }

   void SoqlQuery2()
   {
        List contacts=database.query('select id from Contact');
   }
}

correspond comme prévu à la requête SOQL à la ligne 5 et à Database.query
appel de méthode sur la ligne 10:

, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

C’est aussi loin que je vais pour la partie 1 – dans partie 2 Je vais voir comment créer un ensemble de règles pour cette règle et l’installer dans le scanner CLI. Vous n’aurez pas à attendre trop longtemps car j’espère l’écrire dans les prochains jours pendant qu’il est frais dans mon esprit.

Ressources





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer