Vira e mexe vem alguém e fala que os teste unitários não são legais, não funcionam não dão certo por esse ou aquele motivo. Eu uso teste unitários, a mais ou menos um ano, não consigo mais me imaginar passando horas debugando código só pq implementei uma nova funcionalidade:
Li o artigo no javaworld e o cara faz um pergunta interessante colocação, que eu gostaria de fazer a vc's. " Eu adoraria ouvir estórias de situações mundo real aonde os teste unitários foram abandonados, ou simplesmente rejeitados e pq?"
Te digo um lugar onde os testes foram rejeitados: num antigo projeto meu.
Mas eu era testador e os testes unitários, legados. Num port do sistema para uma nova arquitetura os programadores, que eram muito bons, decidiram que seria mais rapido desenvolver sem testes.
É claro que envolvia coisas simples como umas JNIs, umas Brigdes e bastante codigo novo para suportar uma funcionalidade boba, um tal de IPv6.
O projeto, depois de 6 meses, foi posto na geladeira…
Andei vendo vários programadores preferindo fazer teste de integração ao invés de teste unitário. Isso normalmente acontece quando o cara é preguiçoso ou acredita que integração cobre tudo que ele precisa. Daí quando alguma coisa começa dar errado tem que sair debugando código. É lindo de se ver :lol:
Testes Unitários não garantem que seu sistema está funcionando.
Testes Integrados não garantem que o seu programa está 100%.
Não se pode ficar sem fazer testes unitarios e não se pode ficar sem fazer testes integrados, ter os dois seria o cenario ideal.
Oq acontece é que alguns projetistas de testes planejam testes unitários inuteis, por isso numa empresa que trabalhei os testers não eram muito populares!
Só pra ter idéia, o sistema web tinha testes do tipo:
-Aperte Esc duas vezes para ver se sai do navegador.
Isso sim é um teste inutil!
Sem entrar no mérito se testes unitários é tão importante para os programadores Java quanto a ressurreição para os cristãos (procure no GUJ que há vários tópicos com esse debate), gostaria de expressar minha opinião de desacordo com a afirmação abaixo:
Eu entendo que programação OO requer organização e principalmente separação de responsabilidades. Num código com uma arquitetura e organização minimamente descentes, estender o sistema não pode fundamentalmente ter como consequencia a sua quebra. Muitos, tb por causa dos testes unitários, abominam herança. É estranho entender então porque todas as linguagens OO que surgiram nos últimos 10 anos possuem herança. Será que é porque herança, igualmente junto a interfaces do Java, ajuda a estender um sistema sem quebrar o que já funciona hoje?
Por favor: esqueçam a história do MyProperties extends Properties. Nesse caso é claro que é melhor usar composição, a não ser que vc queira passar o seu novo objeto para um sistema legado que utiliza properties. O certo aqui, como todo mundo já deve saber, é preferir interfaces como java.util.Map, mas infelizmente o properties não implementa nenhuma interface.
Eu acredito que se para qualquer estenção ou mudança no seu código vc precisa de testes unitários, então o seu código é um spagetti code. Acho que as pessoas confundem muito sistema com algoritimo. O primeiro pode existir tranquilamente sem testes unitários, já o segundo pode tirar bastante proveito de testes unitários, principalmente se o algoritmo vai evoluir e ser modificado diversas vezes.
E então temos TDD, que eu entendo pouco, mas que acho ser uma metodologia de desenvolvimento que usa testes unitários como especificação. Se for isso não tem nada haver com esse debate…
Eu gosto muito de testes unitários, ajudam a pegar muitos erros antes de subir a aplicação inteira e ajuda a ver erros de design.
Mas acho que os testes unitários não são suficentes para garantir que o aplicativo funciona. O erro muitas vezes esta bem na parte onde os objetos se “integram” ou se “comunicam”. Além disso, o fato de seu unit test ter passado não significa que a aplicação esta fazendo o que ela deveria fazer.
Olá
Sou amplamente favorável aos testes unitários. Acho que quem tem este hábito programa de um modo mais seguro. Mas faço 3 observações:
-
É óbvio que não são suficientes para garantir que o aplicativo funciona
-
Acho bobagem buscar cobertura 100% principalmente em uma linguagem verbosa como o Java
-
Como disse ontem, infelizmente só conheço um único livro que ensina a programar fazendo testes unitários
[]s
Luca
100% de cobertura de teste nunca é 100% de cobertura de testes.
mas 90% de cobertura de testes é muito melhor do que ?% – se trata de responsabilidade.
Trabalhei numa consultoria que presta serviço pra um banco, lá haviam algumas coisas bem toskas com relação a testes.
Um os testes unitários eram feitos após o build e não durante.
Erros nos testes unitários/integrados eram reportados e cobrados financeiramente da consultoria.
Não falo as empresas por ética.
Q coisa não?
Poderia dizer qual é esse livro?
Obrigado.
Pensando aqui, seria ótimo q os milhares de tutoriais de centenas de tecnologias, frameworks, hello worlds, etc.
Bem como aqueles pedaçoes de código de exemplo, se tivessem testes unitários poderiam ajudar a disseminar mais os testes …
Unit test para Hello World?
Olá
[quote=eric_jf][quote=Luca]
3) Como disse ontem, infelizmente só conheço um único livro que ensina a programar fazendo testes unitários
[/quote]
Poderia dizer qual é esse livro?[/quote]
Se não me engano é este: Agile Java Crafting Code with Test-Driven Development
Quando aprendi Fortran em 1968 meu primeiro programinha NÃO foi um HelloWorld. Foi multiplicação de matrizes.
Mas já que atualmente sempre se usa o HelloWorld, porque não fazer teste unitário? Eu acho que seria muito bom já incluir teste unitário no primeiro HelloWorld. Se fosse assim a gente não precisava ler o que eu li ontem dizendo que escrever testes unitários consome tempo exagerado.
[]s
Luca
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
//...
public class HelloWorldTest extends TestCase {
public void testMain() {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
System.setOut(new PrintStream(bos));
HelloWorld.main(null);
assertEquals("Hello World!\r\n", bos.toString());
}
}[quote=Luca]Olá
[quote=eric_jf]
Poderia dizer qual é esse livro?[/quote]
Se não me engano é este: Agile Java Crafting Code with Test-Driven Development [/quote]
E quanto ao JUnit in Action? Você o recomendou em outro tópico.
Ou ele não ensina a programar (só ensina testes)?
Oi,
Os testes (tanto unitários quanto de integração) devem fazer parte de um desenvolvimento de software. Desenvolvedores profissionais desenvolvem com testes.
Se os testes não estão tão populares, cabe à nós desenvolvedores profissionais a fazer uma maior divulgação da importância dos testes.
Olá
[quote=Schuenemann]E quanto ao JUnit in Action? Você o recomendou em outro tópico.
Ou ele não ensina a programar (só ensina testes)?[/quote]
O Junit in action é muito bom. Eu li e acho que vale a pena mas é para quem já sabe Java.
Já o livro anterior eu só dei uma olhada e achei curioso justamente por ensinar a programar já com testes.
[]s
Luca
Existe MUITOSSS livros sobre teste unitarios… JUnit in Action, JUnit Recipes, Test Driven in Action, isso da editora Manning…
Mas querendo ou não, teste unitario demanda tempo, paciencia, disciplina e habilidade. E em ambientes onde nao te proporcionam isso é muito dificil colocar para funcionar essa prática.
Outra coisa, querendo ou não, testar é dificil… Não digo dificil para seres perfeitos como muitos, ou como eu 8), mas para testar requer bom entendimento de OO, requer conhecimentos de refatoração e, principalmente, necessita entender o valor dos testes unitarios… Senão vira mais uma coisa chata para fazer…
[quote=saoj]Sem entrar no mérito se testes unitários é tão importante para os programadores Java quanto a ressurreição para os cristãos (procure no GUJ que há vários tópicos com esse debate), gostaria de expressar minha opinião de desacordo com a afirmação abaixo:
Eu entendo que programação OO requer organização e principalmente separação de responsabilidades. Num código com uma arquitetura e organização minimamente descentes, estender o sistema não pode fundamentalmente ter como consequencia a sua quebra. Muitos, tb por causa dos testes unitários, abominam herança. É estranho entender então porque todas as linguagens OO que surgiram nos últimos 10 anos possuem herança. Será que é porque herança, igualmente junto a interfaces do Java, ajuda a estender um sistema sem quebrar o que já funciona hoje?
Por favor: esqueçam a história do MyProperties extends Properties. Nesse caso é claro que é melhor usar composição, a não ser que vc queira passar o seu novo objeto para um sistema legado que utiliza properties. O certo aqui, como todo mundo já deve saber, é preferir interfaces como java.util.Map, mas infelizmente o properties não implementa nenhuma interface.
Eu acredito que se para qualquer estenção ou mudança no seu código vc precisa de testes unitários, então o seu código é um spagetti code. Acho que as pessoas confundem muito sistema com algoritimo. O primeiro pode existir tranquilamente sem testes unitários, já o segundo pode tirar bastante proveito de testes unitários, principalmente se o algoritmo vai evoluir e ser modificado diversas vezes.
E então temos TDD, que eu entendo pouco, mas que acho ser uma metodologia de desenvolvimento que usa testes unitários como especificação. Se for isso não tem nada haver com esse debate…
[/quote]
Concordo contigo, os testes não estão em uma lado oposto à herança, aliás isso é novidade para mim, não faço nem idéia de como alguém chega a esse tipo de conclusão.
Isso é um dos motivo que fazem os testes unitários não serem tão populares assim, pelo menos é o que diz o autor do artigo no javaworld.