Nao é o caso do XP que faz questao da parte cliente na equipe. Que corrente se refere?
[quote]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.
[/quote]
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.
[quote=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?
[/quote]
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:
Nao é o caso do XP que faz questao da parte cliente na equipe. Que corrente se refere?
[/quote]
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.
[/quote]
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:
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.
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.
[quote=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.[/quote]
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.
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).
[quote=cmoscoso][quote=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.
[/quote]
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.
[/quote]
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 :
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.
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.
[quote=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 :)[/quote]
TDD facilita o refactoring: depois de cada reescrita de código ou qualquer tipo de alteração, especialmente em códigos que você não conhece bem porque foram feitos por outros membros da equipe, você pode rodar os testes da aplicação inteira afim de garantir que você não está quebrando nenhuma funcionalidade. Alguns sistemas são tão podres que dependendo do lugar que você mexe quebra tudo. Os testes te ajudam a não fazer isso.
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)
[quote=pcalcado][quote=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.
[/quote]
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).[/quote]
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?
[quote=Bruno Laturner]
A questão foi levantada, o cliente pediu por ela e aceitou a demora a mais que esse suporte à acessibilidade irá causar?[/quote]
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)
[quote=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.
[/quote]
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?
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.[/quote]