Partager via

Créer une infrastructure de test

Cet article explique comment créer une infrastructure de test personnalisée pour Microsoft.Testing.Platform. L’infrastructure de test est la seule extension obligatoire. Il découvre et exécute des tests et signale les résultats à la plateforme.

Pour obtenir le résumé complet du point d’extension et les concepts in-process/out-of-process, consultez Créer des extensions personnalisées.

Si vous migrez une infrastructure de test VSTest existante, l’implémentation de l’interface ITestFramework en mode natif est l’approche recommandée. L’extension VSTest Bridge est disponible en tant qu’étape de transition, mais une implémentation native offre la meilleure expérience.

Extension du framework de test

Le framework de test est l’extension principale qui fournit à la plateforme de test la capacité de découvrir et d’exécuter des tests. Le framework de test est responsable de communiquer les résultats des tests à la plateforme de test. Le framework de test est la seule extension obligatoire requise pour exécuter une session de test.

Enregistrer un framework de test

Cette section explique comment enregistrer le framework de test avec la plateforme de test. Vous n’inscrivez qu’une seule infrastructure de test par générateur d’applications de test à l’aide de l’API, comme indiqué dans la TestApplication.RegisterTestFramework documentation de l’architecture de Microsoft.Testing.Platform .

L’API d’enregistrement est définie comme suit :

ITestApplicationBuilder RegisterTestFramework(
    Func<IServiceProvider, ITestFrameworkCapabilities> capabilitiesFactory,
    Func<ITestFrameworkCapabilities, IServiceProvider, ITestFramework> adapterFactory);

L’API RegisterTestFramework attend deux usines :

  1. Func<IServiceProvider, ITestFrameworkCapabilities> : Il s’agit d’un délégué qui accepte un objet implémentant l’interface IServiceProvider et renvoie un objet implémentant l’interface ITestFrameworkCapabilities. Le IServiceProvider fournit un accès aux services de la plateforme tels que les configurations, les loggeurs et les arguments de ligne de commande.

    L’interface ITestFrameworkCapabilities est utilisée pour annoncer les capacités prises en charge par le framework de test à la plateforme et aux extensions. Elle permet à la plateforme et aux extensions d’interagir correctement en implémentant et en prenant en charge des comportements spécifiques. Pour une meilleure compréhension du concept de capacités, reportez-vous à la section correspondante.

  2. Func<ITestFrameworkCapabilities, IServiceProvider, ITestFramework> : Il s’agit d’un délégué qui prend un objet ITestFrameworkCapabilities, qui est l’instance retournée par le Func<IServiceProvider, ITestFrameworkCapabilities>, et un IServiceProvider pour fournir à nouveau l’accès aux services de la plateforme. L’objet de retour attendu est celui qui implémente l’interface ITestFramework. Le ITestFramework sert de moteur d’exécution qui découvre et exécute les tests, puis communique les résultats à la plateforme de test.

La nécessité pour la plateforme de séparer la création du ITestFrameworkCapabilities et la création du ITestFramework est une optimisation pour éviter de créer le framework de test si les capacités prises en charge ne sont pas suffisantes pour exécuter la session de test actuelle.

Considérez l’exemple de code utilisateur suivant, qui démontre un enregistrement de framework de test qui renvoie un ensemble de capacités vide :

internal class TestingFrameworkCapabilities : ITestFrameworkCapabilities
{
    public IReadOnlyCollection<ITestFrameworkCapability> Capabilities => [];
}

internal class TestingFramework : ITestFramework
{
   public TestingFramework(ITestFrameworkCapabilities capabilities, IServiceProvider serviceProvider)
   {
       // ...
   }
   // Omitted for brevity...
}

public static class TestingFrameworkExtensions
{
    public static void AddTestingFramework(this ITestApplicationBuilder builder)
    {
        builder.RegisterTestFramework(
            _ => new TestingFrameworkCapabilities(),
            (capabilities, serviceProvider) => new TestingFramework(capabilities, serviceProvider));
    }
}

