O código provavelmente não está certo.
No entanto, isso pode não importar.
Rápido e sujo pode ser o caminho certo para ir em situações onde:
- O código tem um tempo de vida curto . Por exemplo, você está transformando vários dados em um formato padrão com um programa ad-hoc.
-
O impacto negativo da falha é baixo :
- Os dados que você está transformando não são críticos e os erros podem ser facilmente corrigidos
- O usuário final é um programador compreensivo, que raciocina sobre mensagens de erro e trabalha em torno delas, digamos, massageando a entrada.
Às vezes, não é importante que o código seja robusto e lide com todas as entradas concebíveis. Às vezes, só precisa lidar com os dados conhecidos que você tem à mão.
Nessa situação, se os testes de unidade ajudarem você a escrever o código mais rápido (esse é o caso para mim), use-os. Caso contrário, código rápido e sujo, faça o trabalho. Bugs que não são acionados não importam. Bugs que você conserta ou trabalha ao redor não importa.
O que é absolutamente vital é que você não diagnostique mal essas situações. Se você codificar rápido e sujo, porque o código só vai ser usado uma vez, então alguém decide reutilizar o código em algum projeto que merece um código melhor, esse código merecia mais cuidado.