Construindo algoritmos complexos com TDD

Estou tentando adotar o TDD na minha prática diária de programação. Uso-o no trabalho com muita eficiência, mas estou tendo problemas com meus projetos pessoais, onde estou usando alguns algoritmos complexos.

O algoritmo específico que me faz fazer essa pergunta é o Extended Kalman Filter. É complexo o suficiente para não estar confiante no código que escrevi, mas é simples o suficiente para dificultar a divisão.

Eu poderia escrever um teste para o algoritmo com uma entrada e a saída esperada, mas vou fazer muita codificação de espancamento e espingarda no meio, porque não tenho confiança nessas etapas intermediárias.

Se você trabalhou com algoritmos complexos razoáveis ​​e usa TDD, qual é a sua abordagem?

TDD não é um substituto para o design.

Este é um equívoco comum sobre o TDD, que você pode, de alguma forma, "desenvolver" um design coerente a partir do refator vermelho-verde. Você não pode. Seus testes ainda precisam ser guiados por suas habilidades de design.

Se você está tentando descobrir o que fazer entre a entrada e a saída do seu método em teste, provavelmente significa que você está tentando fazer muito em um único método. Pense no que essas etapas intermediárias devem fazer. Escreva testes para essas etapas intermediárias e escreva métodos que passam nesses testes.

Pode-se usar TDD para algoritmos complexos. Escreva muitos testes claros, porém significativos, e use-os para projetar seu programa. se houver randomização usada no algoritmo, use algum tipo de injeção de dependência e teste a randomização separadamente. TDD é um dos muitos métodos que você usará para escrever algoritmos de alta qualidade: outros são revisões de código, registro etc.

Eu poderia escrever um teste para o algoritmo com uma entrada e a saída esperada,

Não escreva teste "a". O TDD não escreve um teste de cada vez. Escreva vários testes primeiro que verifiquem vários limites e entradas padrão do algoritmo.

Eu sou novo no TDD (leia-se: provavelmente não estou fazendo certo), mas parece ser mais adequado para algoritmos de descrição fácil, quando você pode facilmente raciocinar sobre quais entradas correspondem a quais saídas.

Quando estou fazendo mais "ainda não sei qual será o resultado", o TDD não foi muito útil para mim. O que faço, em vez disso, uso afirmações de maneira muito liberal em pequenas porções que sei como funcionam até agora. Dessa forma, não fico preso ao tentar codificar para um alvo que não tenho certeza se o alvo é válido, mas recebo alguma proteção, localizando as áreas de dor em partes menores do código.

Uma vez que o algoritmo é resolvido quanto à correção (como em eu tenho certeza de pelo menos algumas entradas-> saídas para verificação de ponto), então eu volto e escrevo um teste. Então é muito mais seguro voltar e refatorar ou otimizar a velocidade ou o uso de recursos.

Eu diria que esse tipo de coisa é mais adequado para RDD: desenvolvimento orientado à leitura.

É aqui que você lê em um livro o algoritmo para algo complicado como um filtro Kalman e depois o converte em uma implementação no seu ambiente de destino.

A desvantagem é que fazer as coisas dessa maneira significa que você não obtém casos de teste gratuitamente como parte do processo de design. Por outro lado, algo conhecido como esse quase certamente tem uma implementação existente (por exemplo, Commons Math ). E é fácil usá-lo como um oráculo de teste para sua nova implementação; tudo o que você precisa se preocupar é que seu conjunto de casos de teste cubra todos os caminhos no seu código.