// ...

Maintenant, considérez le point d’entrée correspondant de cet exemple avec le code d’enregistrement :

var testApplicationBuilder = await TestApplication.CreateBuilderAsync(args);
// Register the testing framework
testApplicationBuilder.AddTestingFramework();
using var testApplication = await testApplicationBuilder.BuildAsync();
return await testApplication.RunAsync();

Note

Retourner ITestFrameworkCapabilities vides ne devrait pas empêcher l’exécution de la session de test. Tous les frameworks de test devraient être capables de découvrir et d’exécuter des tests. L’impact devrait être limité aux extensions qui peuvent se désinscrire si le framework de test manque d’une certaine fonctionnalité.

Créer un framework de test

Le Microsoft.Testing.Platform.Extensions.TestFramework.ITestFramework est implémenté par des extensions qui fournissent un framework de test :

public interface ITestFramework : IExtension
{
    Task<CreateTestSessionResult> CreateTestSessionAsync(CreateTestSessionContext context);
    Task ExecuteRequestAsync(ExecuteRequestContext context);
    Task<CloseTestSessionResult> CloseTestSessionAsync(CloseTestSessionContext context);
}

L’interface IExtension

L’interface ITestFramework hérite de l’interface IExtension , qui est une interface dont tous les points d’extension héritent. IExtension est utilisé pour récupérer le nom et la description de l’extension. Le IExtension fournit également un moyen d’activer ou de désactiver dynamiquement l’extension lors de la configuration, via Task<bool> IsEnabledAsync(). Veillez à renvoyer true de cette méthode si vous n'avez pas de besoins spécifiques pour la désactiver.

Méthode CreateTestSessionAsync

La méthode CreateTestSessionAsync est appelée au début de la session de test et est utilisée pour initialiser le framework de test. L’API accepte un objet CreateTestSessionContext et renvoie un CreateTestSessionResult.

public sealed class CreateTestSessionContext : TestSessionContext
{
    public CancellationToken CancellationToken { get; }
}

La SessionUid propriété est héritée de TestSessionContext (voir la section TestSessionContext). Le CancellationToken est utilisé pour interrompre l’exécution de CreateTestSessionAsync.

L’objet de retour est un CreateTestSessionResult :

public sealed class CreateTestSessionResult
{
    public string? WarningMessage { get; set; }
    public string? ErrorMessage { get; set; }
    public bool IsSuccess { get; set; }
}

La propriété IsSuccess est utilisée pour indiquer si la création de la session a réussi. Lorsqu’elle renvoie false, l’exécution du test est arrêtée.

Méthode CloseTestSessionAsync

La méthode CloseTestSessionAsync est juxtaposée à la CreateTestSessionAsync en fonctionnalité, avec la seule différence étant les noms des objets. Pour plus d’informations, consultez la section CreateTestSessionAsync.

Méthode ExecuteRequestAsync

La méthode ExecuteRequestAsync accepte un objet de type ExecuteRequestContext. Cet objet, comme son nom le suggère, contient les détails sur l’action que le framework de test est censé effectuer. La définition de ExecuteRequestContext est :

public sealed class ExecuteRequestContext
{
    public IRequest Request { get; }
    public IMessageBus MessageBus { get; }
    public CancellationToken CancellationToken { get; }
    public void Complete();
}

IRequest : Il s’agit de l’interface de base pour tout type de demande. Vous devriez considérer le framework de test comme un serveur avec état in-process où le cycle de vie est :

Un diagramme de séquence représentant le cycle de vie du framework de test.

