Esse post é sobre um podcast da HSM Management que fala de um artigo publicado com o título: "Aprender com os Programadores", que fala sobre a aplicação das metodologias ágeis e como as práticas ágeis podem ser aplicadas no planejamento estratégico e em outras áreas da organização.
Link: Podcasting HSM Management
Muito interessante, vale a pena conferir...
"Aprende que não importa onde já chegou, mas para onde está indo… mas, se você não sabe para onde está indo, qualquer caminho serve." (Willian Shakespeare)
sexta-feira, janeiro 30, 2009
segunda-feira, janeiro 19, 2009
Dica: Acompanhe os Testes com o Emma
Se você acordou hoje desanimado, chegou no trabalho ligou seu computador e ficou pensando...por onde eu começo? Bom, eu diria, começa pelo teste, essa é uma prática muito interessante conhecida como TDD (Test-Driven-Development), desenvolvimento dirigido a testes, no início é meio estranho montar uma classe de teste sem ter a classe que será testada, mas acredite você vai acustumar e vai gostar do processo.
Estou a pouco tempo adotando essa metodologia e realmente é muito interessante, antes quando eu ia implementar um requisito do sistema eu pensava logo na lógica e em como eu iria implementar aquilo e no final eu montava o teste, mas isso me induzia a montar o teste pra passar no que eu havia desenvolvido...acho que a grande maioria dos desenvolvedores fazem exatamente isso, pois é...então eu resolvi adotar essa metodologia e quando eu recebia um requisito eu pensava como vou montar o teste...no início era muito difícil de imaginar o nome de algo que não existe, mas depois vai ficando mais fácil.
Por exemplo, testar o procedimento somarDoisInteiros(int x, int y) (lembre-se que esse método não existe ainda), então escreve o teste criando os dois inteiros e chamando o método (mesmo o método não existindo), depois passando valores não inteiros e assim por diante, até cobrir as possibilidades de acertos e erros no sistema.
Quando o teste é executado nada passa, pois ainda não temos a implementação, ai começamos a implementação, mas ai você já percebe a diferença, você ta desenvolvendo pra passar no teste que você já programou e esse teste foi desenvolvido para cobrir as especificações do requisito...quando a implementação for feita e passar no teste o requisito estará ok!
Não sei se ficou claro, mas é uma inversão que te leva a construir algo para ser validado e não construir e depois validar o que você construiu. Parece ser a mesma coisa, mas não é, acreditem.
Existem algumas ferramentas que ajudam nesse tipo de tarefa e ajuda a acompanhar os seus testes para verificar se tudo está sendo realmente testado.
Uma dica muito boa para acompanhar os testes em Java é o Emma mostra um relatório dos seus testes indicando o percentual de cobertura dos testes no seu projeto, além de mostrar no código o que foi, e o que não foi testado. Tem uma outra dica para os usuários da IDE Eclipse que é o Eclemma que é o Emma para o Eclipse, que é muito fácil de instalar.
Para saber mais sobre o TDD, leia o artigo da Improve IT, "Desenvolvimento Orientado a Testes".
Abraço!
Estou a pouco tempo adotando essa metodologia e realmente é muito interessante, antes quando eu ia implementar um requisito do sistema eu pensava logo na lógica e em como eu iria implementar aquilo e no final eu montava o teste, mas isso me induzia a montar o teste pra passar no que eu havia desenvolvido...acho que a grande maioria dos desenvolvedores fazem exatamente isso, pois é...então eu resolvi adotar essa metodologia e quando eu recebia um requisito eu pensava como vou montar o teste...no início era muito difícil de imaginar o nome de algo que não existe, mas depois vai ficando mais fácil.
Por exemplo, testar o procedimento somarDoisInteiros(int x, int y) (lembre-se que esse método não existe ainda), então escreve o teste criando os dois inteiros e chamando o método (mesmo o método não existindo), depois passando valores não inteiros e assim por diante, até cobrir as possibilidades de acertos e erros no sistema.
Quando o teste é executado nada passa, pois ainda não temos a implementação, ai começamos a implementação, mas ai você já percebe a diferença, você ta desenvolvendo pra passar no teste que você já programou e esse teste foi desenvolvido para cobrir as especificações do requisito...quando a implementação for feita e passar no teste o requisito estará ok!
Não sei se ficou claro, mas é uma inversão que te leva a construir algo para ser validado e não construir e depois validar o que você construiu. Parece ser a mesma coisa, mas não é, acreditem.
Existem algumas ferramentas que ajudam nesse tipo de tarefa e ajuda a acompanhar os seus testes para verificar se tudo está sendo realmente testado.
Uma dica muito boa para acompanhar os testes em Java é o Emma mostra um relatório dos seus testes indicando o percentual de cobertura dos testes no seu projeto, além de mostrar no código o que foi, e o que não foi testado. Tem uma outra dica para os usuários da IDE Eclipse que é o Eclemma que é o Emma para o Eclipse, que é muito fácil de instalar.
Para saber mais sobre o TDD, leia o artigo da Improve IT, "Desenvolvimento Orientado a Testes".
Abraço!
Assinar:
Postagens (Atom)