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

184 respostas
Hal_Jordan

A empresa linkcom, na qual eu trabalhava aqui em BH, abriu o código de seu framework interno chamado NEO. Ele é baseado em Spring/Spring MVC e Hibernate e facilita muito o desenvolvimento de aplicações, principalmente na criação de CRUD…

Vcs podem baixa-lo em http://www.neoframework.org e testa-lo, tirarem duvidas aqui, dá sugestões e por fim participar em seu desenvolvimento… O site ainda está imcompleto (alguns capitulos da documentação ainda nao foram postados) porem esta sendo atualizado todos os dias e o material q lá se encontra já é suficiente para sua utilização…

Espero que vcs postem seus comentarios. logo o Rógel, criador do framework, vai esta aqui tb respondendo suas dúvidas!!!

[color=darkred]Movido para assuntos gerais porque o framework ainda carece de documentação, principalmente quanto à licença.[/color]

184 Respostas

Kenobi

Hal Jordan:
A empresa linkcom, na qual eu trabalhava aqui em BH, abriu o código de seu framework interno chamado NEO. Ele é baseado em Spring/Spring MVC e Hibernate e facilita muito o desenvolvimento de aplicações, principalmente na criação de CRUD…

Vcs podem baixa-lo em http://www.neoframework.org e testa-lo, tirarem duvidas aqui, dá sugestões e por fim participar em seu desenvolvimento… O site ainda está imcompleto (alguns capitulos da documentação ainda nao foram postados) porem esta sendo atualizado todos os dias e o material q lá se encontra já é suficiente para sua utilização…

Espero que vcs postem seus comentarios. logo o Rógel, criador do framework, vai esta aqui tb respondendo suas dúvidas!!!

[color=darkred]Movido para assuntos gerais porque o framework ainda carece de documentação, principalmente quanto à licença.[/color]

Muito legal a postura da empresa, em compartilhar expertise com o mercado, entretanto, adicionamos mais um à estatística e ao problema do meio java… Frameworks em excesso !!

Hal_Jordan

Opa opa… faltam somente uns 3 capitulos da documentação… Tem documentação sim…

E eu esqueci de falar, a licensa é LGPL… Vai ser colocado daqui a poko lá…

Devia ter pergutnado antes de mudar :?

Hal_Jordan

documentação auqi

http://www.neoframework.org/dist/documentacao/index.html

nbluis

Ei Hal Jordan;

Poupe-nos um pouco do trabalho, diga quais as inovações do neo framework.

Leozin

fazer por fazer crud a gente usa rails com um scaffold e pronto :frowning: :frowning:

quantos segundos pra fazer um crud no netbeans 6? :stuck_out_tongue:

Hal_Jordan

Kenobi:
Hal Jordan:
A empresa linkcom, na qual eu trabalhava aqui em BH, abriu o código de seu framework interno chamado NEO. Ele é baseado em Spring/Spring MVC e Hibernate e facilita muito o desenvolvimento de aplicações, principalmente na criação de CRUD…

Vcs podem baixa-lo em http://www.neoframework.org e testa-lo, tirarem duvidas aqui, dá sugestões e por fim participar em seu desenvolvimento… O site ainda está imcompleto (alguns capitulos da documentação ainda nao foram postados) porem esta sendo atualizado todos os dias e o material q lá se encontra já é suficiente para sua utilização…

Espero que vcs postem seus comentarios. logo o Rógel, criador do framework, vai esta aqui tb respondendo suas dúvidas!!!

[color=darkred]Movido para assuntos gerais porque o framework ainda carece de documentação, principalmente quanto à licença.[/color]

Muito legal a postura da empresa, em compartilhar expertise com o mercado, entretanto, adicionamos mais um à estatística e ao problema do meio java… Frameworks em excesso !!

Na verdade ele não é nada mais nada menos q Spring com Hibernate, ou seja, tudo q vc faz com eles vc faz no NEO, então nao é um framework que pretende fazer você aprender milhares de coisas novas, desconhecidas e não testadas, mas sim ele abstrai a maioria das tarefas que são feitas com ambos frameworks…

Luca

Olá

Hal Jordan:
documentação auqi

http://www.neoframework.org/dist/documentacao/index.html

Sem muitas polêmicas, mas enquanto as coisas estiverem assim e sem caracterização clara como Open Source, isto nem deveria estar aqui como assuntos gerais.

[]s
Luca

Hal_Jordan

Leozin:
fazer por fazer crud a gente usa rails com um scaffold e pronto :frowning: :frowning:

quantos segundos pra fazer um crud no netbeans 6? :P

Escolher tecnologia não é simplesmente escolher… “Ah, se eu quero isso uso a tec X!!!”… Se vc possui uma empresa onde toda sua base de conhecimento tecnologico está emcima de Hibernate e Spring não vale a pena troca da noite pro dia para qualquer outra diferente… E como ele é baseado em ambas as tecnologias, enfim

Hal_Jordan

nbluis:
Ei Hal Jordan;

Poupe-nos um pouco do trabalho, diga quais as inovações do neo framework.

http://www.neoframework.org/siteneo/apresentacao

fabiofalci

Olá!

2 Sugestões:
Javadoc! Baixei o código e olhei, mas sem javadoc não dá, pouca coisa tem documentacao.
Dica, baixa o source do spring e olha os javadoc dos cara.

Teste unitários!

No mais, parabéns pela iniciativa de abrir o código! :wink:

R

Embora exista uma tendência de substituir os mal falados XML por Annotations, acho que a ferramenta de vcs é muito boa.
Achei a velocidade de desenvolvimento boa, no entanto, essa dependencia do Hibernate ( até onde percebi) é o que mata.

pgoncalves

Gostaria de informar-lhes que a geração do javadoc já está sendo providenciada.

Quanto à licença, foi colocada a LGPL para o projeto e também já foi alterado no site. Em breve terá a referência no código fonte do projeto.

Quanto à dependência do hibernate, realmente somos totalmente dependentes, mas atualmente já é possível usar o jdbc em conjunto com o hibernate, através do jdbc template fornecido pelo spring. Porém, não tem como retirar tudo relacionado ao hibernate até este momento.

Isso já temos suporte. Em breve disponibilizaremos no site do projeto um tutorial.

O neo foi desenvolvido para as necessidades da Linkcom, e no momento do seu desenvolvimento não foi pensado nessa flexibilidade. As coisas foram sendo implementadas à medida em que surgiam necessidade. Aos poucos, ao longo das futuras versões, iremos lançar as melhorias sugeridas pelos usuários. Por isso, é importante a participação e colaboração de todos.

Obrigado.

rogelgarcia

Olá pessoal, eu sou Rógel Garcia, criador do framework NEO.

O site já está atualizado com a licença, e os fontes em breve já terão referencia à LGPL.

A documentação já está com o conteúdo principal para começar a trabalhar com o framework. Novas atualizações serão feitas ao longo do tempo para torná-la mais abrangente.

Porque mais um framework?

Mesmo utilizando frameworks disponíveis no mercado ainda precisamos de codificação desnecessárias. Isso porque os frameworks tem um determinado propósito que não chegam a ser um propósito tão profundo quando o propósito do NEO.

Por exemplo, utilizamos o hibernate para fazer o mapeamento dos objetos ao banco de dados. Mas em cada aplicação temos que implementar um método findAll() em cada DAO. Ou então, criamos um campo do tipo Date em alguma classe e precisamos declarar uma validação para datas em algum XML. Esse tipo de trabalho que ainda tem que ser feito mesmo utilizando frameworks é que o NEO tenta resolver.

O NEO não propõe mais um framework, mas sim o próximo passo dos frameworks. Tanto que o NEO utiliza como base os frameworks Spring e Hibernate. O que o NEO propõe está além do que esses framework já propuseram.

A facilidade de desenvolvimento é um ponto chave do NEO. Eu também sou programador e criei um framework para facilitar o trabalho do programador (eu, no caso :D).

Uma das formas de facilitar o desenvolvimento é a não utilização de XML. Antes de existir o NEO, nós utilizávamos Struts para desenvolver na empresa. E eu ficava desanimado porque depois de criar uma Action com um bocado de código ainda tinha que declarar um form, uma action e forwards no struts.xml. Eu me perguntava, porque tenho que declarar isso tudo? Geralmente para fazer uma tela eu tinha que utilizar 3 XMLs. Um para o struts, um para a validação e um para o mapeamento no banco de dados. No NEO esses arquivos simplismente não existem. O NEO, ao ligar a aplicação, procura por classes especiais (como Actions do struts) e faz o registro automaticamente. Não é necessário indicar em nenhum lugar que as classes existem. O NEO simplismente acha.

Outro recurso, é que códigos comuns já vem implementados. Quantas vezes você tem que fazer uma tela de CRUD por dia? Ou um método findBy dentro de um DAO. O NEO fornece DAOs implementados, isto é, com funcionalidades que podem ser utilizadas sem nenhuma linha de código. Além disso ele possui Controllers especificos para as situações mais comuns como CRUDs e relatórios. Não é necessário nenhuma linha de código Java (a não ser a linha que declara a classe) para fazer um CRUD ou DAO. Se desejar modificar o comportamento padrão, você só precisará escrever o que for diferente.

A validação do NEO é feita através de annotations. O simples fato de anotar um getter com @Required faz com que qualquer tela que utilize essa propriedade ganhe a validação automática. Também é feita uma validação no servidor. Campos que forem do tipo Date por exemplo já ganham validação do tipo Date, não é preciso indicar ao framework que o campo date é um date.

Com nenhuma linha de código Java é possível fazer uma dependencia de combos utilizando Ajax.

<n:comboReloadGroup useAjax="true">
   <t:property name="pais"/>
   <t:property name="estado"/>
   <t:property name="cidade"/>
</n:comboReloadGroup>

Pronto! O código acima irá criar todo o javascript necessário para fazer o reload utilizando ajax. Há! Também não é necessário informar que no campo pais, estado ou cidade você deseja um combo. O Framework já sabe. Todas as propriedades que forem entidades já são combo por padrão. A lista a ser preenchida em cada combo vem do DAO que não foi necessário códificar.

public class PaisDAO extends GenericDAO<Pais> {
}

O NEO utiliza sempre que possível Generics. Casts são praticamente inexistentes em aplicações com o NEO. Para utilizar o dao de Pais acima você teria o seguinte código:

List<Pais> lista = paisDAO.findAll(); // todos os finds são genéricos
for(Pais pais: lista){
    System.out.println(pais.getNome));
}

Construir queries também é fácil. O NEO provê uma classe, a QueryBuilder, que serve exclusivamente para contruir queries. Veja:

Sem queryBuilder

String query = "from Aluno ";
if(filtro.getNome() != null){
     query+= "where nome = ?";
}
Query query = session.createQuery(query);
if(filtro.getNome() != null){
     query.setString(1, filtro.getNome());
}
return query.list();

(Tem algum tempo que não utilizo hibernate diretamente, mas existe alguma forma de fazer isso mais simples? Até onde eu saiba, utilizando Criteria não é possível atingir o mesmo efeito porque não é eliminada a condição where nome = ? se nome for null)

Com o QueryBuilder

return query() // o método query() é disponível em todos DAOs
              .from(Aluno.class)
              .where("aluno.nome = ?", filtro.getNome())
              .list();

Um dos princípios da orientação a objetos é o High Cohesion (Alta coesão). Isso significa que códigos relacionados devem ficar próximos. Uma Action do Struts por exemplo não promove isso, uma vez que cada operação fica dentro de uma classe diferente. O NEO possui um controller, o MultiActionController (não é o mesmo do Spring), que permite o High Cohesion. Para adicionar uma nova operação ao controller basta criar um novo método. Códigos relacionados agora, podem ficar dentro da mesma classe, cada operação com o seu método.

Nos JSPs não é necessário falar que determinado input deve possuir máscara para data. Se a propriedade a que se refere o input é do tipo data a máscara será colocada. Se for Double, será colocada uma máscara para Double, se for CPF será colocada uma máscara para CPF. O NEO possui outros tipos de dados como CPF, CNPJ, CEP e Money.

A classe Money possui inclusive métodos para calcular com dinheiro que evitam a perda dos centavos em operações matemáticas.

Essas são algumas idéias que o NEO possui e que diferenciam ele dos outros frameworks. O intuito do NEO é resolver o problema. O NEO efetua configurações, ajustes, realiza operações, escolhe propriedades tudo de acordo com o que foi programado. Ou seja, você programa o mínimo necessário e o NEO faz o resto. Na nossa empresa a pior estimativa de melhora no desenvolvimento depois do NEO foi de 30%.

O NEO existe há dois anos mas só agora está sendo liberado o código fonte. O desenvolvimento do framework foi direcionado pelas necessidades da Linkcom (empresa onde trabalho). Por isso alguns ajustes ou novas funcionalidades ainda são necessários. Mas o framework já possui um conjunto bom de funcionalidades para se desenvolver aplicações. Inclusive, o sistema da Universidade FUMEC é desenvolvido utilizando o NEO.

Dúvidas serão respondidas no fórum do framework. Sugestões são muito bem vindas. Bugs serão corrigidos o mais rápido possível. Espero que o framework seja de grande utilidade para vocês no desenvolvimento de aplicações.

Muito Obrigado pela atenção…

Até mais…

saoj

Parabéns pelo framework. Ficou bem legal e qualquer abstração de complexidade é sempre bem-vinda…

cv1

Isso já temos suporte. Em breve disponibilizaremos no site do projeto um tutorial.

Como assim, “já temos suporte”? Cade os testes unitarios do proprio Neo?

Correndo o risco de bater demais nessa tecla, com a qual o saoj ja apanhou ha pouco tempo atras, mas dar as caras e dizer que fez um framework sem mostrar os testes pra provar que ele funciona eh a mais pura canalhice e má-fé com quem, sem saber no que está se metendo, comeca a usar o seu framework num projeto de verdade.

Foi mal, mas… putz.

Luca

Olá

Galera do NEO, parabéns pelo projeto mas o CV tem toneladas de razão.

cv:
Cade os testes unitarios do proprio Neo?

Correndo o risco de bater demais nessa tecla,

CV, acho que nunca é demais ressaltar isto.

Ultimamente eu me convenci definitivamente de 2 coisas:

  1. EJBs < 3.0 foram a maior asneira que eu conheci nos meus 38 anos de informática.
  2. É um absurdo ensinar alguma linguagem em pleno ano de 2006 sem forçar o aluno a escrever seu primeiro Hello World com testes unitários.

Por isto a gente sempre precisa fazer como você fez. Por mais antipático que a gente pareça, na verdade a estamos fazendo um enorme favor para toda a comunidade que nos lê.

Acho até que a gente aqui no GUJ nem deveria divulgar projetos, brasileiros ou não, sem testes unitários como maneira de forçar as coisas melhorarem.

[]s
Luca

pgoncalves

cv , concordo plenamente com você…

os testes unitários são importantes, quanto a isso não vamos nem entrar em discução. O projeto ainda é novo, estamos passando por um processo de flexibilização dele, até porque era um framework fechado dentro da empresa, como o próprio rógel disse, mais aos poucos vamos deixá-lo da maneira que agrade o maior número possível de pessoas e empresas.

Sérgio, fico agradecido pelo elogio que você vez… ainda mais você!!

[]'s

bgbraga

Galera, concordo plenamente com a importancia de testes unitários. Principalmente em um framework que vai ser a base de uma aplicação.

Mas não é porque não tem teste que devemos parar de divulgar novos projetos, ou projetos antigos.