Le diagramme précédent illustre que la plateforme de test émet trois demandes après avoir créé l’instance du framework de test. Le framework de test traite ces demandes et utilise le service IMessageBus, qui est inclus dans la demande elle-même, pour fournir le résultat pour chaque demande spécifique. Une fois qu’une demande particulière a été traitée, le framework de test invoque la méthode Complete() sur celle-ci, indiquant à la plateforme de test que la demande a été satisfaite. La plateforme de test surveille toutes les demandes envoyées. Une fois que toutes les demandes ont été satisfaites, elle invoque CloseTestSessionAsync et dispose de l’instance (si IDisposable/IAsyncDisposable est implémenté). Il est évident que les demandes et leurs achèvements peuvent se chevaucher, permettant une exécution concurrente et asynchrone des demandes.

Note

Actuellement, la plateforme de test n’envoie pas de demandes qui se chevauchent et attend l’achèvement d’une demande >> avant d’envoyer la suivante. Cependant, ce comportement peut changer à l’avenir. La prise en charge des demandes concurrentes sera déterminée via le système de capacités.

L’implémentation de IRequest spécifie la demande précise qui doit être satisfaite. Le framework de test identifie le type de demande et la traite en conséquence. Si le type de demande n’est pas reconnu, une exception doit être levée.

Vous pouvez trouver des détails sur les demandes disponibles dans la section IRequest.

IMessageBus : Ce service, lié à la demande, permet au framework de test de publier de manière asynchrone des informations sur la demande en cours à la plateforme de test. Le bus de messages sert de hub central pour la plateforme, facilitant la communication asynchrone entre tous les composants de la plateforme et les extensions. Pour une liste complète des informations qui peuvent être publiées à la plateforme de test, reportez-vous à la section IMessageBus.

CancellationToken : Ce jeton est utilisé pour interrompre le traitement d’une demande particulière.

Complete() : Comme illustré dans la séquence précédente, la méthode Complete notifie à la plateforme que la demande a été traitée avec succès et que toutes les informations pertinentes ont été transmises au IMessageBus.

Avertissement

Négliger d’invoquer Complete() sur la demande entraînera le blocage de l’application de test.

Pour personnaliser votre framework de test selon vos besoins ou ceux de vos utilisateurs, vous pouvez utiliser une section personnalisée à l’intérieur du fichier de configuration ou avec des options de ligne de commande personnalisées.

Traitement des demandes

La section suivante fournit une description détaillée des diverses demandes que le framework de test peut recevoir et traiter.

Avant de passer à la section suivante, il est crucial de bien comprendre le concept du IMessageBus, qui est le service essentiel pour transmettre des informations d’exécution de test à la plateforme de test.

TestSessionContext

Le TestSessionContext est une propriété partagée dans toutes les demandes, fournissant des informations sur la session de test en cours :

public class TestSessionContext
{
    public SessionUid SessionUid { get; }
}

public readonly struct SessionUid(string value)
{
    public string Value { get; }
}

Le TestSessionContext se compose du SessionUid, un identifiant unique pour la session de test en cours qui aide à la journalisation et à la corrélation des données de session de test.

DiscoverTestExecutionRequest

public class DiscoverTestExecutionRequest
{
    public TestSessionContext Session { get; }
    public ITestExecutionFilter Filter { get; }
}

Le DiscoverTestExecutionRequest ordonne au framework de test de découvrir les tests et de communiquer cette information pensée au IMessageBus.

Comme indiqué dans la section précédente, la propriété pour un test découvert est DiscoveredTestNodeStateProperty. Voici un extrait de code générique pour référence :

var testNode = new TestNode
{
    Uid = GenerateUniqueStableId(),
    DisplayName = GetDisplayName(),
    Properties = new PropertyBag(
        DiscoveredTestNodeStateProperty.CachedInstance),
};

await context.MessageBus.PublishAsync(
    this,
    new TestNodeUpdateMessage(
        discoverTestExecutionRequest.Session.SessionUid,
        testNode));

// ...

RunTestExecutionRequest

public class RunTestExecutionRequest
{
    public TestSessionContext Session { get; }
    public ITestExecutionFilter Filter { get; }
}

Le RunTestExecutionRequest ordonne au framework de test d’exécuter les tests et de communiquer cette information pensée au IMessageBus.

