Premier test unitaire X++ avec SysTest dans D365 F&O

Un test unitaire X++ est une classe qui hérite de SysTestCase, dont chaque méthode de test porte l'attribut SysTestMethodAttribute et vérifie un résultat avec les assertions (assertEquals, assertTrue, assertFalse…). On la place dans un modèle de test dédié, dont le nom contient « Test », on compile, et les tests apparaissent dans l'Explorateur de tests de Visual Studio, d'où on les exécute.

Par défaut, chaque test s'exécute avec l'isolation AutoRollback : toutes les écritures sont annulées à la fin, aucune donnée ne persiste.

Exemple adapté de Microsoft Learn (application exemple Fleet Management), qui vérifie la validation d'un champ :

class FMUnitTestSample extends SysTestCase
{
    [SysTestMethodAttribute]
    public void testFMCarValidateField()
    {
        FMCarClass fmCar;

        fmCar.NumberOfDoors = -1;
        this.assertFalse(fmCar.validateField(fieldNum(FMCarClass, NumberOfDoors)));

        fmCar.NumberOfDoors = 4;
        this.assertTrue(fmCar.validateField(fieldNum(FMCarClass, NumberOfDoors)));
    }
}

La méthode setup permet de préparer les données avant chaque test. Après enregistrement et compilation, ouvrez Test > Test Explorer, sélectionnez le test et exécutez-le.

L'attribut SysTestTransaction choisit l'isolation : AutoRollback (par défaut, la meilleure), LegacyRollback (suit et supprime les insertions ; utile pour tester des connexions utilisateur ou la concurrence), LegacyRollbackWithUpdateTracking (le plus lent), None (débogage uniquement).

[SysTestTransaction(TestTransactionMode::LegacyRollback)]
class MyTestSample extends SysTestCase

Créez un modèle de test séparé et incluez « Test » dans son nom : la définition de build par défaut découvre les modules de test par ce nom. Attention à deux points documentés : le build sur agents hébergés par Microsoft ne prend pas en charge l'exécution des tests SysTest (pas de runtime) ; dans l'expérience développeur unifiée (UDE), le code de test doit être déployé dans l'environnement avant de s'exécuter, et nécessite Application Foundation et Test Essentials. Voir UDE : ce qui change pour un développeur X++.

• Écrire des tests qui dépendent de données existantes non préparées : ils passent ou échouent selon l'environnement.
• Passer en isolation None et oublier de revenir : les tests laissent des données.
• Mélanger code de test et code applicatif dans le même modèle.
• Vouloir des pré/post-handlers sur une méthode de test : elles ne sont pas « hookables » par défaut (ajoutez [Hookable(true)] si nécessaire).
• Compter sur le pipeline hébergé pour exécuter les tests : il compile et package seulement.

Les tests unitaires font partie de ce que Skalp livre avec le code. Skalp AI rédige la spécification, génère le code X++ et les tests unitaires, compile en contrôlant les bonnes pratiques, puis livre par pull request dans votre Azure DevOps : rien n'est fusionné sans la validation de votre architecte technique. Voir développement X++ par IA, le cadre général dans développer en X++ sans consultant en 2026, et les offres Basic, Pro et Max (1 crédit, ≈ 400 € en Basic, 200 € en Pro, consommé seulement à la génération du code).

• Microsoft Learn, « Testing and validations », mise à jour du 29/04/2026, consultée le 18/10/2026.
• Microsoft Learn, « Build automation that uses Microsoft-hosted agents and Azure Pipelines », mise à jour du 05/03/2026, consultée le 18/10/2026.
• Microsoft Learn, « Unified developer experience - Frequently asked questions », mise à jour du 23/07/2026, consultée le 18/10/2026.