Acho que seria mais legal uma campanha ao invés de proibir.
Vamos liberar e dar apoio para que os projetos cresçam e tenham testes, ao invés de virar as costas no primeiro suspiro de algo novo, ou de algo que precisa de ajuda - da nossa ajuda.
Então o projeto precisa da nossa divulgação, da nossa conscientização, dos conselhos e experiencias que todo mundo já passou, seja com testes ou em outras áreas.
Acho que precisamos disso, de andar junto. Não de ditadura, afinal essa epoca não está mais na moda :stuck_out_tongue: (sem querer criticar, entendo as preocupações de todo mundo)

Bom, agora quanto ao tópico… pessoal do Neo, parabéns pela iniciativa! Gosto de toda essa dedicação a produtividade. Meu artigo da Mundo Java desse mês é até sobre algo nesse sentido. Fala muito de produtividade.
Vi um vídeo do neo, mas não avaliei a solução como um todo ainda.

E dando um puxão de orelha mais ao meu estilo, espero que não esqueçam dos testes. Nesse perfil de aplicação, eles são quase obrigatorios para dar credibilidade a um framework que vai ser core de uma aplicação em produção.

No geral gosto das idéias do Luca, espero que nesse caso ele ajude a divulgar o projeto de vocês. Sei como isso é importante.

Abraços,

bgbraga

ah outra coisa: coloquem o fonte do projeto hospedado em um host de projetos opensource. Não precisa fazer isso com o site todo. Mas com o fonte é importante.

Assim garante que amanhã a linkcom não vai desligar o server e todo mundo ficar sem acesso aos fontes (de um projeto que está em produção por exemplo). Ou seja, é legal os fontes e talvez a até a documentação estarem em um SVN ou CVS publico.

Somente sugestões…

flw

pgoncalves

Ai bruno tranquilo???

Quando a hospedagem do svn e dos downloads já providenciamos, estou apenas esperando o source forge liberar a conta… mais em breve já iremos alterar tudo, provavelmente na segunta já está tudo migrado.

Concordo também que os testes unitários são importantes, mais se começou sem o que podemos fazer é ir testanto tudo, mais como tudo demanda um certo tempo vamos demorar um pouco para executar isso.

obrigado…

G

Pessoal,
parabéns pela iniciativa. Tenho acompanhado um projeto baseado no NEO (na prática), e vejo que, mesmo sem os “testes unitários”, todo o sistema está sendo bem implantado. Só para se ter uma idéia, foram mais de 20.000 horas de desenvolvimento e mais de 15 analistas envolvidos.
Continuem com o bom trabalho e boa sorte.

saoj

Má fé e canalhice são esses tipos de comentários que vc faz, CV, que só tem por objetivo denegrir o framework dos outros se apegando a qualquer crítica com o simples intuito de fazer propagando negativa. Antes era a questão das POJO actions. Agora como não dá mais para falar sobre isso, então fala-se dos testes unitários. Amanhã será do nome que é uma merda. Acho que vc deveria ter testes automatizados, que rodariam sempre que vc começasse a digitar uma resposta aqui no GUJ…

O Mentawai mesmo sem testes unitários é usado e aprovado por muitas pessoas e empresas. E isso deixa a gente muito feliz, mesmo que algumas pessoas prefiram falar que é uma merda porque não tem testes unitários… Por que será que elas adoram bater nessa tecla? Não é difícil perceber as reais intenções por trás desses comentários…

Não queiram transformar esse tópico em mais um flame… Tenham respeito pelo tópico sobre o framework NEO.

Eu gostei da filosofia do projeto, que é elevar o nível de abstração um passo a frente, coisa que como vc falou muito bem, é tudo que a grande maioria dos frameworks não faz, ficando no feijão com arroz do controlador e das actions.

Parabéns e depois vamos bater um papo para trocar umas idéias…

cv1

Ah vá saoj… se vc quer insultar pelo menos seja criativo e nao use o mesmo insulto de volta. Coisa besta, sô.

A proposito, os meus comentarios costumam ser de mah fe e eu tento ser o mais canalha que posso sempre que dah, entao agradeco o reconhecimento.

Er… pq tem gente que se tocou que escrever software sem tambem escrever a prova de que ele funciona eh uma irresponsabilidade absurda?

Tudo bem ficar feliz que o Menta tenha crescido tanto - eu tambem ficaria, claro - mas faltou explicar pra todos os usuarios do Mentawai qual o risco que eles estao correndo.

saoj

Insultar outra pessoa é algo que me ensinaram que não se deve fazer e só demonstra nossas inseguranças e fraquesas. Não que eu nunca tenha insultado ninguém na minha vida, mas todas as vezes que o fiz fiquei no mínimo envergonhado.

O risco é que pode ter bug… Sorte a nossa é que temos uma comunidade ativa e amiga, que já trocou mais de 10 mil mensagens no forum, e que está sempre sugerindo melhorias, apontando bugs, incentivando, etc.

Os bugs que são reportados são corrigidos no mesmo dia e um jar beta é disponibilizado no site. Quem tiver curiosidade pode procurar por “jar beta” no forum do menta.

Vamos selar a paz e deixar o tópico sobre o NEO fluir sem flames?

felipec

Bom…

Eu curti o NEO e a iniciativa…

A cada dia que passa acho os testes unitários mais importantes mas eu mesmo nunca tive paciência de implementar nos meus projetos… Agora que o projeto é livre, a comunidade pode ajudar a testar o software… e criar os testes…

Só não acho legal criticar o software porque ele nao tem testes unitários…
Alguem pode ter testado ele exaustivamente dentro da empresa… vai saber…

Parabéns pelo projeto.

fabim

AMAZING!!!

Concordo com o sérgio… o que vem pra facilitar é sempre bem vindo…
e axei que ficou muito style…

cv1
crítica s. f.,

1 - arte de julgar o mérito das obras literárias, artísticas ou científicas;

2 - exame, apreciação que se faz de uma obra;

3 - discussão de factos históricos;

4 - estudo ou análise de textos, investigação;

5 - critério;

6 - maledicência;

7 - apreciação desfavorável;

8 - censura;

9 - conjunto dos críticos.

Enquanto a gente se mantiver longe dos itens 6 e 8, eu acho que eh legal, sim.

Exatamente por causa desse “vai saber” que eu prefiro nao usar ate alguem me mostrar que de fato isso aconteceu. :wink:

pgoncalves

Concordo Plenamente com você, e como o felipec disse:

felipec:
ó não acho legal criticar o software porque ele nao tem testes unitários…
Alguem pode ter testado ele exaustivamente dentro da empresa… vai saber…

O framework é utilizado em muitas empresas, dentre elas a universidade FUMEC em belo horizonte, que tem mais de 15.000 usuários do sistema academico mais 1000 funcionários e professores, A fundação ezequiel dias também é usuário do framework.

Gostaria de lembrar que BUGS existem, não tem como conviver sem eles, tá certo que com os testes unitários eles diminuem, mais no nosso caso sempre que é encontrado um bug o mesmo é corrigido e publicado rapidamente.

Gostaria que não fosse mais discutido sobre este assunto, pois não queremos mais discuções sobre o assunto. E CV vamos providenciar testes unitários para você ficar mais feliz.

Obrigado…

Hal_Jordan

esse cv deve tá ficar mostrando esses post para o Martin e falar: ‘Tio, tio… Eu fiz certo né!!! esses bobões não fazem testes e merecem ser destruidos…’

Sim, o framework precisa de testes unitarios, e sim é uma forma de garantir a qualidade do produto, poremmmm… Isso não impede do framework ser bom, ter seu valor, etc… Quer dizer, Struts é bem testado e é um lixo…

O projeto foi disponibilizado agora, e como o rógel disse, foi desenvolvido para as necessiades da linkcom e agora que se transformou em open source que será voltado a atender as necessidades da comunidade, ou seja, deverá possuir testes unitários, etc…
haha… deixa pra la

maquiavelbona

Galera, respeito é bom, todo mundo gosta e evita que um dia você possa estar andando na rua e um carro passe por cima de você (não que eu vá fazer isso).
Testes unitários, para algumas pessoas é tão fundamental quanto o código a ser testado, então por favor, vamos moderar os ataques. Sucesso não quer dizer que o software é totalmente funcional e nem testes quer dizer que ele seja bem escrito.
Muita gente ficaria mais tranqüila em testar o framework se o mesmo tivesse passado por esse processo de qualidade - inclusive eu. Outros preferem que ele seja funcional e tenha um tempo de “beta jars” curto.

Só peço mais uma vez, galera, moderem os impulsos e se mantenham na parte técnica da tecnologia.

Até!

Obs.: Copiando o comentário antes que pareça que eu estou falando sem motivo.

Hal Jordan:
esse cv deve tá ***

Ae qdo tiver aparecermos com testes unitários e ser suficiente bom ***…

rogelgarcia

Olá Pessoal, sou eu denovo…

Agradeço as opniões sobre o framework.

O NEO é um framework que está sendo utilizado para desenvolvimento de aplicações há dois anos. Muitos testes já foram feitos e o framework já está bem estável. É claro que agora, como um projeto open-source muitas funcionalidades novas serão necessárias. E novos bugs serão encontrados, e corrigidos.
A intenção é que, com o passar do tempo, o projeto fique mais robusto, inclusive com testes para termos uma garantia maior.
Tempo é necessário para fazer essas atualizações, por isso não temos tudo pronto agora.

O importante é que novas funcionalidades, bugs e sugestões sejam sempre passados para podemos melhorar o frameowrk…

Já estou formulando a versão 3.4 que terá as mesmas funcionalidades da versão atual. Mas, com mais documentação (inclusive no estilo Spring, que é realmente boa) e mais flexível.

Saoj! Vamos trocar uma idéia sim…

Até mais…
Valew

saoj

Calma, vc tava indo bem mas assim vc perde totalmente a razão… Leia o meu post sobre insultar alguém e edite isso o mais rápido possível…

Hal_Jordan
  1. :?: :shock:
fabiofalci

rogelgarcia:

Já estou formulando a versão 3.4 que terá as mesmas funcionalidades da versão atual. Mas, com mais documentação (inclusive no estilo Spring, que é realmente boa) e mais flexível.

Exato!
Rogel, aqui na minha empresa atual também desenvolvemos um framework com alguns conceitos parecidos com o NEO.

Na primeira implementação não tinha testes untiários e nem muito javadoc. Vou te falar que chegou
um momento que era muito difícil mexer/editar o framework por causa desses fatores.

Então teve um refactoring grande, até criamos um novo projeto que tem como regra: javadoc compreensível e testes unitários.

Só compartilhando essa experiência que tivemos aqui que com certeza vai ajudar vcs!

bzanchet

É examente isso que tu não podes garantir, pelo fato de não haver testes unitários.

saoj

É examente isso que tu não podes garantir, pelo fato de não haver testes unitários.

Eu teria muito a falar sobre o porquê de eu não concordar com essa afirmação, mas não vou incendiar ainda mais essa discussão e criar um FLAME gigantesco dos amantes de JUnit versus os não-amantes de JUnit. Sugiro criar um outro tópico, tipo: Vc acha testes unitários essenciais para a vida?

[color=“blue”]“O seguro do seu carro, não é desculpa para vc dirigir de qualquer jeito. Se vc começa a fazer muita besteira ao voltante, o seu seguro vai ficar cada vez mais caro, até um belo dia que vc vai dar perda total no seu carro e a seguradora não vai te pagar. Sua única saída será comprar outro carro! Veja que o Seguro é apenas uma comodidade, que não justifica dirigir de qualquer jeito! Se vc tem utilizado muitas vezes o seu seguro, alguma coisa está errada com o seu jeito de dirigir! Não que seguro não seja bom, mas mais importante é o seu jeito de dirigir!”[/color]

rogelgarcia

fabiofalci e bzanchet a opnião de vocês é interessante. No caso, apenas eu modifico o NEO (até hoje), e caso outra pessoa venha a mecher eu verifico as modificações. Mas realmente os testes são importantes, não foram implementados ainda mas vou pensar seriamente em já colocar os testes unitários na versão 3.4.

A idéia da versão 3.3 seria mais como ‘evaluation version’ uma versão mais para testes, ou aplicações menores, para realmente sentir o framework. Com esses testes do comportamento do framework, opiniões surgirião, e as dificuldades maiores seriam corrigidas, talvez até com alguma refatoração para a versão 3.4.

Obrigado pela opnião

Hal_Jordan

rogelgarcia:
fabiofalci e bzanchet a opnião de vocês é interessante. No caso, apenas eu modifico o NEO (até hoje), e caso outra pessoa venha a mecher eu verifico as modificações. Mas realmente os testes são importantes, não foram implementados ainda mas vou pensar seriamente em já colocar os testes unitários na versão 3.4.

A idéia da versão 3.3 seria mais como ‘evaluation version’ uma versão mais para testes, ou aplicações menores, para realmente sentir o framework. Com esses testes do comportamento do framework, opiniões surgirião, e as dificuldades maiores seriam corrigidas, talvez até com alguma refatoração para a versão 3.4.

Obrigado pela opnião

Ae rapa… agora q c apareceu no post né…

rogelgarcia

Eu não tinha achado ele antes…
:smiley:

Mas tem post meu lá na primeira pg…

Luca

Olá

Sérgio, se algum dia alguém o criticar aqui não será por falta de elegância porque neste quesito você é um professor de todos nós. Falo isto sério. Obrigado por ser assim.

[]s
Luca

saoj

:shock: :slight_smile: A gente tenta… :wink:

Fabio_Kung

mas Sérgio, a analogia com seguros foi horrível! hehehe

F

Fabio Kung:
mas Sérgio, a analogia com seguros foi horrível! hehehe