Voici un extrait de code générique pour référence :

var skippedTestNode = new TestNode()
{
    Uid = GenerateUniqueStableId(),
    DisplayName = GetDisplayName(),
    Properties = new PropertyBag(
        SkippedTestNodeStateProperty.CachedInstance),
};

await context.MessageBus.PublishAsync(
    this,
    new TestNodeUpdateMessage(
        runTestExecutionRequest.Session.SessionUid,
        skippedTestNode));

// ...

var successfulTestNode = new TestNode()
{
    Uid = GenerateUniqueStableId(),
    DisplayName = GetDisplayName(),
    Properties = new PropertyBag(
        PassedTestNodeStateProperty.CachedInstance),
};

await context.MessageBus.PublishAsync(
    this,
    new TestNodeUpdateMessage(
        runTestExecutionRequest.Session.SessionUid,
        successfulTestNode));

// ...

var assertionFailedTestNode = new TestNode()
{
    Uid = GenerateUniqueStableId(),
    DisplayName = GetDisplayName(),
    Properties = new PropertyBag(
        new FailedTestNodeStateProperty(assertionException)),
};

await context.MessageBus.PublishAsync(
    this,
    new TestNodeUpdateMessage(
        runTestExecutionRequest.Session.SessionUid,
        assertionFailedTestNode));

// ...

var failedTestNode = new TestNode()
{
    Uid = GenerateUniqueStableId(),
    DisplayName = GetDisplayName(),
    Properties = new PropertyBag(
        new ErrorTestNodeStateProperty(ex.InnerException!)),
};

await context.MessageBus.PublishAsync(
    this,
    new TestNodeUpdateMessage(
        runTestExecutionRequest.Session.SessionUid,
        failedTestNode));

Les données TestNodeUpdateMessage

Comme mentionné dans la section IMessageBus, avant d’utiliser le bus de messages, vous devez spécifier le type de données que vous avez l’intention de fournir. La plateforme de test a défini un type bien connu, TestNodeUpdateMessage, pour représenter le concept d’information de mise à jour de test.

Cette partie du document expliquera comment utiliser ces données de charge utile. Examinons la surface :

public sealed class TestNodeUpdateMessage(
    SessionUid sessionUid,
    TestNode testNode,
    TestNodeUid? parentTestNodeUid = null)
{
    public TestNode TestNode { get; }
    public TestNodeUid? ParentTestNodeUid { get; }
}

public class TestNode
{
    public required TestNodeUid Uid { get; init; }
    public required string DisplayName { get; init; }
    public PropertyBag Properties { get; init; } = new();
}

public sealed class TestNodeUid(string value);

public sealed partial class PropertyBag
{
    public PropertyBag();
    public PropertyBag(params IProperty[] properties);
    public PropertyBag(IEnumerable<IProperty> properties);
    public int Count { get; }
    public void Add(IProperty property);
    public bool Any<TProperty>();
    public TProperty? SingleOrDefault<TProperty>();
    public TProperty Single<TProperty>();
    public TProperty[] OfType<TProperty>();
    public IEnumerable<IProperty> AsEnumerable();
    public IEnumerator<IProperty> GetEnumerator();
    ...
}

public interface IProperty
{
}

  • TestNodeUpdateMessage : Le TestNodeUpdateMessage se compose de deux propriétés : un TestNode et un ParentTestNodeUid. Le ParentTestNodeUid indique qu’un test peut avoir un test parent, introduisant le concept d’une arborescence de tests où les TestNode peuvent être organisés les uns par rapport aux autres. Cette structure permet des améliorations et des fonctionnalités futures basées sur la relation d’arborescence entre les nœuds. Si votre framework de test n’exige pas une structure d’arbre de tests, vous pouvez choisir de ne pas l’utiliser et simplement la définir à null, ce qui aboutit à une liste plate de TestNode.

  • TestNode : Le TestNode est composé de trois propriétés, dont l’une est le Uid de type TestNodeUid. Ce Uid sert d’ID STABLE UNIQUE pour le nœud. Le terme ID STABLE UNIQUE implique que le même TestNode doit rester IDENTIQUEUid à travers différentes exécutions et systèmes d’exploitation. Le TestNodeUid est une chaîne opaque arbitraire que la plateforme de test accepte telle quelle.

