Tester votre application avec Scratch Orgs

Les Scratch Orgs sont des environnements Salesforce éphémères, créés à la demande et jetables, définis entièrement par du code source versionné. Pour un éditeur AppExchange, ils sont le socle d'un développement moderne : chaque développeur, chaque pull request, chaque scénario de test peut disposer de son propre org isolé, reproductible en quelques minutes.

1. Prérequis : le Dev Hub

Avant de créer un Scratch Org, vous devez activer un Dev Hub — l'org qui a l'autorité pour provisionner des Scratch Orgs. Pour un ISV, le Dev Hub est généralement activé automatiquement dans votre Environment Hub partenaire.

# Authentification au Dev Hub
sf org login web --alias DevHub --set-default-dev-hub

# Création d'un Scratch Org à partir du fichier de définition
sf org create scratch --definition-file config/project-scratch-def.json --alias monapp-scratch --duration-days 7

2. Le fichier de définition (scratch-def)

Ce fichier JSON décrit la configuration de l'org : éditions, fonctionnalités activées, préférences. C'est un élément versionné dans votre dépôt Git, garant de la reproductibilité :

{
  "orgName": "Monapp Dev",
  "edition": "Developer",
  "features": ["MultiCurrency", "EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

Ajustez ce fichier pour refléter les fonctionnalités réellement utilisées par vos clients cibles (multi-devise, Person Accounts, etc.), afin que vos tests reflètent des configurations réalistes.

3. Pousser le code source et les données de test

Un Scratch Org démarre vide. Le workflow typique consiste à :

1. Pousser les métadonnées source : sf project deploy start --source-dir force-app
2. Assigner les Permission Sets nécessaires : sf org assign permset --name MonApp_Admin
3. Charger un jeu de données de test via des plans de données (sf data import tree) pour disposer d'un scénario réaliste sans dépendre d'un export de production.

4. Intégration dans un pipeline CI/CD

C'est ici que les Scratch Orgs prennent tout leur sens pour un éditeur AppExchange packagé en 2GP : chaque pull request peut déclencher la création d'un org temporaire, l'exécution des tests Apex et Jest, puis sa suppression automatique.

# Exemple simplifié d'étape CI
sf org create scratch -f config/project-scratch-def.json -a ci-org -y 1
sf project deploy start -o ci-org
sf apex run test -o ci-org --code-coverage --result-format human --wait 10
sf org delete scratch -o ci-org --no-prompt

Fixez une durée de vie courte (1 à 3 jours) pour les Scratch Orgs utilisés en CI : cela évite d'épuiser le quota d'orgs actifs alloué à votre Dev Hub, généralement limité selon votre palier partenaire.

5. Limites et pièges courants

• Quota limité : le nombre de Scratch Orgs actifs et créés par jour est plafonné ; surveillez la consommation via sf org list.
• Pas d'équivalent parfait de la production : certains comportements liés au volume de données ou à des configurations historiques ne se reproduisent pas dans un Scratch Org neuf — complétez avec des tests en Sandbox pour la validation finale avant release.
• Dépendances de packages tiers : si votre application dépend d'un autre package managé, il doit être installé explicitement dans le Scratch Org via son ID de version (04t...), à ne pas oublier dans le script de provisioning.
• Données de test non représentatives : générez des jeux de données couvrant les cas limites (valeurs nulles, caractères spéciaux, gros volumes) plutôt que des données factices minimalistes.

Adopter les Scratch Orgs transforme fondamentalement la vélocité d'une équipe ISV : fini les orgs de développement partagés qui dérivent au fil du temps. Chaque environnement redevient prévisible, reproductible et jetable — exactement ce qu'exige un cycle de release AppExchange discipliné.