Ainda mais que o seguro na maioria das vezes nao é feito por causa de acidentes.

]['s

Z

Verdade. Eu aceitaria com maior prazer se o preço de seguro fosse reduzido pela metade e a cobertura fosse apenas pra roubo de carro.

Hoje em dia, a chance de você ter o carro roubado é um milhão de vezes maior do que sofrer um acidente com P.T.

bzanchet

Olá!

A analogia é meio torta, mas mesmo assim é fácil de rebater: “Se vc começa a fazer muita besteira ao voltante, o seu seguro vai ficar cada vez mais caro, até um belo dia”… você para de fazer besteira pro seguro não encarecer tanto. Como o TDD, que favorece um design “mais testável” exatamente por causa da complexidade que os testes podem assumir, e implica em maior descoplamento, o que é bom.

Mas vamos tentar uma analogia semelhante: e se o seu carro tivesse um sistema automatizado, que antes de você dar a partida, checasse se esta tudo OK, se tem óleo, se tem água no radiador, se tem combustível, se a kilometragem da revisão está próxima? Você pagaria por isso? As montadoras investiriam nisso? Peraí, acho que já fazem.

(Tá, mas vamos evitar analogias daqui pra frente. Os argumentos ficam mais inteligíveis. :D)

Fabio_Kung

Desculpa desvirtuar o assunto do tópico, mas isso já existe amigo. As seguradoras chamam de “cobertura para roubo e incêndio”.

brunohansen

Acho toda essa dicussão de fazer ou não testes, muito lucrativa para todos!

Só não pode ficar com toda essa magoa pessoal! Pois acho que essas discussões pessoais nem cabem mais aqui no forum! Já ta feio!

Queira nós ou não paradigma de teste já esta ai e tem um monte de estudos que me faz usa-lo!

Agora ae pra galera que não curte teste! Por que vcs não fazem um estudo para provar a não necessidade de teste em desenvolvimento de softwares de qualidade? Quem sabe esse paradigma não seria quebrado! Acho que seria muito legal ter um estudo para dar base ao desenvolvimento sem testes!

Ae Sao vc que um cara que gosta de estudar, gosta de trazer facilidades para o nosso mundo do desenvolvimento e não é muito apegado a teste por que vc não faz um estudo desse? Acho que capacidade não te falta e seria mt legal para nós aprender com seus estudos!

[]s

Z

Desculpa desvirtuar o assunto do tópico, mas isso já existe amigo. As seguradoras chamam de “cobertura para roubo e incêndio”.
Oush. Eu pensei que fosse o contrário: o seguro básico é contra acidentes e se o cara quiser proteção contra roubo (e incêndios), aí sim “adicionaria” mais esta cobertura no contrato. Achava que não pudesse assinar só eles.

Bom saber.

renatosilva

Hum. Mesmo que tenha testes, os testes são confiáveis? :mrgreen:

F

Tendo testes isso é facil descobrir. Acho que esse argumento nao foi dos melhores. :lol:

Luca

Olá

Pode ser que um projeto tenha testes unitários mas que não haja cobertura para os principais algoritmos. Pode ser também que se perceba que quem escreveu os testes tem pouca experiência nisto. Há diversas maneiras de se verificar estas coisas.

Mas desde que existam testes unitários.

O importante desta discussão toda neste tópico nem é para este framework em si. É para mudar a cabeça de desenvolvedores que não estão habituados a escrever testes.

Dizem que há 3 tipos de desenvolvedores:
1- Os que aceitam os conceitos de testes unitários e adotam com naturalidade
2- os que aceitam o conceito mas só adotam se forem obrigados
3- os que não adotam de jeito nenhum porque acham que suas práticas antigas são melhores.

Toda esta discussão aqui é para diminuir o volume de gente do tipo 2. Alguns do tipo 3 serão eliminados pouco a pouco do mercado naturalmente. A menos que visitem o link da minha assinatura e experimentem o JUnitFactory.

[]s
Luca

ASOBrasil

Concordo com os 3 pontos citados pelo Luca.

Luca:

Pode ser que um projeto tenha testes unitários mas que não haja cobertura para os principais algoritmos…

Por isso o ideal é usar também uma ferramenta (EMMA, por exemplo) que mostra que o seu código foi todo testado e/ou o que não foi testado também. Mas é claro que isso também não garante a qualidade dos testes.

Rubem_Azenha

Nada garante :slight_smile:

Eu posso pegar o JUnitFactory e gerar todos os testes do me u projeto. E ter 100% de code cover. Isso vai garantir alguma coisa? :slight_smile:

renatosilva

Tendo testes isso é facil descobrir

Ou seja, para saber se os testes são confiáveis, basta que eles existam?

Argumento ou apenas uma pergunta bem-humorada?

Luca

Olá

microfilo:
Nada garante :slight_smile:

Eu posso pegar o JUnitFactory e gerar todos os testes do me u projeto. E ter 100% de code cover. Isso vai garantir alguma coisa? :)

Você não leu a documentação nem assistiu aos vídeo que lhe passei. :oops:

Leia mais sobre TDD, cobertura de testes e tudo o mais. Se um projeto tem 100% de cobertura, o que é muito raro, significa que tudo foi testado.

Isto não é garantia de um bom produto. Eu por exemplo, não quero nada que use o Struts 1 ou EJBs < 3.0, mesmo que tenha 100% de cobertura de testes. Mas se fosse usar me sentiria mais seguro.

[]s
Luca

Luca

Olá

Vou acertar a frase que você deixou meio sem sentido:
[color=darkred]É possível saber se os testes são confiáveis, desde que eles existam [/color]

[]s
Luca

renatosilva

Que, Luca?

Rubem_Azenha

Opa, eu assisti o vídeo sim :smiley: e gostei :slight_smile:

Lendo essa parte do post, eu presumo que você concorda comigo que o fato de eu ter testes unitários não garante que meu código funciona e nem que eu tenho boa fé, nem garante que eu não sou um canalha.

Proteu_Alcebidiano

Em síntese, com a existência dos testes você pode aferir se o teste do código é condizente com um possível real ponto de entrada da aplicação no codigo a ser testado.

Testes confiáveis não são escritos de qualquer maneira. Testes escritos de qualquer modo sao feitos por pessoas que se sentem obrigadas a escrever os testes e acham que isso é trabalho redundantemente desnecessário.

como um amigo falou certa vez, testes mal escritos é coisa que desenvolvedor só faz mesmo “pra inglês ver”.

T+

Luca

Ola

Se existem nós podemos vê-los. Examinar por amostragem. Executá-los. Verificar a cobertura.

E raciocinando ao contrário. Como avaliar a qualidade dos testes se eles não existem?

[]s
Luca

Luca

Olá

Completamente errado.

O que eu escrevi é que que a existência de testes não faz o Struts melhorar. Mas dá segurança a quem vai usar, ou seja, garante o funcionamento do código de forma unitária.

É óbvio que pode não funcionar como um todo. Para verificar isto se usam testes funcionais.

[]s
Luca

renatosilva

Como se testa testes? Lendo-os?

cv1

Eh importante lembrar, tambem, que uma aplicacao com testes eh bem mais facil de refatorar do que uma onde voce nao tem a minima ideia do que vai acontecer no sistema se vc renomear um metodo.

cv1

O que vc sugere como alternativa? :wink:

Calvin

O que vc sugere como alternativa? ;)

Agora o renato3110 irá começar a filosofa?!

Podemos dizer assim também: Como você testa o que usou para testar os testes feitos! :shock:

Além de você ler e conferir o que foi feito, pode dar os testes para outro analista (que esta fora do projeto) verificar o que você fez. Se tratando de testes sempre acho importante ter a opinião de um analista que esta fora do projeto

Abraços

eric_jf

Se o teste falhar, o erro pode ser tanto do teste ou pode ser da classe testada.
Então a propria intereção do teste com a classe, testa os dois.

O que pode acontecer é q seu teste não está completo, cada vez q aparecer um novo erro que não passou no seus teste. Vc deve adicionar um teste que vai detectar o erro e depois vc conserta o erro, e vai ser muito mais rapido porque é bem mais rapido rodar o teste do que vc verificar.

renatosilva

O que vc sugere como alternativa? ;)

É muito chato ter que explicar piadas :stuck_out_tongue:

A partir de agora, falando sério: eu realmente estou com curiosidade de saber. Aos desavisados, eu não programo, por isso não testo.

Cv, eu não sei como se confia nos testes! Talvez só colocando a mão na massa pra entender o que você quer dizer, certo? Essa é minha dúvida.

Aos interessados, minha opinião: pra mim os testes são sim um dos requisitos mínimos para que um projeto apresentado à comunidade seja levado a sério. Não é questão de que o sofware seja uma enorme bosta, mas sim de fazer um trabalho profissional.

renatosilva

Apesar de tudo ser muito abstrato pra mim, simpatizo com essa filosofia do criador do framework ae de facilitar as coisas, criando camadas de abstração em cima de produtos já consolidados. Na minha opinião particular, é uma enorme falta da plataforma Java: você pode até fazer coisas mirabolantes, mas tem que “falar” muito código.

Boa sorte ao pessoal do framework, e façam os testes!

Calvin

Desculpa!
Não consegui perceber sua expressão facial para ver que você estava bricando!

Na próxima tenta colocar um emoticons :smiley: :slight_smile: :shock: :twisted: :evil: ou apenas uma risada aHUhauAHUhauAHUah hehehehe hahahaha rs rs rs rs

E encare isso com bom humor!

Abraços …

C

Essa história de “quem testa os testes” é um dos maiores papos furados.

  1. Se fôssemos levar esta história adiante, entraríamos em um loop infinito do tipo “Quem testa X?”, e “Quem testa quem testa X?”, etc.

  2. Quem está acostumado a fazer TUs sabe que é altamente recomendável inserir algum erro no código testado, para ver se o teste realmente está falhando. Isso já ajuda muito.

renatosilva

Paulo Roberto Schiavon:
renato3110:

É muito chato ter que explicar piadas :stuck_out_tongue:

Isso era outra piada :stuck_out_tongue:

saoj

Seria bom abrir um outro tópico sobre isso…

Minha opinião não é o correto, até porque o correto é subjetivo… Mas é a minha opinião no momento, que está aberta a mudanças e adequações, mas nesse momento é a minha opinião… Ok, eu sempre vou demorar um pouquinho para arredar o pé, mas isso faz parte do aprendizado…

Um FRAMEWORK é um sistema com uma finalidade definida: servir de base para o desenvolvimento de uma aplicação ou de um outro framework.

Um método público que realiza um determinado algorítimo dentro dele será testado uma única fez: no ato da codificação.

Futuramente se vc precisar alterar o algoritimo dentro dele, o que deveria ser raro, pois vc já testou e já fez o release daquele método para o público, vc tem que considerar algumas coisas:

  • Se vc fizer cagada ali vai tomar um esporro e/ou perder o emprego. Não existe alterar um método que já está funcionando e quebrá-lo. Sim as vezes isso vai acontecer, pois ninguém é perfeito, mas cada vez que vc alterar um código que já estava funcionando e quebrá-lo, vc tem que se sentir o pior programador do mundo.

  • Vale a pena considerar se não é 10 vezes melhor e mais seguro: Criar outro método (que pode fazer uma chamada para o método original) OU Estender a classe e dar um override no método (que pode fazer uma chamada super para o método original)

Vejam que OO foi desenvolvido exatamente para ESTENDER SEM QUEBRAR. Para que serve herança e métodos protected? Para que serve override?

Logo quando estou codificando o Mentawai ou o framework da empresa onde trabalho todo cuidado e concentração é pouco. Alterar uma lógica e quebrá-la ou, igualmente trágico, quebrar o contrato do método é algo totalmente INADIMISSÍVEL.

Está claro pra mim, pela minha experiencia com o Mentawai e com outros frameworks que é plenamente possível estender um framework, sem introduzir novos bugs e sem quebrá-lo, apenas utilizando OO, uma boa arquitetura e disciplina.

Existe uma diferença fundamental em MODIFICAR e ESTENDER! Se vc começa a fazer diversas MODIFICACOES internas no algoritmo dos métodos, vc inevitavelmente está correndo o risco que quebrá-lo. Por isso ou vc faz com todo cuidado, seguindo uma coisa chamada LOGICA, ou vc testa ele novamente quando terminar sua alteração. O que vc não pode e não deve é quebrá-lo…

Agora quando vc ESTENDE a sua classe, vc está ADICIONANDO novas coisas, de forma que serão coisas novas que NÃO INTERFIRIRÃO com os contratos antigos. Se vc quando fizer isso quebrar todo o resto, há apenas três explicações possíveis:

  • Vc não sabe OO
  • Vc não sabe lógica
  • O seu sistema está muito mal feito, sem uma boa arquitetura e sem seguir as boas práticas de OO (mais provável!!!)

Não adianta apelar para testes unitários para te salvar aqui… Isso seria apenas tampar o sol com a peneira…

Agora tudo fica diferente quando falamos de uma APLICAÇÃO !!! Por que?

Porque uma aplicação não é um framework, porque um dia o seu chefe pode chegar e requisitar uma mudança no MODELO DE NEGÓCIOS e não faz sentido vc extender o seu modelo de negócios. Modelo de negócios não é interface… Então vc vai ter que modificar o seu modelo de negócios diversas vezes ao longo da vida da sua aplicação e fazendo isso vc vai invariavelmente correr um grande risco de quebrá-lo. É nesse momento, e nesse caso em específico que os testes podem te ajudar.

O que os testes devem testar? Os métodos individuais do seu modelo de negócios? Sim eles podem fazer isso (famosos testes unitários), mas os bugs geralmente ocorrem mediante a integração/comunicação entre diversos métodos do seu modelo de negócios, e não apenas num único método… Até porque muitas vezes vc é obrigado a eliminar/modificar métodos por completo…

O que precisamos testar são os processos que o nosso modelo de negócios trata !!! Casos de uso mesmo… Ex: Um usuário do grupo “Funcionários” acessa o sistema, faz um novo cadastro de uma tarefa, dá logout, depois volta e modifica a data de deadline, depois faz outra coisa, etc e tal.

Então minha conclusão até o momento: Framework não tem modelo de negócios, tem API e interface… Depois que ele entra na versão stable, vc estende ele usando as boas práticas de OO e respeitando os contratos…

Aplicação tem modelo de negócios e vc vai precisar fazer diversas modificações nesse modelo de negócios ao longo da vida da aplicação porque invariavelmente as funcionalidades e necessidades vão mudar a todo o momento. Coisas que vc nem tinha imaginado vão entrar e é nessa hora, quando vc tiver que fazer alterações meio cabulosas no seu modelo é que os testes podem te ajudar bastante.

É por isso que eu acredito firmemente que um framework pode evoluir sendo estável, sem criar bugs de regressão e sem quebrar os contratos anteriores. Pra isso que existe OO e se vc modificou uma coisa no seu framework e distruiu outra lá do outro lado, o problema é muito maior do que uma simples ausência de testes. Logo, para um framework, testes não são a garantia de absoutamente nada, muito pelo contrário, eles podem na verdade estar disfarçando/sustentando um framework mal-feito, um verdadeiro spagetti code procedural…

cv1

Putz.

renatosilva

Se algum testeiro entendeu minha dúvida e quiser responder, eu quero aprender.

pcalcado

Não me faz muito sentido, Sérgio. Não importa o paradigma, software é passível e bugs e deve ser testado.

Esquecendo a coisa realmente boa que é modelar orientado a testes (o que se faz com TDD), testes de regressão, smoke testes, integração, etc. são parte importante de qualquer processo de desenvolvimento que se preze.

Abstração e encapsulamento ajudam a gerenciar dependências e a fazer com que mudanças em módulos (classes, no caso) não afetem drasticamente outro, mas isso existe muito antes de OOP virar algo comum (vide Yourdon e Page-Jones com projeto Estruturado de Sistemas nos anos 80). Um sistema bem construído em programação procedural tem um nível de acoplamento bem próximo de um bem construído em OOP, e isso não tem nada a ver com protected, private ou o que for. Testes semrpe existiram e sempre foram necessários, independente da característica do paradigma ou da proficiência da pessoa neste.

Enquanto você codifica possui toda a lógica que está escrevendo na cabeça, mas esse é um breve momento. Ainda que você seja o único a manter um sofwtare não vai conseguir lembrar todo o necessário para garantir que haja de maneira correta. Em linguagens sem DBC integrado, como Java, C# e Ruby, o problema é ainda maior porque não há uma maneira clara de identificar um erro de quebra de contrato sequer em runtime. A única maneira de validar um contrato é testando o sistema, e sem testes automatizados essa tarefa é completamente ineficiente, se é que é eficaz.

E mais: é fato normal e muitas vezes diário alterar contratos. Ainda que você consiga manter sua interface interna relativamente a mesma, talvez depreciando um método, a interna vai ser alterada com uma certa frequência e cada alteração de um contrato altera o ecossistema. Se toda vez que eu alterar um método tiver que realizar uma busca pelas vezes que ele é invocado (o que em sistemas cheios de reflection como um framework MVC é muitas vezes inviável) e conferir se devem ser alterados eu caio num processo manual dispendioso e ineficiente. A partir do momento em que eu tenho os contratos sendo validados por testes, unitários ou não, eu verifico o comportamento do sistema quando há a mudança e, de quebra, ainda ganho uma lista de todas as coisas que quebraram.

R

Pessoal do NEO,

Parabens pela iniciativa e tenho certeza que diversas pessoas que postaram aqui contra vcs , fizeram isso pq nunca consiguiram ter coragem de fazer o que vcs fizeram.

