Veja também a tentativa de Ron Jeffries de criar um solucionador de Sudoku com TDD , que infelizmente não funcionou.
O algoritmo requer uma compreensão significativa dos princípios de design do algoritmo. Com esses princípios, é realmente possível proceder de forma incremental, com um plano, como Peter Norvig fez .
De fato, para algoritmos que exigem esforço de design não trivial, é quase sempre que o esforço é de natureza incremental. Mas cada "incremento", que é minúsculo aos olhos de um projetista de algoritmos, parece um salto quântico (emprestando sua frase) para uma pessoa que não teve o mesmo conhecimento ou experiência com essa família de algoritmos em particular.
É por isso que uma educação básica em teoria de CS combinada com muita prática de programação de algoritmos é igualmente importante. Saber que uma "técnica" específica (pequenos blocos de construção de algoritmos) existe é um longo caminho para dar esses saltos quânticos incrementais.
Existem algumas diferenças importantes entre o progresso incremental nos algoritmos e no TDD.
Uma das diferenças foi mencionada por JeffO : Um teste que verifica a exatidão dos dados de saída é separado de um teste que afirma o desempenho entre diferentes implementações do mesmo algoritmo (ou diferentes algoritmos que tentam fornecer a mesma solução).
No TDD, adiciona-se um novo requisito na forma de um teste, e esse teste inicialmente não deve passar (vermelho). Então o requisito é satisfeito (verde). Finalmente, o código é refatorado.
No desenvolvimento de algoritmos, o requisito geralmente não muda. O teste de verificação da correção dos resultados é gravado primeiro ou logo após a conclusão de uma implementação preliminar (altamente confiável, mas lenta) do algoritmo. Esse teste de correção de dados raramente é alterado; não se muda para falhar (vermelho) como parte do ritual TDD.
Entretanto, nesse aspecto, a análise de dados é distintamente diferente do desenvolvimento de algoritmos, porque os requisitos de análise de dados (os conjuntos de entradas e os resultados esperados) são definidos apenas de maneira vaga na compreensão humana. Assim, os requisitos mudam frequentemente em nível técnico. Essa mudança rápida coloca a análise de dados em algum lugar entre o desenvolvimento de algoritmos e o desenvolvimento geral de aplicativos de software - embora ainda sejam pesados, os requisitos também estão mudando "muito rápido" ao gosto de qualquer programador.
Se o requisito for alterado, normalmente será necessário um algoritmo diferente.
No desenvolvimento de algoritmos, alterar (restringir) o teste de comparação de desempenho para falhar (vermelho) é tolo - ele não fornece nenhuma visão sobre possíveis alterações em seu algoritmo que melhorariam o desempenho.
Portanto, no desenvolvimento de algoritmos, o teste de correção e o desempenho não são testes de TDD. Em vez disso, ambos são testes de regressão . Especificamente, o teste de regressão da correção impede que você faça alterações no algoritmo que quebrará sua correção; o teste de desempenho impede que você faça alterações no algoritmo que o tornará mais lento.
Você ainda pode incorporar o TDD como um estilo de trabalho pessoal, exceto que o ritual "vermelho - verde - refator" não é estritamente necessário nem particularmente benéfico ao processo de pensamento do desenvolvimento de algoritmos.
Eu argumentaria que as melhorias do algoritmo realmente resultam em fazer permutações aleatórias (não necessárias) para os diagramas de fluxo de dados do algoritmo atual, ou misturá-las e combiná-las entre implementações conhecidas anteriormente.
O TDD é usado quando há vários requisitos que podem ser adicionados gradualmente ao seu conjunto de testes.
Como alternativa, se seu algoritmo for orientado por dados, cada parte dos dados / caso de teste poderá ser adicionada de forma incremental. TDD também seria útil. Por esse motivo, uma abordagem "do tipo TDD" de "adicionar novos dados de teste - melhorar o código para manipulá-los corretamente - refatorar" também funcionará no trabalho de análise de dados em aberto, no qual os objetivos dos algoritmos são descritos em humanos. palavras centradas e sua medida de sucesso também julgadas em termos humanos definidos.
Pretende ensinar uma maneira de torná-lo menos irresistível do que tentar satisfazer todos (dezenas ou centenas) de requisitos em uma única tentativa. Em outras palavras, o TDD é ativado quando você pode determinar que determinados requisitos ou metas de expansão podem ser temporariamente ignorados enquanto você implementa alguns rascunhos iniciais da sua solução.
TDD não é um substituto para a ciência da computação. É uma muleta psicológica que ajuda os programadores a superar o choque de ter que atender a muitos requisitos ao mesmo tempo.
Mas se você já possui uma implementação que fornece o resultado correto, o TDD consideraria seu objetivo cumprido e o código pronto para ser entregue (para refatoração ou para outro usuário-programador). Em certo sentido, incentiva você a não otimizar prematuramente seu código, objetivamente, sinalizando que o código é "bom o suficiente" (para passar em todos os testes de correção).
No TDD, há um foco em "micro-requisitos" (ou qualidades ocultas) também. Por exemplo, validações de parâmetros, asserções, lançamento e manipulação de exceções, etc. O TDD ajuda a garantir a correção dos caminhos de execução que não são freqüentemente exercidos no curso normal da execução do software.
Certos tipos de código de algoritmo também contêm essas coisas; estes são passíveis de TDD. Mas como o fluxo de trabalho geral do algoritmo não é TDD, esses testes (em validações de parâmetros, asserções e lançamento e manipulação de exceções) tendem a ser gravados depois que o código de implementação já foi (pelo menos parcialmente) gravado.