Para carregar ou não carregar dados para testes de unidade de arquivos externos

Ao testar unidades, muitas vezes me pego debatendo quanto dos dados alimento e espero voltar das minhas unidades em teste, devo incluir nos arquivos de teste reais.

A desvantagem com a qual estou constantemente lutando é:

• Se uma grande parte do teste (em volume de código) consiste em dados de entrada e saída, parece difícil ler o teste, mas posso ver facilmente as entradas e saídas reais.
• Se eu carregar os dados de teste dos arquivos, posso testar facilmente várias variações de possíveis entradas de dados, reutilizar facilmente os dados de teste para vários testes, mas tenho que deixar o código fonte para procurar outro arquivo para ver exatamente quais são as entradas. .

Qualquer um destes é um antipadrão?

Para responder sua pergunta diretamente - não, não acredito que seja um anti-padrão quando usado corretamente.

--- Resposta mais detalhada ---

Pela minha experiência, acho que isso depende muito do objetivo do seu teste. Aqui está a regra prática que usei no passado e me ajudou a decidir:

Você está realmente testando uma pequena unidade de código? (Um verdadeiro teste de unidade)

Se sim, descobri que é muito mais fácil criar os dados dentro do próprio teste exatamente porque consigo ver o que está sendo passado. Nesses casos, geralmente procurarei uma biblioteca semelhante ao Jasmine para usar, porque acho que facilita a criação e a manutenção dos dados de teste. Essa é uma preferência pessoal - use o que facilitar o seu trabalho.

Se não, então provavelmente você está testando o próprio sistema. Nesses casos, eu frequentemente carrego dados de uma fonte externa, sendo os motivos aqui:

1. Esse teste não é sobre clareza de código para programadores (embora isso ainda seja importante - alguém precisa manter isso), é sobre a execução de tipos diferentes de dados em todo o bloco do sistema para ter certeza de que funciona.
2. Frequentemente, escreverei o código do encanamento para carregar e usar os dados de teste, mas os dados em si são criados por outra pessoa (geralmente um membro da equipe de controle de qualidade no meu caso). Essas pessoas geralmente não são programadores, então não posso esperar que elas estejam editando código.

Resposta longa, curta, depende do que você está testando e por quê. Ambas as abordagens são úteis e têm seu lugar - escolha o que funciona melhor para sua situação.

Não vejo uma troca aqui. O código-fonte deve descrever algoritmos, ou pelo menos lógica de negócios, não grandes quantidades de dados. Se você escreve uma transformação de Fourier, deseja verificar se um tom de sinusite está corretamente mapeado para um único pico, um som misto para mais picos etc., mas para isso é completamente suficiente alimentar um arquivo nomeado sinus.wavna rotina e verificar se a estrutura de saída é o que você espera.

Claro, tecnicamente você não tem uma garantia imediata de que sinus.wavrealmente contém um tom sinusal, mas como você disse, listar os 100.000 valores de amplitude na fonte também não fornece isso - na verdade, é pior , porque você pode pelo menos reproduzir um arquivo externo com um reprodutor de áudio para verificar, enquanto os valores de dados enterrados no código-fonte são essencialmente impossíveis de se fazer.