Como introduzir TDD à minha vida?

Oi Bruno!

Sua pergunta é excelente e muito relevante. Eu nao vou argumentar em como começar, mas vou argumentar em relação aos meus próprios erros:

A pior maneira de tentar começar TDD é criando testes unitários em um projeto que já nasceu sem testes. Escrever testes unitários para código muito acoplado é praticamente impossível: eles viram pequenos testes de integração, já que você precisaria criar um número gigante de mocks para transformar o teste em unitário. E isso é um fato: código que nasceu sem testes é mais acoplado que o que nasce com testes! Quando você testa desde o começo, seu código é forçado a ser desacoplado, caso contrário você não conseguiria testa-lo!

Em resumo: se você tentar implantar testes unitários em algo que já tem meses de desenolvimento, além de não conseguir realizar a tarefa direito, vai ficar frustrado e culpar o TDD.

Sim, isso é uma confissao de 4 anos atras

Pois é, estou nessa também porque já faz muito tempo que não pego alguma coisa do zero. Sempre caio de para-quedas em projetos que tem coisas que me dão vontade de chorar.

Sou outro programador de Schrödinger.

Só um adendo…

Existem situações em que você precisa adicionar testes a um projeto existente, caso contrário você vai se dar mau. Para esses casos, é necessário uma pessoa com mais experiência em testes automatizados de um modo geral. E estou com o Paulo no que ele falou: Iniciante em TDD tentando aplicar em um projeto sem testes, vai se irritar e culpar o TDD.

Falando em testes unitários, como vocês definem uma “unidade”? Uma classe, um método?

Paulo Silveira:

Em resumo: se você tentar implantar testes unitários em algo que já tem meses de desenolvimento, além de não conseguir realizar a tarefa direito, vai ficar frustrado e culpar o TDD.

Nao concordo com essa afirmacao.

Em muitas ocasioes vale a pena criar testes unitarios para projetos em andamento. Se vc esta trabalhando num projeto existente porque nao introduzir testes unitarios durante o refactoring ou para novas funcionalides do sistema?

Mas acho que vc quis se referir a introduzir testes unitarios para ser adotado por uma equipe de desenvolvimento e nao por um ‘desenvolvedor solo’. Isso e realmente mais complicado, pq se as pessoas estivessem dispostas a comprar a ideia ja teriam feito desde o inicio do projeto.

Excelente tópico.
Sempre tive a mesma dúvida, mas nunca tive coragem de perguntar :oops: :oops: (na verdade, nunca tive tempo pra estudar direito isso. Agora nas férias não tem como escapar).

Tópico favoritado.

Abraços.

Olá

A pergunta é muito pertinente e ainda tem o mérito de desencavar este excelente post do nosso amigo Chapiewski

Acho que ninguém aqui aprendeu a programar fazendo testes. A gente sabe que é bom e tudo o mais mas começar a programar pelos testes exige um certo esforço mental.

Eu que sou macaco velho e põe velho nisto, sinto dificuldades nas raras vezes em que escrevo código de pensar primeiro nos testes. Já andei me forçando mas como escrever código não faz parte do meu dia a dia ainda não peguei o hábito. É isto que cada um precisa: pegar o hábito. Para isto precisa investir um certo tempo sofrendo um pouco.

Sabem do que sinto falta? De um tutorial explicando como fazer isto usando o eclipse (ou o Netbeans) desde a criação e organização das classes de teste e das classes testadas. Alguns dos melhores links que conheço são também do Chapiewski:

http://gc.blog.br/2007/06/20/slides-da-palestra-sobre-tdd-no-riojug/

http://gc.blog.br/2008/03/30/test-infection-por-onde-comecar/

[]s
Luca

É, caio no mesmo caso do Victor, o código que pego é quase sempre de manutenção. Apesar disso não acho que esse é o maior problema.

Por aqui a arquitetura é o famoso BOLOVO, orientado ao banco de dados. O problema é que não sei testar algo onde o endpoint é sempre o BD, onde as operações são sempre “… do/no banco”, verificar se tal dado existe no banco, trazer várias coisas do banco, associá-las, e mostrar na tela, inserir, alterar… Os dados sempre vem e vão para algum lugar.

E não ajuda o fato que o mecanismo de persistência é fixo, SQL/JDBC na mão, mudar ele para um mock e de volta p/ o mecanismo real daria trabalho e é falível.

Ouvi falar que o melhor modo de tratar isso é instalar um SGBD localmente e zerar os registros antes de começar os testes.

TDD precisa de uma ambiente mínimo para funcionar?

Bruno Laturner:

Indo direto ao ponto:

Sou um Programador de Schrödinger e gostaria de introduzir testes e TDD à minha vida, à empresa que trabalho e nas que trabalharei. Infelizmente tenho aquelas eternas dúvidas:

Como começo a fazer testes partindo do ponto zero; e,

Como tornar isso um hábito, um desenvolvimento orientado a testes de fato?

Gostaria que a discussão tivesse um tema “Como introduzi TDD à minha vida”, queria que falassem do passado e do presente, desafios encontrados, uma opinião muito pessoal de como fizeram e como fazem isso. Eu aprendo muito por exemplo/tutorial de vida de outras pessoas.

Como vocês começaram com TDD? Agradeço desde já a ajuda.

Existe uma diferença entre usar testes unitários e usar TDD. TDD significa Test Driven Development : Desenvolvimento Guiado por Testes. Isso é radicalmente diferente do que simplesmente usar um Junit da vida e ter algumas ou todas as classes sobre o controle de testes ( cobertura 100%).

Então o ponto inicial é começar a usar testes unitários. O JUnit e o Eclipse são uma boa dobradinha, mas existem outras por ai (TestNG + Maven ou Ant por exemplo). O ponto aqui é simples. Vc faz uma classe que executa alguma logica. Vc sabe que passados os parametros x e y o resultado tem que ser z. Vc cria uma classe de test (do junit por exemplo) e executa o codigo como se estivesses dentro de um programa real. A diferença é que o seu método de teste só executa uma classe. testes corriqueiros que vemos em exemplos em revistas e afins não são realistas. ninguém escreve um teste para testar de 1+1 = 2.
Em aplicações normais as suas classes vão produzir objetos e alterar estados em outros objetos de outras classes e não simplesmente retorná-los como uma calculadora. Vão tentar enviar email, mensagens via Jms , acessar o banco, processar um arquivo. É isso que tem que ser simulado no teste. vários niveis de complexidade geram vários tipos de teste (unidade, integração, etc… ) comece pelos de unidade.

Rápidamente vc vai entender que aplicar testes de unidade em ambientes complexos demanda uma muito boa separação de responsabilidade dos seus objetos. Para fazer testes bem feitos o seu modelo tem que ter OO bem feita. O seu modelo vai tender naturalmente a ser desacoplado porque vc vai precisar substituir objetos reais por objetos simulados. Por exemplo, substituir um repositório que comunica com o banco por um que simplesmente guardas as coisas em memoria e disponibiliza métodos públicos para podermos consultar se os objetos estão lá e montar os asserts. Estes objetos ficticios, simulados - chamados mocks - podem levá-lo na grande estrada do teste orientado a mocks. Que nada tem a haver com TDD em uma primeira aproximação.

O habito vem do seu esforço em não desistir de incluir suas classes sobre o controle de testes. A maior parte das vezes isso não é simples e requer um esforço tanto de codificação como de refactoring para que possam ser injetados objetos simulados.

TDD tem um propósito diferente do simples teste. Você não modela a aplicação e depois a testa. Vc primeiro escreve código que usa o modelo na forma de testes. A classe do modelo não tem código, apenas interface. O teste invoca essa interface. O teste é executado e dá erro porque nada foi implementado ainda. Ai vc implementa a lógica da classe. Testa. refactora, Testa. E continua nisto até que o teste passe.
Ai vc parte para outra funcionalidades. Sempre começando por definir como o codigo se deve comportar e só depois implementando o miolo. O teste vem primeiro. É ele que guia o desenvolvimento da classe como um cliente dos serviços da classe e não a classe que dita o teste. É por isso que se chama Desenvolvimento guiado por teste (TDD). Em TDD raramente ha a necessidade de mocks porque vc não está simulando o funcionamento do sistema, vc está escrevendo como ele vai se comportar. Claro que mocks são uteis em situações complexas que acabarão aparecendo, mas não são o foco nem a ferramenta principal. TDD é muito ligado a design by contract. A preocupação é como o que a classe deve fazer e não como ela deve fazê-lo. Ela tem que respeitar o contrato.
O TDD incrementa isso definindo o contrato à priori via código executável ( o código do teste).

TDD é um processo moroso e pouco ágil para sistemas complexos.Para classes unitárias pode ser mais eficaz.
Embora isso, ele é altamente compensador uma vez completado já que vc acaba como a classe e o teste prontos ao mesmo tempo. Eu utilizo esta técnica apenas quando não domino aquilo que a classe irá fazer ou não tenho o modelo claro na minha cabeça, ou quero experimentar com várias interfaces para a API para encontrar a que é mais fluente e coerente. Assim , ao escrever o código cliente primeiro, as funcionalidades da classe (ou de uma pequena biblioteca de classes) aparecem mais naturalmente.

–
Como nota tenho que comentar a desconfiança encontrada nas palavras do Donald Knuth. Ele tem toda a razão no que diz. O problema é que, como sempre, ha uma confusão de conceitos básicos e os hypes levam a melhor. Orientação a Objetos não tem mistérios sobrenaturais.

Como o próprio Knuth diz nessa mesma entrevista “software methodology has always been akin to religion.” é preciso ter muito cuidado quando se fala de TDD , DDD , XP, etc … sem raciocinar a diferença entre a metodologia e a filosofia e as técnicas e ferramentas. As técnicas e ferramentas são as da OO. Não existem outras. Não serão criadas outras.

Aqui fica a ideia dele - expressa na mesma entrevista - sobre XP.

With the caveat that there?s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I?ve ever heard associated with the term “extreme programming” sounds like exactly the wrong way to go…with one exception. The exception is the idea of working in teams and reading each other?s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.

É tudo uma questão de bom senso. Metodologia não poderão nunca suplantar a boa e velha teoria de computação que lhes dá base.
Seja OO ou outra qualquer.

Quanto ao problema do gato do Schrodinger o nome não é muito bom. A MQ é um dos mais exatos ramos da física e não aleatória como é popular. O gato do Schrodinger é só um, não dois. O gato está morto ou vivo. Não morto e vivo. É por isso que quando vc abra a caixa nunca sai um gato zombie de lá. Ou sai vivo, ou está morto. (é como lançar uma moeda , ou sai cara ou coroa, nunca sai cara e coroa)
O problema mais grave com a analogia é que passa a idéia de que vc pode escrever qq código absurdo e por meio de escrever testes vc consegue que ele funcione corretamente (mascarando a incompetência do programador) e sem saber como isso veio a acontecer. Ou seja, faça-se um sistema caótico, inclua-se testes e vira um sistema estável. (!)
É verdade que os testes levam a essa conclusão, mas não sozinhos. É o refactoring e reimplementação durante os testes que leva o sistema a funcionar. Um programador mentecapto nunca irá colocar o programa a funcionar por muitos testes que existam.

Acho que é isso que fica das palavras do Knuth: parem de procurar nas metodologias o que falta em conhecimento fundamental.

Bruno Laturner:

Ouvi falar que o melhor modo de tratar isso é instalar um SGBD localmente e zerar os registros antes de começar os testes.

TDD precisa de uma ambiente mínimo para funcionar?

A principio nao importa se vai ser em memoria, banco de dados local ou remoto desde que seja um espaco onde nao exista interferencias externas. Lembrando que testes unitarios, cada desenvolvedor tem seu processo de build isolado dos demais desenvolvedores no projeto.

Em se tratando do ambiente, eu concordo quando o sergiotaborda diz “TDD é um processo moroso e pouco ágil…” mas ao mesmo tempo é a estrategia mais eficaz que conheco pra desenvolvimento que envolva mais de 1 programador. Isso inclui code ownership, CI e tudo aquilo que TDD compreende alem de testes do desenvolvedor. Este ultimo principalmente acho util no modo solo mas TDD como todo nao oferece tantos beneficios evidentes.

Assino embaixo Luca, na minha opinião é uma falha. Se vários tutoriais viessem com testes unitários, bem como exemplos, ficaria muito mais fácil incorporar estes hábitos sem contar que seria vantajoso verificar como outros usam os testes e ainda ver como certas funcionalidades são testadas.

Seria uma grande mudança da forma de se programar, por mais que falem muito de TDD, sem exemplos a maioria acaba não se acostumando e desiste, sem contar que o esforço de usar algo pouco demonstrado aumenta consideravelmente.

E quando digo pouco demonstrado, não me referi a tuoriais de como usar TDD, isso existe e muitos os conceitos estão bem explicados, é relativamente fácil de entender o q se propões, mas o uso prático, ver os testes, ver como estão usando e resolvendo situações parecidas, comparar, e por isso para aprender através deles ainda falta muito.

Sempre que pego um sistema ou projeto para estudar, a primeira coisa que verifico são os testes unitários, e uma infima minoria se preocupa com eles, e muitos ainda são primários, testando coisas óbvias e deixando de lado testar a lógica de negócio.

Aqui tem ótima referências:

Ando estudando TDD esses ultimos dias, muito bom seu post. Mas fiquei meio confuso no “raramente”. Escrever como o sistema vai se comportar não indica o uso de recursos externos? Claro que a super utilização de mocks mostra que o que você esta escrevendo provavelmente está com um acoplamento muito alto, mas via de regra sempre há algum acoplamento. Esse “raramente” é tão “raramente” assim?

Ótima resposta Sérgio!

Eu já faço a distinção entre fazer testes e fazer TDD, meio que coloquei isso na frases grifadas. “Como começo a fazer testes” é o meu objetivo inicial, o começo de tudo, “Como tornar isso um hábito, um TDD de fato” é o meu objetivo final.

Concordo demais com que fala de exemplos de revistas, elas se focam demais em “testar que instrumentos musicais estão afiados”, pouco falam de testar se os músicos sabem tocá-los e ler as partituras, e nunca falam sobre como garantir que a orquestra ser um sucesso.

Outra, por acaso testar as partes garante que o todo funcione?

No caso que descreveste, não é demais ter ver se o email foi enviado certo, se a mensagem Jms chegou, verificar o que no banco mudou, de o resultado do processamento do arquivo está certo? Testar cada um em separado já não garantiria tudo?

Conseguirá se o que ele fizer passar em todos os testes; [color=green]All green[/color]. Como você disse “A preocupação é como o que a classe deve fazer e não como ela deve fazê-lo.”

Se bem que se ele consegui essa “façanha”, ele não será mentecapto.

Ando estudando TDD esses ultimos dias, muito bom seu post. Mas fiquei meio confuso no “raramente”. Escrever como o sistema vai se comportar não indica o uso de recursos externos? Claro que a super utilização de mocks mostra que o que você esta escrevendo provavelmente está com um acoplamento muito alto, mas via de regra sempre há algum acoplamento. Esse “raramente” é tão “raramente” assim?

Quando vc usa TDD vc não tem as classes ainda. Vc está criando-as e sendo guiado pelos testes para as criar.
É um processo de desenvolvimento de “dentro-para-fora” no sentido que coisas como banco e jms só vão chegar no fim.
Então, vc passa quase todo o desenvolvimento sem estar simulando nada. Vc está correndo o sistema como ele tem que ser.
No fim do desenvolvimento vc aplica a tecnica normal de testes e ai tudo tem que ser testado. É ai que entram os mocks. Mas isso acontece quer vc use TDD ou não.

O raramente vem de que, às vezes, em certas circunstancias, vc precisa de um mock durante o desenvolvimento. Sobretudo quando vc tem alguma comunicação com outro sistema ou mecanismo que vc ainda não conhece, etc… Por exemplo, vc invocar um webservice que não é seu. Ai vc é “forçado” a usar o mock durante o TDD.

E não, o como o sistema vai se comportar não indica uso de sistema externos. É relativamente simples abstrair esses sistemas utilizando classes especializadas e implementações delas que simplesmente simulam o real. Isso é naturalmente util ao mexer com banco de dados, por exemplo, em nunca durante o desenvolvimento vc usa um banco realmente. Vc usa uma classe(biblioteca) que simula o banco. Repare que o foco do TDD é desenvolver a aplicação (tal como outras DD por ai como MDD, DDD , etc…) e não desenvolver os testes em si mesmos. Eles são um sobre-produto que resulta naturalmente da metodologia.

Detalhe, desenvolvendo com TDD vc obtem testes. Não necessariamente vc obtém bons testes ( com a mesma qualidade e profundidade necessária aum teste que visa ter cobertura máxima, por exemplo)

Bruno Laturner:

Ótima resposta Sérgio!

Eu já faço a distinção entre fazer testes e fazer TDD, meio que coloquei isso na frases grifadas. “Como começo a fazer testes” é o meu objetivo inicial, o começo de tudo, “Como tornar isso um hábito, um TDD de fato” é o meu objetivo final.

Concordo demais com que fala de exemplos de revistas, elas se focam demais em “testar que instrumentos musicais estão afiados”, pouco falam de testar se os músicos sabem tocá-los e ler as partituras, e nunca falam sobre como garantir que a orquestra ser um sucesso.

Outra, por acaso testar as partes garante que o todo funcione?

Não. Não garante. Porque aquele pedacinho de codigo que cola as partes tb pode ter erro. É por isso que existem testes de integração. Mais, as peças por si só funcionam, mas cada uma com logica diferente. Quando se unem elas não são compativeis conceptualmente (embora as suas interfaces de codigo sejam)

não, não é demais. Testar nunca é demais. Esse é um fator bom e ruim, já que é facil se desmoralizar por não ter testado tudo o que podia ( já que o que podia ser testado é muito vasto)
No caso do email, por exemplo, ele pertence a um processo. E é o processo que vc está testando, não o envio fisico do email ( isso o pessoal da API de JavaMail já fez) . Por exemplo, o usuario é cadastrado e a senha enviada por email. Se o email não é enviado corretamente o usuário não pode ser salvo (não pode dar o commit) porque assim teriamos um usuário sem acesso ao sistema. O mesmo ao contrario se o banco dá pau não ha pq enviar o email.
Mas quando vc testa isto vc não envia email para ninguem com JavaMail. Vc simula. E simula que o envio deu problema (lançando um exception).
Testes de integração ou de processo são tão ou mais importantes que os de unidade. são eles que realmente garantem o sistema.

Conseguirá se o que ele fizer passar em todos os testes; [color=green]All green[/color]. Como você disse “A preocupação é como o que a classe deve fazer e não como ela deve fazê-lo.”

Se bem que se ele consegui essa “façanha”, ele não será mentecapto.

O ponto é que se o teste dá vermelho e o programador é incompetente ele nunca o fará ficar verde. Não é adicionando mais testes que vai ficar verde, é treinando o cara. Enfim, o conhecimento do programador ainda é mais importante que os testes. Se o cara faz testes mas apenas porque é mau programador, isso não é uma boa utilização dos testes ( é como ficar fazendo debug de tudo o que vc escreve a cada linha que vc escreve pq vc não tem a certeza de que fez certo. )

Aí que eu queria chegar. Eu posso não usar mocks o tempo todo como eles são do lado do teste (mocks de biblioteca, como jMock), mas de alguma forma e em algum momento eu preciso simular meus recursos externos (como BD), e isso não é raro.

E uma classe que simula o real, no meu entendimento, não deixa de ser um mock também!

Obrigado!

Então Sérgio, por onde você começa um teste, como o faz no dia a dia? Como o caso de uso se transforma em testes?

Pergunto por que os casos podem ser muito gerais ou num nível muito alto, sendo que os testes mais unitários são aqueles que estão lá em baixo na cadeia, testando a base do sistema. Como você identifica as tuas unidades?

Disse que o desenvolvimento é de “dentro para fora”, mas é necessário ter uma boa visão de tudo antes de escrever teu primeiro teste.

Tem alguma macete/dica para começar com os testes ou é só com a experiência?

Olá

Este tópico está muito bom. Gostei muito dos links que passaram.

Antigamante, no tempo em que ninguém falava de testes, que os programas eram lotados de System.out.println, passei por aqui e quando o chique era o chamado desenvolvimento top down, eu muitas vezes discutia com os top downzistas argumentando que sentia necessidade de fazer coisas bottom up.

É claro que levava pedrada de todo jeito porque estava violando um princípio básico da época que era primeiro pensar, pensar, pensar e pensar mais um pouquinho e só depois começar a fazer. Mas o que sentia era necessidade de ver funcionando algoritmos que seriam posteriormente incorporados na solução. Era como testar as ideías. Ainda bem que hoje ninguém mais pensa em top down e outras cascatas.

Encaro o TDD mais ou menos do mesmo jeito. É poder partir sabendo que o principal vai dar certo.

Vantagens? A principal, como o Paulo salientou, é que o sistema redundante fica naturalmente mais desacopladinho e para mim mais fácil de entender.

E devemos testar tudo para obter 100% de cobertura? Isto já acho exagêro em muitos casos mas chegar perto é muito tranquilizador.

[]s
Luca

Gostei bastante deste screencast.

Me fez pensar numa coisa: quando a classe tem responsabilidades demais você faz tantos testes que acaba ficando cansado, e assim segue refatorando a classe em duas ou mais delas, refatora também os testes em mais classes e só para não ter que testar as mesmas coisas sempre.

Acho que o relato de uma pessoa de umas das equipes que estou colocando o conceito de qualidade/agilidade resume muito bem o que acontece com o desenvolvimendo com TDD, “se tem uma segurança muito grande de poder alterar qualquer coisa e saber exatamente onde os problemas vão refletir!”.

Quando se falam por exemplo em análise de riscos, nada mais prático de alterar o teste, executar e ver quais pontos podem ser atingidos por aquela alteração, isso realmente da uma segurança na hora de se fazer alterações, óbvio que um bom nível de cobertura é essencial para isso.

Luca:

Olá

Este tópico está muito bom. Gostei muito dos links que passaram.

Concordo. IMHO, tópicos desse tipo é que fazem com que bons desenvolvedores ainda estejam aqui no GUJ.

Os meus ainda tem bastante disso. Sem contar a quantidade de comentários existentes… é um terror.
O debugger entra nessa parte de testes? Porque vejo muitas pessoas falando (tá certo que é em RoR) que não usam mais o debugger. Provavelmente me enganei em alguma coisa.

Luca:

Encaro o TDD mais ou menos do mesmo jeito. É poder partir sabendo que o principal vai dar certo.

Vantagens? A principal, como o Paulo salientou, é que o sistema redundante fica naturalmente mais desacopladinho e para mim mais fácil de entender.

Abraço.

Esse link discute estilos de TDD:

Bruno Laturner:

Então Sérgio, por onde você começa um teste, como o faz no dia a dia? Como o caso de uso se transforma em testes?

Pergunto por que os casos podem ser muito gerais ou num nível muito alto, sendo que os testes mais unitários são aqueles que estão lá em baixo na cadeia, testando a base do sistema. Como você identifica as tuas unidades?

Disse que o desenvolvimento é de “dentro para fora”, mas é necessário ter uma boa visão de tudo antes de escrever teu primeiro teste.

Tem alguma macete/dica para começar com os testes ou é só com a experiência?

Na realidade eu também ando à procura do mesmo que vc. Me custou muito tempo diferenciar entre TDD e Programação Orientada a Teste ( que nada mais é que boa OO + JUnit da vida) por isso fiz questão de explicar a diferença.

No projeto MiddleHeaven que tou conduzindo no tempo livre uso o TDD para implementar as features. Na realidade uso uma mistura. Eu tenho o modelo ± na cabeça e uso os testes para experimentar na prática. Não são testes exaustivos. (como falei, esse não é o objetivo do TDD). Eu acho bastante util porque força o desacoplamento quer vc queira ou não As minhas unidades são normalmente conjuntos de classes (mini API) ligadas por herança ou delegação. (de novo, aqui eu estou preocupado com o desenvolvimento, não com cobertura) e esta “inspeção” de desacoplamento é muito importante quando se constrói um framework.

Cobertura tb acho um porre. Como o Luca tb irrealista na prática, embora na teoria seja excelente se for alcançado. É um excelente trabalho de voluntariado (ou para um equipa de testers. Se vc tiver uma)

No trabalho a política não é muito orientanda a TDD ou qq DD na realidade, então eu somo esses conceitos sempre que posso. É um work in progress na realidade. ja que como são filosofias, ha um trabalho de convencimento. Normalmente testamos as classes mais criticas ou as que são mais complexas ou mais centrais ( normalmente classes do tipo Services do DDD). Mas não todas e não ha uma procura real de cobertura 100%.

Eu acho POT e TDD muito util, mas dificil , custosa e demorada. Os resultados são otimos, mas ha muito tempo sendo investido. Não sei se, na balança, realmente compensa…

Aí que eu queria chegar. Eu posso não usar mocks o tempo todo como eles são do lado do teste (mocks de biblioteca, como jMock), mas de alguma forma e em algum momento eu preciso simular meus recursos externos (como BD), e isso não é raro.

E uma classe que simula o real, no meu entendimento, não deixa de ser um mock também!

Ai é que está. Eu acho que deixa. O objeto mock é especificamente artilhado para o teste. Quando vc usa uma implementação diferente isso não é um mock. Por exemplo, usar um repositorio que guarda em memoria em vez de um que grava no banco não é usar um mock.
Vc usa o mock quando ele está vinculado ao teste. Por exemplo, ele contem atributos, que será alterado espeficicamente pelo/para o teste e depois vc vai lá , ler esse campo e ver se tem o valor certo.

então, enquanto o uso de implementações diferentes dos mesmos serviços é comum, o uso de mocks (objetos especiais destinados explicitamente ao ambiente de teste e nunca ao de produção) são raros.

Andre Brito
Concordo. IMHO, tópicos desse tipo é que fazem com que bons desenvolvedores ainda estejam aqui no GUJ. ++

Concordo plenamente estou acompanhando e colocando os blogs indicados no meu favoritos.

Paulo, vi que a última postagem no blog da Caelum foi sobre Integração Contínua, que cai bem no tema que temos aqui.

Como vocês fazem aí na Caelum para transformar idéias ou casos de uso em testes? Qual o pontapé inicial? Fazem uso de BDD?

Sobre a entrevista do Knuth, acho que às vezes os testes podem mascarar maus programadores…tipo, o cara programa se preocupando apenas em fazer o código passar no teste, e acha que a barra verde do JUnit é por si só sinônimo de código de qualidade…

Acho que existe um certo exagero de pessoas que vendem o uso de testes como algo incrível, como se isso fosse redimir os maus programares, e a questão da qualidade do código fica meio de lado…

renato3110:

Sobre a entrevista do Knuth, acho que às vezes os testes podem mascarar maus programadores…tipo, o cara programa se preocupando apenas em fazer o código passar no teste, e acha que a barra verde do JUnit é por si só sinônimo de código de qualidade…

Acho que existe um certo exagero de pessoas que vendem o uso de testes como algo incrível, como se isso fosse redimir os maus programares, e a questão da qualidade do código fica meio de lado…

Ao meu ver a qualidade do código melhora por que melhorar é a maneira que dá menos trabalho. Testes forçam a melhora.

Bruno Laturner:

É, caio no mesmo caso do Victor, o código que pego é quase sempre de manutenção. Apesar disso não acho que esse é o maior problema.

Por aqui a arquitetura é o famoso BOLOVO, orientado ao banco de dados. O problema é que não sei testar algo onde o endpoint é sempre o BD, onde as operações são sempre “… do/no banco”, verificar se tal dado existe no banco, trazer várias coisas do banco, associá-las, e mostrar na tela, inserir, alterar… Os dados sempre vem e vão para algum lugar.

Quem bom que vocês estão olhando para TDD porque este é um dos problemas que a técnica evita. Quando você precisa de um mock de DAO (ou equivalente) para testar sua classe Usuario você percebe que tem algo errado nas suas responsabilidades.

Para introduzir testes num sistema deste tipo (o que é diferente de introduzir testes ao time, como o Paulo falou) ter um ambiente que faça isso automaticamente é crucial. Geralmente ao testar código que não foi escrito com TDD começa-se por fora, com testes de alto nível (funcionais) para depois cair na integração e unidade.

No dia a dia de um profissional acostumado com testes o que você faz geralmente é criar os testes de alto nível primeiro. Eles vão falhar e para que passem você vai ter que identificar os colaboradores. Você não acha os testes, acha as classes (no caso de Java) então o processo é o mesmo.

cmoscoso:

Em se tratando do ambiente, eu concordo quando o sergiotaborda diz “TDD é um processo moroso e pouco ágil…” mas ao mesmo tempo é a estrategia mais eficaz que conheco pra desenvolvimento que envolva mais de 1 programador. Isso inclui code ownership, CI e tudo aquilo que TDD compreende alem de testes do desenvolvedor. Este ultimo principalmente acho util no modo solo mas TDD como todo nao oferece tantos beneficios evidentes.

Essa é uma afirmação curiosa, imho. Se eu uso Test-Driven Development eu crio um mínimo de confiança no código que estou escrevendo imediatamente, se eu não uso TDD eu ainda vou precisar ter este mínimo de confiança. Como vou obtê-lo? Será que no final eu não vou acabar tendo que testar manualmente o sistema toda vez que fizer qualquer alteração? Será que eu não vou acabar não testando boa parte das alterações?

Acho que está faltando um conceito importante aqui: você não cria mocks de código que não é seu. Não se cria mock de JMS, não se cria mock de JDBC nem de Hibernate. Você isola a dependência em classes que agem “na fronteira” e usa testes de integração nelas.

Não quis falar nada, mas pensei na mesma coisa. Comparado com outros tipos de testes, TDD parece ágil (ou menos lento, sei lá o termo).
Sem contar que, se testar do jeito que o shoes falou (do jeito em quotes), imagina a quantidade de erros que podem surgir e o tempo necessário pra corrigir cada erro…

Abraço.

Phillip,

Se nao tem outras pessoas pra compartilhar, comunicar e integrar codigo sobra TDD pelo fato de escrever o teste antes do codigo. Mas esse isolado é o aspecto menos importante do TDD na minha opiniao. O mais importante é encorajar as melhorias no codigo sendo desenvolvido. E a confianca necessaria pra esse “pitstop em movimento” vem da cobertura de testes, independente de ter sido obtida escrevendo teste antes ou depois do codigo testado.

Não quis falar nada, mas pensei na mesma coisa. Comparado com outros tipos de testes, TDD parece ágil (ou menos lento, sei lá o termo).
Sem contar que, se testar do jeito que o shoes falou (do jeito em quotes), imagina a quantidade de erros que podem surgir e o tempo necessário pra corrigir cada erro…

Abraço.

Achei que isso ja tivesse ficado claro mas TDD != de se ter testes unitarios.

Eu nao diria que TDD é agil mas continuo achando que ele compensa no medio/longo prazo e na maioria dos projetos profissionais.

Não entendi sua resposta. Tentando colocar meu comentário em outras palavras:

Seja com 1 ou 100 desenvolvedores você tem que testar o que está fazendo. Se você não fizer TDD vai ter que ter testes da mesma maneira, só que provavelmente de uma maneira menos eficiente. Supondo que você concorde com isso, qual a opção à ‘morosidade’ e ‘baixa agilidade’ de TDD?

Acho que ninguém que contestou sem comentário implicou que TDD é sbre testes unitários. A questão é: a parte ‘morosa’ que você tem com TDD vai ter que ser feito de qualquer modo, então será que é TDD que é ‘pouco ágil’?

Reendo, acho que entendi a primeira parte, apesar de não responder minha questão (por isso não apago minha mensagem anterior).

Isso não é verdade. TDD, seja praticado por um time de uma ou trezentas pessoas, afeta o design do código. Como você mesmo notou TDD não é sobre testes e-seja aplicado solo ou em equipe- é uma técnica de design.

Como eu falei se vc tem 1 desenvolvedor fazer TDD se resume a nao haver codigo sem um teste falho. Querendo ou nao isso é uma restricao e considerando que meu objetivo final é entregar software funcionando, nao consigo imaginar como isso poderia resultar em um processo mais eficiente. Deve ter algo que nao estou vendo.

pcalcado:

Reendo, acho que entendi a primeira parte, apesar de não responder minha questão (por isso não apago minha mensagem anterior).

Isso não é verdade. TDD, seja praticado por um time de uma ou trezentas pessoas, afeta o design do código. Como você mesmo notou TDD não é sobre testes e-seja aplicado solo ou em equipe- é uma técnica de design.

Por esse lado vc tem razao. TDD é uma forma de levar o programador a criar um bom design, principalmente com baixo acoplamento entre os objetos.

Entendo, mas nas pesquisas que eu fiz sobre TDD achei esse link da ImproveIT de testes de unidade com Mock Objects, e um dos exemplos do EasyMock ele faz um mock de um HttpServletRequest

private HttpServletRequest requestMock() { HttpServletRequest requestMock = createMock(HttpServletRequest.class); expect(requestMock.getParameter("login")).andReturn("patricia"); expect(requestMock.getParameter("senha")).andReturn("floresta"); expect(requestMock.getRequestDispatcher("bem-vindo.jsp")). andReturn(requestDispatcher()); replay(requestMock); return requestMock; }

Decididamente, HttpServletRequest não é um código meu. O exemplo está errado OU falta alguma coisa a esse conceito?

Obrigado.

Vou tentar argumentar com um exemplo. Suponha que você esteja implementando uma mudança numa classe que conecta com um servidor qualquer, antes ela conectava em http://123.com e agora vai conectar em http://321.com

1. O ciclo com testes é:

• Crie o teste
• Escreva o Código
• Teste Manual de Sistema

2. O ciclo com testes e sem TDD é:

• Escreva o código
• Crie o teste
• Teste Manual de Sistema

3. O ciclo sem testes é:

• Escreva o códio
• Teste Manual de Sistema

Então, a menos que você escolha a opção #3, onde não existem testes de unidade, você vai ter o ciclo “moroso” da mesma forma, seja acotnecendo antes ou depois e com qualquer número de pessoas no time.

Supondo que concordemos que #1 e #2 são as únicas opções de processo com qualidade minimamente aceitável (i.e. precisamos de testes unitários) então onde TDD seria menos ágil que a opção 2? Se a opção 3 for usada estamos discutindo o valor de testes unitários, e não de TDD.

O exemplo possui problemas.

chegando um pouco atrasado neste tópico, mas foi um tópico que muita gente estava esperando acontecer.

no meu caso consegui introduzir à minha vida sim não 100%, mas não no projeto no qual faço parte, sendo o maior motivo falta de maturidade da equipe neste aspecto e sendo um pouco menos produtivo em relação aos outros desenvolvedores visando este aspecto, apesar de que na época, na pressa ninguém enxergava isto como lucro e sim a coisa funcionando. hoje, a cada release a galera pina para não dar um erro inesperado em uma manutenção que foi efetuada em uma operação que estava funcionando.

na verdade ainda existe um pouco de dificuldade nisto, no meu caso por exemplo, sobre uma forma interessante para uso e implementação de arquitetura utilizando dbunit ou outro framework. O tratamento, configuração e gerenciamento para manter os dados íntegros e específicos para se manter o teste funcionando, conforme mudanças foi um dos casos por eu não ter utilizado no início do projeto. Alguém teria alguma motivação e/ou referência a respeito disto?

quando mencionei acima não, fiz menção à todas as camadas lógicas, bem como componentes e métodos de classes de modelo de domínio.

Bruno Laturner:

Indo direto ao ponto:

Como começo a fazer testes partindo do ponto zero; e,

Como tornar isso um hábito, um desenvolvimento orientado a testes de fato?

Como vocês começaram com TDD?

Também chegando atrasado, mas acho que vai ajudar… Como vcs viram nos links e explicações anteriores que não é tão fácil, mas eu te digo que com a experiência “mão-na-massa” a coisa melhora, e melhora muito !

Aqui na empresa que trabalho começamos fazendo Coding Dojo(http://www.codingdojo.org/), é um exercício muito bacana para TDD, sem contar os demais atributos de um bom programador que esse tipo de exercício explora.

Existem alguns pontos espalhados pelo Brasil, eu pessoalmente conheço o pessoal do Dojo SP(http://www.dojosp.org/) pessoal muito receptivo e gente boa.

Bom, depois de ler todos os ótimos links postados, sugiro realmente você a participar de exemplos práticos e com outras pessoas que podem servir de “coach” para você.

[]´s

Nao entendi o que quis dizer por teste manual, ate onde sei os testes sao automatizados; e se for outro nivel de teste (QA) nao é mais ciclo TDD.

Ainda, a opcao 2 e 3 nao fazem sentido, pq sem TDD de que ciclo vc se refere? A iteracao? Sprint?

Fique claro que uma coisa é usar TDD como tecnica de design, outra é vc ter uma boa cobertura de testes. Pra mim o mais importante é o segundo pq o primeiro nao resolve meu problema imediato.

Ao teste que você, como desenvolvedor, faz para saber se o que escreveu está funcionando.

O ciclo muda código/vê se funcionou/muda código/vê se funcionou…

cmoscoso:

Fique claro que uma coisa é usar TDD como tecnica de design, outra é vc ter uma boa cobertura de testes. Pra mim o mais importante é o segundo pq o primeiro nao resolve meu problema imediato.

Eu acho que isto está bem claro há algum tempo. O ponto que eu estou tentando provar é que qualquer estratégia de desenvolvimento com qualidade mínima vai cair na ‘morosidade’ e ‘baixa agilidade’ que você colocou sobre TDD porque estas não são causadas por TDD e sim pelo fato de que você tem que testar o que faz. TDD só deixa isso mais evidente.

Eu prefiro dizer que nao uso mocks em alguns tipos de teste. Por exemplo, como posso depender de objetos ‘fake’ para testar integracao?!?!

Se seu objeto depende do httpservlet request pra fazer o teste unitario e estranho pq geralmente foco os testes nos objetos que estao relacionados as regras de negocio, onde nao existe esse nivel de acoplamento.

Só uma adendo: depende da integração sendo testada naquele teste. Se você está testando a aderência do seu c’pdogio com, digamos, Servlets framework, você pode fazer mock da parte de persistência naquele teste, e vice-versa.

pcalcado:

cmoscoso:

Nao entendi o que quis dizer por teste manual, ate onde sei os testes sao automatizados; e se for outro nivel de teste (QA) nao é mais ciclo TDD.

Ao teste que você, como desenvolvedor, faz para saber se o que escreveu está funcionando.

O ciclo muda código/vê se funcionou/muda código/vê se funcionou…

cmoscoso:

Fique claro que uma coisa é usar TDD como tecnica de design, outra é vc ter uma boa cobertura de testes. Pra mim o mais importante é o segundo pq o primeiro nao resolve meu problema imediato.

Eu acho que isto está bem claro há algum tempo. O ponto que eu estou tentando provar é que qualquer estratégia de desenvolvimento com qualidade mínima vai cair na ‘morosidade’ e ‘baixa agilidade’ que você colocou sobre TDD porque estas não são causadas por TDD e sim pelo fato de que você tem que testar o que faz. TDD só deixa isso mais evidente.

Entao o programador profissional deve procurar boa cobertura de testes unitarios mais do que TDD. TDD é uma forma de alcancar esse objetivo pq considera os testes como parte do processo de projetar o sistema desde o inicio, mas isso implica em uma bagagem maior do que é necessario carregar, considerando que sozinho e vc nao escreve teste antes do codigo sempre, por exemplo: se vc vem de uma suite de testes compreensivel e tem uma adicao de funcionalidade que pode exigir um refactoring um pouco maior, deixar os testes (naquela parte especifica) de lado por um instante permite que vc experimente mais rapidamente outras solucoes. Neste momento eu nao estaria fazendo TDD, e talvez pq fosse menos agil pra ocasiao.

Vc pode dizer que poderia experimentar usando TDD mas acho o processo mais ‘moroso’. Talvez seja a tipagem estatica do java, ou talvez apenas necessidade de enxergar o sistma de outros pontos de vista e nao apenas a visao black-box dos objetos na estrategia TDD.

Exatamente o que eu tentei dizer.

Entendo, mas no final creio que é questão de prática com TDD. Uma pessoa com prática não vai nem cogitar iniciar um refactoring sem ter um teste falhando (supondo que o refactoring em questão afete testes, que nem sempre é o caso) porque vê nesta prática uma especificação do que ela deseja. Refatorar sem um objetivo certo é meio ineficiente, IMHO, e testes te dizem exatamente quando seu objetivo foi cumprido. Como disse, creio que é questão de prática.

cmoscoso:

Vc pode dizer que poderia experimentar usando TDD mas acho o processo mais ‘moroso’. Talvez seja a tipagem estatica do java, ou talvez apenas necessidade de enxergar o sistma de outros pontos de vista e nao apenas a visao black-box dos objetos na estrategia TDD.

Não necessariamente Java mas alguns frameworks de mock (EasyMock, JMock…) podem tornar sua vida bem mais chata. Acho que Ruby (por exemplo) se beneficia do fato de que quando surgiram os RSpecs e shoulda da vida nós já fazíamos TDD há um bom tempo.

cmoscoso:

Vc pode dizer que poderia experimentar usando TDD mas acho o processo mais ‘moroso’. Talvez seja a tipagem estatica do java, ou talvez apenas necessidade de enxergar o sistma de outros pontos de vista e nao apenas a visao black-box dos objetos na estrategia TDD.

TDD é desenvolvimento. Todo o desenvolvimento implica em pensar, experimental, refazer… é por isso que se chamada desenvolvimento.
TDD tem dois artefactos : codigo e testes. Vc tem que aplicar o ciclo de desenvolvimento : pensar, experimental, refazer em ambos os artefactos. É por isso que é moroso. A culpa não é do Java.

Se vc for um desenvolvedor chuck noris que já sabe como o sistema vai ser antes de Deus, então vc não precisa de TDD para ficar experimentando… lol

Agora, cobertura de testes é outra historia. Concordo contigo.
Ai não ha muito que pensar exceto como mocar certa parte do sistema… Isso não é, a bem dizer, trabalho de desenvolvimento, é trabalho da equipe de testes ou de QA.
Claro que na visão minimalista das filosofias ageis o desenvolvedor é um ser super-poderoso auto-gerenciável. capaz de analizar, desenvolveder, codificar, testar, conversar com o cliente , convencê-lo a fazer o seu trabalho e nas horas vagas ainda participa de projetos open sorce, escreve me blogs, dá palestas no google talks e beb muito café…
Na visão realista ninguem sabe fazer tudo. Alguns sãi melhores desenvolvedores, outros analistas outros a lidar com o cliente, outros a fazer frameworks… e claro, tem os que só são bons bebendo café… lol
Na real, cobertura 100% é uma maravilha se vc tiver todo o tempo do mundo. Pois existe sempre mais uma coisinha que vc pode testar/ não testou antes. Em projetos reais privados duvido que algum tenha cobertura 100%. Digo privados porque os open source tem - virtualmente - todo o tempo do mundo (aka, não têm prazo para terminar)

Lá vou eu com minhas perguntas idiotas

Quando se sabe que a cobertura foi 100%? - Isso parece “meio” impossível…

Desculpa se a pergunta é boba, mas é uma coisa que eu acredito ser praticamente inviável de fazer.

Depende. Pela métrica (não definitiva, mas isso é outro assunto) de test coverage basta você usar alguma ferramenta como Emma.

O grande ponto é que não faz sentido ter 100% de cobertura de testes e este nunca foi nem será o objetivo de TDD, metodologias ágeis ou o que quer que seja. Cobertura baixa te diz que o sistema está muito ruim mas cobertura alta não diz nada.

Existe muito ruído e pouco sinal por aí, cuidado.

Trocando uns e-mails com o GC (que está de férias e não baixa aqui tão cedo), ele me passou link pro blog dele pra ajudar, o mesmo que o Luca passou antes:

Test infection: por onde começar?

Basicamente fala do que discutimos no começo, sobre o que fazer com sistemas sem testes algum.

GC:

Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

Mais fácil falar que fazer, mas tudo sempre é.

Quanto a livros, se alguém perguntar no futuro, uma resposta do Luca sobre o assunto (tá no meu favoritos desde que fiz a pergunta).

Luca:

Ola

JUnit in Action de 2004 - excelente livro

Test Driven Development: By Example de 2002

Test Driven Development: A J2EE Example de 2005

Test-Driven Development: A Practical Guide de 2003

Pragmatic Unit Testing in Java with JUnit de 2003

TDD and Acceptance TDD for Java Developers de 2007

Java Testing and Design livro grátis disponivel em PDF desde 2004

Além destes livros, há muitos tutoriais que podem ser baixados livremente como este por exemplo: http://hotwork.sourceforge.net/hotwork/manual/junit/junit-user-guide.html

Outra fonte de aprendizado podem ser as centenas de projetos open source que usam testes unitários

E a documentação do JUnit não é “palpérrima” e muito menos paupérrima

Não é por falta de documentação que não se usa.

[]s
Luca

Finalmente, respondendo em parte a minha dúvida inicial,

como começar com testes?

cmoscoso:

Paulo Silveira:

Em resumo: se você tentar implantar testes unitários em algo que já tem meses de desenolvimento, além de não conseguir realizar a tarefa direito, vai ficar frustrado e culpar o TDD.

Nao concordo com essa afirmacao.

Em muitas ocasioes vale a pena criar testes unitarios para projetos em andamento. Se vc esta trabalhando num projeto existente porque nao introduzir testes unitarios durante o refactoring ou para novas funcionalides do sistema?

So pra deixar claro, eu nao afirmei que nao vale a pena. Quero dizer que é dificil e provavelmente vai culpar o TDD se nao conseguir testar.

Lá vou eu com minhas perguntas idiotas

Quando se sabe que a cobertura foi 100%? - Isso parece “meio” impossível…

Vc executa todo o codigo de testes e vê se todo o codigo do seu programa foi executado. e TODO é TODO inclusive codigo de tratamento de exceção e aquele que vc colocou só porque na possibilidade de aliens o raptarem amanhã o codigo tem que funcionar…

Existem ferramentas que fazem isso por vc (bendito seja o bytecode). Tem uma com um nome sujectivo: Cobertura.

Cobertura 100% é a única forma de garantir que o seu sistema está testado. Qualquer coisa abaixo disso e zero é a mesma coisa do ponto de vista de uma equipe de QA/Testing.
Do ponto de vista do desenvolvedor colocar testes unitátios em 50% das classes é suficiente para garantir que o sistema funciona. Mas apenas com 100% de cobertura vc realmente garante - com selo de garantia - que o sistema está testado.

O objetivo do TDD não é ter 100% cobertura. Aliás , o objetivo de TDD não é sequer fazer testes de unidade. Os testes de TDD são , digamos, mais conceptuais. Vc quer testar se a sua ideia para o problema X funciona. Repare que a coisa é ao contrario.
Vc sabe o input e o output e não sabe o como a classe faz transforma um no outro. O objetivo do TDD é encontrar esse miolo da classe. O objetivo não é que o teste rode todas as possibilidades em cima da mesma classe.

Em testes “de garantia” vc não sabe o miolo e não quer saber. Vc sabe os inputs e os outputs para várias situações (todas as situações) e vc quer testar exaustivamente a mesma unidade em todas essas situações. O objetivo é diferente. Aqui o objetivo é que todo os codigo da classe seja executado para ter a certeza que não ha erro em nenhuma linha. É este trabalho que é complexo.

Confundir TDD com teste “de garantia” é tiro no pé. TDD não lhe garante nada mais além do que vc pensou.
Testes de garantia provam que a classe funciona mesmo em situações em que o programador da classe não pensou.

O que é preciso entender é que garantia real só existe com cobertura 100%. Não podem ser ser usados processos estatisticos, não é aceitável vc dizer “o sistema tem 99.99% de codigo testado” Ou é tudo ou não é nada.

É por isto que promessa que se vincula na media é meio oca. A mensagem normalmente é "Vc está melhor com testes do que sem "
mas a realidade é que sem cobertura total os testezitos que vc fez garantem tanto como nenhum. Entenda que não é possivel tem 80% de confiança. Ou vc confia, ou vc não confia.

Veja por outro lado. Imagine que a sua empresa dá garantia para o osftware produzido de X anos.
qual é o maximo de anos que pode dar sem dar prejuizo À empresa.
Se o seu software é totalmente não testado o risco de problemas em X anos é tanto maior quando mais anos.
Se o seu software tem 100% de cobertura o risco é zero indepndnete de quantos anos são.

Assim empresas com 1 ano de garantia vs empresas com 10 anos são diferentes.
Em qual vc confiaria ? A primeira cobra barato mas dá 1 ano, a outra cobra caro, mas tem uma garantia maior que a vida util do software ( ou seja, vc sabe que nunca mais vai pagar nada ) Qual vc escolhe ?

Por isso que cobertura 100% é algo inerente a equipes de teste/QA. Equipes de QA não são formadas pelos desenvolvedores que criaram o software ( principio de imparcialidade).

O ponto é que se contam pelos dedos empresas que façam isso. E pior, com essa vaga de agilidade que anda por ai , ha muito desenvolvedor enganando-se com cobertura 10% , 50% , 90% …

Entendido isso , não ha um meio termo ?
Ha. Ha um compromisso. É dizer que 100% cobetura é impossivel e amarrar os anos de garantia à confiança/risco que vc tem. a formula é risco = 1 / cobertura

cobertura 0 (0%) = risco infinito. Os bugs parecem aleatorios e parecem nunca mais acabar
cobertura 1 (100%) = risco 0. Vc poe a ma mão no fogo se for preciso.
cobertura 0.5 (50%) = risco 1/0.5 = 2 (200%) … o que significa isto ? ninguem sabe… ( na realidade não significa nada, esse é o ponto, mas vc pode enganar-se e pensar que sim).

A priori, aprendi o que são os testes de cobertura.
Mas (opz), o que o Phillip falou não entra em um pouco de contradição com que o Sergio falou?

Bom, pelo que eu entendi, testes de cobertura é testar o software de fio a fio, linha por linha. Daí, surge uma vantagem e uma desvantagem: a vantagem é de que a segurança e a confiabilidade são imensas (como o Sergio falou, eu ponho minha mão no fogo pelo software). Só que tem a desvantagem, que (acredito eu) seja muito caro.

O que vocês fazem nos projetos?

Abraço.

Exatamente. Vc matou a charada. É muito caro.

Então o que os agilistas defendem é que se vc começar por fazer o sistema junto com os testes então quando vc acabar o sistema os testes já estão prontos. Melhor ainda, vc faz os testes antes e modela o seu código para se encaixar nos testes.

Mas quais testes são estes que os agilistas defendem ? Aqui é que está o buzilis da questão.
Estes testes não são os testes de cobertura/garantia. São os testes de aceitação.

Ou seja, se o teste passa vc aceita que o programa está pronto. Mas “pronto” é diferente de "garantia que não dá erro"
A ideia é que um requisitos de funcionalidades gera vários testes. Quanto os testes passaram o requisitos está implementado.
Mais que isso, eu aceito sem duvidar que está implementado.

Isto tem vários senãos. Vc começa a confiar demais no teste. Vc vê uma barra verde e fica feliz. Mas como o objetivo não é testar todos os cenários possiveis então vc testa apenas aqueles que estão nos requisitos. Ou seja, vc testa aquilo que o cliente pediu que quer no sistema e vc (quanto a mim ingenuamente) aceita que ele só vai usar isso do sistema , que ele lhe disse tudo o que havia a dizer ou seja, vc supoe que não existem mais casos de uso escondidos que foram esquecidos.
Pior, vc aceita que não precisa de uma equpe de QA e que o seu desenvolvimento é totalmente imparcial.

Fora isso vc não usa testes de aceitação para requisitos não funcionais a menos que eles tenham sido explicitados pelo cliente.

No fim vc fica com a certeza de que os requisitos estão bem implementados, mas como uma aplicação é mais que o conjunto dos requisitos isso significa que tem um monte de código que não foi testado. Vc tem o aceite do cliente, mas vc não tem garantia do funcionamento.

Ai vc soma testes de garantia aos de aceitação. E ai voltamos ao ponto em que ha muitos testes e a coisa fica cara.

Isso eu tb queria saber. O que as pessoas realmente fazem nos projetos? Porque é irrealista acreditar que façam testes de garantia com 100% de cobertura ainda por cima em equipes ageis em que não se faz nada além do que o cliente pediu.

Eu por mim uso testes para guiar o desenvolvimento e em uma ou outra classe critica coloco Junit. Normalmente quando dá problema em uma classe coloco um teste que simula esse problema e depois tento resolver. Isso é bom porque não preciso correr o codigo inteiro para resolver o problema ( ou saber se o problema resurgiu). Ou seja, vc mata o bug e garante que ele continua morto. Testes vão sendo adicionadas à medida que bugs vão sendo encontrados. Mais raramente o teste é criado junto com a classe. Isso normalmente para classes de serviço que pegam algo e retornam algo, tipo calculadora. E mesmo assim só quando é critico ( em sistema financeiros , contas é critico)

Quando o algoritmo é muito complexo ou a interação dos tipos é complexa começo por fazer o teste antes da classe e depois preencho o miolo (TDD)

Enfim, estratégias diferentes para problemas diferentes.

Testes (as in TDD) são justamente para você desenvolver somente o que foi pedido.

Testes (as in TDD) são justamente para você retomar o desenvolvimento a partir do ponto que o deixou, refatorar o sistema para comportar todas a novas alterações e ter certeza que o que fez antes não quebrou.

Testes (as in TDD) são justamente para você desenvolver menos de tudo e mais o que realmente importa. Nem um pingo a mais nem a menos.

Tudo vai depender da definicao de teste de aceitacao (TA). Por exemplo eu considero TA outro de nivel de teste (captura de requisitos+ QA-), mas definitivamente nao relacionado com teste unitario e seu “principio ativo” TDD. Sao testes criados pelo analista! E esse é o principal ponto de divergencia quanto a definicao de TA, que IMO deve ser focada na visao funcional do sistema apenas. Mas o assunto desse topico é testes unitarios e TDD. Podemos falar de BDD, RSpec mas nao disso tem a ver com TA que sao criados pelo papel do analista.

Segundo algumas correntes agilistas esses testes ditados pelo analista ( que é uma figura que não existe em ambiente agil onde todo o mundo é desenvolvedor faz-tudo) são colocados em codigo. Assim simplesmente correndo um suite de testes podemos saber quando do requisitos já foi completado. tudo isso de forma automática.
Coisas como o FIT/Fitness servem exatamente para testes de aceitação em codigo. Esse codigo pode ser corrido em qualquer momento pela equipe de dev, logo em nada é diferente de um teste de unidade.

Nao é o caso do XP que faz questao da parte cliente na equipe. Que corrente se refere?

Coisas como o FIT/Fitness servem exatamente para testes de aceitação em codigo. Esse codigo pode ser corrido em qualquer momento pela equipe de dev, logo em nada é diferente de um teste de unidade.

Na verdade ele é corrido na maquina de CI, nao por alguem especifico. Ou seja, o processo todo espera-se que seja automatico, nao entendi o que isso tem a ver com teste de unidade.

E analista nao dita teste. Ele os escreve textualmente. Depois vira codigo. FIT faz isso.

Andre Brito:

A priori, aprendi o que são os testes de cobertura.
Mas (opz), o que o Phillip falou não entra em um pouco de contradição com que o Sergio falou?

Bom, pelo que eu entendi, testes de cobertura é testar o software de fio a fio, linha por linha. Daí, surge uma vantagem e uma desvantagem: a vantagem é de que a segurança e a confiabilidade são imensas (como o Sergio falou, eu ponho minha mão no fogo pelo software). Só que tem a desvantagem, que (acredito eu) seja muito caro.

O que vocês fazem nos projetos?

Eu não sei o que são “testes de cobertura” e nem nunca vi ninguém utilizando este termo que me lembre. Pelo seu texto me parece que você não está falandod e Test-Driven Development e sim de um processo de QA normal -que é parte integrante de um processo de desenvolvimento ágil.

Como falei, cuidado com o ruído. Tem muito achismo por aí.

Antes que este tópico perca completamente o sentido:

• TDD não é sobre testes, é sobre design
• TDD cria por consequência uma malha de testes que protege o software sendo alterado
• Cobertura é importante mas não tanto. 100% de cobertura é besteira e isso não é parte de nenhuma metodologia que eu conheça
• Existe QA em metodologias ágeis e isso não tem nada a ver com TDD. Os testes gerados por TDD não substituem QA.
• QA tsta o sistema em condições extremas, testa condições inesperadas, etc.
• Testes de aceitação são criados pela Equipe. Eles podem ser criados pelo cliente e automatizados pelos desenvolvedores, ou pelo testador… tanto faz. O que importa é termos critérios de aceite automatizados.
• Teste de unidade é algo completamente diferente de teste de aceitação. Teste de aceitação verifica se o sistema atende ao requisto, teste de unidade verifica se a unidade (classe, módulo, etc.) atende ao que se espera dela. Testes de unidade são feitos em isolamento, testes de aceitação são feitos com o sistema todo integrado.
• Testes de aceitação geralmente utilizam a interface do usuário, seja ela qual for

Sim. Não entendi se o post é como introduzir testes unitários ou TDD. Introduzindo TDD leva-se de presente testes unitários, agora testes unitários são independentes de TDD.

Sobre o Programador de Schrödinger eu não concordo. Testes unitários (não estou falando de TDD) garantem muito pouco e uma mudança mais radical vai acabar forçando a feitura de novos testes unitários.

Um bom software deve ser modularizado (esse sendo um dos objetivos dos objetos) e uma mudança em um módulo deve afetar apenas aquele módulo, não o sistema todo, a não ser que o sistema todo dependa daquela módulo, o que deve ser raro, se não temos uma arquitetura spaghettiana.

Claro que é necessário sempre testar. Ninguém em sã consciência altera, compila e coloca no ar. Só que existe diversas maneiras de testar. Pra isso que existe um ambiente de testes, onde o sistema é colocado para rodar e diversos testes, automatizados ou não (manuais mesmo), podem ser executados. Muitas vezes basta reproduzir alguns testes sobre o módulo que foi alterado.

Esses dias descobri algo fenomenal para testar aplicações web: http://wtr.rubyforge.org/. Com ele vemos que podem existir testes automatizados bastante úteis que não são testes unitários.

Agora se me perguntam se testes unitários são válidos para tentar reduzir bugs eu digo que sim, assim como não andar descalço em casa com certeza reduz as suas chances de pegar um resfriado.

Agora se vc quer aprender um pouco de TDD, que é todo baseado em testes unitários, então pode começar por aqui:

http://today.java.net/pub/a/today/2004/01/22/DozenWays.html

Nao é o caso do XP que faz questao da parte cliente na equipe. Que corrente se refere?

O cliente dentro ou fora continua sendo o cliente. E continua sendo necessário destrinchar o que ele quer.
Se o cliente for muito esperto (como a maioria das correntes XP assume) ele pode até fazer listas de requisitos
mas mesmo assim alguem da equipe tem que validar e esmiuçar esses requisitos. Esse é o analista.
Agora, em XP não ha destinção entre analista,programador, desenvolvedor, tester, etc…
Logo, a presença do cliente não tem nada a haver para o caso em epigrafe. O ponto é que não existe 1 pessoa analista, existe analise feita por toda a equipe sobre a tutela/guia de um lider.

Na verdade ele é corrido na maquina de CI, nao por alguem especifico. Ou seja, o processo todo espera-se que seja automatico, nao entendi o que isso tem a ver com teste de unidade.

O ponto é que pode ser corrido quando se quiser. Automático significa exactamente isso.
Mas se o desenvolvedor quiser correr o teste fora do CI ele pode. Aliás como pode qualquer teste.

Um analista XP é um programador tb e por isso ele os codifica directamente.
O ponto conversa é que vc tem um certo tipo de testes que não visa a qualidade do codigo ou livar o codigo de bugs. Visa pura e simplesmente avaliar se as logicas de negocio foram implementadas corretamente para certos casos especificos ( user stories/ casos de uso). Este tipo de testes guia o cliente a pensar que programa está pronto , mas isso é completamente diferente do programa não ter bugs e complementamente diferente do codigo ter qualidade ou garantia de funcionanento.

Para o pessoal agilista 10% de cobertura são suficientes. 5% de testes de aceitação e 5% de testes unitátios nas classes mais criticas. E a desculpa é que 100% de cobertura é utópico. Humm… é mais ou menos como vc dizer que ser bom é importante e vc deve ser bom, mas ser perfeito é utópico. Então porquê sequer tentar ser bom em primeiro lugar ? Ser mau é muito mais fácil. Porquê tentar colocar testes nos programas se testar tudo é utópico. É muito mais facil não testar nada …

A conclusão a que chego é que, ninguem, na realidade , sabe usar testes, de maneira coerente, na prática. Sejam unitários, de integração, de aceitação , etc… cada um pega o que lhe importa no momento que lhe importa e pronto, já que o proprio conceito de testar tudo é falacioso. Então um dia testamos com testes unitátios, outro dia com testes de aceitação , outro dia com testes de QA e assim vai… conforme a aplicação, a disposição, a equipe e o cliente do momento. Isso parece-me extremamente fajuto e incorente com o que vemos em blogs e media em geral fazendo apologia de testes. A ideia é otima, a pologia é válida, mas se a prática é impossivel , cara, ou sem garantia, qual é o propósito afinal ?

Minha teoria, e essa é a minha opinião pessoal, é que as pessoas precisam de alguma “segurança” e para isso estão dispostos a qualquer coisa. Elas começam a programar e o seu código tem bugs. Até aí nada mais normal. Então eles pensam: Eu sou um pecador e preciso de testes unitários para expurgar meu código desses bugs maléficos. Mas qual é realmente o custo-benefício de testes unitários? Isso vai variar de projeto para projeto, de profissional para profissional e de linguagem para linguagem.

Encaro software como uma arte, onde a qualidade do código e a agilidade com que ele pode ser feito fazem toda a diferença no produto final e na satisfação do cliente. E testes unitários são extremamente restritivos, pois colocam uma trava na sua agilidade e vc passa a ser culpado antes mesmo de cometer o bug. Veja o que diz esse artigo sobre as três regras básicas de TDD:

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Daqui a pouco haverá uma regra assim:

4. Você não está autorizado a programar, pois o seu código conterá bugs. A máquina ditará para vc os procedimentos e vc apenas vai adequar o código caso necessário e é claro criando testes unitários antes.

Eu fico com a frase de Benjamim Franklin:

Cliente na terminologia XP é o papel que representa os interesses do cliente, como analista. Que eu saiba podem ser mais de 1. Eles pertencem a equipe assim como testers, desenvolvedores, designers, etc. Dizer que nao ha separacao entre os papeis no XP é atestar que nao sabe o que esta falando.

sergiotaborda:

Coisas como o FIT/Fitness servem exatamente para testes de aceitação em codigo. Esse codigo pode ser corrido em qualquer momento pela equipe de dev, logo em nada é diferente de um teste de unidade.

O ponto é que pode ser corrido quando se quiser. Automático significa exactamente isso.
Mas se o desenvolvedor quiser correr o teste fora do CI ele pode. Aliás como pode qualquer teste.

Entao vc conclui que todos os testes sao de unidade é isso???

Por isso devemos considerar usar diferentes tipos de teste. Ninguem esta dizendo que o teste X é bala de prata, certo?

Vc precisa se informar melhor pra nao escrever bobagens como essa.

Curiosa essa afirmacao. Pq testes de aceitacao sao criados a partir de casos de uso ou user stories, onde residuo de GUI é considerado poluicao.

Não sei sobre casos de uso mas você tem aguma referência sobre histórias?

Histórias estão ligadas intimamente à forma como o usuário vê o sistema, e ele o faz através da UI. Além disso, existem regras de negócio que só são implementadas na UI (tal campo deve estar vermelho se passar da data X, por exemplo).

cmoscoso:

sergiotaborda:

O cliente dentro ou fora continua sendo o cliente. E continua sendo necessário destrinchar o que ele quer.
Se o cliente for muito esperto (como a maioria das correntes XP assume) ele pode até fazer listas de requisitos
mas mesmo assim alguem da equipe tem que validar e esmiuçar esses requisitos. Esse é o analista.
Agora, em XP não ha destinção entre analista,programador, desenvolvedor, tester, etc…
Logo, a presença do cliente não tem nada a haver para o caso em epigrafe. O ponto é que não existe 1 pessoa analista, existe analise feita por toda a equipe sobre a tutela/guia de um lider.

Cliente na terminologia XP é o papel que representa os interesses do cliente, como analista. Que eu saiba podem ser mais de 1. Eles pertencem a equipe assim como testers, desenvolvedores, designers, etc. Dizer que nao ha separacao entre os papeis no XP é atestar que nao sabe o que esta falando.

Blz… eu não sei do que estou falando. Então assista esta palaestra do Google Tech Talks.

Diz a mesma coisa. Tlv eu não soube expressar tão eloquentemente quando a platestrante, mas vc pode entender claramente que :

1. não existem muitos clientes em XP, existe apenas 1. Cliente em XP é o cara que representa o cliente real, como vc disse. Mas é apenas um cara, não muitos.
2. Na equipe XP todos são desenvolvedores. Uns com mais skills em design outros em analise outros em testes, mas nunca são considerados várias partes. A equipe é só uma. Por isso os desenvolvedores XP são desenvolvedores faz-tudo.
   Não ha separação de papeis porque não ha papeis. Toda a aquipe tem as mesmas responsabilidades e todos seguem a mesma bitola de desenvolvimento (isto no XP). A unica coisa que muda é aptidão de cada um para as tarefas e portanto serão alocados em correspondência, mas isso deriva da experiência e não do desempenho de papeis “formais”. Exactamente por isso o pair programming funciona. porque não escalas formais de programador, tester , etc… todo o mundo usa todos os chapéus.

Não. Vc já perdeu o fio da meada…
O ponto é que ha vários tipos de testes. Mas apenas 1 tipo visa garantia de qualidade e pode realmente assegurar tranquilidade absoluta. Os outros tipos visão prover tranquilidade em areas especificas do desenvolvimento. A ideia dos agilistas é que equipes de QA não são necessários porque os desenvolvedores, eles próprios, irão escrever os testes. Eles escreverão os testes, mas não com a profunidade que QA necessita. Os testes, em XP por exemplo, visão permitir comitar o código. Um expecie de passaporte carimbado para o codigo poder viajar para o repositorio. Mas quem garante que aquele teste realmente testa alguma coisa e que está garantindo a qualidade. A resposta do XP para isso é : a própria garante porque todo o mundo vê todo o código.
Eu apenas acho isto ingênuo. Se o XP dissesses “a equipe garante que o codigo funciona” , tudo bem. Mas " a equipe garante que o codigo tem qualidade" são outros 500. O primeiro principio de processo de qualidade é impacialidade/independencia. A equipe não está em posição imparcial para fazer os testes de qualidade. Ah!, mas detalhes, testes de qualidade - convinientemente - não existem em XP… ( porque nunca existe uma equipe de QA independente)

O outro lado do ponto é que em filosiofias ageis testes são sempre programáticos. Ou seja, é codigo testado outro codigo. Não são pessoas fazendo milhares de simulações manualmente. Todo o teste, seja de unidade, integração, aceitação , etc… é sempre programado em código. Mais do que isso, esse código é encarado como documentação daquilo que o software tem que ser. Documentação ilegivel pelo cliente, mas documentação mesmo assim. ( dai a importancia de softare FIT-like que junta texto legivel por humanos com testes feitos pelo codigo)

Mais ou menos. Ninguem está dizendo que o teste X é bala de prata, mas estão dizendo que a prática de utilizar testes é bala de prata.
A mensagem é que devemos colocar testes automatizados nos nossos processos de desenvolvimento e não deixar isso para uma equipa de QA depois.
Mas quando se pergunta “quais testes” ? as respostas são tão diversificadas e que não ha consenso. Nisso o XP é mais organizado porque ele define bem que testes fazer ( mas que nunca visam QA directamente) básicamente de desenvolvimento (unitários, integração, etc … = CI ) e de aceitação ( também dentro do CI)
TDD é uma tecncia de design que utiliza um framework de testes para se guiar e acaba , em XP , sendo fundido com a propria filosofia do XP.

Fora de XP, as coisas são mais soltas. Outros sabores de agilidade têm as suas próprias ideias sobre testes.
Esta falta de consenso mostra que embora se considerem os testes como bala de prata ainda ninguém sabe bem qual é o alvo a abater e o resultado é que disparam para todos os lados.

Blz. Veja o video e depois conversamos.

Paulo Silveira:

Em resumo: se você tentar implantar testes unitários em algo que já tem meses de desenolvimento, além de não conseguir realizar a tarefa direito, vai ficar frustrado e culpar o TDD.
Sim, isso é uma confissao de 4 anos atras :)

FONTE:
:arrow: http://gc.blog.br/2007/05/09/test-driven-development-in-a-nutshell/

Só deixando um texto que mostra bem o problema que está acoplado à cobertura de testes:

http://www.infoq.com/news/2007/05/100_test_coverage

Além disso mostra bem como saber “Quanto teste é suficiente ?” é difícil, subjetivo, caro e em ultima análise enganador.
(o texto defende que até 100% de cobertura é enganador e que menos que 100% é pior ainda)

pcalcado:

cmoscoso:

Curiosa essa afirmacao. Pq testes de aceitacao sao criados a partir de casos de uso ou user stories, onde residuo de GUI é considerado poluicao.

Não sei sobre casos de uso mas você tem aguma referência sobre histórias?

Histórias estão ligadas intimamente à forma como o usuário vê o sistema, e ele o faz através da UI. Além disso, existem regras de negócio que só são implementadas na UI (tal campo deve estar vermelho se passar da data X, por exemplo).

Referencias nao tenho. Mas independente de ser casos de uso ou estorias, em se tratando de especificacao de rquisitos mais correto IMO seria: o que o usuario ou analista espera do sistema, do ponto de vista funcional.

Mas de fato isso diz muito pouco pq aspectos funcionais podem ser considerados a partir de diferentes pontos de vista, apenas questiono qual criterio utilizado pra definir quais merecem serem implementadas em testes de aceitacao. Pq nao acho que objetivo seja fazer teste de tudo, prefiro usar algo como bug/issue trackers como complemento. E o argumento é mesmo sobre o perigo da cobertura 100% mas com implicacoes diferentes no caso de testes de aceitacao:

• Um processo de CI deve estar prontamente disponivel para cada developer varias vezes por dia, demora no build impacta negetivamente o processo.
• criar testes com tal granularidade leva a criacao de mais testes superficiais do ponto de vista do valor de negocio e tendem a ser cada vez mais acoplados a UI.

No caso, se o alerta precisa ser testado EM VERMELHO, nao deveria haver tb um teste para garantir uma boa experiencia para usuarios daltonicos por exemplo?

A questão foi levantada, o cliente pediu por ela e aceitou a demora a mais que esse suporte à acessibilidade irá causar?

Bruno Laturner:

A questão foi levantada, o cliente pediu por ela e aceitou a demora a mais que esse suporte à acessibilidade irá causar?

O ponto é que, se todo requisito precisa de teste de aceitacao, entao ou se tem uma cobertura 100% (que nao é bom pelos motivos que eu apresentei), ou o sw nao atende as necessidade s do cliente.

E se nem todo requisito precisa de teste, eu questionei qual o criterio utilizado, diferentemente do pcalcado o meu é geralmente evitar a GUI.

Não li os posts dos amigos do guj, porém, posso responder a sua pergunta da seguinte maneira:
A minha monografia tem o título de: Desenvolvimento Orientado a Testes e Integração Contínua.
Disponibilizarei a todos, assim que for aprovado ( é hj a noite a apresentacao pra banca… rsrs)

cmoscoso:

apenas questiono qual criterio utilizado pra definir quais merecem serem implementadas em testes de aceitacao. Pq nao acho que objetivo seja fazer teste de tudo, prefiro usar algo como bug/issue trackers como complemento.

Teste de aceitação ou teste de aceitação automatizado?

Teste de aceitação por si deve-se ter em todas as histórias. É como o time sabe que a história foi implementada.

Automatizar tarefas sempre que possível é o ideal. Ninguém é obrigado a ter testes automatizados mas dado o desperdício brutal e sem sentido que é ter testes manuais quando poderiam ser automatizados (não é sempre o caso mas é a maioria) não existem muitos motivos para não o fazer.

Não entendi a relação que você tentou fazer. Ter 100% de cobertura não é objetivo porque é algo muito caro de se mantêr e não traz valor que justifique este preço. Testes de aceitação possuem a mesma granularidade de histórias, na verdade eles são escritos pelos clientes, então tendem a ser completamente focados em valor de negócio. Eles são acoplados à UI pura e simplesmente porque o usuário usa a UI e na maioria das vezes vai se referir aos seus termos (“tela”, “botão”, “campo”, etc. e não “classe”, “objeto”, “pré-condição”, “api”, etc.).

Não sou eu nem você quem diz isso, é o usuário. Se isso faz parte desta história, se é uma outra história ou se nunca será implementado a responsabilidade (e o problema) é dele. Se faz parte desta história vai haver um critério de aceite e logo um teste de aceitação para ele.

Como funciona um teste de aceitação automatizado para webapplications?

O teste manda um POST com os dados preenchidos, recebe uma resposta, comparamos o HTML dessa resposta com o esperado e verificamos os efeitos colaterais da operação, como, por exemplo, uma inserção no banco?

Se constar nos requisitos de acessibilidade sim, mas aí eu acho que foge do escopo do teste de aceitação.

Contradicao detectada!

pcalcado:

Não sou eu nem você quem diz isso, é o usuário. Se isso faz parte desta história, se é uma outra história ou se nunca será implementado a responsabilidade (e o problema) é dele. Se faz parte desta história vai haver um critério de aceite e logo um teste de aceitação para ele.

Como isso difere da estrategia de cobertura 100%?

Bruno Laturner:

Como funciona um teste de aceitação automatizado para webapplications?

O teste manda um POST com os dados preenchidos, recebe uma resposta, comparamos o HTML dessa resposta com o esperado e verificamos os efeitos colaterais da operação, como, por exemplo, uma inserção no banco?

é uma infraestrutura tal que uma vez feito o investimento toda a equipe ira girar em torno disso pra basear seus testes de aceitacao.

Bruno Laturner:

Como funciona um teste de aceitação automatizado para webapplications?
O teste manda um POST com os dados preenchidos, recebe uma resposta, comparamos o HTML dessa resposta com o esperado e verificamos os efeitos colaterais da operação, como, por exemplo, uma inserção no banco?

Não entendi a pergunta, você está se referindo ao ferramental? Se for dê uma olhada em Selenium e Webdriver. Uma funcionalidade sempre vai ter alguma consequência observável, na maioria das vezes esta pode ser observada diretamente na interface. Estas ferramentas são scriptadas para fazer a alteração e checar o novo estado.

cmoscoso:

pcalcado:

Teste de aceitação por si deve-se ter em todas as histórias. É como o time sabe que a história foi implementada.

Contradicao detectada!

Hmm acho que agora entendi o problema de comunicação. Não ha contradição.

Quando eu e a literatura que conheç dizemos"cobertura" estamos falando em testar todos os possíveis estados de um sistema. Este tipo de cobertura é que não temos 100%, porque é algo muito caro com benefícios que não valem a pena.

Parece que você está falando em 100% de cobertura dos requisitos por testes. Isso é algo bem diferente do conceito anterior e sim, em um processo ágil sadio 100% dos requisitos vão ser cobertos por testes, em sua grande maioria automatizados.

Note que 100% dos requisitos cobertos não quer dize 100% de cobertura, já que existem estados em um sistema que não estão cobertos nos requisitos.

cmoscoso:

pcalcado:

Não sou eu nem você quem diz isso, é o usuário. Se isso faz parte desta história, se é uma outra história ou se nunca será implementado a responsabilidade (e o problema) é dele. Se faz parte desta história vai haver um critério de aceite e logo um teste de aceitação para ele.

Como isso difere da estrategia de cobertura 100%?

Falando sobre cobertura de requisitos, se não for um requisito você não precisa testar em aceitação. Não faz parte do que o sistema precisa fazer então você ainda está cobrindo todos os requisitos com teste, já que isso não é um requisito.

Pessoal,

Sei que isso não é muito importante, mas quando ouço “teste de aceitação” meus ouvidos chegam a doer. O correto, segundo o bom português, não seria “teste de aceite”?

Parece ser a mesma coisa do uso de “história” e “estória”. Particularmente, acho “estória” ridículo. É simplesmente o uso de uma expressão mal traduzida do inglês (“story”). “Estória” não existe em português.

E aí? “Teste de aceite”, que soa muito melhor e parece português de verdade, ou “teste de aceitação”, uma tentativa frustrada de traduzir “acceptance test”?

Story e History são duas palavras diferentes que significam coisas diferentes e são totalmente mapeadas para estória e história.
Em portugal “estoria” não é usado e história significa ambos story e history. É bom de ver que isso leva a uma perda de informação.

Embora em desuso , estória é uma palavra portuguesa e não é uma tradução mal feita.
Por outro lado, o uso e desuso apenas depende da frequencia em que as pessoas querem usar a palavra.

Ah! e sim, “teste de aceitação” não é grande problema já que Aceitação significa

<blockquote>   s. f.,

acto de aceitar;

acolhimento;

consentimento;

aplauso;

aprovação;

deferência;

bom crédito.

</blockquote>

que é exactamente o que se quer.

Já aceite é um termo mais “legal” que significa

s. m.,
acto ou assinatura com que se aceita uma letra de câmbio;
o m. q. aceito.

“teste de aceito” parece meio estranho , mais que “teste de aceitação”

Então, na época do ensino médio lembro da minha professora de português dizendo que “estória” era uma tentativa de trazer o “story” para o português, e que isso estava sendo combatido pelos defensores do bom e velho português (pelo menos no brasil). Segundo o dicionário http://www.priberam.pt (de português europeu, inclusive), “estória” não existe.

Quanto a “teste de aceitação” e “teste de aceite”, já vi uso dos dois, mas o primeiro certamente é mais usado. Pessoalmente (apenas gosto pessoal mesmo, não sei qual dos dois está correto), prefiro “teste de aceite”.

Isso aí.

neófito:

Então, na época do ensino médio lembro da minha professora de português dizendo que “estória” era uma tentativa de trazer o “story” para o português, e que isso estava sendo combatido pelos defensores do bom e velho português (pelo menos no brasil). Segundo o dicionário http://www.priberam.pt (de português europeu, inclusive), “estória” não existe.

Como eu já tinha dito, estória não existe em português de portugal (aka europeu). É obvio portanto que vc não vai encontrar lá.
Repare que a diferenciação é importante. Quando vc fala em inglês vc precisa diferenciar entre os dois. Se vc não sabe a diferença - independentemente de existir na sua lingua - vc não consegue comunicar direito.

em ingles History é relativo a sequencia de eventos no tempo , enquanto que story é um conto, uma narrativa dos eventos (reais ou ficticios). Uma User Story é uma narrativa neste sentido e não uma seqüencia de eventos no tempo. Historias do Usuário perde o sentido original e passa a signiicar “sequencia de eventos no tempo”. Isso é ruim. Melhor então Narrativa do Usuário se vc quiser manter a essencia do significado original da expressão. E é isso que significa traduzir : manter o significado.

Espero que tenha entendido porque isso não é correto. Se depois de entender vc ainda quer continuar usando, ok, é uma escolha sua, mas não use sem entender a escolha que fez.

Eu sei a diferença entre “history” e “story”, em inglês.

Êta pessoazinha difícil você, hein?

neófito:

Eu sei a diferença entre “history” e “story”, em inglês.

Êta pessoazinha difícil você, hein?

Eu não sou dificil. Eu só torno as coisas dificieis porque isto é um forum publico. Não quero que algum incauto fique com a ideia que é correto usar “teste de aceite” ou achar que “estória” é coisas do século passado e que traduzir é apenas usar a palavra mais parecida.

Como vc afirma com tanta certeza assim que “teste de aceite” é errado e que “estória” existe realmente no português? Você é formado em letras também? Ou é apenas arrogância?

Eu não afirmei com certeza.
Eu não preciso ser formado em letras para expressar um argumento.
Eu só apresentei um argumento. O argumento não foi rejeitado, então suponho que seja válido (ser falso ou verdadeiro é outra historia, que [sarcasmo] apenas [/sarcasmo] um doutorado em Português poderia resolver).
Se o argumento é válido e como ele expressa uma visão diferente da sua, vc tem que pelo menos entender que a sua opção pode estar errada, à luz do argumento.

Se mesmo assim vc escolhe o seu argumento a despeito do meu argumento e do uso comum da expressão "teste de aceitação"
otimo. Está no seu direito. A única coisa ruim é se vc aceita o seu argumento sem entender o meu, ou entender pq “teste de aceitação” é mais comum. O meu argumento explica porque “teste de aceitação” é mais comum ( porque é a forma correta, segundo o argumento) o seu simplesmente afirma (sem provas ou suporte) que “teste de aceitação” está errado.

básicamente vc parte da ideia de todo o mundo é burro e que usa a expressão errada. Eu parto do principio que tem que se analisar o significado de “aceite” e “aceitação” e decidir baseado nisso e não na permissa que todo o mundo é burro.

Eu so espero que as pessoas que lerem isto no futuro leiam o argumento e o contraponham ao seu ( e claro, tenho esperança que raciocinei e cheguem à conclusão que o seu argumento é falso)

Se quiser mesmo tirar a prova os 9 procure por um doutorado em letras. A primeira coisa que ele lhe dirá - sobre tudo se for brasileiro - é que " o uso faz a regra". Logo, mesmo que “teste de aceitação” esteja errado, pelo uso , ele passa a estar certo.
Mas sinta-se livre de fustigar quantos doutorados quiser até ter um resposta difinitiva. :lol:

É por essas e por outras que eu não tento traduzir termos tecnicos…

Pois bem.

Também postei uma argumentação, que você simplesmente não teve a sensibilidade de entender. A de que se tentam trazer “story” como “estória” para o português, também podem trazer “acceptance” como aceitação, e não como “aceite”, que é a forma mais utilizada em outras áreas. Como o desenvolvedor está habituado ao inglês, é muito mais fácil traduzir “acceptance” como “aceitação” do que “aceite” que, como já disse, é a forma correta em outras áreas.

Para comprovar o fato de que “aceite” é mais usado em outras áreas, basta fazer uma rápida busca no google por “cliente deu o aceite” e “cliente deu a aceitação”. Você vai ver que “aceite” é muito mais usado.

“Aceitação”, em geral, é muito mais usado em termos de “o sistema teve uma boa aceitação entre os usuários?”, enquanto que “aceite” é utilizado em “o cliente deu o aceite?”, “o sistema atingiu os critérios de aceite?”. Parece uma argumentação socrática, onde tentamos primeiro definir os termos, mas essa é a realidade. Mas é claro que isso é perfeitamente normal, já que somos desenvolvedores e não mestres em letras, e é totalmente compreensível um erro de tradução, já que nosso propósito é desenvolver software e não fazer traduções.

Quanto à “estória”, que nada tem a ver com o tópico - me desculpem - dê uma olhadinha em:

Podemos deixar o Grammar Nazi interior de cada um de lado e voltar ao tópico?

90 respostas depois e não vi ninguém falando como começaram com testes ou como sobrevivem até hoje com isso, nem uma mísera história de terror/development hell.

Vou começar achar que filosofia.match(/[DFMT]DD/) é marketing.

Bruno Laturner:

Podemos deixar o Grammar Nazi interior de cada um de lado e voltar ao tópico?

90 respostas depois e não vi ninguém falando como começaram com testes ou como sobrevivem até hoje com isso, nem uma mísera história de terror/development hell.

Vou começar achar que filosofia.match(/[DFMT]DD/) é marketing.

filosofia.match(/[BDFMT]DD/)

:lol: