PessoAll, estou pesquisando as ferramentas para aplicar testes unitários e de cobertura.
Dentre as opções e indicações encontradas nessa pesquisa,
optei para testes Unitários:
Junit / TestNG
e para testes de cobertura:
Cobertura / Emma
Pelo que percebi no contexto de cobertura ambas ferramentas já vêem com exemplos utilizando
o Junit. A ferramenta de teste de cobertura está diretamente dependente dos testes unitários para
conseguir fazer a cobertura ok? Me corrija caso tenha entendido errado.
Mas para todo o caso queria chegar numa solução que a princípio não vejo viabilidade na aplicação
dessas boas práticas numa fábrica de software onde existe projetos com legados complexos, e todos
os caminhos que levam para a mesma situação. No final resultaria em um teste que na próxima
manutenção do sistema não conseguiria utilizar. Por diverssos motivos, base de dados modificada
entre outros.
Ae, cai exatamente nos Mocks que também fiz uma pesquisa, porém para chegar nesse nível de criar mock
para simular situações que envolvem bancos daos etc… Não é apenas o prazo dos projetos mas também o
treinamento da equipe para o uso do mock que no final resultaria num subsistema…
Gostaria de uma opnião de quem já teve uma experiência como essa com necessidade de implantar essas
ferramentas e passar para equipe, e quais dificuldades encontradas e os procedimentos adotados.
mesmo porque essa cultura de boas práticas está sendo aplicada paulatinamente num cenário de
fábrica de software.
comentem por favor!
Em meio a tudo que você escreveu, o que posso te dizer é que primeiramente você precisa encontrar uma maneira de fazer as pessoas entenderem a importância dos testes automatizados. Sugiro algum techtalk até mesmo com uma parte hands-on da coisa. Depois disso, um treinamento intensivão e disponibilização de algumas boas referências sobre o assunto são importantes.
Mas não se iluda, muitos vão ignorar completamente o assunto e vão continuar fazendo a coisa da mesma forma de sempre. Você vai ter que saber lidar com isso. Se vai trocar esses profissionais ou chegar junto deles pra tentar entender o por que do desinteresse, ai é contigo.
Eu tenho uma Classe XYZ e os testes dessa Classe.
Se eu alterei XYZ os testes precisam ser alterados senão a tarefa não está completa. Se ninguem cobra, então bota fora os testes. E pelo controlador de versão dá pra saber essas coisas. Com CruiseControl então, basta configurar que o maluco que quebrar os testes vai receber um email gigante escrito 'SEU FILHO DUMA ÉGUA, QUEBRASSE OS TESTES UNITARIOS!!!".
Se está complexo pense num refactoring do sistema legado. Se o refactoring é proibitivo (as vezes é “pra que alterar uma parada q ta funcionando pra colocar essas frescuras de teste” pensam muitos gerentes), proibitivo sera criar testes pra esse elefante branco 
Se o devido valor não é dado aos testes, um treinamento/palestra pode ser pensado. Se não muda o pensamento tem que apelar pra ignorancia.
Pegue um BUG que deu um BAITA STRESS e mostre como os testes unitários podiam ter evitado.
Aplicando TDD você ganha tudo de graça. Testes, Cobertura, Documentação e ainda de lambuja um Design Simples e Emergente. Leia meu artigo “O ciclo ágil de um dia” da MundoJava #29.
