Um novo projeto que iniciamos introduziu muitas novas tecnologias com as quais não estávamos familiarizados e uma arquitetura na qual não temos muita prática. Em outras palavras, as interfaces e interações entre classes de serviço etc. Re construção são bastante voláteis, ainda mais devido ao feedback interno e do cliente. Embora eu sempre tenha me frustrado com as especificações sempre em movimento, vejo que isso é, até certo ponto, parte necessária da construção de algo que nunca construímos antes - se ficássemos presos ao design e ao escopo originais, o produto final provavelmente seria muito menos inovador e útil do que está se tornando.

Também introduzi o desenvolvimento orientado a testes (TDD), já que os benefícios são bem documentados e conceitualmente, eu adorei a ideia. Mais duas coisas novas para aprender - NUnit e zombaria -, mas ver todos esses círculos verdes fez tudo valer a pena.

Com o tempo, no entanto, essas mudanças constantes no design pareciam significar que eu estava passando muito mais tempo mudando meus testes do que escrevendo o próprio código. Só por esse motivo, voltei às antigas formas de teste - isto é, não automatizadas.

Embora não tenha dúvidas de que o aplicativo seria muito mais robusto com centenas de excelentes testes unitários, descobri que o tempo de lançamento do produto é inaceitável. Minha pergunta é, então - algum de vocês também descobriu que o TDD pode ser um incômodo se você está fazendo protótipos de algo / construindo uma versão beta? O TDD vai muito mais naturalmente de mãos dadas com algo em que as especificações são mais fixas ou onde os desenvolvedores têm mais experiência na linguagem e nas tecnologias? Ou fiz algo fundamentalmente errado?

Note que não estou tentando criticar o TDD aqui - só que não tenho certeza se é sempre o melhor ajuste para todas as situações.