:: NEO Framework... Novo projeto Open Source brasileiro!

[quote=eduveks]Que um método pode levar valores negativos e positivos e não da erro, que pede receber valores nulos e não arrebenta?!?! Isto é garantia do que?!?!?!

Muito simples, no método xpto ou manda os valores corretos ou já era, se ele estiver de acordo com a especificação, o que tem isto de mau? é bug?

Imagina vc tem um método para fazer adição monetária, onde é proibido números negativos, e recebe um valor negativo e funciona, os testes unitários não vao detectar este bug, e o novo programador q ta fazendo merda, não vai ser testes unitários que vai te ajudar a descobrir este bug.
[/quote]

public void testAdicionarValoresNegativos(){
 Somador s = new Somador();


  try{
   somador.somar(3, -1);
   fail("Nao deu erro ao somar valor negativo");
  }catch(IllegalArgumentException e){ 
    //ok, pegou o erro
  }
}

Isso testa valores negativos.

E como você vai fazer os testes funcionais, na mão? Quanto tempo demora para você fazer um teste de regressão? Testes unitários não eliminam testes funcionais, eles agem em um nível mais abaixo e quando você acha um bug num teste unitário é mais barato que num funcional.

Nossa, então você vai colocar algo em produção sem sequer testes funcionais?

Sem dados eu só posso acreditar que esta seja a sua opinião. A questão é simples: regressão. Qualquer um que já trabalhou num software que teve releases sabe que existe um grande problema em testar o software todo novamente a cada mudança.

Não ponha palavras na minha boca. Eu nunca andei concientemente num carro sem testes, mesmo porque a legislação não deixa carros deixarem a produção sem testes. Ou componentes eletrônicos. Ou banquinhos de padaria. Ou qualquer coisa que se leve minimamente a sério.

[quote=eduveks]
Vc não acha que a melhor forma de testar isto, é no formulário colocar um número negativo e clicar em gravar, e ai se aceitar, aproveita para reportar um bug, e diz para corrigir no método e também colocar uma validação no formulário, não é muito mais simples? [/quote]

Das duas uma: ou seu software só tem essa tela ou você tem todo o tempo e recursos do mundo. Mesmo assim, é muito fácil um tester esquecer um passo ou fazer algo errado. Como disse antes um teste não substitui o outro mas teste click-click-click é simplesmente perda de tempo e dinheiro quando pode ser evitado. No seu exemplo acima no mínimo deveria ser utilizado algo como Selenium.

E isso ignorando condições que são facilmente simuláveis em testes unitários e não emt estes funcionais. Que acotnece se aquela classe recebe 1000 pediddos numa ordem específica? Como você simula isso em testes funcionais?

[quote=eduveks]
Obrigado pela cuiriosidade sobre a fundação Mozilla, realmente não sabia, e nem dei ao luxo de pesquisar, pois minha intenção foi dizer que todos os dias usamos muita coisa que não é passado por testes, e q muito provavelmente nunca será, por isso dizer q testes é fundamental? Não é![/quote]

Não sei qual foi sua intenção, mas o que ficou foi a certeza que você está argumentando sobre o que não conhece e nem quer ‘se dar ao luxo’ de conhecer.

Não sou completamente contra os testes unitários, para aplicações, pelo menos a que fazemos, com inumeros campos, diabo a quatro, ter q configurar uma ferramenta de testes, isto vai dar ainda muito mais trabalho, os preços e prazos terão q ser revistos, além de que o cliente não quer saber se tem testes ou não, e não acredito muito se os testes trariam vatagens práticas significativas.

Mas eu custumo usar os tetes, para testas os packages com muitas classes e métodos q foram desenvolvidas a queima roupa e q são usadas como “tools”, ai sim fazemos para já polir alguma coisa. Agora em grandes projetos onde isto vai influenciar custos além de que o teste do cliente é q conta mais, não vejo a necessidade.

