Tenho uma discussão interna aqui no meu trabalho e gostaria de compartilhar ela com vocês:
Seria interessante rodar os testes de aceitação antes de gerar cada build em um cenário de integração/deploy contínuo?
Ao meu ver não, dado que a execução desse tipo de testes é muito lenta, e junta ao fato de que, eu percebo que nem sempre um erro no teste de aceitação está ligado a um erro da aplicação, por exemplo, o JSF (no meu caso), demorou pra renderizar um elemento e o teste de aceitação não conseguiu encontrá-lo. Tudo isso somado, faz com que a execução desses testes antes de cada build fique caro demais, demorando execivamente a publicação da aplicação e consequentemente o feedback.
Com testes unitários bem feitos, testando tanto o código da camada de visão, quanto regras de negócio e tudo mais, já dá uma segurança boa para liberar esse build para ser publicado né?
Queria saber a opinião de vocês. O que costumam praticar nos projetos que vocês participam? Existe esse tipo de teste automático? Eles são executados antes de cada build? Executados esporaticamente?
Amigão, concordo com você. Passei por isso diversas vezes na entrega de meu ultimo projeto aqui na empresa.
Fazer os testes de aceitação “antes do deploy” no servidor do cliente por exemplo, é meio que perca de tempo. Pois aqui mesmo, quando faziamos o deploy no nosso servidor, era tudo 1000 maravilhas, e quando chegava no cliente, vixi maria, tudo quebrado. Daí, começamos a implementar uma rotina de testes mais garantida aqui na empresa, e os testes finais eram feitos diretamente no servidor do cliente, dando assim a certeza que no dia de apresentação do sistema, nada iria quebrar !
Com certeza é sempre bom utilizar o cenario mais real possivel, mas, depois dessa lição vou sempre estar fazendo essa nova prática.
Testes de aceitacao != Testes da interface com o usuario.
Sempre eh possivel fazer seus testes rodarem mais rapido. Voce pode:
2.1. Comecar por optimizar sua aplicacao.
2.2. Rodar testes em paralelo.
2.3. Rodar testes totalmente em memoria (sem bd, sem browser rodando)
2.4. Quebrar a suite de testes em grupos de prioridade e comecar sempre pelos mais criticos primeiro.
[quote=darksteel3000]Amigão, concordo com você. Passei por isso diversas vezes na entrega de meu ultimo projeto aqui na empresa.
Fazer os testes de aceitação “antes do deploy” no servidor do cliente por exemplo, é meio que perca de tempo. Pois aqui mesmo, quando faziamos o deploy no nosso servidor, era tudo 1000 maravilhas, e quando chegava no cliente, vixi maria, tudo quebrado. Daí, começamos a implementar uma rotina de testes mais garantida aqui na empresa, e os testes finais eram feitos diretamente no servidor do cliente, dando assim a certeza que no dia de apresentação do sistema, nada iria quebrar !
Com certeza é sempre bom utilizar o cenario mais real possivel, mas, depois dessa lição vou sempre estar fazendo essa nova prática.[/quote]
A situacao que voce descreve me parece mais um problema de configuracao do que em testes em si. Para se ter confianca nos testes, o ideal eh conseguir um ambiente identico ao de producao, com exatamente a mesma coisa rodando nos servidores. Por isso que nos meus projetos usamos o conceito de “mirror of production” e automacao de configuracao dos servidores (usando puppet/chef), para garantir que o sistema funcionara exatamente igual hardware de producao. Alem disso essa eh a unica maneira de se testar e garantir capacidade e performance de um sistema antes de sua entrega.
Havia alguma razao para tamanha diferenca entre o seu servidor e o do cliente?
Testes de aceitacao != Testes da interface com o usuario.
Sempre eh possivel fazer seus testes rodarem mais rapido. Voce pode:
2.1. Comecar por optimizar sua aplicacao.
2.2. Rodar testes em paralelo.
2.3. Rodar testes totalmente em memoria (sem bd, sem browser rodando)
2.4. Quebrar a suite de testes em grupos de prioridade e comecar sempre pelos mais criticos primeiro.[/quote]
Você tem razão, estou falando de teste de interface com o usuário.
Mas uma coisa que me dá muita dor de cabeça, são esses erros que acontecem durante o teste ex: ids que o JSF dá para os elementos html que são renderizados.
Quanto ao bd, o que vc recomendaria pra rodar os testes totalmente em memória? Usar um bd não relacional?
Nos projetos em que você trabalha, vocês rodam esses testes antes de cada build?
Nunca trabalhei com JSF, entao nao sei se eh possivel gerar HTML com id/classes pre-definidos. Na minha experiencia ter que referenciar elementos no DOM usando xpath, por exemplo, eh receita para dor de cabeca.
Se seu uso de banco de dados for trivial, pode tentar usar algo como hsqldb. Caso contrario, pode criar implementacoes “in-memory” para seus Repositorios/DAOs e usa-las para testes. Aconselho neste caso a tambem criar testes de integracao (usando BD) para garantir que os contratos dessas classes sao implementados corretamente.
Sim. Porem nossos testes de interface sao minimos, ja que a grande maioria dos nossos testes de aceitacao abstraem a interface com o usuario e se concentram nas regras de negocio.
!