Vi em um java puzzle que o Junit não funciona direito com concorrência, daí surge pergunta, qual o framework de teste que vc’s usam para programação concorrente?
Eu cruzo os dedos e rezo, mas há um artigo no DeveloperWorks sugerindo um framework:
Você pode baixá-lo de:
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Blz vou tentar esse
Somos 2.
Testes unitários são para coisas determinísticas.
Para coisas não determinísticas como threads baseado em time slicing, teste unitário não servirá como desculpa para se fazer alguma cagada.
O TestNG eh um pouco melhor na hora de testar coisas multithreaded. Vale dar uma conferida.
[quote=saoj]Testes unitários são para coisas determinísticas.
Para coisas não determinísticas como threads baseado em time slicing, teste unitário não servirá como desculpa para se fazer alguma cagada.[/quote]
Eu concordo com vc, mas eu estou pensando no seguinte, em algum tempo teremos máquinas com n núcleos, se vc não fizer seus programas com programação concorrente que vantagem eles vão tirar dessas máquinas, evitemente terei de usar novas tecnologias e novas/velhas linguagens “melhores que java” para esse cenário, mas estou estudando com seria um ambiente de produção com um cenário desse.
Sua preocupação é muito pertinente nos dias de hoje.
Java tem um suporte maravilhoso para programaçõa concorrente. Não vou entrar no mérito se ERLANG ou XXXX é melhor, mas se vc quer ou tem que usar Java vc estará em boas mãos.
Só que testar programação concorrente é rocket science, principalmente se tiver sicronização fina (locks, wait, notify e notify all). Se tiver mais de um lock então cuidado com deadlocks. Lock dentro do outro nem pensar.
Programação concorrente = vc pensa 10 vezes no que está fazendo, revisa o seu código outras 10 vezes, pensa mais um pouco, testa um pouco, cruza os dedos e dá um release.
E mesmo assim pode ser que dali a duas semanas apareça algum erro.
Esses dias fiz um concurrent audit log para usar uma thread separada para fazer IO de forma que o IO fosse feito utilizando outro processador e não bloqueasse o thread principal da aplicação. Parece simples falando, mas tinha que sincronizar uma porrada de coisa, criar um queue de buffers para serem flusheados, etc.
Estava tudo certinho, mas eu tive um sonho que tinha um race condition no código. Pior que tinha mesmo. Sorte minha que ela só ocorreria em casos muito raros, ou seja, um belo dia ia explodir! Sorte que tive o sonho…
Já gostei muito de programação concorrente, mas hoje prefiro fazer outras coisas mais legais e que não judiem tanto do meu cérebro.
Suporte maravilhoso comparando-a com programação concorrente em baixo nível, diretamente com o SO. Mas ainda esta longe de ser trivial, coisa que acho que vai ser essencial em um futuro não muito distante.