GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Cadê os testes?


#81

Exatamente o que eu penso, só que muita gente acha que o problema está no TDD e não em seus fracos conhecimentos sobre OO. E muita gente mesmo, inclusive muita gente a favor da técnica.


#82

E a discussão continua, agora é a vez de David Heinemeier Hansson se rebelar contra o TDD.

Simplesmente o criador do Ruby on Rails.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Isso gerou uma série de discussões bastante interessantes em vídeo com o criador da técnica Kent Beck e um dos evangelizadores, Martin Fowler.

http://martinfowler.com/articles/is-tdd-dead/

Curiosamente, ambos colocam um ponto discutido nesse tópico. Raramente usam mocks e "sugerem" que o uso excessivo deles indica um problema de design.

Excelente a discussão, muito dos pontos colocados pelo Heinemeier Hansson já foram apontados aqui pelo saoj.


#83

Em relação a sistemas de informação o mais importante é automatizar os testes no nível mais alto, o funcional, usando Selenium por exemplo para o caso de aplicações web, o resto é querer brincar de TI.


#84

algumas pessoas que acham justamente o contrário: quanto menos teste de UI, melhor.

Gostaria de ler suas razões para chegar a conclusão que teste unitário é brincadeira.


#85

Vai dizer que você também não gosta de encerrar suas discussões com frases de impacto?


#86

Haha.. Tem uma galera que adora dar resposta de uma linha como se tivesse falando a verdade absoluta, sem justificações.

Geralmente ignoro respostas de usuários assim, mas geralmente não é o caso do javaflex.

Por isso achei que valia a pena discutir isso.


#87

Pelos testes funcionais cobrirem o que preciso. Normalmente saber diariamente se o sistema continua funcionando de verdade, e não um método ou sequência de métodos que não garantem se o que o usuário vai usar de fato funciona. O resto o time sempre se fala e se entende, o importante é não por em produção com problema. Pra mim o teste tem que abranger desde a digitação até o retorno do que foi gravado no banco está conforme o digitado originalmente. Nada adianta testes unitários ou integrados se algo no meio do caminho falhar por algum motivo, como por exemplo uma mensagem de validação não aparecer pro usuário conforme o esperado, por erro no javascript, ai você vai ter que fazer teste unitário do javascript também... Outro exemplo, o usuário não conseguir enviar o formulário para gravar o registro porque a nova versão do browser quebrou a versão do jquery usada. Então, quero testar o sistema de fato para o usuário seja lá o que tiver no meio do caminho. Já para quem produz bibliotecas para uso externo é super válido testes unitários, um projeto como o Hibernate por exemplo tem que ter. Eu já cheguei a fazer unitários, até que os funcionais evoluíram a ponto de não fazer sentido o unitário. Mas tudo bem se é válido para você e a maioria, pode ser que você passe por situações que precise do unitário, mas pra mim achei inútil.

TDD então nem se fala, eu parto do princípio de não lidar com problemas que não existem, senão é criado um obstáculo sem necessidade.


#88

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.


#89

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.


#90

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.


#91

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.


#92