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
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
Como se testa testes? Lendo-os?
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.
O que vc sugere como alternativa? 
O que vc sugere como alternativa? ;)[/quote]
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
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.
O que vc sugere como alternativa? ;)[/quote]
É muito chato ter que explicar piadas 
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.
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!
Desculpa!
Não consegui perceber sua expressão facial para ver que você estava bricando!
Na próxima tenta colocar um emoticons 
:shock: :twisted: :evil: ou apenas uma risada aHUhauAHUhauAHUah hehehehe hahahaha rs rs rs rs
E encare isso com bom humor!
Abraços …
Essa história de “quem testa os testes” é um dos maiores papos furados.
-
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.
-
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.
[quote=Paulo Roberto Schiavon][quote=renato3110]
É muito chato ter que explicar piadas
[/quote]
…[/quote]
Isso era outra piada
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…
Putz.
Se algum testeiro entendeu minha dúvida e quiser responder, eu quero aprender.
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.
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
Nao é o momento mas existem ferramentas pra isso?
:shock:
]['s
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.
[quote=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.
[/quote]
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.