DependsOnAttribute Classe

Definição

[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

Herança

Attribute

DependsOnAttribute

Atributos

AttributeUsageAttribute NullableAttribute

Exemplos

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

Comentários

O atributo declara uma borda "este teste depende desse teste". Aplicá-lo várias vezes é como um teste declara mais de um pré-requisito (fan-in); vários testes que nomeia o mesmo pré-requisito é como um grafo é lançado. O fan-out é o ponto do recurso: depois que o pré-requisito compartilhado é passado, cada dependente se torna executável ao mesmo tempo e o agendador é livre para executá-los simultaneamente, sujeito à ParallelizeAttribute disponibilidade e ao trabalho.

Quando aplicada a uma classe, a dependência se aplica a cada teste nessa classe. Quando o destino é um tipo (em vez de um método específico), a borda aponta para cada teste desse tipo, portanto, o dependente começa apenas uma vez que todos eles tenham terminado.

Escopo. As dependências são resolvidas em uma única fonte de teste. Um destino em outro assembly não pode ser aguardado, mesmo DependsOnAttribute(Type) que e DependsOnAttribute(Type, String) aceite com prazer um tipo de um: tal borda não corresponde a nada e é relatada como uma dependência ignorada em vez de ordenar silenciosamente qualquer coisa.

Semântica de falha. Se um pré-requisito não passar, o dependente será ignorado, não falhará e o salto se propaga transitivamente para baixo do grafo. Ignorar é a convenção estabelecida (TestNG's dependsOnMethods, TUnit's [DependsOn], pytest-dependency) e mantém o sinal legível: uma causa raiz é relatada como uma falha mais um conjunto de saltos claramente rotulados, em vez de uma parede de falhas. Definido ProceedOnFailure como true um dependente que deve ser executado de qualquer maneira . Normalmente, um teste de auditoria ou limpeza.

Ciclos. Um ciclo de dependência é um erro de configuração e é relatado antes de qualquer teste no assembly ser executado. Todos os testes no ciclo falham com uma mensagem nomeando o caminho do ciclo.

Interação com paralelização. A ordenação é imposta independentemente de Scope. Em ClassLevel (o padrão) a unidade de agendamento é toda a classe, portanto, as dependências entre duas classes são respeitadas na granularidade da classe; uma dependência entre dois métodos da mesma classe ordena-as dentro da execução dessa classe. Em MethodLevel cada teste é agendado individualmente, o que proporciona o maior paralelismo e a melhor ordenação. Se o agendamento em nível de classe exigir a execução de duas classes antes uma da outra (o teste da classe A depende da classe B e vice-versa), a ordem declarada ainda será respeitada - os testes dessas classes são executados sequencialmente, em ordem de dependência e um aviso os nomeia - mas perdem o paralelismo; alternando para MethodLevel recuperá-lo.

Um teste marcado DoNotParallelizeAttribute é executado na fase sequencial, que ocorre após a fase paralela. Um teste paralelizável que depende desse teste é, portanto, movido para a fase sequencial também (transitivamente), de modo que seu pré-requisito realmente tenha sido executado primeiro.

Testes controlados por dados. Nomear um teste que se expande para vários casos de teste (por exemplo, via [DataRow]) cria uma borda para todos os seus casos: o dependente aguarda por cada linha e é ignorado se qualquer linha não passa. Não há suporte para correspondência por linha.

Herança. Um método de teste declarado em uma classe base é executado como um teste de cada classe de teste derivada e a dependência que ele declara viaja com ela: a borda é resolvida em relação à classe derivada , de modo que cada classe derivada obtém sua própria borda entre suas próprias cópias dos dois testes. Soltar a borda lá descartaria silenciosamente a ordenação declarada em cada classe de teste concreta. O que Inherited = false recusa é substituir cadeias: um método que substitui um teste dependente sem declarar novamente o atributo não tem dependência, pois apontar novamente um pré-requisito para um método que o autor reescreveu tende a criar bordas que ninguém pediu.

Teste os testes de casal de dependências e impossibilita a execução de um dependente em isolamento, portanto, eles são um ajuste ruim para testes de unidade. Eles existem para integração de várias etapas e pacotes de ponta a ponta, em que o restabelecimento do estado caro em cada teste é impraticável.