Testes de unidade dinâmicos em C #

Obter falha de compilação de executores de teste automatizados (como o NCrunch ) pode ser bastante irritante. Mas é possível escrever testes sem receber nenhum erro de compilação como feedback em C #? Bem, com a dynamicpalavra-chave você pode!

Esta dica é na verdade de @markrendle , que mostrou isso na conferência # leetspeak12 . No entanto, não consegui encontrar nenhum artigo descrevendo isso, então vou postar a ideia aqui.

Etapa 1. Crie uma fábrica de tipo dinâmico

Se você realmente deseja ser capaz de inicialmente testar a unidade de uma classe que ainda não existe, sem nenhum erro de compilação , você pode começar criando um prático auxiliar de fábrica que cria seus tipos dinamicamente como este:

class TypeFactory {
    public static dynamic Build { 
        get { 
            return new TypeFactory(); 
        } 
    }
}

Isso foi simples, não?

O método de fábrica (que é tecnicamente uma propriedade chamada neste caso Build) retornará uma instância da classe de fábrica como um dynamic, ou seja, um certo algo com propriedades e métodos que serão resolvidos durante a execução. Por causa disso, você pode usar a fábrica dinâmica para criar qualquer coisa de qualquer tipo, mesmo objetos de tipos que ainda não foram definidos, diretamente em seus testes.

O exemplo abaixo usa a fábrica dinâmica invocando a Buildpropriedade seguida por outra propriedade que deve criar nosso objeto indefinido atualmente como este:

var myNewObj = TypeFactory.Build.MyNewObj;

Este trecho de código não mostrará nenhum erro de construção, mas lançará durante o tempo de execução um, RuntimeBinderExceptionjá que TypeFactory não tem uma propriedade MyNewObj implementada nem está dinamicamente definida. Mas isso é o suficiente para escrevermos o primeiro teste com falha e a ideia é estender a fábrica conforme você cria novos tipos para seus testes. Continuaremos com um exemplo abaixo.

Etapa 2. Crie um teste de unidade que teste algo de tipo desconhecido – torne-o vermelho

Digamos que queremos criar uma classe chamada Roman, que gere numerais romanos a partir de numerais arábicos representados como string e como inteiro, respectivamente.

Portanto, vamos começar com um caso de teste simples antes de escrever a classe (em vez do mantra red-green-refactor do TDD). Conforme explicado acima, podemos obter qualquer tipo da fábrica dinâmica por meio da propriedade getter seguida pela propriedade getter que cria o tipo que você deseja, iremos com o nome :TypeFactory.BuildRoman

[Test]
public void RomanNumeralOne() {
    var roman = TypeFactory.Build.Roman;

    Assert.That(r.ToRoman(1), Is.EqualTo("I");
}

Observe que não temos erros de construção aqui, mesmo que não haja nada no TypeFactoryque tenha a Romanpropriedade. No entanto, conforme esperado durante a execução, o teste ficará vermelho devido a a RuntimeBinderException. Implementar este caso de teste será fácil.

Etapa 3. Consertar o teste de falha – torná-lo verde

Vamos começar modificando a fábrica de tipos para retornar o novo objeto:

public class TypeFactory {
    // ... keep the Build property

    public Roman Roman { get { return new Roman(); } }
}

Usando Resharper ou Coderush, a geração da nova classe (com a coisa mais simples que poderia funcionar para o teste) deve ser ridiculamente rápida e fácil:

public class Roman {
    public string ToRoman(int arabic) { return "I" };
}

O teste deve ser verde . Ensaboe, enxágue e repita a partir da etapa 2. Continue com TDD: ing para implementar o resto da aula.

Etapa 4. Lucro!

Feliz TDD: ing!