Transcendendo Teste Unitário?

gistfile1.txt

É 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).

Não tem nenhum x++ nem y-- no código acima.

Consigo conceber unidades de código como um quicksort (talvez a galera do Haskell discorde) que precisam necessariamente de teste unitário. Mas quero propor q existem unidades, como a acima, q não precisam.

A unidade acima é útil? Precisa de testes >unitários< ou nao?

Se nao precisa, saberemos q não é 100% das unidades q precisam. Resta saber: qual a porcentagem q precisa? Mais de 50%? Menos? Qual sua opiniao?

Aos q forem argumentar no sentido de q o código acima precisa de teste >unitário<, postem aqui, por favor, o CÓDIGO de teste e digam no q exatamente ele ajuda.

Me parece que o fato de caberem ou não testes unitários não é o ponto, o ponto é se precisa ou não de TDD.

Como é que eu vou saber se essa é a implementação mais simples que resolve o problema sem ter os testes que levaram a esse código?

Como saber se uma implementação é a mais simples mesmo tendo os testes?

A questão não é se o código acima tem ou não x++ ou ++x. A questão é que não existe código simples demais que não mereça testes. Uma das poucas razões para não se realizar um teste é se o mesmo custa mais do que o valor que entrega--o que poderia, remotamente, ser o caso dos testes acima (novamente, eu advogaria o uso de testes de integração por motivos óbvios). Isso, por outro lado, não tem absolutamente nada a ver com transcender tests unitários. There ain't such a thing.

Como saber se uma implementação é a mais simples mesmo tendo os testes?

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.

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)