Estratégia de Testes

6 respostas
J

Galera,

Dei uma procurada no google e aqui no guj e não consegui achar nenhum post referente a isso, então segue a minha dúvida.

Aqui na empresa que eu entrei, temos um sistema que é dividido em campanhas. As campanhas tem mecanismos básicos que são padrões, mas toda vez que o cliente quer uma campanha nova, ele passa um monte de solicitações novas que mexem com esses mecanismos. =)

E do jeito que foi arquitetado aqui, todas as campanhas utilizam as mesmas classes para funcionar. Ou seja, a mesma classe tem que atender campanhas diferentes. Sim eu sei, não é o melhor cenário, mas aqui está assim. Estamos planejando refatorar…mas até lá, precisamos garantir que a arquitetura atenda a todas as campanhas.

E não temos testes para nada disso! (Que bom não?!)

E estamos querendo implementar testes, para garantir que qualquer mudança que nós iremos fazer, não acabe com a funcionalidade de uma campanha antiga.

Mas existem várias classes, e estavámos discutindo aqui como poderíamos implementar esses testes. Ainda não chegamos a um consenso, mas por enquanto tende a ser JUnit + DBUnit. Só que começaríamos de cima pra baixo, ou seja, com testes de sistema primeiro para garantir o correto funcionamento das campanhas. E quando algum desses testes falhassem, descobriríamos o erro e criaríamos o teste unitário do método que deu o erro e assim, aos poucos, teríamos todos os métodos sendo testados.

Só que ainda não estou confortável com essa solução, alguém já passou por algo parecido? Alguém tem idéias melhores de implementar isso?

6 Respostas

J

Ninguém?

renanpto

Como o projeto é usado em várias campanhas, talvez uma estratégia seria dividir o projeto em módulos e add o Maven para cuidar da gerencia de dependencias.

Havendo a necessidade de criar uma nova campanha, bastaria selecionar quais serão os modulos irão compor a campanha e configurar as dependencias no Maven.

Com o projeto dividido em modulo, voces estariam livres para decidir qual será o melhor caminho a iniciar com os testes (por modulo, modulos principais pro negócio, etc).

Caso seja um sistema web, uma boa dica é criar testes funcionais com o SeleniumHQ. Eles vão ajudar a avaliar se a funcionalidade ainda/estão funcionando.

J

Sim! A idéia de refatorar é essa, ter uma arquitetura flexível em que possamos ter um padrão e seja fácil de personalizar as novas campanhas. Algo como uma classe Campanha abstract e as novas campanhas herdam dela, e sobreescrevem os métodos que forem diferentes.

A arquitetura aqui hoje, é meio engessada, a mesma classe Campanha atende n Campanhas. Então tem vários ifs dentro do código para atender a todo mundo. E o nosso primeiro problema, é garantir que essa arquitetura engessada, esteja funcionando para as campanhas antigas e para as novas, enquanto nós não pudermos refatorar.

E para isso, queríamos fazer um plano de testes rápido e que atendesse logo. Se fomos fazer todos os testes de unidade necessários levaria tempo demais, até ter um resultado satisfatório.

Vi nesse link que tem um pessoal que usa o Príncipio de Pareto. Que em 20% do código, é gerado 80% dos Bugs, e eles tem essa estatística através do histórico dos bugs. Então eles focam os testes nesse 20% do código, para depois testar o resto. Achei uma idéia interessante, alguém tem outra?

gomesrod

Realmente escrever testes unitários para todo um sistema que já está funcionando é loucura.
Você pode até conseguir 100% de cobertura, mas mesmo assim não terá bons testes - pois a equipe com certeza não estará com a mesma “cabeça” de quando desenvolveu, por dentro de todos os detalhes e necessidades.

Dentro desse cenário, a estratégia de concentrar-se nos testes de funcionalidade ainda será a melhor apesar de não ser perfeita.
Procure automatizar o que for possível: geraçao de massa de dados, algumas rotinas de navegação com Selenium, etc.

E daqui para frente, Testes Unitários para tudo que for feito! Inclusive para as correções de bug, como vc mesmo mencionou.

J

gomesrod:
Realmente escrever testes unitários para todo um sistema que já está funcionando é loucura.
Você pode até conseguir 100% de cobertura, mas mesmo assim não terá bons testes - pois a equipe com certeza não estará com a mesma “cabeça” de quando desenvolveu, por dentro de todos os detalhes e necessidades.

Dentro desse cenário, a estratégia de concentrar-se nos testes de funcionalidade ainda será a melhor apesar de não ser perfeita.
Procure automatizar o que for possível: geraçao de massa de dados, algumas rotinas de navegação com Selenium, etc.

E daqui para frente, Testes Unitários para tudo que for feito! Inclusive para as correções de bug, como vc mesmo mencionou.

Valeu pela ajuda. Acho que iremos nos concentrar mais nesse princípio de Pareto

A

gomesrod:
Realmente escrever testes unitários para todo um sistema que já está funcionando é loucura.
Você pode até conseguir 100% de cobertura, mas mesmo assim não terá bons testes - pois a equipe com certeza não estará com a mesma “cabeça” de quando desenvolveu, por dentro de todos os detalhes e necessidades.

Dentro desse cenário, a estratégia de concentrar-se nos testes de funcionalidade ainda será a melhor apesar de não ser perfeita.
Procure automatizar o que for possível: geraçao de massa de dados, algumas rotinas de navegação com Selenium, etc.

E daqui para frente, Testes Unitários para tudo que for feito! Inclusive para as correções de bug, como vc mesmo mencionou.

Concordo.

Gomesrod, talvez eu já tenha lhe perguntado mas, como é que você faz para realizar testes a partir de massa de dados (excel?)?

Criado 25 de maio de 2011
Ultima resposta 26 de mai. de 2011
Respostas 6
Participantes 4