Important

La stabilité et l’unicité de l’ID sont cruciales dans le domaine du test. Elles permettent de cibler précisément un seul test pour l’exécution et permettent à l’ID de servir d’identifiant persistant pour un test, facilitant des extensions et des fonctionnalités puissantes.

La deuxième propriété est DisplayName, qui est le nom convivial pour le test. Par exemple, ce nom est affiché lorsque vous exécutez la ligne de commande --list-tests.

Le troisième attribut est Properties, qui est un type PropertyBag. Comme démontré dans le code, il s’agit d’un conteneur de propriétés spécialisé qui contient des propriétés génériques sur le TestNodeUpdateMessage. Cela implique que vous pouvez ajouter n’importe quelle propriété au nœud qui implémente l’interface de remplacement IProperty.

La plateforme de test identifie des propriétés spécifiques ajoutées à un TestNode.Properties pour déterminer si un test a réussi, échoué ou été ignoré.

Vous trouverez la liste actuelle des propriétés disponibles avec la description relative dans la section TestNodeUpdateMessage.TestNode.

Le type PropertyBag est généralement accessible dans chaque IData et est utilisé pour stocker des propriétés diverses qui peuvent être interrogées par la plateforme et les extensions. Ce mécanisme nous permet d’améliorer la plateforme avec de nouvelles informations sans introduire de changements incompatibles. Si un composant reconnaît la propriété, il peut l’interroger ; sinon, il l’ignorera.

Enfin, cette section clarifie que votre implémentation de framework de test doit implémenter le IDataProducer qui produit des TestNodeUpdateMessage comme dans l’exemple ci-dessous :

internal sealed class TestingFramework
    : ITestFramework, IDataProducer
{
   // ...

   public Type[] DataTypesProduced =>
   [
       typeof(TestNodeUpdateMessage)
   ];

   // ...
}

Si votre adaptateur de test nécessite la publication de fichiers pendant l’exécution, vous pouvez trouver les propriétés reconnues dans ce fichier source : https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Platform/Messages/FileArtifacts.cs. Comme vous pouvez le voir, vous pouvez fournir des ressources de fichiers de manière générale ou les associer à un TestNode spécifique. Rappelez-vous, si vous avez l’intention de pousser un SessionFileArtifact, vous devez le déclarer au système à l’avance, comme indiqué ci-dessous :

internal sealed class TestingFramework
    : ITestFramework, IDataProducer
{
   // ...

   public Type[] DataTypesProduced =>
   [
       typeof(TestNodeUpdateMessage),
       typeof(SessionFileArtifact)
   ];

   // ...
}

Propriétés connues

Comme indiqué dans la section des demandes, la plateforme de test identifie les propriétés spécifiques ajoutées à TestNodeUpdateMessage pour déterminer le statut d'un TestNode (par exemple, réussite, échec, ignoré, etc.). Cela permet au runtime d’afficher avec précision une liste des tests échoués avec leurs informations correspondantes dans la console, et de définir le code de sortie approprié pour le processus de test.

Dans ce segment, nous allons élucider les différentes options de IProperty bien connues et leurs implications respectives.

Pour obtenir la liste complète des propriétés connues, consultez TestNodeProperties.cs. Si vous remarquez qu’une description de propriété est manquante, envoyez un problème.

Ces propriétés peuvent être divisées dans les catégories suivantes :

  1. Informations génériques : Propriétés qui peuvent être incluses dans tout type de demande.
  2. Informations de découverte : Propriétés qui sont fournies lors d’une demande de découverte DiscoverTestExecutionRequest.
  3. Informations d’exécution : Propriétés qui sont fournies lors d’une demande d’exécution de test RunTestExecutionRequest.

