Transcendento Testes Unitários II

We couldn’t find any files to show.

Penso da mesma forma.. inclusive escrevi sobre isso também: http://www.loogica.net/blog/2010/09/21/testes-nao-obrigado/

Oi Klaus,

Chegando um pouco atrasado na discussão, mas vamos lá. Acho que temos que testar 100% do que escrevemos, mas precisamos sempre lembrar que testes de unidade não é o único nível de teste -- temos vários outros e devemos usar o que fizer mais sentido.

No código que você escreveu acima, também acho que testes de unidade não fazem sentido. Mas não pq esse código é simples; mas sim pq esse código simplesmente "controla" o fluxo das coisas. Ele não contém regras de negócio ou coisa do tipo. Um exemplo mais natural para a maioria dos desenvolvedores é justamente o código de um "controller" bem escrito. Ele basicamente invoca coisas em uma ordem determinada.

Se eu fizer um teste de unidade pra esses caras, no fim, vou testar se os métodos foram invocados na ordem que eu preciso. Não sei se vale a pena gastar tempo escrevendo isso (e é chato, pq é basicamente trabalhar com mocks). Acredito que um teste de integração/sistema me traria mais feedback sobre a qualidade do mesmo.

Agora, com certeza tuas classes Deployer e Trigger contém regras de negócio e a meu ver, muito provavelmente, deverão ser testadas de maneira isolada.

O que acha?

É tudo sobre contratos. Sua classe SimployMainLoop depende das implementações de Trigger e Deployer? Então por que as interfaces?

class FailTrigger implements Trigger {
    public void waitFor() {
        try {
            Thread.sleep(1 << 30);
        } catch (InterruptedException e) {
        }
    }
}

class FailDeployer implements Deployer {
    public void deployNewBuild() {
        throw new RuntimeException("gotta catch'em all");   
    }
}

Aliás, @felipecruz, acho que o @klauswuestefeld não quis dizer o que você escreveu no seu post:

"construir um sistema de informação com pouca lógica de negócio usando TDD não funciona"

eu vejo como uma critica ao 'over-testing'

e realmente.. TDD em um sistema basicamente de CRUD, nao faz sentido..

ps: editei um erro de port :)

Pelo que entendi, ele disse que podem existir partes de um sistema que não precisam de testes unitários.

Não disse que sistemas inteiros não precisam de testes unitários, nem que existem partes de sistema que não precisam de teste nenhum.

se vc faz um sistema de catalogo de filmes, apenas um catalogo, qual o sentido testar alguma coisa?

testar se o model, entity o que quer que seja é salvo no banco pelo ORM? testar se uma query "all" vem como todos os resultados?

se a unica regra de negocio de um catalogo é cadastrar, buscar, listar, editar e apagar, o que precisa ser testado?

existem trechos de codigo que nao precisam de testes.. assim como podem existir sistemas mais simples que nao precisam de testes.. Qual o sentido de tesdtar se o save do JPA ou do django realmente cria uma linha no banco? ele ja nao foi testado pelo proprio ORM?

e repara que ele ta falando de testes unitarios..

@juanlopes

queria saber de onde no blog voce tirou que eu disse isso

"Não disse que sistemas inteiros não precisam de testes unitários, nem que existem partes de sistema que não precisam de teste nenhum."

Agora, com certeza tuas classes Deployer e Trigger contém regras de negócio e a
meu ver, muito provavelmente, deverão ser testadas de maneira isolada. O que acha?

Hoje ainda faço testes unitários para muitas unidades, mas me pergunto se não faltou simplificá-las mais, a ponto da maioria das unidades não precisar mais de teste...

@juanlopes - Não entendi sua pergunta.

@klauswuestefeld
Nesse caso acho que dá mesmo pra ficar sem testes.... mas... sempre o mas.... mas deployer.deployGoodBuild(), trigger.waitFor() e deployer.deployNewBuild() devem ter sidos testados em algum lugar.

Eu tenho uma situação que imagino ser similar ao que você descreve:

    public List<?> list(HttpServletRequest request) {
        return list( FilterFactory.newFilter( GivenSituationFilter.class, request ) );
    }

    protected List<?> list(GivenSituationFilter filter) {
        //logica de vedade
    }

Temos testes para o FilterFactory.newFilter() e testes para o list(GivenSituationFilter) protected. Agora o list(HttpServletRequest) public ficou sem testes.

(2 anos atrasado, kkkkk)