Deixe-me começar por agradecer-lhe para compartilhar sua experiência e expressar suas preocupações ... o que eu tenho a dizer não é incomum.
- Tempo / Produtividade: Escrever testes é mais lento do que não escrever testes. Se você fizer isso, eu concordaria. No entanto, se você executar um esforço paralelo no qual aplique uma abordagem não-TDD, é provável que o tempo que você gasta o código existente de detecção e depuração de detecção de interrupção o colocará na rede negativa. Para mim, o TDD é o mais rápido possível sem comprometer minha confiança no código. Se você encontrar coisas no seu método, que não estão adicionando valor, elimine-as.
- Número de testes: se você codificar N coisas, precisará testar N coisas. Parafraseando uma das linhas de Kent Beck " Teste somente se você quiser que ele funcione. "
- Ficando preso por horas: eu também (às vezes, não > 20 minutos antes de parar a linha) .. É apenas o seu código dizendo que o projeto precisa de algum trabalho. Um teste é apenas outro cliente para sua classe SUT. Se um teste está achando difícil usar seu tipo, as chances são tão grandes para seus clientes de produção.
- Tédio de testes semelhantes: Isso requer um pouco mais de contexto para eu escrever um contra-argumento. Dito isto, pare e pense sobre a semelhança. Você pode conduzir esses testes de alguma forma? É possível escrever testes em um tipo base? Então você só precisa executar o mesmo conjunto de testes contra cada derivação. Ouça seus testes. Seja o tipo certo de preguiça e veja se você consegue descobrir uma maneira de evitar o tédio.
- Parar para pensar sobre o que você precisa fazer em seguida (o teste / especificação) não é uma coisa ruim. Pelo contrário, é recomendado que você construa "a coisa certa". Normalmente, se não consigo pensar em como testá-lo, geralmente não consigo pensar na implementação. É uma boa ideia apagar as ideias de implementação até chegar lá .. talvez uma solução mais simples seja ofuscada por um design preventivo YAGNI-ish.
E isso me leva à consulta final: como melhorar? Minha (ou An) resposta é Ler, Refletir e Praticar.
por exemplo. Ultimamente, fico de olho em
- se meu ritmo reflete RG [Ref] RG [Ref] RG [Ref] ou é RRRRGRRef.
- % de tempo gasto no estado Red / Compile Error.
- Eu estou preso em um estado vermelho / quebrado?