| Autor |
Mensagem |
|
|
YvGa wrote:
Entao, eu acho que eh justamente ai que esta o problema do mock. Quando o acoplamento eh alto o uso de mock eh bem mais frequente, o que torna os testes dificeis e chatos.
O problema eh que eh dificil reconhecer o problema no meu codigo e bem mais facil dizer que teste eh perda de tempo.
Então.. bacana o seu pensamento.. mas em minha opinião isso não é culpa do mock.. mas sim do seu objeto.
Se vc está tendo q mocar muita coisa, entra no q vc disse.. está com acoplamento muito alto...
Só discordo com vc qndo vc diz q é dificil reconhecer o problema... em minha opinião não é...
aliás, o problema está mto bem descrito no setUp inicial dos seus testes
Testes unitários deveriam ser fáceis e divertidos de se fazer... se no setUp inicial dos seus testes vc esta tendo q mocar muita coisa, recebendo muitas dependencias no constructor do seu objeto, isso pode ser sinal de q vc nao esteja seguindo o SRP e SoC
Bom, mais um vez... teste unitário te ajudando no seu design
Mas como eu disse, a culpa não é do mock... ele é apenas um facilitador.... resta agora nós sabermos utilizá-lo corretamente
|
 |
|
|
O que me deixa mais feliz nessa discussão é que em um fato todos nós concordamos... Temos SIM que automatizar os testes!
Uma das vantagens que eu vejo nos testes unitários que eu não vi nas discussões propostas pelos Bill, é que eles ajudam e muito no design da sua aplicação..
Principalmente quando falamos sobre baixo acoplamento (entre classes e até com o proprio framework)!
Com testes unitários, temos a tendência sempre em pensar nas classes usando muito de IoC, especialmente injeção de dependência... resultando em classes com pouca responsabilidade (SRP) e bem coesas (SoC)
Pensamos assim, pois se nao fizer dessa forma, vc não será capaz de testá-la! simples! (A não ser que vc tenha um container para te prover essas dependencias)
Outra vantagem é que hj em dia é mto mais facil vc fazer testes unitários do q de integração.... talvez algum dia, com as facilidades que ferramentas como o Arquillian trazem, os testes unitarios tornaram-se um pouco inúteis...MMMMMMMMMMASSSSSS, eu nao vejo como os testes de integração ajudam no design!.. Bom, vc já tem um container que irá startar e lhe prover todas as dependencias.... até mesmo se o seu objeto estiver muito acoplado e fazendo muita coisa (mesmo aquelas q ele nao deveria fazer)
Mas bom... vamos ver como vai ficar...
|
|
|
|
Bill Burke fez um barulho no post sobre JavaEE X Spring, mas o que muitas pessoas não notaram é que teve uma discussão intensa nos comentários
sobre a necessidade de se fazer testes unitários.
http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/
Uma das opiniões dos leitores, que Bill Burke disse concordar completamente, é essa
"...Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks...."
A discussão foi tão grande, que ele acabou de lançar um post sobre mocks!
http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery
No post ele volta a discutir a necessidade de teste unitário e integração.
E o que você acha? Vale a pena investir em testes unitários ou ficar só com testes de integração e fazer o uso de ferramentas como o Arquillian?
|
|
|
|
Exemplo
String hql = select iss from InteracaoSolicitacaoServico as iss where iss.estado in (:aguardandoAtendimento, :aguardandoRetorno, :atendendo)
Query query = getEntityManager().createQuery(hql);
query.setParameter("aguardandoAtendimento", AGUARDANDO_ATENDIMENTO);
query.setParameter("aguardandoRetorno", AGUARDANDO_RETORNO);
query.setParameter("atendendo", EM_ATENDIMENTO);
|
|
|
|
Bom, eu delego a responsabilidade para o container..
Se vc utilizar CDI pode fazer dessa forma : http://www.adam-bien.com/roller/abien/entry/java_ee_6_observer_with
Se vc utilizar Seam pode fazer dessa forma: http://docs.jboss.com/seam/2.0.0.GA/reference/en/html/events.html
Enfim, pesquise se o seu framework já prove a implementacao...
|
|
|
|
tbm nao sei o q esperar dela
mas padronizando o login pra facilitar o Sigle Sign On
já seria algo
|
|
|
|
|
inscrição feita!
|
|
|
|
congrats!!!!
a looooooooootttt
|
|
|
|
|
+1
|
|
|
|
Iae Jonas tudo bom?
Cara, parabéns!
To usando a versão 1.5 do mirror lá no BB fazendo bastante propaganda dele!
Deixa eu te fazer uma pergunta..
Atualmente, a classe GetterHandler tem os métodos para acessar os Fields do objeto.
Tem algum jeito para acessar os Methods do objeto?
|
|
|
|
never mind!
já descobri!
seta o atributo plugins="table"
e
theme_advanced_buttons1="tablecontrols"
just for the record!
|
|
|
|
Opa, o post é antigo, mas deixa eu te perguntar um negócio..
Aonde vc achou esses valores?
cut,copy,paste,pasteword, separator,search,replace,separator,undo,redo,fontsizeselect
pois quero achar o valor para adicionar um botão de tabela!
Valeu
maurenginaldo wrote:Não sei se com o theme básico ele funciona. Uma dica para usar o theme avançado é customizar os botões.
No exemplo abaixo ele coloca o toolbar no topo e à esquerda. Mostra somente uma barra de botões e somente com os botões que eu coloquei.
Abraços,
|
|
|
|
Então.. pq vc nao faz mocks?
http://mockito.org/
|
|
|
|
|
sem alardes...
|
|
|
|
PO.. queria que melhorasse o suporte ao git!, mas parece que o http://www.eclipse.org/egit/documentation/ já melhorou bastante!
pelo o menos a documentação se mostra bem completa!
e pelo amor de deus! eu odeio o repositório de plugins do eclipse!
levante a mão qm nunca teve problema ao tentar instalar um!
hehehe!
|
|
|
|