Além que mais uma vez, a questão principal pra mim é dizerem q código não testado é inutil, e framework sem testes não presta, coisa q não é verdade!

Quando q o teste click-click-click não é preciso? Como vc vai testar se o form esta bem do lado do cliente, e retornando a informação correta? Os testes unitários garantem isto?

Então vc afirma que uma framework com testes é mais seguro e melhor, do q outra sem?

Acho q isto não se pode afirmar…

E é, é achismo, pois até hoje ninguém me comprovou de modo prático que sem testes nenhum produto sobrevive, e que vamos perder um cliente se não fizermos testes.

Testes no final, é irrelevante, e durante, depende… acho q não se aplica sempre… testes não é regra absoluta a seguir, em alguns casos auxiliam, mas também se sobrevive sem…

Minha opinião baseado na minha experiência até hoje e principalmente baseada no meu atual emprego. Não sou o dono da verdade mas esse é o meu feeling…

Quando vc programa um método ou uma classe crítica vc vai testá-lo muitas vezes. Pra isso existe ambiente de testes, métodos main() onde vc pode fazer alguns testes na mão, etc.

E quando vc colocar em produção, um belo dia vc vai descobrir um problema que vc nunca preveu e nunca poderia ter previsto… (Ex: Quantidade fracionada ou em notação científica quando uma ordem é executada). Nenhum teste vai pegar situação que vc não tem como prever, e isso já é uma grande desvantagem de testes, o que o torna meio inútil para muitas situações da vida real.

Aí alguns vão dizer: Testes são fundamentais para refactoring.

Eu concordo que ajuda e é uma segurança a mais, mas está muito longe de garantir alguma coisa e quando vc for fazer um refactoring numa classe crítica vc tem uma grande chance de mostrar sua responsabilidade, disciplina e profissionalismo para o seu chefe. O menos importante aqui é mostrar que vc é um testador de primeira, mas sim mostrar que vc entende conceitos básicos como backwards compatibility, lógica, herança e override.

Quando se altera algo que se está funcionando perfeitamente, devido há uma nova necessidade, não há qualquer desculpa teórica para se introduzir um bug de regressão. O que vc vai fazer é abrir um branch (if, override, o que seja) para tratar o caso novo de forma que se for uma situação corriqueira o código vai executar o que ele sempre veio executando até aqui com sucesso. Apenas se for o novo caso especial é que ele executará um código novo. Meu ponto é claro: nada justifica um bug de regressão quando se trabalha com disciplina e boas práticas de OO.

Apenas minha opinião. Não estou falando de TDD, pois nem conheço direito. Estou falando que testes unitários deveriam ser desnecessários quando se trabalha com disciplina e boas práticas de OO. Sim, ter testes unitários é melhor do que não ter testes unitários, mas achar que eles vão garantir alguma coisa e que a simples presença deles vão garantir um bom sistema com menos bug é muita ilusão na minha opinião.

Fazendo isto, ta tudo garantido? Isto num teste funcional não iria ser testado? E não seria resolvido logo? O tempo q gastaria fazendo isto, isto é uma regra simples, mas imagine uma regra mais complicada, como a aprovação de crédito, q tem q respeitar uma lógica cheia de exessões, imagina o código do teste para fazer isto, e o próprio código de testes estaria propenso a erros e graves, o que me garante q o testes esta bem feito? O teste funcional q vai dizer tudo, e o teste unitário, é algo q não vai ter influência nenhuma no final, e o tempo q gastei fica aonde? Moral, vou gastar muito mais tempo para detectar o erro, dois processos (funcional e unitário), onde 1 (funcional) resolve…

Ótimo, na sua opinião.

Na opinião de Martin Fowler, Kent Beck, Ron Jeffries, Erich Gamma e muitos outros, eles não são uma ilusão.