Sobre os testes, acho que nao é bem esse o objetvo do tópico , mas como o pessoal resolveu falar de testes, tbem queiro deixar minha opiniao:

Os testes são importantes sim, e iniciam no requisito e vao até o Pós-producao, qq um que já trabalhou numa empresa de maior porte sabe disso.

Sobre os testes unitarios no NEO, acho que devem pensar sim, mas acho que o momento nao é pra isso, já que existem varias tecnicas e ferramentas de testes unitarios.

Pra ser mais sincero, nunca vi ninguem levar isso a sério, esse papo é mais acadêmico que qualquer outra coisa.
No caso deste POST, como ninguem quiz começar usar, encontraram esse argumento para te descartar.

Várias(quase todas) empresas com CMMI e etc, fazem tudo nas coxas, ou contratam um teórico para criar planos de testes de componentes, que geralmente sao diferentes do requisito, da construcao e da producao.

Minha opiniao é que devem continuar firme com o NEO, e mais, proporcionar facilidade para construcao de sistemas baseados em Ajax
ou Flex. Acredito que isso seria um grande diferencial.

Outro ponto que aconselho, seria desenvolver um aplicativo simples e funcional de exemplo, para acompanhar o framework e guiar nas melhores práticas.

Abs

F

Nao é o momento mas existem ferramentas pra isso?

