[quote=YvGa][quote=javaflex][quote=AbelBueno]Ah, agora sim você apresentou seus motivos.
Primeiro uma observação: eu nunca sei qual a definição sendo usada para teste unitário, teste de integração ou teste funcional.
Pela sua descrição eu concluo que unitário é level de classe ou método isolado, funcional é usando o sistema com um agente externo (tipo Selenium) e integração não ficou claro. É isso?
Segundo, outra observação: eu li esse post quando foi lançado, mas agora que o Yvga reviveu com essa nova polêmica, não voltei pra ler tudo novamente. Conclusão: tudo que eu disser pode já ter sido dito.
Eu concordo com a importância dos testes funcionais, mas vejo dois problemas neles: eles são lentos e testam muita coisa de uma só vez.
Pra ter uma ampla cobertura de teste, sua suite inteira demora muito pra rodar (imaginar testar que cada validação javascript foi disparada, cada dado inválido filtrado, etc). E o pior, na minha opinião, quando um teste quebra você não consegue apontar imediatamente o que quebrou: pode ter sido o banco de dados fora do ar, o servidor de aplicação fora do ar, um erro de javascript, uma constraint no banco, um if errado no código backend, um timeout porque a página demorou um pouco mais pra carregar…enfim, para descobrir porque quebrou você gasta um enorme tempo investigando (isso quando não são testes que as vezes passam as vezes falham).
Eu gosto de testes unitários/isolados justamente para evitar esse tipo de coisa. Quando um teste unitário quebra, ele me diz exatamente em que ponto do código está o problema. E sendo rápido, eu posso rodar a cada alteração que faço no código.
Você pode acabar tendo certa redundância entre os funcionais e os unitários, mas eu ainda acredito que valha a pena, justamente pelo feedback rápido que temos do teste unitário.[/quote]
Você pode rodar vários testes funcionais em paralelo com selenium grid. Mesmo assim concordo que os unitários são infinitamente mais rápidos, só que independente de ser rápido não me dá uma garantia razoável para por em produção, que é o que me importa, pelos n motivos que comentei, já o dia a dia de desenvolvimento flui naturalmente, onde não existe “problema” para motivar automatizar um “policiamento do desenvolvimento durante o dia todo do que não é para liberar para produção ainda”, as vezes os problemas são outros como saoj já falava antes de todos nós aqui lá em 2012.
Sobre achar difícil detectar o problema, não é bem assim não saber imediatamente onde quebrou. Por exemplo supondo que teste funcional “Gravar Pedido” retornou “ORA-01722: invalid number”, o erro vai ser pontual na maioria dos casos. Resolvendo naturalmente como qualquer erro que pegamos, executando em debug e quando der erro vai parar e resolvemos pontualmente, não tem nada de ruim nisso, o importante é que o teste detectou que houve tela impactada e qual foi o erro para poder resolver em tempo de desenvolvimento tranquilamente, não sendo pego de surpreso em produção por algo místico que os testes unitários podem não pegar.
Sobre definição de cada tipo de teste, também me confundo e nem ligo pra isso, importante é a prática, só sei que uso “o que simula o uso real do usuário”, que muitos podem chamar também de teste de integração. Mas o “integrado” que eu me referia no post anterior não era o “funcional”, era um nível a mais que o unitário, ao invés de testar um método isolado com código fake, chamar um método real, que pode chamar outro com dependências, como por exemplo testar começando da controller até chegar à persistência.[/quote]
O importante, como diz o Kent Beck na discussão é sentir confiança no código que você escreve. Se você atingiu isso, independente da forma que for, e essa confiança se reflete efetivamente na qualidade do código que você põe em produção então você está fazendo certo, seja lá a técnica que usa.
Eu, particularmente, gosto muito do TDD, como eu nunca gostei dos mocks, o próprio TDD me forçou melhorar as responsabilidades do meu código antes de conseguir testar, eu testo regra. Se chega x tem que sair y, não me importa de onde vem x, nem pra onde vai y.
Quanto ao Selenium eu não consegui me adaptar, achei muito complexo e no final você acaba testando poucos cenários. Talvez seja um problema meu de não ter achado o jeito certo de usar a ferramenta, mas não consegui me acertar com ele ainda.[/quote]
Exatamente, confiança no código, entrosamento do time e buscar parceria com o cliente. É por ai mesmo o melhor caminho para não precisar que as “siglas” resolvam os problemas.
Regra testo no Selenium mesmo, o teste executa as entradas inválidas e espera que a mensagem de validação seja exibida na tela, e depois executa as entradas válidas esperando a gravação retornar sucesso. Sei que TDD o propósito é outro, de já começar testando o que está fazendo imediatamente, mas exatamente isso que acho desmotivante. A empolgação pra começar a criar a tela de fato e ir conversando com o cliente mostrando prévias acaba compensando as vantagens vendidas pelo TDD. É muito complexo sim chegar numa infraestrutura para teste via selenium webdriver que facilite as coisas para a equipe, é um grande investimento que depois traz lucros, o importante é ir atacando aos poucos cada tipo de funcionalidade.