Certaines propriétés sont requises, tandis que d’autres sont optionnelles. Les propriétés obligatoires sont nécessaires pour fournir une fonctionnalité de test de base, telle que le signalement des tests échoués et l’indication si l’ensemble de la session de test a réussi ou non.

Les propriétés optionnelles, en revanche, améliorent l’expérience de test en fournissant des informations supplémentaires. Elles sont particulièrement utiles dans les scénarios IDE (comme VS, VSCode, etc.), les exécutions en console, ou lors de la prise en charge d’extensions spécifiques qui nécessitent des informations plus détaillées pour fonctionner correctement. Cependant, ces propriétés optionnelles n’affectent pas l’exécution des tests.

Note

Les extensions sont chargées d’alerter et de gérer les exceptions lorsqu’elles nécessitent des informations spécifiques pour fonctionner correctement. Si une extension manque des informations nécessaires, elle ne devrait pas provoquer l’échec de l’exécution du test, mais simplement se désinscrire.

Informations génériques
public record KeyValuePairStringProperty(
    string Key,
    string Value)
        : IProperty;

Le KeyValuePairStringProperty représente une paire clé/valeur générale de données.

public record struct LinePosition(
    int Line,
    int Column);

public record struct LinePositionSpan(
    LinePosition Start,
    LinePosition End);

public abstract record FileLocationProperty(
    string FilePath,
    LinePositionSpan LineSpan)
        : IProperty;

public sealed record TestFileLocationProperty(
    string FilePath,
    LinePositionSpan LineSpan)
        : FileLocationProperty(FilePath, LineSpan);

TestFileLocationProperty est utilisé pour identifier l’emplacement du test dans le fichier source. Cela est particulièrement utile lorsque l’initiateur est un IDE comme Visual Studio ou Visual Studio Code.

public sealed record TestMethodIdentifierProperty(
    string AssemblyFullName,
    string Namespace,
    string TypeName,
    string MethodName,
    string[] ParameterTypeFullNames,
    string ReturnTypeFullName)

TestMethodIdentifierProperty est un identificateur unique pour une méthode de test.

public sealed record TestMetadataProperty(
    string Key,
    string Value)

TestMetadataProperty est utilisé pour transmettre les caractéristiques ou traits d’un TestNode.

Informations de la découverte
public sealed record DiscoveredTestNodeStateProperty(
    string? Explanation = null)
{
    public static DiscoveredTestNodeStateProperty CachedInstance { get; }
}

Le DiscoveredTestNodeStateProperty indique que ce TestNode a été découvert. Il est utilisé lorsqu’un DiscoverTestExecutionRequest est envoyé au framework de test. Notez la valeur mise en cache pratique offerte par la propriété CachedInstance. Cette propriété est requise.

Informations d’exécution
public sealed record InProgressTestNodeStateProperty(
    string? Explanation = null)
{
    public static InProgressTestNodeStateProperty CachedInstance { get; }
}

Le InProgressTestNodeStateProperty informe la plateforme de test que le TestNode a été planifié pour l’exécution et est actuellement en cours. Notez la valeur mise en cache pratique offerte par la propriété CachedInstance.

public readonly record struct TimingInfo(
    DateTimeOffset StartTime,
    DateTimeOffset EndTime,
    TimeSpan Duration);

public sealed record StepTimingInfo(
    string Id,
    string Description,
    TimingInfo Timing);

public sealed record TimingProperty : IProperty
{
    public TimingProperty(TimingInfo globalTiming)
        : this(globalTiming, [])
    {
    }

    public TimingProperty(
        TimingInfo globalTiming,
        StepTimingInfo[] stepTimings)
    {
        GlobalTiming = globalTiming;
        StepTimings = stepTimings;
    }

    public TimingInfo GlobalTiming { get; }

    public StepTimingInfo[] StepTimings { get; }
}

