Melhores Práticas para Teste / TDD
14/08/2012 16:12
1
Boa tarde!

Estou desenvolvendo a parte de testes aqui e fiquei na dúvida: Qual é a melhor maneira para testes / TDD no Grails?

O que os testes unitários devem englobar? Eles não deveriam englobar chamadas externas como chamadas a serviços, correto? Eu devo mockar todas as chamadas externas?
O que os testes de integração e funcionais devem englobar?
Quais tipos de testes eu utilizo para Models, Services e Controllers?

Existe alguma ferramenta boa para os testes no geral? (alguma coisa no estilo Cucumber + Webrat do Rails)


Obrigado!
Tags: TDD, teste, testing, unit


1
Oi Mussatto,

o mais difícil na minha opinião é evitar que seus testes unitários se tornem integrados (aliás, sinceramente tenho cá minhas dúvidas (e muita gente além de mim) se isto é possível ou mesmo uma vantagem).

A idéia básica por trás dos testes unitários é você poder testar um componente do seu software de maneira isolada. Até ai, tudo bem: na teoria, nada pode dar errado, porque ao ajuntar uma série de componentes individualmente testados o todo deveria estar 100% ok. O problema é que quando lidamos por exemplo com manipulação e persistência de entidades no banco de dados, os testes unitários acabam se mostrando fracos, porque não vemos como é a coisa na prática: e é ai que a diferença entre testes unitários e integrados começa a ficar borrada.

Eu sou a favor da abordagem TDD, ou seja, de primeiro escrever os testes e depois o código: percebo nisto uma abordagem mais disciplinadora, porque minhas interfaces ficam melhor pensadas (normalmente, se é testável, é porque está boa). NO entanto, percebo que nem sempre é possível fazer isto, mais por problemas de disciplina minha do que por pressão de empresa, cliente ou algo assim. Mas me esforço o máximo possível para obter algo similar.

Como ferramentas legais, eu costumo usar o plugin "Code Coverage", que me diz qual a cobertura total dos meus testes. Com isto eu consigo detectar quais trechos do meu código foram afetados pelos testes ou não.

Outra ferramenta bacana, mas que nunca usei é o Spock: aliás, se alguém aqui já usou, seria bacana contar sua experiência.


0
Ae Kico,

Eu estava achando que meus testes unitários não tavam testando muita coisa, pelo menos é bom saber que é um problema comum hehe.
Muitos testes estavam mockando muita coisa (erro arquitetural meu também).

Já que caí nesse caso, acho que vou dar mais foco para os de integração.

Como você faz normalmente? Cria um bootstrap que e cria dados a partir de dados reais?
Eu tava pensando em utilizar o h2 / hsqldb pra dar uma velocidade.
E você costuma usar o Jenkins / Hudson?

Vou estudar o plugin, muito obrigado pela dica!
15/08/2012 12:18


1
Oi Mussatto,

depende do caso: muitas vezes o próprio teste cria os registros necessários pra mim. Como todo teste é envolvido em uma transação, acaba se tornando a opção mais cômoda na maior parte dos casos em que trabalho. Nestas situações, o que procuro seguir ao máximo é evitar escrever testes que dependam da presença ou não de determinado registro no banco de dados. Assim acabo criando, antes de testes, definições formais do código que estou escrevendo.

Jà trabalhei bastante com o Hudson: o Jenkins ainda não experimentei, mas pelo que sei a respeito, me parece ser a mesma coisa. Sobre usar outro banco de dados, dado que estou lidando com integração, faz mais sentido usar o banco de dados padrão mesmo, assim eu consigo detectar problemas do ambiente de produção mais sinistros antes que estes ocorram, o que seria mascarado usando algo como o h2 ou hsqldb.


0
Obrigado kico,

Legal, vou levar tudo isso que falou em consideração.
Tem algumas chamadas a WebServices e de sistemas externos que vou precisar mockar, pra testar o processo completo.
A parte que estou testando é justamente um integrador, e ta sendo uma tarefa bem dificil testar (porem estou aprendendo bastante)

Descobri que existe o Cucumber pro Grails tbm: http://grails.org/plugin/cucumber

Vou estudar ele, pra saber se está muito diferente do Rails.
15/08/2012 14:08


0
Alias, se tiver uma dica boa de como lidar com testes que dependem de WebServices e chamadas remotas, agradeço muito eheheh!

Valeu
15/08/2012 14:10


0
Pessoal, quando eu "mocko" outros componentes como coisas que envolvem requisições web(webservices, etc), Persistência e até mesmo Serviços que tem transações envolvendo mais de um domínio eu não estou criando um teste que na verdade não reflete a realidade ? pois mesmo que o teste falhe seria pela ausência de algo e não porque na verdade meu objeto sabe lidar com as situações advindas da falha no objeto "mockado" ?

Sendo assim as vezes, ou quase sempre seria bom ter testes unitários e até mesmo uma redundância com testes de integração em pontos críticos ?
15/08/2012 18:46


0
Sendo assim testes para Design Incremental e testes para testar mesmo rs
15/08/2012 18:47


0
Pra testar as chamadas externas, estou mockando para cada um dos casos que encontrei (sucesso, falha, negado), não é o ideal mas é o que posso... e está exigindo bastante colher dados e conhecer a regra de negócio (mais do que realmente programacao).

Vou fazer um teste programado depois (de integração, validação e de usuário) que façam chamadas reais, para não vazar nada.

Tentarei implementar com essa idéia de testes unitários + de integração, acho que uma mistura dos dois realmente vai cobrir muito mais o código.
17/08/2012 17:50


0
Incrementar os testes é uma coisa bem válida, mas acho que abre muito espaço para o desenvolvedor ficar com preguiça e pular essa parte ahhahahah.

Agora que comecei a usar de verdade os frameworks de teste, estou perdendo bem menos tempo para validar minha aplicação (bem menos lenga lenga de subir aplicacao)
17/08/2012 17:55



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto