Alguém poderia me informar onde ficam os testes unitários da classe java.util.ArrayList ?
Ou qualquer outra classe standard do java ?
Não sou contra testes unitários nem metodologias etc… mas pensei nisso agora e fiquei curioso.
O kernel do linux pelo visto não tem teste unitário como a maioria conhece, engraçado que está para nascer alguém que escreva um kernel do zero concordam ?
Escrevo código com e sem teste. Entendo absolutamente as questões sobre refactor, bom design, manutenibilidade etc… quando usamos testes unitários, tdd etc? mas a questão religiosa estou fora.
Tem alguém que não usa projeto opensource/free sem testes unitários ? Caso sim, já parou para pensar sobre o editor de textos, a IDE, o framework, a linguagem, o compilador, o SO ?
Ou quem cria editor de texto, IDE, SO etc… é semi-deus e não precisa escrever teste unitário ?
Modo religião ON:
O comando “ls” para listar diretórios e arquivos é antigo pra caramba alguém sabe alguma notócia sobre o teste unitário dele ? Pode ser que liste um arquivo a mais ou a menos do que deveria !
Cadê o teste unitário do counter strike ? Se enviar um comando para lançar uma granada mas na verdade o sprite lança uma carteira de marlboro ? CS nunca mais ?
A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred.
/oj/hg/web/hgwebdir.cgi in ()
48
49 def make_web_app():
50 return hgwebdir(“hgweb.config”)
51
52 wsgicgi.launch(wsgiapplication(make_web_app))
wsgicgi = <proxied module ‘wsgicgi’>, wsgicgi.launch = <function launch at 0x8477b1c>, wsgiapplication = <class ‘hgweb.request.wsgiapplication’>, make_web_app = <function make_web_app at 0x8477c6c>
/oj/lib/hghost/hgweb/wsgicgi.py in launch(application=<hgweb.request.wsgiapplication object at 0x8476c2c>)
62 return write
Vou enviar um email hoje ou amanhã pro Richard Stallman, outro pro Linus Torvalds outro pro Patrick Volkerding perguntando se escrevem testes unitários.
Se algum deles responder eu vou pedir permissão para publicar aqui.
[editado]
Emails enviados, agora é esperar e torcer para que um mero mortal possa ser respondido.
Sr. Patrick Volkerding (O cara que criou e mantém o Slackware) respondeu meu email:
heliofrota :
I do not want to take your time, just ask if you usually write unit tests.
Patrick Volkerding:
heliofrota :
I’m not religious about TDD and i believe that free software can and should have credits without unit tests.
Patrick Volkerding:
Tem alguém que não usa framework porque não tem teste unitário, e está usando Slackware no momento ? (acredito que não, provavelmente usa windows 7 ou MacOX, no máximo rodou o live-cd do kurumim ou ubuntu)
Se alguem escrever uma distribuição brasileiraderivadado Slackware com ou sem testes unitários, gostaria de participar do projeto para aprender mais.
Teste unitário é chato demais, pega poucos bugs e não garante qualidade/simplicidade do código. Teste funcional automatizado ainda vai. O melhor é o teste manual e a programação defensiva. Quando for alterar, use técnicas seguras e lógicamente corretas, ao invés de sair metendo a mão em tudo como um louco. Depois rode os seus programinhas e sistemas para ver se eles continuam funcionando. Os testes automatizados que faco geralmente vão dentro do main das minhas classes. Então eu posso re-executá-los quando quiser. Mas não fazem parte do meu sistema em si, ou seja, não precisam ser mantidos, refatorados, etc.
Na minha opinião, o mais importante de uma biblioteca / framework é se ele possui uma API simples de usar. Isso é qualidade. Caso contrário ninguém entende nada, nem mesmo o cara que fez.
O melhor teste automatizado para o seu sistema é o seu sistema. Pra isso que existe ambiente de testes. Se testes unitários fossem tão bons não precisaria de ambiente de testes. Altera, roda os testes e joga para produção.
[quote=saoj]Teste unitário é chato demais, pega poucos bugs e não garante qualidade/simplicidade do código. Teste funcional automatizado ainda vai. O melhor é o teste manual e a programação defensiva. Quando for alterar, use técnicas seguras e lógicamente corretas, ao invés de sair metendo a mão em tudo como um louco. Depois rode os seus programinhas e sistemas para ver se eles continuam funcionando. Os testes automatizados que faco geralmente vão dentro do main das minhas classes. Então eu posso re-executá-los quando quiser. Mas não fazem parte do meu sistema em si, ou seja, não precisam ser mantidos, refatorados, etc.
Na minha opinião, o mais importante de uma biblioteca / framework é se ele possui uma API simples de usar. Isso é qualidade. Caso contrário ninguém entende nada, nem mesmo o cara que fez.
[/quote]
++
Concordo plenamente.
E há uma leva de “evangélicos” dos testes, que creem que qualquer coisa fora do mundo dos evangelhos dos testes é coisa do demônio.
Isso traduz bem o que penso: testes unitários onde eles são necessários.
Geralmente uso em rotinas que executam lógicas complexas ou razoavelmente complexas, mas sem essa obrigação de 100% de cobertura. Por exemplo, um determinado parâmetro não informado lança uma exceção. Não crio um teste para isso pois está bastante óbvio o comportamento do código.
Outros pontos que o pessoal às vezes faz malabarismos com mock apenas para conseguir cobertura de 100%: Actions/Controllers, Serviços que só delegam ao DAO.
Nos meus últimos projetos, utilizamos TDD, e para mim a mudança foi excelente.
No meu caso, o que sinto após usarmos TDD é que aumenta e muito a confiança no seu sistema, por exemplo, ocorreu um bug, você identifica e cria um teste reproduzindo-o.
Assim, você pode ter certeza que esse bug não existirá mais em futuras modificações do código, pois cada vez que você modificar o código, poderá rodar o testee verificar que os bugs descobertos não voltam mais.
Então a equipe consegue evoluir o software, fazer grandes refactors, mudar implementações de módulos mantendo as mesmas interfaces e garantir que continue tudo ok.
Falo isso porque éramos uma equipe ágil, que mesmo quando o cliente não sabia exatamente o que queria, sempre implementávamos uma versão básica da funcionalidade, e conforme íamos discutindo a solução completa com o cliente, conseguíamos mudar o que já tínhamos feito sem muito esforço.
E testes unitários ajuda principalmente quando você vai dar manutenção em código que não escreveu.
Olhando o teste você consegue ter uma noção maior de como o pedaço de código interage com outros componentes.
Isso é legal, mas pensa comigo: Se vc corrigiu um bug e ele voltou isso muito provavelmente significa uma das opções abaixo:
Código spagetti, sem divisão de responsabilidades, onde tudo depende de tudo.
O cara que tá programando não sabe o que tá fazendo.
Ambos
Minha opinião: se o código tá zoneado e spagetti não será o teste unitário que vai te salvar na hora de dar manutenção. Se o código tá direito e vc sabe o que tá fazendo então não precisa de testes unitários.
quando eu digo bug pode ser também requisitos que mudaram, e então você vai ter que modificar o que estava funcionando antes para funcionar da nova maneira. Isso é muito comum. Como você sabe que vai continuar tudo igual, sem efeitos colaterais no código que depende disso sem testes?
O Eclipse não vai indicar nenhum erro de compilação, mas como saber se a lógica dos componentes que dependem do que você mudou continua correta?
andreiribas o que você escreveu eu entendo, tanto que escrevi a frase acima.
O foco do pensamento é Não usar software que não tem teste unitário. “Você” usa software que não tem teste unitário ? Caso sim, não “você” não teria argumentos para degradar qualquer framework que não possui testes unitários estou certo ?
PS: Quando falo “Você” me refiro aos fanáticos por testes unitários e não você andreribas
Se o cara reclamar que o neoframework (por exemplo) não tem teste unitário e está usando slackware linux, então esse cara está dando um “TIRO no pé” bem feio.
Foi uma grande iniciativa mandar e-mail pra esses caras pra saber o que eles pensam Mais legal ainda foi ver que eles responderam com suas opinioes.
Nao sou fanatico, mas passsei a trabalhar com TDD e BDD nos ultimos seis meses e tenho gostado muito. Antes nao tinha trabalhado nao porque nao gostava, mas sim porque nao tinha oportunidade.
Alguns pontos interessantes a observar, em minha opiniao:
TDD e testes unitarios nao sao a mesma coisa. TDD e mais uma tecnica de design, e a cobertura de testes adquirida com o seu uso e uma consequencia, e nao a motivacao.
Usando TDD voce tem menos chances de escrever codigo espagueti por dois motivos: 1) voce tende a separar as responsabilidades em diferentes classes e 2) o refactoring faz parte da metodologia. Ou seja, voce tende a escrever codigo menos acoplado e nao fica satisfeito com o primeiro resultado, voce o melhora.
Testes unitarios nao sao, e nem devem ser, a unica forma de garantir a qualidade do software. O teste unitario, quando existe, e bom para o desenvolvedor, mas ele por si so nao garante que todas as features serao entregues sem erros.
EDIT - nao, eu nao deixo de usar software so porque ele nao tem testes unitarios.
Eu falei aquilo lá em cima (sobre não usar tão rigidamente) mas confesso que gostaria de experimentar o TDD de verdade, já vi muito por aí gente dizendo que depois de experimentar não quer saber de outra coisa na vida
Li o livro (Kent Beck) mas quando tentei praticar tive uma dificuldade imensa com os “passos pequeninos”, ciclos curtíssimos onde cada etapa de codificação não pode levar mais de um minuto. Para mim essa é uma das mudanças de paradigma mais difíceis. E para vocês que usam TDD, foi tranquilo passar a pensar dessa forma?
Programação é uma arte. Um programa é como um livro: há infinitas maneiras de contar a mesma história.
Refatoração é fundamental para melhorar a coisa. Um sistema está sempre under construction e pode ser sempre melhorado, simplificado e arrumado.
Minha opinIão é que teste unitário funciona mais como atrito do que como incentivo. O fato de Java ser uma linguagem fortemente tipada com IDEs maduras que vão te ajudar e muito no refactory faz uma grande diferença para a necessidade ou não de testes unitários.
Se eu quiser fazer uma mudança mais radical, vou ter que mudar também todos os testes. Já paras as mudanças mais simples os testes vão testar as coisas óbvias que provavelmente vc não quebrou tendo em vista que vc entende bem lógica if-then-else-or-and-etc. Se você ainda não treinou o seu cérebro para ser bom com if-then-else-or-and-etc. então os testes serão sua muleta. Cada passo que vc der vc vai executá-los para saber se vc não quebrou aquele IF. Quanto mais vc programar, menos erros de IF você irá cometer, até chegar num ponto que vc vai estar seguro o bastante para modificar um IF sem testar. Nesse ponto os testes unitários serão apenas um pé-no-saco.
Minha opinião é que os testes unitários são um limitador da liberdade e da criatividade. É uma muleta que não ajuda muito e causa atrito desnecessário.
Agora TDD é outra coisa como o mestre Tarso falou. Cada um tem sua preferência para modelar. Pra mim a melhor maneira de planejar é executar. Sair programando, analisando e aperfeiçoando ao mesmo tempo. O teste se torna uma burocracia que reduz a dinâmica da coisa. Mas cada um com suas preferências. Apenas estou expondo minha preferencia e opinião sobre o assunto.
Agora com certeza: Teste unitário é a última coisa que vai determinar se um sistema está bom ou não. Ele é no máximo uma ajuda para o programador.
E ter que especificar todos os contratos, todos os IF-then-ELSE do meu sistema via testes unitários é coisa de maluco. Eu preciso de liberdade para programar sem ter que bater continência pros testes unitários a cada passo que dou.
Ha algumas questoes a serem consideradas quanto a isso.
A resposta óbvia a sua pergunta implicita é: Sim, é possível fazer software sem TDD, muita gente já fez e muita gente continua fazendo software de qualidade sem essa tecnica.
Eu nao gosto de nada que seja imposto, nem de nada que não tenha sua eficacia comprovada, por isso eu entendo perfeitamente a irritação de voces contra os pregadores incondicionais da tecnica. Esses caras estao em toda parte, atacando todo mundo que nao pensa como eles. Seja la por que motivo for, qual tecnica, qual ferramenta, qual SO, qualquer coisa tem esses caras.
Se voce nao usa Mac voce nao eh feliz, se nao usa Linux voce eh burro, se nao usa Scrum esta fora do mercado, se nao usa TDD nao sabe desenvolver software.
Esses caras sao umas pragas que se espalham por todo o lado e na maioria das vezes nao sabem nem porque defendem as coisas que defendem.
Mas nao eh por isso que a tecnica é ruim, que nao te ajuda e que deve ser evitada.
Eu posso desenvolver software sem TDD? Logico que posso, mesmo hoje a maioria é desenvolvida assim. Mas por que? Sera que eu nao posso fazer uso de novas tecnicas pra me ajudar a desenvolver?
Sera que so por que tem um mala o tempo todo me enchendo o saco dizendo que TDD eh isso, isso e aquilo, que eu tenho que desconsiderar?
Eu uso TDD, e gosto bastante, ele me ajuda a entender código legado (quando eu jogo testes em pontos que vou ter que alterar) e me ajuda a definir a estrutura de novos
codigos. Ele, para mim, eh muito mais uma ferramenta de analise e desenvolvimento do que de teste. Mas nao eh uma tecnica facil, voce precisa de muita pratica pra que ele
seja produtivo. Depois ele eh absurdamente produtivo, mas nao sem estudo árduo. E esse é o ponto, o estudo árduo é em conceitos basicos OO, que muita gente acha que nao precisa e não necessariamente em TDD que todo mundo procura aprender.
Nao adianta nada voce mergulhar em toda a literatura de TDD sem antes entender os conceitos basico de programacao e de orientacao a objetos. Depois que voce tiver aprendido, pelo menos um pouco, a base da programacao, os principios de atribuicao de responsabilidades, alta coesao, baixo acoplamento, divisao em camadas logicas e etc e etc e etc, aí sim TDD pode te ajudar, mas se o cara nao sabe o basico nao adianta chorar, com testes ou sem testes o resultado eh o mesmo: codigo ruim.
O grande problema que eu tenho visto ultimamente, salvo excecoes, é que muita gente quer “se livrar” de TDD, não porque acha que nao precisa, porque é capaz de escrever
um código simples sem TDD. Mas por que TDD simplesmente é reflexo do seu código, se o teu codigo for simples, será facilmente testavel, se for complexo os testes ser
tornarao um inferno.
É como o saoj disse, voce nao tem que ficar esbarrando em burocracia de testes a cada vez que quiser fazer uma alteracao simples. Nesse passo voce pode optar por jogar
os testes fora, ou estudar TDD e aprender a escrever testes de uma forma que a “dor” da alteração no teste será tão pequena quanto a alteração da regra.
Essa eh uma coisa que eu sempre repito, se criar ou alterar um teste leva mais tempo do que criar ou alterar aquilo que ele esta testando, tem algo errado com a forma
que voce testa. Eu ja vi gente se enrolando no meio de mocks e stubs e coisas do genero, tentando fazer TDD e “fingindo” gostar dele, quando deveria rever
a forma de programar. O seu codigo tem que ser simples, os seus testes tambem. O uso excessivo de mocks eh um bom indicativo de que há algo errado com eles, ao menos
nos casos que tenho visto.
Eu concordo com saoj tambem quando ele diz que testes unitarios não são determinantes para a qualidade do sistema. Nao sao, nem de longe.
Mas para quem critica os testes, eu aconselho a se perguntar, se esta lutando contra TDD porque produz codigo ruim que dificulta o uso da tecnica, ou porque realmente
não precisa da tecnica?
Tenho uma observacao em relacao a testes unitários
Muitas vezes, por ser obrigado a fazer o teste, o programador cria um método qualquer joga uma anotation @Test e chama o método no qual deseja testar e se dá como satisfeito.
Em grande parte deles, nao testa nem 10% dos casos de testes possíveis e termina a tarefa com a sensacao de teste concluído e de sofware bom.
Acontece um caso muito parecido qd alguem coloca um comentário no código, q nao diz nada com nda, simplesmente para ter o gosto de falar q fez o javadoc ou o resolveu as críticas do checkstyle.
O q me preocupa em relacao ao TESTES é q muitas vezes se impõe a obrigacao de se criar 100% dos testes unitários, e isso algumas vezes acaba forcando a barra para a criacao de testes que nao fazem nada com nada. Tem empresa q obriga o programador a testar POJO, enfim, coisas do tipo…
Acredito q Testes Unitários são bons qd são usados verdadeiramente onde é necessário e nao simplesmente por leis, religioes ou caprichos…
Sobre o q o pessoal tava debatendo, nao deixaria de usar um software ou framework q nao tem teste. O q me diz se o software ou framework é bom ou nao, é a confianca q ele adquiriu. Na minha opnião confianca se conquista por diversos outros fatores, como por exemplo opnião dos usuários e resultado final em cima do problema q ele se propôs a resolver e diversos outros fatores.
Esse foi o segundo motivo real da discussão que iniciei, o primeiro foi realmente o questionamento a respeito de testes sobre a classe ArrayList e que propaguei em outras questões.
Eu penso que proibir publicação e divulgação de software livre em um fórum democrático e que apoia o opensource signifca postura ditatorial e apoio à software proprietário (não free software). Criticar iniciativas, mesmo sabendo que existem pessoas/profissionais neste mundo, que , muitas vezes fizeram-nos o favor de criar software para que possamos programar em linguagens de mais alto nível, e que tais pessoas/profissionais nem sequer se estressam com TDD, ou testes unitários.
A questão toda é que se “você” quer ser 100% radical e verdadeiro seja realmente 100%. Começe escrevendo o seu próprio sistema operacional com 100% de cobertura de testes ou mude sua postura e passe a aceitar que existem inúmeras pessoas/profissionais melhores do que você e softwares melhores do que o que você escreve/cria mesmo sem testes unitários.
É bem mais simples ser humilde do que ser “o foda”. Afinal, escrever código mais simples demonstra mais inteligência do que escrever código complexo, para atingir o mesmo objetivo.
