DependsOnAttribute Classe

Définition

[System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Method, AllowMultiple=true, Inherited=false)]
[System.Runtime.CompilerServices.Nullable(0)]
public sealed class DependsOnAttribute : Attribute

[System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Method, AllowMultiple=true, Inherited=false)]
public sealed class DependsOnAttribute : Attribute

[<System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Method, AllowMultiple=true, Inherited=false)>]
[<System.Runtime.CompilerServices.Nullable(0)>]
type DependsOnAttribute = class
    inherit Attribute

[<System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Method, AllowMultiple=true, Inherited=false)>]
type DependsOnAttribute = class
    inherit Attribute

Public NotInheritable Class DependsOnAttribute
Inherits Attribute

Héritage

Attribute

DependsOnAttribute

Attributs

AttributeUsageAttribute NullableAttribute

Exemples

[TestClass]
public class CheckoutTests
{
    [TestMethod]
    public void CreateCart() { }

    // Fan-out: both of these wait for CreateCart, then may run in parallel with each other.
    [TestMethod]
    [DependsOn(nameof(CreateCart))]
    public void AddItem() { }

    [TestMethod]
    [DependsOn(nameof(CreateCart))]
    public void ApplyCoupon() { }

    // Fan-in: waits for both.
    [TestMethod]
    [DependsOn(nameof(AddItem))]
    [DependsOn(nameof(ApplyCoupon))]
    public void Checkout() { }

    // Runs even when its prerequisite failed.
    [TestMethod]
    [DependsOn(nameof(Checkout), ProceedOnFailure = true)]
    public void WriteAuditRecord() { }
}

Remarques

L’attribut déclare un bord « ce test dépend de ce test ». L’application de celui-ci plusieurs fois est la façon dont un test déclare plusieurs conditions préalables (ventilateur) ; plusieurs tests nommant le même prérequis est la façon dont un graphe est sorti. Le fan-out est le point de la fonctionnalité : une fois que la configuration requise partagée est passée, chaque dépendant devient exécutable en même temps et le planificateur est libre de les exécuter simultanément, sous réserve de ParallelizeAttribute disponibilité et de travail.

Lorsqu’elle est appliquée à une classe, la dépendance s’applique à chaque test de cette classe. Lorsque la cible est un type (plutôt qu’une méthode spécifique), le bord pointe à chaque test de ce type, de sorte que le dépendant ne démarre qu’une fois que tous les éléments ont terminé.

Portée. Les dépendances sont résolues dans une source de test unique. Une cible dans un autre assembly ne peut pas être attendu, même si DependsOnAttribute(Type) et DependsOnAttribute(Type, String) acceptera heureusement un type à partir d’un : un tel bord ne correspond à rien et est signalé comme une dépendance ignorée plutôt que d’ordonner silencieusement quoi que ce soit.

Sémantique d’échec. Si une condition préalable ne passe pas, la dépendance est ignorée, n’a pas échoué et l’ignorer se propage de manière transitive vers le bas du graphique. Skipping est la convention établie (TestNG’s dependsOnMethods, TUnit’s [DependsOn], pytest-dependency) et conserve le signal lisible : une cause racine est signalée comme un échec plus un ensemble d’skips clairement étiquetés, au lieu d’un mur de défaillances. true Défini ProceedOnFailure sur pour un dépendant qui doit s’exécuter de toute façon : généralement un test d’audit ou de nettoyage.

Cycles. Un cycle de dépendance est une erreur de configuration et est signalé avant l’exécution d’un test dans l’assembly. Chaque test du cycle a échoué avec un message nommant le chemin du cycle.

Interaction avec la parallélisation. L’ordre est appliqué indépendamment de Scope. Sous ClassLevel (la valeur par défaut), l’unité de planification est la classe entière, de sorte que les dépendances entre deux classes sont respectées au niveau de la granularité de classe ; une dépendance entre deux méthodes de la même classe les commande dans l’exécution de cette classe. Chaque MethodLevel test est planifié individuellement, ce qui donne le plus de parallélisme et le meilleur ordre. Si la planification au niveau de la classe nécessiterait l’exécution de deux classes les unes avant les autres (le test de la classe A dépend des classes B et vice versa), l’ordre déclaré est toujours respecté - les tests de ces classes sont exécutés séquentiellement, dans l’ordre des dépendances et un avertissement les nomme - mais ils perdent leur parallélisme ; basculer pour MethodLevel le ramener.

Un test marqué DoNotParallelizeAttribute s’exécute dans la phase séquentielle, qui se produit après la phase parallèle. Un test parallélisable qui dépend d’un tel test est donc déplacé dans la phase séquentielle également (transitivement), afin que sa condition préalable s’exécute en premier.

Tests pilotés par les données. Le nommage d’un test qui se développe dans plusieurs cas de test (par exemple via [DataRow]) crée un bord à tous ses cas : les attentes dépendantes pour chaque ligne sont ignorées si une ligne ne passe pas. La correspondance par ligne n’est pas prise en charge.

Héritage. Une méthode de test déclarée sur une classe de base s’exécute en tant que test de chaque classe de test dérivée, et la dépendance qu’elle déclare voyage avec elle : le bord est résolu par rapport à la classe dérivée, de sorte que chaque classe dérivée obtient son propre bord entre ses propres copies des deux tests. La suppression de la bordure là-bas ignorerait silencieusement l’ordre déclaré dans chaque classe de test concrète. Ce qui Inherited = false exclut les chaînes de remplacement : une méthode qui remplace un test dépendant sans déclarer de nouveau l’attribut n’a aucune dépendance, car le fait de pointer à nouveau une condition préalable sur une méthode que l’auteur réécrit tend à créer des arêtes que personne n’a demandé.

Testez les dépendances couplent les tests ensemble et rendent impossible l’exécution d’une dépendance en isolation, de sorte qu’ils sont un mauvais ajustement pour les tests unitaires. Ils existent pour l’intégration multi-étapes et les suites de bout en bout, où la réécriture de l’état coûteux dans chaque test n’est pas pratique.