[quote=eduveks]
Fazendo isto, ta tudo garantido? Isto num teste funcional não iria ser testado? E não seria resolvido logo? O tempo q gastaria fazendo isto, isto é uma regra simples, mas imagine uma regra mais complicada, como a aprovação de crédito, q tem q respeitar uma lógica cheia de exessões, imagina o código do teste para fazer isto, e o próprio código de testes estaria propenso a erros e graves, o que me garante q o testes esta bem feito? O teste funcional q vai dizer tudo, e o teste unitário, é algo q não vai ter influência nenhuma no final, e o tempo q gastei fica aonde? Moral, vou gastar muito mais tempo para detectar o erro, dois processos (funcional e unitário), onde 1 (funcional) resolve…[/quote]

Companheiro, já avaliou o tempo e o trabalho de fazer um teste funcional? E o de fazer e rodar um unitário que pega a mesma coisa?

Ótimo, na sua opinião.

Na opinião de Martin Fowler, Kent Beck, Ron Jeffries, Erich Gamma e muitos outros, eles não são uma ilusão.[/quote]

Testes unitários são milagrosos então, e eu q pensava q não existia milagres em TI!

Na boa, isto em teoria é muito lindo, e na prática do meu trabalho e da minha equipe no dia-a-dia, os testes iria causar atrasos, além de não manter a fidelidade total, pois temos q manter o código fiel, e agora também os testes unitários? Alterações tem q fazer em dois lugares? Isto no nosso caso seria desastroso…

Testes não é obrigatório… não é por q estes caras dizem q é, quem diz se é e não é é o cliente, e até hoje nenhum disse q era, por q até eles confiam mais no teste q eles fazem do q em testes unitários.

[quote=Maurício Linhares][quote=eduveks]
Fazendo isto, ta tudo garantido? Isto num teste funcional não iria ser testado? E não seria resolvido logo? O tempo q gastaria fazendo isto, isto é uma regra simples, mas imagine uma regra mais complicada, como a aprovação de crédito, q tem q respeitar uma lógica cheia de exessões, imagina o código do teste para fazer isto, e o próprio código de testes estaria propenso a erros e graves, o que me garante q o testes esta bem feito? O teste funcional q vai dizer tudo, e o teste unitário, é algo q não vai ter influência nenhuma no final, e o tempo q gastei fica aonde? Moral, vou gastar muito mais tempo para detectar o erro, dois processos (funcional e unitário), onde 1 (funcional) resolve…[/quote]

Companheiro, já avaliou o tempo e o trabalho de fazer um teste funcional? E o de fazer e rodar um unitário que pega a mesma coisa?[/quote]

Pega a mesma coisa? Certeza? No nosso caso garato q não! Nunca na vida…

Como vc vai garantir a validação dos campos na tela? Se vou ter q testar isto, então vou acabar por testar tudo, e é o teste q o cliente quer, é o teste q realmente importa.

IMHO,

Nao acho ilusao, testes unitarios garantem sim a funcionalidade dos metodos em si quando bem desenvolvidos, juntando com testes funcionais e com uma boa equipe de QA voce consegue sim garantir um bom sistema com menos bugs.

Porem se voce nao vive nesse meio(atualmente eu nao vivo essa realidade) fica um pouco dificil de acreditar nisso.

Ate mais… :thumbup:

Ótimo, na sua opinião.

Na opinião de Martin Fowler, Kent Beck, Ron Jeffries, Erich Gamma e muitos outros, eles não são uma ilusão.[/quote]

Leia de novo o texto que eu escrevi e que vc citou na sua resposta. Lá eu falo que ilusão é achar que testes vão garantir um bom sistema com menos bug, e não que testes é uma ilusão.

Mas tudo bem… Acaba dando no mesmo no final das contas… Testes vão ser muito importante se vc tem na sua equipe uma kamikaze/maluco e/ou um programdor muito fraco é o que é pior, sem disciplina e responsabilidade.

