• Accueil / Salesforce / Métadonnées non empaquetées…
, Métadonnées non empaquetées pour les tests de création de packages au printemps 21<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

Métadonnées non empaquetées pour les tests de création de packages au printemps 216 minutes de lecture


, Métadonnées non empaquetées pour les tests de création de packages au printemps 21<span class="wtr-time-wrap after-title"><span class="wtr-time-number">6</span> minutes de lecture</span>

introduction

La version Spring 21 de Salesforce a introduit une nouvelle fonctionnalité utile pour ceux
d’entre nous utilisant des packages gérés ou déverrouillés de deuxième génération (qui
devrait être nous tous maintenant) – la capacité d’avoir des métadonnées disponibles au
au moment de la création d’une nouvelle version de package, mais qui n’est pas ajoutée à la
paquet.

J’ai déjà écrit sur la façon dont j’utilise
répertoires décompressés pour le code supplémentaire, mais ce n’est pas du code nécessaire au moment de la création, c’est généralement
utilitaires pour aider le processus de développement ou exemple de code d’application à créer
assurez-vous que le code du package fonctionne comme prévu lorsqu’il est intégré ailleurs.

Le scénario

Pour démontrer la puissance du nouveau concept non packagé, voici mon scénario:

J’ai un package qui définit un cadre de calcul de la remise sur un
Opportunité grâce à des classes de règles plug and play. Le package fournit un global
interface que toute classe de règles doit implémenter:

public interface DiscountRuleIF 
{
    Decimal GetDiscountPercent(Opportunity opp);
}

Les règles sont configurées via un
Discount_Rule__c objet personnalisé,
qui a les champs importants suivants:

  • Rule_Class__c – le nom du
    classe avec l’implémentation de l’interface de règle
  • Rule_Namespace__c – l’espace de noms
    de la classe, au cas où la classe vit dans un autre package

Et il y a le gestionnaire de règles, qui récupère toutes les règles, les itère,
instancie la classe d’implémentation et exécute la méthode GetDiscountPercent
sur la classe créée dynamiquement, calculant éventuellement la remise totale
dans toutes les règles:

global with sharing class DiscountManager 
{
    global Decimal GetTotalDiscount(Opportunity opp)
    {
        List discountRules=[select id, Rule_Class__c, Rule_Class_Namespace__c
                                              from Discount_Rule__c];
        Decimal totalDiscount=0;

        for (Discount_Rule__c discountRule : discountRules)
        {
            Type validationType = Type.forName(discountRule.Rule_Class_Namespace__c,discountRule.Rule_Class__c);        
            DiscountRuleIF discountRuleImpl = (DiscountRuleIF) validationType.newInstance();
    
             totalDiscount+=discountRuleImpl.GetDiscountPercent(opp);

        }

        return totalDiscount;
    }
}

L’idée est donc que quelqu’un installe ce package, crée des règles localement (ou
installe un autre package qui implémente les règles), et lorsqu’une opportunité est
enregistré, la réduction est calculée et certaines mesures sont prises, probablement une réduction
le prix, mais ils ne sont limités que par leur imagination.

Tester le package

Je ne veux pas inclure quelconque règles avec mon colis – c’est purement
contient le cadre permettant de brancher les règles. Malheureusement, cela signifie que
Je ne pourrai pas tester ma classe de gestionnaire de règles, car je n’aurai rien qui
implémente l’interface de règle de remise. Aux fins de vérification de ma classe,
Je peux définir un code supplémentaire en utilisant la technique de
mon post précédent
via le sfdx-project.json suivant:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "default": true,
            "package": "UNPACKMETA",
            "versionName": "ver 0.1",
            "versionNumber": "0.1.0.NEXT"
        },
        {
            "path": "example",
            "default": false
        }
    ],
    "namespace": "BGKBTST",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "51.0"
}

Ensuite, je place mon exemple d’implémentation et les classes de test associées dans
exemple / force-app / main / classes, et
lorsque j’exécute tous les tests, j’obtiens une couverture de 100%. Je peux également créer un nouveau
version du package sans problème. Malheureusement, lorsque je fais la promotion de mon forfait
version via la CLI, les roues se détachent:

Command failed
The code coverage required to promote this version has not been met.
Please add additional test coverage and ensure the code coverage check
passes during version creation.

Mon exemple d’implémentation et le code de test associé ont été réussis
exclu du package, mais cela signifie que je n’ai pas le test requis
couverture. Avant le printemps 21, je soupirais et polluerais mon colis avec du code que je
ne voulait pas, juste pour satisfaire l’exigence de couverture de test. Ce serait un
petit soupir, mais ils s’additionnent au fil des ans.

La propriété unpackagedMetadata

La nouvelle fonctionnalité Spring 21 est activée en ajoutant le unpackagedMetadata
propriété à mon sfdx-project.json, dans la strophe du répertoire de package par défaut:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "default": true,
            "package": "UNPACKMETA",
            "versionName": "ver 0.1",
            "versionNumber": "0.1.0.NEXT",
            "unpackagedMetadata": {
                "path": "example"
            }
        },
        {
            "path": "example",
            "default": false
        }
    ],
    "namespace": "BGKBTST",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "51.0",
}

Notez que mon répertoire supplémentaire est toujours défini, mais je le marque également comme des métadonnées qui devraient être utilisées au moment de la création pour déterminer la couverture du test, mais non incluses dans le package.

Après avoir créé une nouvelle version avec cette configuration, je suis en mesure de la promouvoir sans aucun problème. Juste pour vérifier, j’ai installé le package dans une organisation scratch et le unpackagedMetadata n’était, comme prévu, pas présent.

Couverture réduite dans l’organisation des abonnés

Un effet secondaire de ceci est que la couverture de code sur tous les espaces de noms sera réduite dans l’organisation abonnée. Selon votre point de vue, cela peut vous inquiéter en tant qu’auteur du package. Cela peut également causer de l’angoisse à l’administrateur qui a installé le package dans son organisation.

Personnellement, je ne pense pas que cela compte – la couverture du code de package géré n’a aucun impact sur l’organisation abonnée, et je ne pense pas qu’il soit possible de créer des tests dans un package géré qui sont garantis de réussir quelle que soit l’organisation. ils sont installés dans. Je pourrais le faire pour mon exemple de scénario, mais si c’est quelque chose de plus complexe que cela, les tests sont à la merci de la configuration de l’organisation. Je crée une opportunité en mémoire pour tester mon gestionnaire de remises, mais si je devais l’insérer dans la base de données, il y a une quantité de validation ou de données attendues qui pourrait me trébucher. Bien qu’il existe des techniques qui pourraient être utilisées pour garantir la réussite de mes tests, imposer à tous ceux qui installent mon package de les avoir utilisés dans toute leur automatisation semble peu susceptible de susciter une réaction positive.

Ce que cela signifie plus probablement, c’est que l’exécution de tous les tests sur tous les espaces de noms a plus de chances de réussir, car les tests qui pourraient facilement être déraillés par la configuration de l’organisation peuvent être laissés en dehors du package, laissant simplement ceux qui sont complètement isolés. le code du colis en place, donc des balançoires et des ronds-points.

Ce que cela signifie, c’est que l’auteur du package a le choix de savoir si les tests sont conditionnés ou non, ce qui me semble être la façon dont cela devrait être.

Articles Similaires





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

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

Fermer