:shock:

]['s

Z

Sérgio, o pensamento de “se tá funcionando, deixa como está”, que foi o que consegui entender em umas partes do seu post, vai de encontro com muito do que é conhecido hoje como boas práticas de desenvolvimento. Aliás, não só isso, esse pensamento é um dos princípios de programação orientada a gambiarras. Realmente me assusta um programador experiente como você defender a teoria de que se tá funcionando, deixa como está… e esquecer coisas como refactoring.

Eu conheço o Mentawai apenas como usuário do framework (satisfeito, até). Infelizmente, não conheço a equipe de desenvolvimento e nem a metodologia, mas com essa linha de pensamento que anda em sentido contrário com o de refactoring, fico receoso de vocês estarem criando um bicho papão, que vai se tornar um pesadelo na hora de refatorar.

saoj

ZehOliveira:
Sérgio, o pensamento de “se tá funcionando, deixa como está”, que foi o que consegui entender em umas partes do seu post, vai de encontro com muito do que é conhecido hoje como boas práticas de desenvolvimento. Aliás, não só isso, esse pensamento é um dos princípios de programação orientada a gambiarras. Realmente me assusta um programador experiente como você defender a teoria de que se tá funcionando, deixa como está… e esquecer coisas como refactoring.

Acho que vc entendeu tudo errado, tudo ao contrário. “Se está funcionando deixa como está” não foi o que eu falei. Isso se aplica mais para frameworks que se escondem atrás de testes, ou seja, “se passou nos testes então o código é bom”.

O argumento de que se nõa tem testes não tem refactoring é fraco. Temos um framework que já evoluiu para a versão 1.10 e esse não é o meu sentimento… O próprio eclipse faz um monte de refactoring automatizados… Enfim…

Bicho papão é uma coisa muito diferente… Vc é livre para usar o que quiser e para fazer essa propaganda negativa se agarrando somente num argumente teórico bobo de que se não tem testes é ruim… Se está receoso fique a vontade para não usar, mas tenha certeza que muitas outras pessoas não pensam como vc. Usam, gostam e confiam. Em breve teremos testes unitários pra tudo… Com o simples intuito de satisfazer os apaixonados por testes unitários… Aí sim: o framework vai ficar maravilhoso, perfeito, estensível, suportando refactoring, etc. (Quanta ilusão!)

Nunca tive problema algum com isso, e olha que já passei por diversas empresas, grandes e pequenas. Nunca ninguém me perguntou numa entrevista se eu gostava de testes unitários. Estavam preocupados com outros skills… Mas enfim, não tenho dúvida que deve haver empresas que vão achar que “código bom, é código que aparece verdinho no final do build com Junit”, e profissional bom, é profissional que faz testes… Nessas empresas, para o bem delas e para o meu bem, eu espero ser barrado na primeira fase da entrevista… Entrar na empresa errada, assim como casar com a mulher errada, é receita para muita dor de cabeça…

E mais uma vez: Não que teste não seja bom. Teste é bom, e ter testes vai ser sempre mais desejável do que não ter testes… Agora francamente, ficar se apegando nesse ponto para desacreditar um sistema, chamá-lo de bicho papão, etc. é como dizer que um cara que não tem certificado Java é um merda e que um cara com certificado Java é 10 vezes melhor do que um cara sem certifado. Meu feeling é totalmente o oposto disso, ou seja, há muitos profissionais por aí sem certificado e sem faculdade que são 10 vezes melhores do que profissionais formados e com certificados.

Z

Beleza. Confirmou o que todo mundo achava. Vocês estão metendo refactoring no código sem nenhuma garantia de que não estão quebrando outras partes do sistema. Ótimo.

Mas não precisa ser falacioso e tentar rebaixar o que eu disse usando termos como “ilusão”, “maravilhoso”, “apaixonados”, “outras pessoas não pensam como você”. Eu sou usuário do Mentawai, como já disse, mas fico preocupado como certas coisas são levadas no desenvolvimento deste. Se você não se preocupa com o que os usuários pensam, aí piorou.

Não estava argumentando contra você, nem contra o framework, nem contra nada. Eu só quis dizer que estava preocupado com o que aparentemente acontece no desenvolvimento do Menta. Mas isso é uma preocupação minha. Não esquente. :wink:

saoj

Me desculpe se fui muito enfático no meu post. Mas eu sou um eterno liberal e acho que estou enfrentando uma tropa de conservadores, que acham que testes unitários é tudo! O Mentawai ou o NEO, sem testes unitários, são um lixo e estão fadados ao fracasso. Uns verdadeiros bichos-papões.

Agora se foram usados em empresas, testados na prática, se possuem pessoas experientes tocando esses frameworks, etc e tal… Há isso tudo é um detalhe inútil perto da ausência de testes…

Não é errado gostar de testes unitários, assim como não é errado fazer uma certificação. Errado é achar que isso é fundamental e essencial para medir a qualidade de um framework ou de um profissional… E, na ausência de outros argumentos, é nisso que vcs estão se apegando para criticar/desmerecer os frameworks em questão… Isso é ruim…

hussan

hmmmm

não sei não, mas tem gente que gosta de ficar rebaixando o trabalho dos outros.

Já que o framework foi aberto agora, ele poderá crescer mais ainda e atender as necessidades da comunidade…

valeu pela iniciativa

ahhh, beleza… precisam ser feitos testes unitários, mas o que já foi feito não pode ser desconsiderado.

viva o mentawai, o neo framework e qualquer outro framework feito com muito suor e muito trabalho!

grande abraço

H2

esb

Sergio,

Eu acompanhei a discussão do MentaBeans de longe, e acho ótima sua iniciativa, assim como a do Mentawai. Sempre reclamam que brasileiro só usa a infra-estrutura criada pelos outros e não investe nesse setor, e quando o fazem, caem de pau. O problema não são as críticas, mas as críticas destrutivas, que não agregam em nada…

Enfim, só acho que você também se utiliza desse tipo de argumento, o que é triste, afinal, não devemos fazer para os outros o que não queremos para nós mesmos:

Testes unitários não servem pra tampar o sol com a peneira. Servem para, além de garantir que o código está funcionando para o que foi proposto, em conjunto com o TDD, garantir que não se vai construir além do necessário.

Pelo que eu venho lendo, acho que você não conhece TDD, e muito pouco de testes unitários. Seria interessante você ler um pouco a respeito, e quem sabe talvez seguir o conselho de outro colega e fazer uma comparação ou um artigo a respeito dos métodos de desenvolvimento…

Proteu_Alcebidiano

saoj:

Me desculpe se fui muito enfático no meu post. Mas eu sou um eterno liberal e acho que estou enfrentando uma tropa de conservadores, que acham que testes unitários é tudo! O Mentawai ou o NEO, sem testes unitários, são um lixo e estão fadados ao fracasso. Uns verdadeiros bichos-papões.

Agora se foram usados em empresas, testados na prática, se possuem pessoas experientes tocando esses frameworks, etc e tal… Há isso tudo é um detalhe inútil perto da ausência de testes…

Não é errado gostar de testes unitários, assim como não é errado fazer uma certificação. Errado é achar que isso é fundamental e essencial para medir a qualidade de um framework ou de um profissional… E, na ausência de outros argumentos, é nisso que vcs estão se apegando para criticar/desmerecer os frameworks em questão… Isso é ruim…

Posso estar absolutamente enganado, mas acho que se o nome empregado para garantir funcionamento, fácil refatoração, dentre outras coisas essenciais não fosse chamado de ‘teste’, as coisas seriam mais fáceis de serem aceitas, assimiladas, etc.

Considerando um exemplo fora da computação, o conceito de ‘Teste’ é como a parte externa de um elemento de máquina, por exemplo.

Quando você o martela, deixa marcas do martelo no elemento. Na manutenção de um software é a mesma coisa: você precisa saber que tipo de marcas aparecerão no produto quando você o modifica com a marretada.

Mesma coisa para aplicações em matemática aplicada. Como você pode assegurar o funcionamento de qualquer sistema físico se não houver algo que o assegure disto, tanto teoricamente (teoremas, lemas) quanto na prática (testes de fadiga, simulações, etc)?

Testes são úteis para saber como seu produto reage a intervenções externas em sua estrutura. Softwares também são máquinas, ainda que sejam intangíveis.

t+

saoj

Me desculpe se te passei essa idéia. Não quiz ofender, menosprezar ninguém. A questão é que defendo que quando vc estende um framework vc não deveria quebrá-lo. Se isso está acontecendo com uma certa frequencia, então há alguma coisa errada… Isso é diferente de quando vc MODIFICA um sistema, ou seja, modifica um algortimo de algum método por exemplo. Aí sim qualquer um vai correr um alto risco de quebrar a coisa e um teste, seja prático, unitário e/ou automatizado, vai cair muito bem.

Fabio_Kung

Sérgio, eu acho que aqui caberia o contrário. Desenvolvimento tradicional de software (e conservador, nesse contexto) até hoje foi ignorar os testes unitários automatizados.

Dar valor aos testes, TDD, BDD, … É tudo relativamente novo (ou que pelo menos caiu na “boca do povo” recentemente). No meu ponto de vista, ser liberal aqui é abrir a cabeça para isto. Exatamente o contrário do que você disse.

saoj

Tem razão. :slight_smile:

Estou sendo liberal por um lado, quando aceito que um sistema pode ser bem-feito sem testes unitários/automatizados e conservador por outro, quando não estudo mais a fundo TDD…

Lembrando que testes é fundamental, isto é, ninguém vai escrever código sem “testar”. Isso simplesmente não existe… Só que existem vários níveis de testes, desde de “se compilar, funciona” até testes automatizados para setter and getter*.

  • Se bem que um dia eu fiz isso e o Eclipse me alertou:
public void setName(String s) {

    this.name = name;

}

Acho que essas maravilhas do Eclipse acabam te salvando de muita dor de cabeça e “debugging”… O Eclipse acaba virando um testador as you type

Kenobi

SAOJ, entendo que às vezes falta tempo e etc… para criar testes, tarefa chata pra caramba !!

Vou te dar uma dica, já que seu projeto é Open e não precisa manter privacidade do código - http://www.junitfactory.org/

Bora, instala o plugin ae no eclipse e gere tudo !!

Fim da discussão !!

Luca

Olá

Passei isto para o Microfilo e ele ainda desdenhou.

Este negócio está na minha assinatura há 10 dias e depois de assistir o webcast do Alberto Savoia, não vejo mais desculpas para não ter testes em um projeto que pretende obter colaboraçào de outros.

[]s
Luca

fabiofalci

Olá!

Muito bom esse junitfactory…
Mas tem que ter um cuidado, se passar um método errado, ele vai gerar um teste errado pensando estar certo.
Então não é só substituir os testes unitário por completo pelo junitfactory.

Um exemplinho, um método que diz se um número é par. Se o programador fizer errado, olha os testes gerados…

public boolean isEvenNumber(int number) {
		return number % 2 != 0;
	}

        // testes gerados
    public void testIsEvenNumber() throws Throwable {
        boolean result = new HelloWorld().isEvenNumber(100);
        assertFalse("result", result);
    }
    
    public void testIsEvenNumber1() throws Throwable {
        boolean result = new HelloWorld().isEvenNumber(1);
        assertTrue("result", result);
    }
    
    public void testIsEvenNumber2() throws Throwable {
        boolean result = new HelloWorld().isEvenNumber(-1);
        assertTrue("result", result);
    }

Mas dai é pedir demais pra uma ferramenta! :smiley:

mister_m

O JUnitFactory na verdade gera testes unitários que funcionam mais como testes de regressão: eles garantem/deveriam garantir que se você mudar o código, não vai quebrar o que funciona.

Kenobi

Que talvez seja o caso de refactorings e plano de continuidade do Menta - o que estamos conversando para o futuro.

Concordo com o desenvolvimento orientado a testes - TDD, mas se o sistema já existe, essa é uma boa abordagem para pensar em futuro do mesmo .

renatosilva

Quer dizer que não é só porque tem testes que vou confiar de cabeça, como se passasse do bosta para a maraviha :stuck_out_tongue:

Z

Implementar teste pra código existente não vai fazer com que o código fique melhor ou mais bonito, mas deixará o programador mais seguro de que ele não vai quebrar nada quando for melhorá-lo.

Kenobi

Boa resposta :slight_smile:

cv1

Leitura obrigatoria:

maciel.bombonato

saoj:
Seria bom abrir um outro tópico sobre isso…

Minha opinião não é o correto, até porque o correto é subjetivo… Mas é a minha opinião no momento, que está aberta a mudanças e adequações, mas nesse momento é a minha opinião… Ok, eu sempre vou demorar um pouquinho para arredar o pé, mas isso faz parte do aprendizado…

Um FRAMEWORK é um sistema com uma finalidade definida: servir de base para o desenvolvimento de uma aplicação ou de um outro framework.

… continua …

Sergio, tudo bem?

Bom, nada pessoal, só uma opinião que venho formando de um tempo que tenho acompanhado as discuções aqui… sinceramente não li toda sua mensagem (nessa vc caprichou e escreveu pra caramba. rsss)… mas pelas partes que li de vc falando que um framework possui uma classe publica que dificilmente vai apresentar problemas e ter que ser alterada e que testes são feitos na aplicação e não no framework e blablabla… fiquei curioso e cliquei no link da sua assinatura, depois procurei forum e em seguida bug’s… bom… nem parei pra ler tb… afinal, lá também tem coisa pra caramba… mas resolvi só pra passar e deixar minha opinião… com tudo que estão reportando lá na parte de bug’s (novamente digo que não li), mas digo em relação a quantidade, vc acredita mesmo que está certo nesse ponto?

nessa questão de testes compartilho da opinião do Luca e o CV, acredito que eles devem ser feitos sim, porque isso garante que aquilo que está sendo proposto pela aplicação (framework) é feito e não dá pau… é esse o ponto… no que está sendo proposto vc afirma que está funcionando ou pelo menos tenta chegar o mais prox disso, agora vc disponibilizar uma ferramenta e simplesmente dizer “gente, eu fiz e agarantiu… funciona que é uma belezura” fica mais complicado.

PS: Pelo amor de Deus, sem aquelas considerações de que milhares de pessoas usam, empresas grandes usam, melhares de pessoas aprovam, estou falando de que para adotarmos uma ferramenta para ser utilizada em um meio coorporativo, é relativamente arriscado ir pelo lado do, “olha, é legal, simples e funciona que é uma blz.”

Novamente estou só comentando que essa é minha opinião, sem ofensas, ok? :wink:

grande abraço a todos.

saoj

Respeito a sua opinião, mas acho que vc usou um argumento um pouco estranho. Vc fala de bugs, né? Dizer que tem bugs é muito fácil… Vc queria que no forum de bugs tivesse o que? Bugs sobre o Struts? Zero bugs… 2 bugs ??? Isso seria se ninguém usasse o framework. Temos +10 mil mensagens no nosso forum, vários usuários utilizando, daí bugs e sugestões de melhorias são encontrados e reportados no forum. O número de mensagens sobre bugs aumenta. Conclusão: o framework é uma merda, cheio de bugs. Assim não compensa entrar no debate…

E vc não diferenciou bugs. Uma coisa é bug de regressão, outra coisa é bug em funcionalidade/feature nova. O primeiro pode e deve ser evitado a qualquer custo (com disciplina, boas práticas ou testes mesmo), já o segundo é inevitável por definição. A maioria dos bugs que tivemos está no segundo grupo… Mas vc jogou tudo no mesmo saco…

Depois eu leio o seu post com mais calma, pois agora estou em Beverly Hills a trabalho e amanhã cedo parto para New York… No caminho irei perguntar para o meu chefe porque ele não fez nenhuma pergunta sobre testes na minha entrevista, e porque nenhuma das nossas mais de 30 conexões eletronicas não possuem testes unitários… As conexões estão funcionando e gerando bastante dinheiro para a empresa, mas como não tem testes deve ter bugs, bugs, bugs como vc falou… Talvez vc fale que a empresa aonde eu trabalho é um lixo (já tive que ouvir isso aqui) , que os sistemas são uma merda e não funcionam porque não possuem testes… Isso é subjetivo… Mas tem uma coisa que não é subjetivo… Tem uma coisa que eu, vc, seu chefe, o meu iremos concordar: 1,000,000 dólares é maior do que 1,000 dólares… Com testes ou sem testes… Ainda bem…

“sem ofensas, ok?” Quem sou eu para te ofender? Achei o seu post bastante inconveniente, onde vc me acusa entre-linhas de um monte de coisas, mas não tenho porque te ofender… Pra que perder tempo te ofendendo? Amanhã quando chegar em Nova York eu entro aqui pra ver se vc achou mais algum bug lá no forum de bugs…

(Editado: dei uma olhada lá por curiosidade e tem 26 tópicos, alguns improcedentes e outros realmente bugs… Acho que para um framework que está aí a 2 anos, 26 posts na área de bugs é até pouco… eu gostaria que houvesse mais, principalmente se compararmos com o número de tópicos do fórum regular: 1170)

Z

Sérgio, estamos falando de software e da melhor forma de desenvolvê-los. Ninguém tá falando do faturamento da empresa que trabalha, até por que isso não é do interesse de ninguém. Uma coisa não tem nada a ver com a outra. Uma é o desempenho comercial da empresa e outra é a qualidade de software. Fica muito estranho quando você mistura os assuntos. Vamos manter a conversa presa da esfera da gente. Testes é uma garantia pro desenvolvedor, não pro negócio. É bom que isso fique claro.

eduveks

Caramba isto ta indo longe :stuck_out_tongue:

Em primeiro lugar parabéns pela framework e sucesso, mais um bom trabalho brazuca ai :wink:

Agora quanto as opiniões de testes…

Concordo com o Sérgio, e percebo a idéia dele.

Testes unitários só garante uma coisa, que não vai ter bugs idiotas, “apenas” bugs de lógica de negócio.

Mas isto é importante? Depende de quem esta desenvolvendo, um projeto que passou por testes e outro que não passou, que difença faz? O que não passou é pior do que o que passou? Quanto tempo a informatica e milhares de empresas teem envoluido e ganhando muito sem testes unitários? Agora por que surge esta de testes, então tem que ser obrigatório, e o que não tem teste é lixo?

Desculpa ai mas isto é pura ignorância, e falta de sentido da realidade, na realidade de hoje, talvez nem 10% no máximo é código testado, garanto que no mínimo 90% do código programado hoje no mundo não vai passar por testes, e isto garante que 1 é pior que outro? Eu sinceramente não conheço nenhuma empresa onde seja obrigatório fazer testes, não na minha e não nas empresas concorrentes.

Quantas linguagens teem feramentas de testes unitários? E quantos programadores/empresas que usam as linguagens q teem, utilizam?

Testes não garantem nada, apenas é algo para poder dizer de boca cheia, que no método xpto podem passar um parâmetro null que não vai dar erro.

Mas isto não influencia nem no preço nem no lucro e nem na qualidade.

Até por que um bom programador, sabe que vai dar erro se vier um parâmetro esquisito, e sabe se é preciso previnir ou não. Não vai ser testes unitários que vai mudar tudo, e garantir que é uma maravilha ou não.

Eu sou a favor dos testes, acho q tem utilidade, mas não é algo que seja obrigatório, e que faça a diferença entre vinho e água.

Testes virou moda, e tem muita boa gente radicalizando isto…

maciel.bombonato

Sergio, tudo bem?

Pelo visto vc não entendeu quando falei sem ofenças.

Bom, vamos lá, primeiro, de nada me interessa se seu chefe ganha muito dinheiro ou se vc está na rocinha ou em new york, por favor, tente entender, estou dando a minha opinião em relação a processo de desenvolvimento de software.

Outra coisa, como já foi dito antes, testes não “melhoram a aplicação” (note que está entre aspas ok?) mas sim a confiabilidade que as pessoas podem ter dela em dado momento, afinal, se a aplicação se propoe a fazer coisas inúteis ou o quer que seja, ela vai continuar fazendo isso, a garantia que vc tem com testes é que em dadas situações não vai dar NullPointer. Por exemplo, nunca usei o hortelã mineiro e infelizmente sua palavra não basta pra me convencer que ele é confiável (e nem de quem mais vc falar, ok?), eu gostaria de provas concretas disso (caso fosse usar, ok? isso é um exemplo… rsss). Que mesmo assim não garantem que ele seja um espetaculo (Struts 1.1 lembra?).

O fato é que é muito chato em todos foruns que vamos ler aqui (de qualquer assunto) tem sempre uma msgzinha lá dizendo, olha quando o menta isso ou o menta aquilo… acho que vc não precisa fazer tanta propaganda assim. Outro problema é que o legal de um forúm é as pessoas debaterem opiniões e com isso crescerem, entende? pra isso temos que encarar criticas e deixar os outro criticarem em paz, não ser tão mala.

Cara, em momento algum eu quiz ofender vc na primeira mensagem (apesar de saber que vc não é muito bom para enteder textos quando as pessoas discordam de vc), como já disse várias vezes, não concordo com vc e pode fazer o espetáculo que for, não vou concordar, ainda mais com respostas do tipo… Olhaaa meu chefe é o cara, ele ganha dinheiro pra caramba e paga um montão de viagens pra mim… viu que legal??? então… testes não servem pra nada porque ele não gosta… faz favor vai. rsss

[]'s e por favor, deixe o forum seguir falando do assunto inicial.

Por falar nisso. pessoal do NEO, parabéns pela iniciativa, espero que vc’s consigam muito sucesso. Quanto aos testes, na minha opinião, seria bem legal vc’s colocarem isso em prática pra que a aceitação da aplicação seja mais tranquila.

[]'s gente e sucesso.

saoj

Eu gosto de debater, mas quando alguém coloca um post como esse seu desanima muito, principalmente quando o principal argumento é, seguindo a sua própria lógica: “Tem alguns (vc falou muitos, mas não contou 26) posts de bugs no forum do Mentawai, então ele dá pau pra caramba, ou seja, testes é muito importante.”

Quando vc fala uma coisa dessas, vc passa como boi de piranha de outras pessoas, um homem-bomba que foi convencido a criticar/condenar, sem nem saber porque e sem ter qualquer argumento… Quando expor sua opinião, procure embasá-la antes, se não fica parecendo que vc é apenas um mensageiro do além…

Não venha com ironias… Pode falar diretamente quando falar comigo…

Muitas pessoas não me acham mala… Mala são esses seus argumentos…

Talvez devesse interessar, principalmente para quem pretende usar/conhecer o Mentawai. Quando apresento RESULTADOS CONCRETOS, REALIZAÇÕES CONCRETAS, EMPREGO CONCRETO, EXPERIÊNCIAS CONCRETAS, FRAMEWORK CONCRETO, etc. algumas pessoas vão pelo menos se dar ao trabalho de LER as coisas que eu falo e se não concordar pelo menos apresentar bons argumentos para um debate de nível… Vc infelizmente não está entre essas pessoas, e se continuar com essa postura nunca estará…

eduveks

Acho que estão engrossando o caldo a toa…

Acreito que o que o Sérgio quis dizer em citar a empresa e o chefe dele, é demonstrar a realidade que ele vive todos os dias, assim como a minha realidade e de 90% dos programdores nestes mundo!

Maciel se já ta vendo chifre em cabeça de cavalo, e começa a ser muito “mala”… mau começa a postar no forum e já é tão “mala”??? E quem fugio do assunto principal foi tu, se encherga! Flamer!

Voltando ao assunto, e respondendo a este Maciel, e aproveitando o exemplo do cotidiado do Sérgio, a verdade é que o dono da minha empresa não ta interessado em testes unitários, ele quer saber do lucro e que a coisa funcione, com testes ou sem testes, não importa, e eu não vou receber mais se fazer testes unitários ou não, assim tb é o dono da tua empresa! Por isso que dúvido que qualquer empresa de médio/grande porte faça dos testes unitários algo padrão! Hoje não é assim, e dúvido que no fururo seja.

Quanto a ter mais confiança num projeto com testes e menos em um sem teste, isto é tudo psicológico, o FireFox tem testes unitários? Lá vc coloca a tua senha do banco online, e vc não se preocupa se tem ou não… e nem por isso ter ou não ter vc vai confiar mais ou menos…

Usa testes unitários quem quer, e quem não quer não usa, tanto em um caso como no outro não vejo problemas, cada um tem um estilo, e um não é melhor q outro!

saoj

Existe um mundo teórico, socialista, romantico, cheio de testes e existe um mundo prático, capitalista, ágil, incerto, orietando a resultados e lucros… Ainda bem que estou no segundo… Nada contra Cuba, mas prefiro os Estados Unidos…

:roll:

Vc pensa muito parecido comigo… Vc mora em Lisboa? Quer fazer um entrevista sem compromissos aqui nos Estados Unidos?

eduveks

Opa, obrigado pelo convite, mantemos contato e quem sabe num futuro próximo, pois agora estou muito focado e preso aqui, agora não dá mesmo , só daqui uns 3 anos…

To morando em Lisboa a 5 anos, e gosto muito de estar aqui, mas tb não conheço o USA, quem sabe goste mais :twisted:

Mais uma vez obrigado, e quando eu estiver mais disponível para uma aventura destas te dou um toque, valew :wink:

R

Testes unitários para operações críticas eu sou a favor.

Só não acho legal sair escrevendo teste pra coisas triviais, até porque nunca me dão tempo pra isso.

[]´s

maciel.bombonato

Vejamos pelo seguinte lado, se vc quer dizer que trabalha com x, y ou z, blz, diga e isso eu considero legal, agora acho que não tem nada a ver sair falando que está nos EUA ou em qquer outro lugar… vamos dizer pelo lado de que estavamos falando de opinião técnica e isso colocado do tipo… na empresa que trabalho isso não é considerado importante e tal, tem a ver com o assunto… blz, agora falar… olha, pensamos assim e ganhomos milhões (como se o dinheiro fosse conseguido por causa daquilo… não tem nada a ver… concorda? (como vc´s são parecido, acho que não. rsss)

Acredito que não estou vendo unicórnio… leia o post desde o inicio e vc vai ver que a coisa tava interessante… ai depois desandou como aconteceu com outros posts daquido guj… isso que eu acho chato pra caramba… ai pergunto… quem é Flamer?

Pergunta: a quantidade de post´s te dá permição de ser mala? rsss
A questão é que estou tentando “aprender” e hj acredito que tenha muita gente bem mais capacitada para sair postando, o problema é quando alguns tentam fazer de sua opinião absoluta e soberana, entende?

Sua resposta quanto a sua empresa foi melhor que a dele… quanto a empresas fazerem dos testes algo padrão, creio que seja difícil também, mas acredito que pode acontecer de algumas adotarem em pelo menos partes do projeto (as mais críticas pelo menos), acredito que isso pode acontecer sim… mas opinião, ok?

Nesse ponto eu quis dizer o seguinte, imagine-se procurando um framework para utilizar na sua empresa e que vc não conheça o histórico do carinha, agora imagine que vc tem duas opções equivalentes em utilização, um com testes e outro sem… qual vc escolheria?

Foi isso que eu quis dizer.

[]´s

maciel.bombonato

Tente entender, eu disse na minha opinião testes são importantes, outra coisa, o que eu quis dizer quanto a pag de bug´s é o seguinte, se vc tivesse colocado testes sua aplicação isso não a tornaria melhor, mas pergunto, aquela quantidade (grande ou pequena) não poderia ter sido menor? simplesmente isso, entendeu?

Eu estaria sendo ironico se eu falasse que sou seu fã… ou seja, pode ficar tranquilo, quando eu quiser dizer alguma coisa vou dizer, não vou ficar dando voltas.

Comigo também é assim, muitos não me acham, mas pare pra analisar seus argumentos e me diga, foram legais? rsssss

Realmente, nesse ponto vc tem razão, se eu continuar levando uma discução com vc não chegarei em lugar nenhum, mas leia a sua resposta e a minha réplica, vc realmente acha que tem alguma coisa a ver o fato de vc estar em um lugar e depois ir pra outro com uma converça sobre opinião técnica? basicamente foi isso que eu disse, o fato de vc estar aqui ou ali, não tem nada a ver com o fato de testes serem ou não importantes. Isso na opinião de cada um, ok?

Lembrando, estamos falando sobre o que seria interessante como boas práticas, tipo, realizar ou não testes unitário, caso sim, onde e quando realiza-los… é bem isso o foco do assunto no momento.

Quanto ao exemplo do menta, me desculpe, não deveria mesmo ter falado de uma aplicação na qual nada conheço, agora falando de testes, vc acredita que a quantidade de bugs pode diminuir se um framework possui testes unitários?

Eu acredito que sim. é isso… entendeu?

[]´s

maciel.bombonato

Rafaelprp:
Testes unitários para operações críticas eu sou a favor.

Só não acho legal sair escrevendo teste pra coisas triviais, até porque nunca me dão tempo pra isso.

[]´s

Concordo contigo.

Rubem_Azenha

Não necessariamente, teste unitário não garante que o software não tenha bugs. Inclusive é bom que apareça bastante bugs ali :slight_smile: Isso só mostra que o framework esta sendo utilizado. Desconfie de projetos que não tenha bug reports, ou que tenha mas não estejam sendo tratados :slight_smile:

maciel.bombonato:

Quanto ao exemplo do menta, me desculpe, não deveria mesmo ter falado de uma aplicação na qual nada conheço, agora falando de testes, vc acredita que a quantidade de bugs pode diminuir se um framework possui testes unitários?

Eu acredito que sim. é isso… entendeu?

[]´s

Talvez… Um teste unitário aumenta a garantia\confiança de compatibilidade com versões anteriores. Também é uma oportunidade de descobrir bugs no projeto. Mas ter testes unitários não garante que o projeto não tem bugs.
Um projeto sem bugs é um projeto com pouca ou nenhuma utilização.

cv1

Eu so peço a zahl que isso nao seja uma desculpa pra nao escrever testes. Ou o bebê zumbi jesus vai chorar.

pcalcado

O cliente não quer saber se foi feito em java, C# ou Pascal, desde que funcione e dê lucro.

O usuário de um framework não quer saber se foi feito usando X, Y ou Z, desde que funcione e ele consiga fazer seu trabalho.

E nenhum dos dois da a mínima se você não tem testes logo não consegue adaptar seu framework às mudanças necessárias porque não tem uma vírgula de confiança na base de código não quebrar

Se um software não tem testes, automatizados ou não, é porque ele não vale o esforço (é isso que o Carlos disse, mas cv-style).

Você compraria um carro que não foi testado? Veja bem, ele funciona, 100 pessoas já dirigiram eles, tem uma empresa que fatura 1 bilhão de euros a cada nanossegundo que tem uma frota deles mas… você poria sua família dentro dele?

Você usaria um carro sem cinto de segurança? Eu passo boa parte do meu tempo no trânsito, nunca sofri nenhum acidente sério. Cinto de segurança não consegue me dar nem 90% de garantia sequer de sobrevivência num acidente, isso me faz mais confiante para largar minha segurança?

eduveks

Nossa…

Ainda não entendi que raio de tão perfeita segurança os testes unitários, garamtem!?!?!

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.

Se for feito bons testes funcionais, os testes unitários só ajudariam na primeira fase, mas nada de ajuda decisiva, além que muitas vezes os erros dos testes unitários não fazem sentido, na teoria pode fazer, mas na prática não.

Em código critico, ai sim que precisa muito menos de testes, pois se são criticos, é por que vai ser muito usado, e até entrar em produção vai passar por varias situações de testes funcionais, e ai já serão detectados variantes de erros, testes unitários em partes criticas ai que é perda de tempo, pois são as partes mais testadas no nível funcional.

Quanto ao caso dos testes unitários reduzir os “bugs” (Menta usado como exemplo), na primeira/segunda versão até que vai, mas depois não vai ajudar em nada, no caso do Menta, no nivél que esta, acha que faria alguma diferença? Acha que já não passou tudo por muitos testes, muita gente usando aquilo todos os dias, os testes unitarios fariam que diferança?

Quanto a questão de manter a compatibilidade, talvez, mas na prática não sei…

O que sei como já disse, isto virou na “moda”, e tão exagerando, fazendo isto algo essêncial, coisa q não é!

Como o pcalcado disse o exemplo do carro, meu tu andou com “carros” sem testes, e sem sinto, e ta vivo até hoje, até a tua “familia”, já andou em carros assim e tu nem sabe, e agora dramatiza, e o pior, vc vai continuar vivendo num mundo que os testes não vão ser padrão, o windows não vai ter testes unitários, nem o office, nem o firefox, nem o kernel do linux, e são coisas que vc usa todos os dias.


maciel.bombonato:
Rafaelprp:
Testes unitários para operações críticas eu sou a favor.

Só não acho legal sair escrevendo teste pra coisas triviais, até porque nunca me dão tempo pra isso.

[]´s

Concordo contigo.

E depois diz q não é mala e nem flamer! Se todos fossem dizer se concorda ou não, isto já tinha umas 5.000 respostas, tu é mesmo um Flamer aka Mala!

Mauricio_Linhares

Antes de dizer uma abominação dessas, tenha certeza de que você não está falando besteira, porque todos os softwares da fundação Mozilla tem sim tests unitários -> http://www.mozilla.org/projects/firefox/review.html

E como é que você prova que o Windows e o Office não tem testes unitários? Você, por acaso, trabalha na Microsoft pra dizer isso?

Se você acha que testes unitários não valem de nada, fique com isso pra você e os seus projetos, não envolva projetos alheios no meio não.

eduveks

Antes de dizer uma abominação dessas, tenha certeza de que você não está falando besteira, porque todos os softwares da fundação Mozilla tem sim tests unitários -> http://www.mozilla.org/projects/firefox/review.html

E como é que você prova que o Windows e o Office não tem testes unitários? Você, por acaso, trabalha na Microsoft pra dizer isso?

Se você acha que testes unitários não valem de nada, fique com isso pra você e os seus projetos, não envolva projetos alheios no meio não.

LoL, citei alguns exemplos, sabia q ia ser infeliz em algum :stuck_out_tongue:

Ok então o FireFox usa, mas a Microsoft acho dificil. :stuck_out_tongue:

Estou trabalhando diretamente com a Microsoft, em apliações de grande porte para o maior banco de Portugal, e não há testes unitários, e a grande quantidade de testes funcionais que fazemos, não faz sentido testes unitários, e dúvido que o Windows ou Office haja, mas foi apenas como exemplo o que citei!

Eu não acho sentido radicalizarem isto, dizendo que código sem testes é lixo, coisa que não é! E que testes não garantem mais segurança ou menos.

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 é!

Z

Esse é o típico caso de utilidade para testes unitários (verificar se o método está checando a validade de parâmetros) e eles funcionam muito bem, obrigado, nessas situações.

Com um teste de unidade razoável implementado para esse método, você tem certeza que ele nunca vai aceitar números negativos, mesmo depois de mexer no código da classe. Quer garantia melhor que essa? Ou você prefere ter que ir na “mãozona” e testar todo o tipo de combinação da parâmetros e ver se o método continua funcionando? Acho que a maioria de nós precisa de mais garantias que não quebrou nada no código, ao fazer uma alteração.

Definitivamente, você deveria conhecer melhor testes untiários antes de tentar argumentar alguma coisa contra eles por aqui. Ou, pelo menos, melhorar os exemplos. :smiley:

eduveks

Esse é o típico caso de utilidade para testes unitários (verificar se o método está checando a validade de parâmetros) e eles funcionam muito bem, obrigado, nessas situações.

Com um teste de unidade razoável implementado para esse método, você tem certeza que ele nunca vai aceitar números negativos, mesmo depois de mexer no código da classe. Quer garantia melhor que essa? Ou você prefere ter que ir na “mãozona” e testar todo o tipo de combinação da parâmetros e ver se o método continua funcionando? Acho que a maioria de nós precisa de mais garantias que não quebrou nada no código, ao fazer uma alteração.

Definitivamente, você deveria conhecer melhor testes untiários antes de tentar argumentar alguma coisa contra eles por aqui. Ou, pelo menos, melhorar os exemplos. :D

Exatamente, citei este exemplo para depois combater, a resposta que dariam e ir mais pra prática em vez da teoria…

Então vamos lá, seguindo a tua ideia, o teste vai ter q ser ajustado a mão para fazer o teste deste método certo? E vc vai lembrar de fazer este ajuste? E vai ter certeza que o teste esta bem configurado? Em uma aplicação peguena, isto é simples, mas numa aplicação de grande porte, seria um tempo muito precioso, perdido nisto, aumento o custo do projeto.

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?

E não iriamos ter que fazer isto? Ou vc confia tanto assim em testes unitários?

Z

…?

Então você está dizendo que testes são perda de tempo? Hum.

A qualidade de um bom programador pode ser medida pela sua capacidade de escrever testes que avaliem o código de modo satisfatórios.

E acredite, escrever testes não gasta tanto tempo assim.

Agora você está falando de projeto de que porte? Pq no parágrafo anterior você estava preocupado com projetos de grande porte e agora vem com essa, de que o melhor modo de testar é na mãozona ou no velho PSVM.

Isso pode funcionar pra crud de 10 campos… mas, como já disse, precisamos de um pouco mais de garantias do que isso. :slight_smile:

Confio. Bem mais do que o programador ter que ficar testando formulário. Além do fato de que eu não só macaco que escreve código e que passa o dia só escrevendo formulário, graças a deus.

Continuo achando que você conhece muito pouco do assunto. Dá uma lida, na boa… :wink:

Mauricio_Linhares

Então tenha mais cuidado antes de citar fontes erradas, porque assim não há argumentação. E, mais uma vez, você não trabalha pra Microsoft, não diga que eles fazem X ou Y, isso é achismo

Testes unitários não garantem mais segurança? Com base no que você dis isso? Achismo também?

Existe toda uma literatura que fala sobre os benefícios de testes unitários. Você deve conhecer uma que fale o contrário né.

Não é porque muita gente faz, que é certo.

pcalcado

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.

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.

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?

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?

pcalcado

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 é!

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.

eduveks

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!

eduveks

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?

eduveks

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…

saoj

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.

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…

Mauricio_Linhares

Ó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.

Mauricio_Linhares

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…

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?

eduveks

Ó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.

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.

eduveks

Maurício Linhares:
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…

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?

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.

keller

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:

saoj

Ó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.

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.

Z

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…

saoj

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…

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

Mauricio_Linhares

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

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

eduveks

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…

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…

Z

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).

saoj

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…

Rodrigo_Carvalho_Aul

É 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

saoj

Usando um conceito lógico chamado backwards compatibility. Vc vai adicionar novas funcionalidades sem quebrar seja qual for a lógica que já está ali…

Exemplo prático:

public double parseExecutedQty(ByteBuffer buf) {
 
       // 100 linhas de um lógica gigantesca para parsear um inteiro que está num byte buffer...
       
       // isso sempre funcionou só que acabamos de descobrir que tem uma bolsa enviando quantidade executada em notação científica
       // e o seu chefe pediu para vc corrigir isso...
}

Em algum ponto da lógica acima, vc vai poder fazer um IF mais ou menos assim:

if (qtyString.indexOf("E") &gt 0) {

   // estamos falando de notação cientícia (1E4), 
   // logo aqui partimos para um algoritimo alternativo para parsear a coisa...

}

Não é difícil perceber que a alteração acima respeitou TOTALMENTE a questão da backward compatibility. O seu código novo só vai ser aplicado A SITUAÇÃO NOVA, sendo que para as situações antigas, que estão funcionamento perfeitamente, o código ficou praticamente intocado, ou seja, as linhas executadas (algoritmo) serão as mesmas. Isso se consegue com um mínimo de disciplina e lógica, ou seja, basta vc fazer um IF direito.

Essas são as situações práticas da vida real onde vc pode muito bem alterar uma coisa, sem teste unitário e sem quebrar nada…

OBS: Não tenho dúvida que existe profissionais por aí que diante desse problema iriam partir para uma re-implementação do método e/ou que não entendem o que venha a ser backwards compatiblity, etc. Vc não quer ser um profissional desses! E vc não quer ter um profissional desses na sua equipe.

Se ele for o filho do seu chefe, então vc realmente precisa de testes unitários e testes unitários passa a ser a coisa mais importante do seu sistema.

Não sei se conseguir passar minha opinião de que teste unitário, na maioria das vezes passa como um remédio que resolve apenas os sintomas do problema e não o problema em si…

L

Não seria melhor vocês criarem outro tópico para discutir estas coisas?

De vez de vocês incentivarem o projeto do cara que poderia ser uma coisa que facilitaria nosso dia a dia de trabalho, fição ai na briga de QUEM TEM O EGO MAIS ALTO.

Senhores, por favor mantenha a devida compostura.

J

O ponto é que não são os testes o grande milagre, mas como o desenvolvimento orientado a testes funciona.

Teste unitário, testam uma classe só, seguindo uma necessidade que você têm para ela.

Por exemplo: Eu tenho que criar um classe que faz soma e não pode aceitar numero negativos.

Eu vou lá, escrevo meu test, que no caso estou usando JUnit, mas poderia ser um main como já citaram aqui. O JUnit é um framework que te ajuda a fazer teste e só.

public void testSomaNaoAceitaNegativo() {
  MeuSomadorMaster somador = new MeuSomadorMaster();
  try {
    somador.soma(3, -1);
    fail("Deveria lançar exception com possitivo, negativo);
  } catch (Exception e) {}

  try {
    somador.soma(-3, 1);
    fail("Deveria lançar exception com negativo, possitivo);
  } catch (Exception e) {}

  try {
    somador.soma(-3, -1);
    fail("Deveria lançar exception com negativo, negativo);
  } catch (Exception e) {}

  assertEquals(4, somador.soma(3, 1));
}

É um exemplo simples, e assim como foi um exemplo simples foi super simples de fazer o teste.

Eu escrevi esse teste antes de implementar, e já tenho na minha cabeça como vou implementar pois fui pensando nisso enquanto escrevi o teste.

O que eu garanto com isso? Que vou fazer certo? Nesse caso nem isso, pois é bem simples e com certeza eu ia fazer correto. Mas eu já pensei na pratica como isso será utilizado e tenho certeza que amanha não vai aparecer um mané, que precisando que essa classe some negativos, mude o comportamento dela. Na qual todo o resto do sistema está baseado.

Testes unitários evitam 100% os Bugs? NÃO! E NINGUÉM ESTA FALANDO ISSO! Mas eles evitam que os bugs que você já pensou em evitar ou que já foram descobertos voltem a acontecer.

E se você escrever os testes antes do desenvolvimento, você vai ter uma baita ajuda para pensar na maneira mais simples de implementar algo. Quando você implementa algo sem nem saber como vai utilizado na real, você acaba complicando demais.

Abram a cabeça, experimentem, no inicio é complicado você demora muito para ter eficiência, mas depois que você aprende, você começa a programar melhor, mais rápido, mais simples e mais seguro.
Isso é um fato, mais do que documentado e vivido no mundo real.

Agora, não é só teste unitário que você tem que ter os outros testes continuam sendo necessário, mas acabam ficando mais simples e mais baratos.

Agora, existe sim o mundo dos sem testes, mas para esse mundo que até funciona. Se você usar testes, o seu design seria mais simples, melhor entendido por todos e mais barato (os problemas não voltariam a acontecer pq uma pessoa mudou uma classe de uma maneira que não deveria).

Fazer testes unitários no inicio, quando ainda não falta experiência e conhecimento, é dificil e trabalhoso. Depois acaba sendo muito mais rapido programar com testes do que sem testes. Vira uma ferramenta que te ajuda a tomar decisões de design, te ajuda a documentar o funcionamento de uma classe, te ajuda a entender o funcionamento de um framework que você achou na internet e tem testes, melhora a colaboração da equipe e a qualidade do software.

Por favor, comprem um livro de alguém reconhecido sobre TDD e desenvolvimento orientado a testes e leiam de cabeça aberta. Façam uma experiência. E parem de justificar a cabeça dura. É um fato que está sendo vivido pelas empresas e pessoas que geram software mais barato e melhor.

Utilizar um framework sem testes unitário, é acreditar muito na competência de uma pessoa, o problema é um bom framework deve ter um ambiente alltamente colaborativo, e ser altamente colaborativo em um ambiente aonde os testes são manuais é muito caro, além de ser chato, e quando se trabalha de graça as pessoas só querem fazer o que é legal.

Então, mesmo o framework sendo bom e tal, o fato de não ter testes unitário é um risco para a continuidade do framework, quando o atual core encher o saco e partir para outra. Além de ser um trabalho ter que testar (você não vai colocar um framework novo em produção sem testar né) o framework na mão.

Com testes unitário, você pode ir lá e ler se os testes do cara são suficiente para você ou não, pq usar só testes também não diz nada, têm que usar e usar bem.

Z

Isso é gambiarra, na minha opinião. Depois de um tempo, o código estaria cheio de IFs que ninguém sabe ao certo pra que serve, colocados lá só para ser uma garantia mandrake de backward compatibility. Parece mais medo de mexer no códigos dos outros.

Interessante, se você procurar sobre programação orientada a gambiarras em sites do Wikipedia ou Desciclopedia, eles falam que isso é técnica de POG. Se você não sabe o porquê daquele código existir, coloca um IF e deixa ele lá. Se funciona, tá ótimo.

J

O problema é fazer backwards compatiblity sem você saber qual é o comportamento do método. Você têm que documentar isso, ou você documenta em javadoc, ou você documenta em word ou você documenta utilizando testes unitário.

A vantagem de utilizar testes unitário é que você têm certeza que quem implementar vai seguir direitinho tudo que você documentou.

As pessoas cometem erros, e isso não faz delas maus profissionais.

Você parece acreditar muito em profissionais perfeitos, tipo, e só o cara olhar o método é não fazer errado. Não é só, isso é tudo o que o ser humano não é, perfeito.

Quando você fala assim, soa no meu ouvido como se alguem fala-se assim: As montadoras não precisam testar os carros, é só o cara olhar as instruções e montar do jeito que tá lá. Você não vai querer ter um profissional que monta carro errado na sua equipe, vai?

Mauricio_Linhares

Pois é, é POG e ainda é um code smell -> http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

saoj

Isso é gambiarra, na minha opinião. Depois de um tempo, o código estaria cheio de IFs que ninguém sabe ao certo pra que serve, colocados lá só para ser uma garantia mandrake de backward compatibility. Parece mais medo de mexer no códigos dos outros.

Cara, eu acho que vc está confundindo IF com gambiarra. Um caso novo vai exigir um IF novo para tratar dele. Isso está longe de ser gambiarra, mas fique a vontade para propor uma solução alternativa PRÁTICA e enriquecer o debate…

Como vc faria a alteração no método parseExecutedQty para parsear notação científica?

saoj

O problema é fazer backwards compatiblity sem você saber qual é o comportamento do método. Você têm que documentar isso, ou você documenta em javadoc, ou você documenta em word ou você documenta utilizando testes unitário.

O meu ponto é o OPOSTO desse. Vc não precisa conhecer o código, nem saber o que ele faz para não quebrá-lo. Vc usou um IF e fez um branch, ou seja, partiu para um outro caminho e deixou o caminho anterior intocado.

Rodrigo_Carvalho_Aul

Até funciona, mas concordo com o ZehOliveira, depois um tempo o código vai tá uma salada.

E a gente tava falando de refactoring, refactoring não é só adicionar um if ou fazer um override.

Realmente, ele trata o sintoma, pra ele não aparecer mais.
Teste unitário não resolve nada, só evita problemas, principalmente que os problemas voltem.

[]'s

Rodrigo Auler

pcalcado

eduveks:
pcalcado:

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.

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?

Leia novamente meu texto.

eduveks:

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.

Eu concordo que um código sem testes tem valor, mas também concordo que a qualidade deste processo de desenvolvimento, não necessariamente do código, não é aceitável.

J

saoj:
O problema é fazer backwards compatiblity sem você saber qual é o comportamento do método. Você têm que documentar isso, ou você documenta em javadoc, ou você documenta em word ou você documenta utilizando testes unitário.

O meu ponto é o OPOSTO desse. Vc não precisa conhecer o código, nem saber o que ele faz para não quebrá-lo. Vc usou um IF e fez um branch, ou seja, partiu para um outro caminho e deixou o caminho anterior intocado.

Isso não é bom Sergio, pode até funcionar, mas com o passar do tempo você vai criando um monstro.

O melhor modelo de desenvolvimento, na minha opinião, é um ambiente colaborativo aonde todos sabem qual é a funcionalidade do software e o conhecimento está distribuido pela equipe.

Vamos supor que a parte de cima do método precise ser alterada, e o carinha que fez morreu atropelado na semana passada, testes unitário seriam uma mão na roda ter testes unitário, não?

E se testes unitários não lhe custa-se nada, além de tornar a sua equipe mais produtiva? Então, essa é a promessa do TDD, que eu e muitos aqui vivemos no dia-a-dia e damos o testemunho de que passada a fase de aprendizado aumenta a sua produtividade e qualidade.

Agora, você pode continuar ler e chamar isso de teórico e socialista (pelo visto, estar nos EUA esta lhe fazendo bem), mas é algo que eu e muitas empresas vivemos no dia-a-dia.

pcalcado

saoj:
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.

Vamos supôr que esta situação aconteceu e você recebe uma issue/trouble ticket com este problema. Quais os próximos passos?

Se você não criar um teste automatizado (funcional ou unitário, preferencialmente ambos) como vai ter um mínimo de garantia que ao corrigir este bug você não introduziu outros em funcionalidades que já estavam OK antes da mudança? vai testar tudo de novo manualmente ou com métodos main?

Quanto ao imprevisível, existe toda uma disciplina de engenharia de software dedicada a testes, sobre limites, classes de equivalência e demais características que, se aplicadas, reduzem as incertezas drasticamente. Estão entre nós há décadas, todo mundo estuda e faz prova disso na faculdade mas ninguém nem sonha em pôr em prática.

Não vou entrar na discussão ‘use OO e evite testes’ porque algumas páginas atrás já vimos que isso não é real. Que tal msotrar para seu chefe que você tem segurança de mudar o codebase e não é um code cowboy? E se você adoecer e outra pessoa tiver que fazer este refactoring? Como ele consegue saber que ao mudar aquela vírgula o comportamento básico da classe foi mantido?

Em OO nós utilizamos polimorfismo para comportamento que varia e não ifs, inviabilizando o argumento acima, mas esta não é a discussão.

Se você garante que seu código não tem erro parabéns, eu não sou tão bom assim e ninguém que tenha conhecido até hoje é, por isso me precavejo com testes que vão garantir que eu ou um dos meus 100+ colaboradores não quebrem contratos.

Colocar OO como panacéia quando os nomes mais importantes do paradigma (Fowler, Beck, Evans, Page-Jones, tres amigos, Gamma, Uncle Bob só os que lembro de cabeça) usam e escrevem livros sobre o uso de testes unitários é beeeeeeeeeem estranho. Eu não sei não mas acho que estes nomes entendem um pouquinho mais sobre o paradgima que eles ajudaram a criar, especificar e catalogar.

saoj

De novo quero deixar claro que não sou o dono da verdade, estou apenas colocando a minha opinião baseado na minha experiencia. Experiencias diferentes geram opiniões diferentes igualmente válidas.

Concordo com que vc falou mas quando vc diz Vamos supor que a parte de cima do método precise ser alterada a minha dúvida passa a ser outra.

Por que a parte a cima precisa ser alterada? Ela não estava funcionando? Se ela precisa ser alterada, ela tem um bug sério, que com certeza não tem como ter passado nos primeiros testes funcionais da coisa.

O meu ponto no debate é que existe código que funciona, que vc não fez e que vc respeita. Esse código só deve ser alterado nos últimos dos casos, quando vc pegou um erro muito grotesco, ou algo desse nível. Isso (erros grotescos) geralmente vai acontecer na fase inicial de desenvolvimento, onde vc está esperando e pode pagar o preço de um erro grotesco. Num sistema (ou framework) estável e que já está rodando algum tempo, é natural não esperar um tipo de erro desses e é prudente (na minha opinião) respeitar os códigos que já estão lá e que já estão funcionando.

pcalcado

eduveks:

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.

E seus clientes falam pra você cirar a classe X, a interface Y e o método Z? Não né? E por quê?

Porque quando eles contratam um profissional eles acreditam que estão comprando os serviços de alguém que sabe o que está fazendo.

saoj

Leia de novo o meu exemplo prático (o código mesmo) para constatar que é praticamente impossível para minha alteração quebrar alguma coisa. E não foi porque foi eu que fiz, foi uma questão de filosofia e lógica.

fabim

Acho que essa pergunta encerra qqer discussão sobre testes.

pcalcado

O estilo deste exemplo é conhecido como codigo spaghetti:

http://yost.com/computers/java/java-spaghetti/

E é algo que OO veio solucionar, mas soluções já existem desde programação estruturada (coesão, acoplamento, módulos…) nos anos 80.

saoj

pcalcado:
saoj:

Exemplo prático:

O estilo deste exemplo é conhecido como codigo spaghetti:

http://yost.com/computers/java/java-spaghetti/

E é algo que OO veio solucionar, mas soluções já existem desde programação estruturada (coesão, acoplamento, módulos…) nos anos 80.

De novo peço que se minha solução é errada ou spagetti que vc ensine para a gente como deveria ter sido o procedimento correto para alterar o método e resolver o problema. É muito fácil e deselegante falar que o código do outro é spagetti e não ter a humildade de propor uma solução alternativa e melhor…

pcalcado

Ñão sei se concluindo, mas tentando, o ponto aqui me parece claro. Vocês (Sérgio e etc.) não usam testes unitários e ficaram ofendidos quando alguém falou que código sem estes não presta e começaram a atacar testes unitários. O problema é que os argumentos acabaram há várias páginas, estamos apenas repetindo a mesma coisa novamente e novamente.

Como falei antes eu acho que desenvolvimento sem testes não presta, mas o código gerado pode (apesar de tender fortemente a não) ser de qualidade. O problema é que se eu compro software que não tem testes eu não confio no fornecedor (seja software livre ou não).

saoj

pcalcado:
Ñão sei se concluindo, mas tentando, o ponto aqui me parece claro. Vocês (Sérgio e etc.) não usam testes unitários e ficaram ofendidos quando alguém falou que código sem estes não presta e começaram a atacar testes unitários. O problema é que os argumentos acabaram há várias páginas, estamos apenas repetindo a mesma coisa novamente e novamente.

Como falei antes eu acho que desenvolvimento sem testes não presta, mas o código gerado pode (apesar de tender fortemente a não) ser de qualidade. O problema é que se eu compro software que não tem testes eu não confio no fornecedor (seja software livre ou não).

pcalcado

Se você lesse o que te indicam e não ficasse praguejando contra a teoria saberia a resposta. Polimorfismo, sobrescrita, etc.

class A{

 public void fazAlgo(Com b){
     if(b.numero&gt12121){fazUmaCoisa(b);}
     else{fazOutraCoisa(b)};
 }

 public void fazAlgo(ComUmaCoisaQuePareceQueEhMasNaoEh b2){
    //comprotamento variante
 }
}


class EhUmAMasFazAlgoDiferente extends A{
 public void fazAlgo(Com b){
      //comportamento variante
  }

}
saoj
pcalcado:
saoj:
De novo peço que se minha solução é errada ou spagetti que vc ensine para a gente como deveria ter sido o procedimento correto para alterar o método e resolver o problema. É muito fácil e deselegante falar que o código do outro é spagetti e não ter a humildade (ou coragem) de propor uma solução alternativa e melhor...

Se você lesse o que te indicam e não ficasse praguejando contra a teoria saberia a resposta. Polimorfismo, sobrescrita, etc.

class A{

 public void fazAlgo(Com b){
     if(b.numero&gt12121){fazUmaCoisa(b);}
     else{fazOutraCoisa(b)};
 }

 public void fazAlgo(ComUmaCoisaQuePareceQueEhMasNaoEh b2){
    //comprotamento variante
 }
}


class EhUmAMasFazAlgoDiferente extends A{
 public void fazAlgo(Com b){
      //comportamento variante
  }

}

Claro!!! Sempre falei isso aqui e isso apenas reforça o meu ponto:

Boas práticas de OO (polimorfismo e sobrescrita) é apenas MAIS UM MOTIVO (na verdade o principal) para vc não precisar de testes e para que vc possa alterar uma coisa sem quebrá-la... Se vc está estendendo a classe A como nesse seu exemplo, porque diabos vc vai precisar testar A ??????? Não faz o menor sentido testar A quando vc estende A e isso é uma grande sacada/vantagem de OO como todo mundo sabe (ou deveria) saber...

Só que no meu exemplo, vc não quer sobrescrever o método para alterá-lo APENAS para uma situação em particular. Vc quer alterá-lo para todas as situações, ou seja, vc quer que qualquer bolsa que já estava usando aquele método possa lhe enviar notação científica sem abendar o seu código.

Por isso pela opção pelo IF ao invés de polimorfismo/sobrescrita. (Sim, até um simples IF é perigoso, principalmente quando vc está desatento e se esquece de testar um NullPointerException! Logo por isso que mais abaixo eu digo que prefiro polimorfimo/sobrescrita a esse IF em prol da segurança... Mas qualquer um com atenção e disciplina consegue fazer um IF direito...)

E confesso que muitas vezes, em prol da segurança, prefiro polimorfismo/sobrescrita para que apenas aquela BOLSA seja afetada por novo código, e não todas as outras juntas. Não é a melhor solução, visto que se outras bolsas amanhã resolverem te mandar notação científica (improvável mas possível, principalmente pelas novas que entrarem no sistema) o seu código vai abendar, mas é a mais segura...

E não acredito de maneira nenhuma que o código com um IF para tratar uma situação particular seja spagetti code ou POG. O problema é quando vc usa IF quando deveria usar polimorfismo ou herança, e aí sim, temos um problema grave como colocaram aqui: http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

Rodrigo_Carvalho_Aul

Eu acho ótimo quando tenho segurança de alterar alguma coisa sem quebrar. Só não entendo pq isso é um motivo pra eu não fazer um teste pra garantir que ninguém mais quebre sendo que:
:arrow: Eu não sou o único que mexe no código.
:arrow: As pessoas que eu trabalho erram, assim como eu também erro.

[]'s

Rodrigo Auler

nbluis

Acho que este tópico viria a calhar nesse momento.

J

Por que software é uma coisa viva, o que hoje é certo amanha não é, precisa ser melhorado, modificado ou complementado.

Quanto a ser normal uma coisa que funcionava passar a não funcionar, eu mesmo várias vezes já fiz mudanças em projetos que já participei, que eu jurava que estavam correto, que faziam a mesma coisa que faziam antes, só que melhor e mais completa e quando rodava os testes descobria que não estava tão correto assim.

Você pode argumentar que eu não deveria ter mexido no que tava pronto, mas o fato de ter testes me dava total liberdade de ousar e tentar melhorar o que já existia com um bom nível de segurança e eu fui lá e melhorei e complementei o que já existia ao invés de duplicar funcionalidade no seu sistema.

Um abraço,
Jose Peleteiro

pcalcado

Ok, argumento batido. Se você realmente defende o ponto de vista que OOP elimina a necessidade real de testes deveria escrever um livro, artigo, paper ou o que for para contrastar sua opinião com a das pessoas citadas em outros lugares, que possuem suas opiniões favoráveis a testes (são grandes evangelistas, na verdade).

Como essa sentença foi repetida diversas vezes sem novos argumentos (aliás, como foi repetido!) vou colar o trecho que escrevi nesta thread em 26/06:

Exclua deste todo mundo Martin Fowler, Eric Evans, Page-Jones, Uncle Bob Dave Thomas e todos os já citados nesta thread. Sobra quem?

Creio que o problema possa ser o fato de que seu design simplesmente não é OO. Se você tem objetos colaborativos cada objeto tem sua responsabilidade e seu comportamento, que é a forma com que ele se modifica (se move no espaço-estado).

Se você tem um objeto que recebia uma coisa (Diagmos uma instância de Dinheiro) e passa a receber outra (uma instância de NotacaoCientifica) você apenas cria outro método sobrecarregando o inicial. É extremamente simples e sem ifs, e como você pode ver pelo texto do Fowler que o Mauricio citou ifs no lugar de polimorfismo (o que voce fez no exemplo) ja é motivador suficiente para refactoring.

É esse o caso, Sérgio. Vamos tentar esquecer implicâncias e pormenores, do contrário este debate é inútil do ponto de vista de produção de conteúdo mas continua influenciando quem o ler, e influenciando negativamente.

Eu tenho uma classe X que se comporta da maneira Y. Duas mudanças possíveis:

1)A classe X agora deve se comportar da maneira Z ao invés da maneira Y:

  • Procedimento: Substitua a implementação de Y por Z
  1. A classe X deve se comportar da maneira Y se receber A e da maneira Z se receber B
  • Procedimento: Sobrecarregue o método criando um que lide com a nova situação, separe o comportamento comum em outro método que é invocado pelas duas sobrecargas

No seu caso específico me parece que o problema é que o parâmetro que muda o comportamento tem o mesmo tipo. Se você tem:

public void metodo(String qualquerCoisa){

E depende do valor do parametro para entender o que fazer é uma simples questão de dispatching e parsing. Se você possui uma arquitetura de Camadas bem construída a de Apresentação, seja um Servlet, MDB, Socket ou o que for, já converterá esta mensagem de String para o objeto em questão, se sua aplicação não usa Camadas (parece ser o caso) você precisa fazer este parsing em algum lugar. No caso em específico vai até haver um if, mas ele está no lugar errado. O que eu faria:

/*

@deprecated Use os metodos de sobrecarga
*/
public void metodo(String qualquerCoisa){

 if(ehUmaNotacaoCientifica(qualquerCoisa){
    NotacaoCientifica nc = converteParaNotacao(qualquerCoisa);
    metodo(nc);
 }else{
     Dinheiro d = converteParaDinheiro(qualquerCoisa);
    metodo(d);
 }
}

Novamente: Esta conversão deveria estar na Camada de Apresentação, não aqui.

saoj

Sobra quem entendeu o que eu falei…

Quando vc estende HttpServlet vc para para testar HttpServlet ???

Quando Fiho estende Pai, não há qualquer motivo para testar Pai, a não ser que vc faça um esforço sobre-humano para fazer cagada. E isso acho que até esses nomes bonitos aí vão concordar… :wink: Mas se tiver testes melhor ainda, quanto mais segurança melhor. Se tiver um cara para fazer code review em cada alteração que vc fizer melhor ainda… Se tiver um departamente de QA que a cada novo release vai testar tudo na mão, funcionalidade por funcionalidade, melhor ainda! Só que no mundo real, não é isso que acontece… Vc precisa produzir mais com menos e é nessa hora que disciplina, organização, boas práticas, atenção, concentração vão ser mais importantes que qualquer outra coisa…

Eu não coloquei IF em lugar nenhum. Eu apenas falei que dentro do método que vc está alterando vai haver um IF para fazer um branch, mas isso foi o suficiente para algumas pessoas sem pensar o entender taxassem a coisa de gambiarra, code smell, POG, etc.

Tanto faz esse IF levar para um novo bloco de código ou para uma outra função que recebe um ByteBuffer e que, como o parametro é o mesmo, ela terá que ter outro nome, tipo parseExecutedQtyNC(ByteBuffer), o que é muito ruim para a API do seu sistema, a não ser que esse método seja feito private/protected.

Rodrigo_Carvalho_Aul

Dessa vez seu exemplo foi ruim. Você não precisa testar a classe mãe se ela já foi testada. E você testa o que você desenvolveu. Bom senso é uma das qualidades mais importantes pra um bom programador. Exemplos como esse não ajudam na discussão.

[]'s

Rodrigo Auler

pcalcado

Cara, na boa: você pdoe estar certo. Eu acho que não está, mas pode ser que esteja. Se você quer guardar para você tudo bem, mas se você quer discutir suas idéias, etc. é bom embasá-las em algo, por isso sugeri o artigo, paper, etc.

Ao adquirir software, por exemplo o framework de servlets, eu já suponho que meu fornecedor testou o sistema. Na verdade existe um grande teste chamado TCK especificamente para este caso.

Isso não evita a necessidade de testar o meu código. Ainda que o seu framework tivesse testes eu deveria testar o código que eu produzo.

A não ser que Pai seja de sua responsabilidade.

Pois é, Sérgio: não vai haver um if. Vão haver dois métodos, um recebe banana e o outro laranja. Como você infelizmente já tinha um método que recebe fruta você precisa que ele descubra de qual fruta falamos, mas isso é uma problema de projeto que deve ser consertado.

saoj

Dessa vez seu exemplo foi ruim. Você não precisa testar a classe mãe se ela já foi testada. E você testa o que você desenvolveu. Bom senso é uma das qualidades mais importantes pra um bom programador. Exemplos como esse não ajudam na discussão.

[]'s

Rodrigo Auler

Ajudam sim, pois é exatamente isso que vc faz no mundo real. É exatamente isso que vc faz quando vc cria novas funcionalidades para um framework web por exemplo, ou quando vc altera um sistema assim por exemplo:

// codigo figurativo...
public abstract class AbstractConnection implements Connection {

         public void orderExecuted() {
        
               // muito codigo aqui...

               double qty = buf.getInt();

               // muito codigo aqui...

         }

}

Vamos alterar isso:

Primeiro preparamos a classe para sofrer um override.

// codigo figurativo...
public abstract class AbstractConnection implements Connection {

         public void orderExecuted() {
        
               // muito codigo aqui...

               double qty = getExecutedQty();

               // muito codigo aqui...

         }

         protected double getExecutedQty() {

                  return buf.getInt();

          }

}

E agora vamos estender a classe:

public class ConnectionWithNotacaoCientifica extends AbstractConnection {

      @Override
      protected double getExecutedQty() {

            //  pega quantidade de outra maneira aquil...
      }
}

Vc até pode c onseguir quebrar a classe AbstractConnection quando vc faz isso, mas vc tem que fazer um esforço sobre-humano para conseguir tamanha façanha…

saoj

A verdade é que nós dois estamos certos, pois ambos estão discutindo civilizadamente e apresentando argumentos contra e a favor.

Meu ponto é que testes são legais, mas não são tudo, nem o mais importante, como já sugeriram por aqui em outros posts.

Isso vai depender da experiencia, estilo, tipo de projeto, etc. Logo não dá para dizer que um está mais certo do que o outro…

guilherme.chapiewski

Dessa vez seu exemplo foi ruim. Você não precisa testar a classe mãe se ela já foi testada. E você testa o que você desenvolveu. Bom senso é uma das qualidades mais importantes pra um bom programador. Exemplos como esse não ajudam na discussão.

[]'s

Rodrigo Auler

Ajudam sim, pois é exatamente isso que vc faz no mundo real. É exatamente isso que vc faz quando vc cria novas funcionalidades para um framework web por exemplo…

Discordo de você. Veja só (retirado da Wikipedia):

“The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.”

Você disse que acha que não precisa testar uma classe “Pai” se as classes “Filhas” estão sendo testadas. Isto não é correto. Os testes devem ser feitos isoladamente de forma que, se houver algum problema nas classes filhas, você saiba que o problema é na classe Filha (ou na classe Pai no caso inverso). Não há dúvidas de que todos os testes devem ser feitos isoladamente, inclusive de eventuais superclasses.

[ ]s, Guilherme

saoj

Se vc não altera e apenas estende uma classe PAI, vc não tem muitos motivos para ter que testar a classe pai, do mesmo jeito que vc não tem muitos motivos para testar HttpServlet quando vc estender HttpServlet…

Tem um tópico meu aí mais atrás onde eu falo da diferença de estender e modificar alguma coisa…

Acho que essa discussão já deu o que tinha que dar… Já deu pra fornecer bastante combustível para que agora cada um queime seus neurônios por si só e tirem as conclusões que desejarem…

pcalcado

Na verdade, na verdade, pelo Principio de Substituicao de Liskov você precisa testar a filha em todas as situações onde a pai funcionaria.

guilherme.chapiewski

Se vc não altera e apenas estende uma classe PAI, vc não tem muitos motivos para ter que testar a classe pai, do mesmo jeito que vc não tem muitos motivos para testar HttpServlet quando vc estender HttpServlet…

Você não precisa testar HttpServlet porque alguém já testou ela pra você quando desenvolveu a Servlet API! :slight_smile:

Aliás, esse exemplo do HttpServlet é muito bom.

Imagina se o pessoal da Sun pensasse: “Não, não vamos testar HttpServlet porque todo mundo no mundo todo irá testá-la quando desenvolver seus Servlets.”. Se fosse desta forma estaríamos perdidos.

Esse exemplo deixa claríssimo a necessidade de testar a superclasse isoladamente (a Sun não poderia fazer um release de uma Servlet API cheia de bugs) e você também não pode deixar de testar a sua classe isoladamente (você não precisa testar o que já funciona da superclasse, você testa a subclasse isoladamente).

esb

pcalcado:
O cliente não quer saber se foi feito em java, C# ou Pascal, desde que funcione e dê lucro.

O usuário de um framework não quer saber se foi feito usando X, Y ou Z, desde que funcione e ele consiga fazer seu trabalho.

E nenhum dos dois da a mínima se você não tem testes logo não consegue adaptar seu framework às mudanças necessárias porque não tem uma vírgula de confiança na base de código não quebrar

Se um software não tem testes, automatizados ou não, é porque ele não vale o esforço (é isso que o Carlos disse, mas cv-style).

Você compraria um carro que não foi testado? Veja bem, ele funciona, 100 pessoas já dirigiram eles, tem uma empresa que fatura 1 bilhão de euros a cada nanossegundo que tem uma frota deles mas… você poria sua família dentro dele?

Você usaria um carro sem cinto de segurança? Eu passo boa parte do meu tempo no trânsito, nunca sofri nenhum acidente sério. Cinto de segurança não consegue me dar nem 90% de garantia sequer de sobrevivência num acidente, isso me faz mais confiante para largar minha segurança?

Gostei! Bela analogia, muito melhor do que as anteriormente apresentadas pelos outros participantes do debate! :smiley:

maciel.bombonato

Concordo contigo, só quis dizer que acho que se testes unitários tivessem sido utilizados provavelmente ou possívelmente a quantidade poderia ser menor… só isso.

Quanto a não garantir, bom, isso é complicado dizer, eu acredito que se feito com muito cuidado, mas muito cuidado mesmo, onde vc segue uma documentação bem feita e monta os testes de acordo, existe a chance de sair sem nada a fazer, mas pode acontecer casos em que isso falhe, é normal, afinal foi feito por humanos (assim espero… hehehehehe).

Quanto a confiabilidade, na minha opinião, aumenta sim.

No caso dos bugs, eu considero que é uma ótima oportunidade (mais que boa. rsss).

[]'s

cv1

Rola limitar a conversa a 3 paragrafos por pessoa de cada vez? Eu tenho mais o que fazer, mas quero acompanhar a discussao, saco :mrgreen:

Edufa

Olha testes ajudam a testar, afirmação óbvia.

É um mundo muito cor-de-rosa esse q vc não mexe num framework, ainda mais em algo q é aberto, se vc tem uma funcionalidade não prevista, o ideal seria poder mexer no core mesmo, mas sem testes isso pode ser suicídio.

E pq alguem mexeria no core, dá para listar montes de situações, novas funcionalidades não previstas, suporte a nova versão da VM com mais recursos (por exemplo qdo apareceram os generics) q pode fazer diferença.

Se amanhã ou depois, sei lá, o desenvolvedor morre, sem testes como saber todos os contratos q o código dele obedecia tão primorosamente e como faze-los continuar funcionando, mágica? Só por isso testes já seriam uma ótima ferramenta.

Mas realmente não é a coisa mais importante do mundo, que nem documentação e comentários no código, rs são todas ferramentas, tire os comentários, testes, documentação, javadoc, desenhos no quadro branco, etc… Todas ferramentas válidas. Ainda hj tem muita gente q não coloca nenhuma linha de comentário nem faz documentação, dar manutenção num código desses meses depois de feito deve ser lindo, sem testes melhor ainda [ironia]. Quem sabe um dia a falta de testes seja tão mal vista como a falta dessas outras ferramentas, rs

CV escrevi mais de 3 parágrafos, rs … hehehehe

guilherme.chapiewski

Edufa:
… Mas realmente não é a coisa mais importante do mundo, que nem documentação e comentários no código, rs são todas ferramentas, tire os comentários, testes, documentação, javadoc, desenhos no quadro branco, etc… Todas ferramentas válidas. Ainda hj tem muita gente q não coloca nenhuma linha de comentário nem faz documentação, dar manutenção num código desses meses depois de feito deve ser lindo, sem testes melhor ainda [ironia]. Quem sabe um dia a falta de testes seja tão mal vista como a falta dessas outras ferramentas, rs

CV escrevi mais de 3 parágrafos, rs … hehehehe

Sem querer desvirtuar do assunto, se o seu código precisa de comentários e muita documentação para ser entendido, é um sintoma de que você precisa refatorá-lo. :slight_smile: Eu sou a favor de comentar apenas as coisas que sejam super-ultra importantes. No resto você deve se obrigar a escrever código legível e semântico. Se ainda assim alguma não ficar clara o suficiente, certamente os testes preencherão o espaço que falta.

A documentação do seu sistema não deve ser documentação sobre código. Ela não deve ser frágil, isto é, se o sistema mudar (por exemplo, deixar de ser Java e passar a usar RoR) ainda assim a documentação deverá servir ou a necessidade de modificá-la deverá ser mínima.

Thiago_Senna

Em minha opinião um dos poucos casos que justifica comentário em código é documentar gambiarras. E para completar com classe de ouro coloque um TODO para não pegar tão mal.

cv1

http://www.nigelthorne.com/blog/2005/06/comments-are-deodorant-for-code.html

guilherme.chapiewski

Boa :slight_smile:

abstract

Parodiando uma músiquinha “testar pra quêeee se eu ja sei o que fazer?!”, acredito que alguns programadores escutem ela enquanto fazem "projetos. Testes é um assunto que nem se discute, se faz e quem acha besteira ou algo acadêmico, “boa sorte…good luck”.

Pena que cheguei atrasado nessa maGavilhosa discussão, mas acho que antes de alguém falar de orelhada, entender o que é teste seria importante. E honestamente algumas recomendações de frameworks que encontro em posts aqui no GUJ que parecem a cura do câncer, não citarei nomes, vou criar o www.baladeprataframework.org. :shock:

Este cara, também achava que testes era besteira, piada nerd.

G

Correndo o risco de ser criticado e de fugir ao tema original do tópico:

Gostaria de agradecer ao pessoal do guj. Leio o fórum tem uns anos e admito que nos últimos meses depois que comecei a acompanhar os tópicos aflamados sobre testes unitários, meu nível de conhecimento nessa parte cresceu muito. Somente acompanhando as ironias, brigas, ofensas e sei lá mais o que comecei a ter mais curiosidade na parte de testes, e análise de projeto em geral.

Mas como graduando e profissional nessa área posso afirmar que fazer testes foi, e sempre será, uma boa prática. E olha que é na época de faculdade que você começa com as lambanças de código, e justamente nessa época meu interesse por estudar métodos de projeto, e testar tudo que fazia me garantiram mais tranquilidade e segurança pra desenvolver meus projetos, e o melhor: código estável.

Hoje como profissional faço questão de sair testando as coisas que faço e por enquanto tive poucos contratempos sérios em meus códigos.

Testes de código não mais uma bobagemzinha que te ensinam na faculdade. Já vi colega falar que essas coisas de projeto, análise e testes eram encheção de linguiça. Garanto que eles se ferraram em projetos muito mais vezes do que eu.

Pro pessoal do Neo Framework: parabéns pelo projeto.

Continuem brigando. Até

Criado 13 de junho de 2007
Ultima resposta 5 de nov. de 2007
Respostas 184
Participantes 45