Le TimingProperty est utilisé pour transmettre des détails de minutage sur l’exécution du TestNode. Il permet également de chronométrer des étapes d’exécution individuelles via StepTimingInfo. Ceci est particulièrement utile lorsque votre concept de test est divisé en plusieurs phases telles que l’initialisation, l’exécution et le nettoyage.

Une et une seule des propriétés suivantes est requise par TestNode et communique le résultat du TestNode à la plateforme de test.

public sealed record PassedTestNodeStateProperty(
    string? Explanation = null)
        : TestNodeStateProperty(Explanation)
{
    public static PassedTestNodeStateProperty CachedInstance
        { get; } = new PassedTestNodeStateProperty();
}

PassedTestNodeStateProperty informe la plateforme de test que ce TestNode est réussi. Notez la valeur mise en cache pratique offerte par la propriété CachedInstance.

public sealed record SkippedTestNodeStateProperty(
    string? Explanation = null)
        : TestNodeStateProperty(Explanation)
{
    public static SkippedTestNodeStateProperty CachedInstance
        { get; } =  new SkippedTestNodeStateProperty();
}

SkippedTestNodeStateProperty informe la plateforme de test que ce TestNode a été ignoré. Notez la valeur mise en cache pratique offerte par la propriété CachedInstance.

public sealed record FailedTestNodeStateProperty : TestNodeStateProperty
{
    public FailedTestNodeStateProperty()
        : base(default(string))
    {
    }

    public FailedTestNodeStateProperty(string explanation)
        : base(explanation)
    {
    }

    public FailedTestNodeStateProperty(
        Exception exception,
        string? explanation = null)
        : base(explanation ?? exception.Message)
    {
        Exception = exception;
    }

    public Exception? Exception { get; }
}

FailedTestNodeStateProperty informe la plateforme de test que ce TestNode est en échec après une assertion.

public sealed record ErrorTestNodeStateProperty : TestNodeStateProperty
{
    public ErrorTestNodeStateProperty()
        : base(default(string))
    {
    }

    public ErrorTestNodeStateProperty(string explanation)
        : base(explanation)
    {
    }

    public ErrorTestNodeStateProperty(
        Exception exception,
        string? explanation = null)
            : base(explanation ?? exception.Message)
    {
        Exception = exception;
    }

    public Exception? Exception { get; }
}

ErrorTestNodeStateProperty informe la plateforme de test que ce TestNode a échoué. Ce type d’échec est différent du FailedTestNodeStateProperty, qui est utilisé pour les échecs d’assertion. Par exemple, vous pouvez signaler des problèmes comme des erreurs d’initialisation de test avec ErrorTestNodeStateProperty.

public sealed record TimeoutTestNodeStateProperty : TestNodeStateProperty
{
    public TimeoutTestNodeStateProperty()
        : base(default(string))
    {
    }

    public TimeoutTestNodeStateProperty(string explanation)
        : base(explanation)
    {
    }

    public TimeoutTestNodeStateProperty(
        Exception exception,
        string? explanation = null)
            : base(explanation ?? exception.Message)
    {
        Exception = exception;
    }

    public Exception? Exception { get; }

    public TimeSpan? Timeout { get; init; }
}

TimeoutTestNodeStateProperty informe la plateforme de test que ce TestNode a échoué en raison d'un délai d'attente. Vous pouvez signaler le délai d’attente en utilisant la propriété Timeout.

public sealed record CancelledTestNodeStateProperty : TestNodeStateProperty
{
    public CancelledTestNodeStateProperty()
        : base(default(string))
    {
    }

    public CancelledTestNodeStateProperty(string explanation)
        : base(explanation)
    {
    }

    public CancelledTestNodeStateProperty(
        Exception exception,
        string? explanation = null)
        : base(explanation ?? exception.Message)
    {
        Exception = exception;
    }

    public Exception? Exception { get; }
}

CancelledTestNodeStateProperty informe la plateforme de test que ce TestNode a échoué en raison d’une annulation.

  • Last updated on