-
-
Save klauswuestefeld/1181000 to your computer and use it in GitHub Desktop.
| É bem útil conceituar forte e explicitamente a diferença entre Resolver/Eliminar um problema | |
| e Contornar/Gerenciar um problema. | |
| Exemplo de Problema: "Tá um inferno gerenciar os bugs do nosso sistema." | |
| Contornar/Gerenciar: "Vamos subir um bug tracking tipo Jira/BugZilla da vida!" | |
| Resolver/Eliminar: "Vamos melhorar a qualidade do código até reduzir em 98% o surgimento de | |
| bugs." | |
| Pensei nisso pq estou experimentando partir de um código praticamente intestável (uma engine | |
| de continuous deployment q depende de http, filesystem e execução de processos externos (o | |
| problema)) para um código tão simples (código das partes e código de cola extremamente | |
| simples (a solução)) que mal precisa ser testado, em vez de recorrer pesadamente a mocks e | |
| testes complexos (o contorno). |
kalecser, será q uma unidade só é válida quando ela é complicada o suficiente para justificar um teste unitário? Não estou falando de um código hipotético. Fiz a implementação do SaimployMainLoop e as classes q ela usa não jogam exception. Atualizei o código acima pq acabou até ficando mais simples.
rferraz, não realizar testes unitários pq entregam menos valor do q custam e usar apenas testes de integração, por definicao tem tudo a ver com transcender testes unitários.
Eu acho que você está confundindo o significado da palavra transcender. A mesma implica na existência de conhecimento o bastante para dizer que os testes não são necessários porque você pode afirmar absolutamente que não há bugs no mesmo. A própria necessidade de testes invalida isso. Como eu disse anteriormente, o fato de que a melhor maneira de testar certo código é através do uso de testes de integração não implica transcendência.
Continuando a mesma discussão: https://gist.github.com/1215891
(rferraz, deletei meu ultimo draft de post, q ficava acima. mova essa sua resposta pra nova discussao, revisando-a, por favor)
Simplificando a implementação (se possível) e rodando os testes pra ver se eles continuam atendendo o requisito. Claro que isso só vale pra TDD.
Eu não consigo visualizar a classe SimployMainLoop como uma entidade isolada do sistema, ela depende de que os métodos da classe Worker não lancem exceptions por exemplo, usando TDD isso implica pelo menos um teste do tipo onServerNotAvailable_SimployWillContinueToRun. Pode ser que olhando esse teste fique claro que é mais simples deixar os métodos da classe worker jogarem Exceptions e tratar na SimployMainLoop.