DependsOnAttribute Klasse

Definition

[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

Vererbung

Attribute

DependsOnAttribute

Attribute

AttributeUsageAttribute NullableAttribute

Beispiele

[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() { }
}

Hinweise

Das Attribut deklariert einen Rand "dieser Test hängt von diesem Test ab". Wenn sie mehrmals angewendet wird, deklariert ein Test mehr als eine Voraussetzung (Fan-In); mehrere Tests, die die gleiche Voraussetzung nennen, ist, wie ein Graph-Lüfter heraus kommt. Fanout ist der Punkt des Features: Sobald die freigegebene Voraussetzung bestanden wurde, wird jeder abhängige Benutzer gleichzeitig ausgeführt, und der Zeitplaner kann sie gleichzeitig ausführen, vorbehaltlich ParallelizeAttribute der Verfügbarkeit von Mitarbeitern.

Wenn sie auf eine Klasse angewendet wird, gilt die Abhängigkeit für jeden Test in dieser Klasse. Wenn es sich bei dem Ziel um einen Typ (anstelle einer bestimmten Methode) handelt, wird der Rand bei jedem Test dieses Typs punktiert, sodass der abhängige Typ erst beginnt, wenn alle elemente abgeschlossen sind.

Bereich. Abhängigkeiten werden innerhalb einer einzigen Testquelle aufgelöst. Ein Ziel in einer anderen Assembly kann nicht gewartet werden, obwohl DependsOnAttribute(Type) und DependsOnAttribute(Type, String) glücklicherweise einen Typ von einem akzeptiert: Ein solcher Rand stimmt mit nichts überein und wird als ignorierte Abhängigkeit gemeldet, anstatt im Hintergrund etwas zu sortieren.

Fehlersemantik. Wenn eine Voraussetzung nicht übergeben wird, wird der abhängige Wert übersprungen, nicht fehlgeschlagen, und der Übersprung wird transitiv nach unten verteilt. Das Überspringen ist die etablierte Konvention (TestNG, dependsOnMethodsTUnit, [DependsOn]Pytest-Abhängigkeit) und hält das Signal lesbar: Eine Ursache wird als ein Fehler gemeldet und eine Reihe eindeutig gekennzeichneter Überspringungen anstelle einer Wand von Fehlern. Legen Sie diesen true Wert für einen abhängigen Wert ProceedOnFailure fest, der trotzdem ausgeführt werden muss – in der Regel ein Überwachungs- oder Bereinigungstest.

Zyklen. Ein Abhängigkeitszyklus ist ein Konfigurationsfehler und wird vor jedem Test in der Assembly gemeldet. Jeder Test im Zyklus ist fehlgeschlagen, wobei eine Meldung mit der Benennung des Zykluspfads aufgetreten ist.

Interaktion mit Parallelisierung. Die Sortierung wird unabhängig von Scope. Unter ClassLevel (Standard) ist die Planungseinheit die gesamte Klasse, sodass Abhängigkeiten zwischen zwei Klassen bei der Klassen granularität berücksichtigt werden; eine Abhängigkeit zwischen zwei Methoden derselben Klasse sortiert sie innerhalb der Ausführung dieser Klasse. Unter MethodLevel jedem Test ist individuell geplant, was die parallelste und die feinste Sortierung gibt. Wenn die Planung auf Klassenebene zwei Klassen voreinander erfordert (der Test der Klasse A hängt von Klasse B und umgekehrt ab), wird die deklarierte Reihenfolge weiterhin berücksichtigt – die Tests dieser Klassen werden sequenziell ausgeführt, in Abhängigkeitsreihenfolge und eine Warnung nennen sie - aber sie verlieren ihre Parallelität; zu wechseln, um MethodLevel es zurück zu erhalten.

Ein test markierter DoNotParallelizeAttribute Lauf in der sequenziellen Phase, was nach der parallelen Phase geschieht. Ein parallelisierbarer Test, der von einem solchen Test abhängt, wird daher auch in die sequenzielle Phase (transitiv) verschoben, sodass seine Voraussetzung wirklich zuerst ausgeführt wurde.

Datengesteuerte Tests. Das Benennen eines Tests, der in mehrere Testfälle erweitert wird (z. B. via [DataRow]), erstellt einen Rand zu allen zugehörigen Fällen: Die abhängigen Wartet auf jede Zeile und wird übersprungen, wenn eine Zeile nicht bestanden wird. Der Abgleich pro Zeile wird nicht unterstützt.

Vererbung. Eine für eine Basisklasse deklarierte Testmethode wird als Test jeder abgeleiteten Testklasse ausgeführt, und die Abhängigkeit, die sie deklariert, wird mit ihr verbunden: Der Rand wird gegen die abgeleitete Klasse aufgelöst, sodass jede abgeleitete Klasse ihren eigenen Rand zwischen den eigenen Kopien der beiden Tests erhält. Das Ablegen des Rands würde die deklarierte Sortierung in jeder konkreten Testklasse im Hintergrund verwerfen. Was Inherited = false keine Außerkraftsetzungsketten ist : Eine Methode, die einen abhängigen Test außer Kraft setzt, ohne das Attribut erneut zu deklarieren, hat keine Abhängigkeit, da das erneute Verweisen einer Voraussetzung auf eine Methode, die der Autor umgedreht hat, dazu neigen, Kanten zu erstellen, die niemand gefragt hat.

Testabhängigkeiten paaren Tests zusammen und machen es unmöglich, eine abhängige Isolation auszuführen, sodass sie für Komponententests schlecht geeignet sind. Sie sind für mehrstufige Integration und End-to-End-Suites vorhanden, bei denen die Neugründung eines kostspieligen Zustands in jedem Test unpraktisch ist.