TDD para processamento em lote: como fazer?

Eu gosto de "vermelho / verde / refatorado" para RoR, etc.

Meu trabalho diário envolve o processamento em lote de arquivos muito grandes de terceiros em python e outras ferramentas personalizadas.

A rotatividade nos atributos desses arquivos é alta; portanto, há muitas correções / aprimoramentos aplicados com bastante frequência.

O teste de regressão por meio de um corpo conhecido de dados de teste com resultados esperados não existe. A coisa mais próxima está sendo executada no último lote, com novos casos de teste codificados manualmente, verifique se eles não explodem e aplique a verificação pontual e os testes estatísticos para verificar se os dados ainda parecem bons.

Q >> Como trazer os princípios de TDD para esse tipo de ambiente?

Apenas um FYI: o teste de unidade não é equivalente ao TDD. TDD é um processo no qual o teste de unidade é um elemento.

Com isso dito, se você estava procurando implementar testes de unidade, há várias coisas que você pode fazer:

Todos os novos códigos / aprimoramentos são testados

Dessa forma, você não precisa passar por um teste de unidade e tudo o que já existe, portanto, o hump inicial da implementação do teste de unidade é muito menor.

Teste partes individuais de dados

Testar algo que pode conter grandes quantidades de dados pode levar a muitos casos extremos e lacunas na cobertura do teste. Em vez disso, considere a opção 0, 1, muitos. Teste um 'lote' com 0 elementos, 1 elemento e muitos elementos. No caso de 1 elemento, teste as várias permutações em que os dados desse elemento podem estar.

A partir daí, teste as arestas (limites superiores ao tamanho de elementos individuais e quantidade de elementos no lote). Se você executa os testes regularmente e possui testes de execução longa (lotes grandes?), A maioria dos executores de testes permite a categorização para que você possa executar esses casos de teste separadamente (noturno?).

Isso deve lhe dar uma base forte.

Usando dados reais

Alimentar dados 'reais' usados ​​anteriormente, como você está fazendo agora, não é uma má ideia. Basta complementá-lo com dados de teste bem formados para que você saiba imediatamente pontos específicos de falha. Em caso de falha no tratamento de dados reais, você pode inspecionar os resultados do processo em lote, produzir um teste de unidade para replicar o erro e voltar ao vermelho / verde / refatorar com casos úteis de regressão.

É o mesmo que qualquer outro ambiente.

Separe a lógica em seu menor nível de granularidade. Isso fornecerá um conjunto de regras para o processo, cada regra cobrirá um item de lógica necessário para o seu processo.

Em seguida, escreva um teste para cada regra. Esses testes falharão. Escreva o código para corrigir o teste.

O teste de regressão com dados de teste conhecidos dos quais você está falando não é um teste de unidade. Isso seria teste de integração, isso é diferente do TDD. Com o TDD, você pode ter um único teste para testar se pode carregar um arquivo, mas geralmente nenhum outro teste chegaria perto de um arquivo de dados com dados de teste. Em vez disso, você simularia os dados necessários para exercer uma regra específica usando um objeto de simulação.

Comece com uma boa estratégia de software e aplique o TDD.

(Isenção de responsabilidade: eu posso ter entendido errado "rotatividade", ou TDD, ou ambos.)

Aqui está minha estratégia sugerida para o processamento em lote de "dados sujos": Specify-Triage-Execute.

• Elabore uma especificação dos dados de maneira rigorosa e restrita, mas abrangerá a maioria (digamos, 80% ou mais) dos dados recebidos. Chame esta especificação 1 .
• Desenvolva um módulo Triage (TDD, se desejar) que decida se um registro atende à Especificação 1.
  • Verifique se o módulo funciona muito rápido.
  • O módulo deve retornar verdadeiro / falso: atende a todas as regras ou não.
• Desenvolva um módulo Execute (TDD, se desejar) que analise um registro conhecido por atender à Especificação 1, executando as tarefas necessárias aos seus clientes.
• Aplique a triagem 1 em todos os dados recebidos.
  • O resultado é um valor booleano para cada registro. Isso basicamente separa os dados recebidos em: Especificação 1 ou Desconhecido.
  • Aplique Execute 1 nos dados da Especificação 1, sempre que necessário pelo cliente.
• Relaxe as regras da especificação 1 para admitir 80% dos dados restantes. Chame esta especificação 2 .
• Desenvolva a triagem 2 e execute 2 . Aplique-o a qualquer dado que não atenda à Especificação 1.
• Repita para quantos níveis forem necessários, até que os dados restantes sejam pequenos o suficiente para que possam ser processados ​​manualmente todos os dias.

O boato da eficiência:

Salve todos os resultados da triagem (históricos ou atuais) associados a um registro. Se nenhum módulo Triage for modificado desde a última execução, ele não precisará ser executado novamente em dados antigos.

O boato "você precisa saber o que deseja criar antes de fazer o TDD":

O Specify-Triage-Execute é uma maneira de manter os requisitos gerenciáveis ​​em cada nível e permite crescimento futuro.

(Se alguém souber os termos corretos padrão para essas três etapas, informe-me, editarei minhas respostas.)