Aquele cara que pode acordar um belo dia e pensar assim: Hoje eu vou modificar aquele método crítico do meu sistema. Estou com uma coceira no xx e acho aquele método bem feinho, logo vou mudar algumas coisas ali…

Num ambiente profissional, onde há lideranças, organização e responsabilidade, esse tipo de profissional e esse tipo de atitude não entra de maneira nenhuma, tenha testes ou não tenha testes.

eduveks, você realmente conhece testes unitários, tdd, etc.? Ou está falando isso baseado apenas em um tutorial de JUnit que leu? Sinceramente, parece muito que você tá falando de algo que não conhece!

Dá pra argumentar a favor de testes unitários usando exatamente as mesmas palavras que você tá usando. Isso é sinal de que você tá argumentando sem conhecer…

[quote=ZehOliveira]eduveks, você realmente conhece testes unitários, tdd, etc.? Ou está falando isso baseado apenas em um tutorial de JUnit que leu? Sinceramente, parece muito que você tá falando de algo que não conhece!

Dá pra argumentar a favor de testes unitários usando exatamente as mesmas palavras que você tá usando. Isso é sinal de que você tá argumentando sem conhecer…[/quote]

O cara tem a experiencia prática, e isso ao meu ver vale muito mais do que qualque experiencia teórica.

Mais uma vez, essa é a sua opinião.

A opinião dos que eu já citei acima é o contrário.

[quote=ZehOliveira]eduveks, você realmente conhece testes unitários, tdd, etc.? Ou está falando isso baseado apenas em um tutorial de JUnit que leu? Sinceramente, parece muito que você tá falando de algo que não conhece!

Dá pra argumentar a favor de testes unitários usando exatamente as mesmas palavras que você tá usando. Isso é sinal de que você tá argumentando sem conhecer…[/quote]

Realmente não conheço muito afundo, uso para testar alguns packages q não serão muito testados, e q vamos usar de vez em quando… e não vi a grande utilidade dos testes unitários, além de testes superficiais.

Agora se os testes unitários vão para muito além disto, e são tão bons assim, tenho q me informar melhor, e quem sabe me interessar mais por isto.

Mas testes unitários não quer dizer q A é melhor q B, pelo menos acho q dizer isto é um absurdo.

Quanto ao meu conhecimento dos testes, vou tentar melhor e me informar mais, pra ver se realmente vale a pena…

E quem perguntou sobre prática ou teórica? Eu perguntei se ele conhecia testes unitários, minha pergunta não foi se ele já havia lido determinado livro. Pode se conhecer determinado assunto de vários modos e a minha impressão é que ele não conhecia muito bem em nenhum deles (algo que, aliás, ele até admitiu).

Eu só acho que é bastante chato discutir com quem nem sequer procurou estudar o tema que está argumentando (assim como foi discutir com você sobre Hibernate, quando você nunca tinha usado o framework).

Por isso que estou aconselhando que procurem a ler, testar do modo certo (e não do modo que acham que é) e usar, pra depois argumentar.

Do mesmo jeito que você não gosta quando alguém fala do Mentawai sem ter testado, é igualmente irritante quando vemos vocês falando de T.U. e TDD sem nunca ter usado (nem estudado).

Tudo bem. Mas não estou falando disso… Estou fazendo de ter testes unitários ou não e da diferença prática que isso faz no final das contas…

TDD é outra história… Da qual realmente eu não conheço muito a respeito…

É verdade, mas o teste vai garantir que o que vc já pensou não vai dar problema.

Só do código ter sido feito por um ser humano já é propenso a erro, e se o teste dá uma segurança a mais e não leva muito tempo pra fazer, ele é válido.

Posso até mostrar isso, mas eu não conheço o sistema inteiro, não sei quem fez o que, um monte de gente já passou pelo código, como eu vou me garantir de refatorar um código desse mesmo que todos as pessoas que passaram pelo código sejam ótimos programadores (o que é raríssimo)?

[]'s

Rodrigo Auler