Criando uma função de mapeamento através do TDD: muito tempo gasto em testes de escrita?

Question

Sou um grande entusiasta do TDD e sempre me esforço para escrever testes antes de escrever o código de produção para garantir o comportamento correto do código que estou escrevendo. Ocasionalmente, no entanto, várias perguntas se é prudente escrever um grande corpo de testes para certos tipos de métodos. Isso parece surgir com mais frequência ao escrever uma aula de mapeador.

public class FooBarMapper
{
    public Foo MapToFoo(Bar bar)
    {
        return new Foo
        {
            Id = bar.Id,
            Name = bar.Name,
            FooYuk = bar.Beverage,
            /* ... */
        };
    }
}

Diga, por exemplo, que existem cerca de uma dúzia de propriedades para mapear acima. Em um ambiente TDD, antes de escrever qualquer um dos mapeamentos, eu provavelmente escreveria um teste. Algo como MapToFooMapsBeverageToFooYuk(). O teste falha, levando -me a escrever o código para fazê -lo passar. Repito isso para cada propriedade mapear. A questão é: isso está levando o desenvolvimento a primeira? Pessoalmente, acho que não, como prefiro ter um conjunto completo de testes me dizendo exatamente o que o código faz, mas gostaria de ouvir o que a comunidade pensa.

Answer 1

Até o tio Bob Martin, um firme defensor do TDD e todas as coisas do TDD, diz que você não precisa escrever testes de unidade para todas as propriedades triviais (uma propriedade trivial sendo definida como uma propriedade que apenas obtém e define uma variável de membro).

Se você escrever uma propriedade que tenha efeitos colaterais (que eu duvido que você faça), então Você pode adicionar um teste de unidade a ele. Como Duffymo aponta, se suas propriedades forem cobertas por testes funcionais, não deve haver necessidade de testes de unidade, pois não há especificação de funcionalidade que você está definindo com o teste de unidade, exceto o trivial GET/Set.

Answer 2

Talvez seja isso Fitness nasceu para.

Answer 3

Nesse caso, eu escreveria um único teste que testa todas as propriedades triviais de uma só vez. Não é exatamente a maneira padrão de fazer as coisas, mas, eventualmente, os testes para propriedades triviais individuais provavelmente seriam reformuladas em um único teste para todas as propriedades. Como as propriedades são triviais, proponho começar com o teste com o qual terminaria.

Answer 4

Depois de mapear as três primeiras propriedades, eu veria a duplicação e a substituiria iterando as propriedades e atribuindo -as usando a reflexão. Isso precisa apenas de alguns testes: 0 propriedades, 1 propriedade, 5 propriedades, objeto de destino não possui as propriedades esperadas, o objeto de origem não possui as propriedades esperadas. Agora, posso reutilizar esse mecanismo de mapeamento geral em qualquer outro lugar de todos os meus aplicativos e não preciso verificar cada vez que o uso.