O programador profissional precisa de testes unitários?

This message was edited 1 time. Last update was at 03/03/2008 22:15:12

rodrigoy wrote:
Pode pegar QUALQUER cliente, de qualquer ramo, de qualquer projeto... pergunte para ele: Você quer ver um requisito implementado ou um requisito documentado? O que vc acha que ele vai responder?

"O que, você não tem capacidade para me entregar os dois?"

rodrigoy wrote:
Em TDD, para implementar um caso de uso você roda os testes umas 200 vezes. Você roda os testes umas 20 vezes por hora. É importante que os testes rodem rapidamente. O Feedback tem que ser rápido.

Mas peraí, o cara tem que ser esperto e rodar o tempo todo só os testes que rodam mais rapidamente né, ou seja, os unitários! Não vai rodar o teste que sobe o JBoss cheio de EJBs e mapeamentos JPA!

rodrigoy wrote:
Como você modela dados nas aplicações que você faz? Os dados também não são requisitos? Se o cliente diz "o pedido de venda tem que ter um campo de observação" isso é um comportamento ou é um requisito que faz parte da visão estática do sistema?

O cliente me fala "o pedido de venda tem que ter um campo de observação". Eu colocaria isso num requisito. Se eu vou guardar esse pedido em XML, num banco relacional, num banco OO, num papel de pão, não importa para o requisito em si.

rodrigoy wrote:
Difícil... está no código e nunca é deixado pra trás. Se o requisito muda a primeira coisa que alteramos é a classe de teste. Entra no ciclo TDD. O código tem tendência a mostrar problemas mais facilmente. Documentos fora do código tendem mais a serem esquecidos.

Não é incomum o pessoal não atualizar as classes de testes - por pressões de prazo, alteram direto o código de produção e boa. Já vi isso acontecer com meus proprios olhos - inclusive removeram os testes da build pois estava atrapalhando, não serviam para nada, pois alguns nem compilavam. Acho que esse problema de não replicar a alteração em todos os artefatos não é resolvido transformando requisito em teste.

rodrigoy wrote:
Sim... e alguma vez você viu isso funcionando? Já tentou avaliar o custo benefício dessa abordagem? Já conseguiu fazer isso sem gastar centenas de milhares de dólares em ferramentas caras?

Sim... já vi utilizarem isso. A quantidade gasta em ferramentas depende do tamanho da equipe. Muita gente não se importa de investir alto em ferramentas pagas que resolvam o seu problema.

cmoscoso wrote:
Testes de aceitacao nao guiam desenvolvimento, e quem os escreve nao sou eu programador, mas o cliente.

É fácil colocar teste de aceitação pra fora do TDD: são difíceis de se extrair, escrever, automatizar e manter. A questão é que os critérios de aceitação definidos com o cliente deveriam ser o guia principal para o desenvolvimento. É a maneira mais simples de verificar que um requisito foi implementado como esperado.

cmoscoso wrote:
Testes de aceitacao complementam sim testes unitarios, mas lembra daquela historia de ferramenta certa para um certo problema, pois é disso que estou falando...

O problema é diferente mesmo. O que eu não entendo é essa tentativa de limitar TDD apenas a testes de unidade, se você pode obter muitos dos seus benefícios se aplicá-lo para outros testes...

This message was edited 1 time. Last update was at 04/03/2008 08:13:27

microfilo wrote:Não é incomum o pessoal não atualizar as classes de testes

Pra isso que serve integracao continua.

microfilo wrote:por pressões de prazo

Pra isso que serve gerencia de projeto.

microfilo wrote:alteram direto o código de produção e boa.

Pra isso que serve gerencia de configuracao.

microfilo wrote:Já vi isso acontecer com meus proprios olhos

Pra isso que serve vodka.

microfilo wrote:inclusive removeram os testes da build pois estava atrapalhando

Pra isso que serve violencia.

microfilo wrote:não serviam para nada, pois alguns nem compilavam.

Pra isso que serve integracao continua, de novo.

microfilo wrote:Acho que esse problema de não replicar a alteração em todos os artefatos não é resolvido transformando requisito em teste.

Nao?

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

s4nchez wrote:
O que eu não entendo é essa tentativa de limitar TDD apenas a testes de unidade...

Eu escrevi minha opiniao sobre isso na pagina anterior:

cmoscoso wrote:
...mas pra acrescentar diria que TDD compreende: suite de testes unitarios, integracao continua e propriedade coletiva de codigo.

s4nchez wrote:
É fácil colocar teste de aceitação pra fora do TDD: são difíceis de se extrair, escrever, automatizar e manter. A questão é que os critérios de aceitação definidos com o cliente deveriam ser o guia principal para o desenvolvimento. É a maneira mais simples de verificar que um requisito foi implementado como esperado.

Nao é pq é facil mas pq faz mais sentido pra mim.

Acho que apenas estamos falando de "guiar desenvolvimento" em niveis diferentes. Eu nao tenho testes de aceitacao executando na maquina do desenvolvedor, mas sim no servidor de build. A integração continua é o ponto de intersecao entre TDD e os testes funcionais.

cmoscoso wrote:
...mas pra acrescentar diria que TDD compreende: suite de testes unitarios, integracao continua e propriedade coletiva de codigo.

TDD compreende: 1) Escreva um teste que falhe 2) Faça o teste passar 3) Refatore 4) Volte para passo 1.

Se você faz TDD somente com teste unitário isto não significa que você mudou a definição de TDD.

This message was edited 1 time. Last update was at 04/03/2008 08:28:16

xandroalmeida wrote:Mas para isso o sistema deve ser coberto 100% por testes unitários e para isso o sistema deve nascer com testes unitários. É muito difícil você implementar teste em um sistema já existente. Mesmo porque para que um sistema seja bem testável sua arquitetura deve permitir isso.

Concordo !!!
Outra coisa que não entendo nesse Fórum, é estão discutindo mesmo, é que técnica o programador deve utilizar, em minha visão isso foge extremamente do contexto que envolve mesmo todo um cenário a ser considerado.

Bom até parece que o programador é uma espécie de um acumulador de papéis para tudo que é solução.

This message was edited 1 time. Last update was at 04/03/2008 08:41:48

s4nchez wrote:

cmoscoso wrote:
...mas pra acrescentar diria que TDD compreende: suite de testes unitarios, integracao continua e propriedade coletiva de codigo.

Se você faz TDD somente com teste unitário isto não significa que você mudou a definição de TDD.

De acordo. No meu projeto solo por exemplo nao uso integracao continua e Collective Code Ownership.

Bem, fugindo um tanto do assunto, mas ainda falando nele:

E se os testes tivessem comentários, e destes comentários fosse gerada uma documentação?
Tipo:

Aliás, existe alguma ferramenta que faça isso?

Qual seria a vantagem, Rafael? O benefício de testes é que a descrição dos requisitos não pode estar desatualizada ou o build não passa.

Se você apenas mudar a documentação textual de lugar só vai usar o Eclipse ao invés do OpenOffice.

pcalcado wrote:Qual seria a vantagem, Rafael?

Seria um tanto mais prático para lugares que exigem ter um maldito .doc/.pdf/.html com os requisitos em papéis.

Tava só divagando aqui mesmo.

pcalcado wrote:O benefício de testes é que a descrição dos requisitos não pode estar desatualizada ou o build não passa.

Creio que não entendi aqui.
O que você se refere com 'descrição do requisito'? Um documento?

Rafael Nunes wrote:

pcalcado wrote:O benefício de testes é que a descrição dos requisitos não pode estar desatualizada ou o build não passa.

Creio que não entendi aqui.
O que você se refere com 'descrição do requisito'? Um documento?

pcalcado wrote:
[...]Mas atualmente eu estou referindo o StoryRunner:

Scenario "file is already in registro's format" do Given "A file in Registro's format" And "A parser for log files in DSL" When "Parser parses file" And "The resulting DSL lines are interpreted" Then "A timeline should be created with all entries in the file" end

microfilo wrote:
"O que, você não tem capacidade para me entregar os dois?"

Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.

microfilo wrote:
Mas peraí, o cara tem que ser esperto e rodar o tempo todo só os testes que rodam mais rapidamente né, ou seja, os unitários! Não vai rodar o teste que sobe o JBoss cheio de EJBs e mapeamentos JPA!

Lembra que falei aqui a minha frustração com ambiente EJB3 com relação a TDD? Dá para rodar no Microcontainer, mas é lento. Cada rodada de teste demora de 10-20 segundos. Ninguém para muito pra pensar nisso, mas é simplesmente ridículo que o EntityManager demore 10 segundos para subir com um mapeamento de umas 100 entidades.

microfilo wrote:
O cliente me fala "o pedido de venda tem que ter um campo de observação". Eu colocaria isso num requisito. Se eu vou guardar esse pedido em XML, num banco relacional, num banco OO, num papel de pão, não importa para o requisito em si.

Colocaria isso num requisito? Como assim? Num texto? Num dicionário de dados?

XP, DDD, MDA, DSLs, no fundo, tudo isso tenta fazer com que tenhamos menos "layers" nos nossos artefatos, aproximando o software do negócio. Se a tecnologia permite hoje que a visão lógica e a visão fisica seja a mesma, porque não juntar a necessidade à solução? Você não sonha um dia ter uma ubiquitous language implementada numa DSL ou PIM que resolva o negócio de maneira executável?

microfilo wrote:
Não é incomum o pessoal não atualizar as classes de testes....

Acho que o CV já respondeu isso da melhor maneira possível... dá margem a criar o VDD (Vodka-Driven Development). TDD não resolve tudo. XP não resolve tudo. Nem mesmo a computação resolve tudo. Não procure a bala de prata.

microfilo wrote:
Sim... já vi utilizarem isso. A quantidade gasta em ferramentas depende do tamanho da equipe. Muita gente não se importa de investir alto em ferramentas pagas que resolvam o seu problema.

Cara, na boa, deve ser meio caro desenvolver software na tua visão... como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.

microfilo wrote:
Não é incomum o pessoal não atualizar as classes de testes - por pressões de prazo, alteram direto o código de produção e boa. Já vi isso acontecer com meus proprios olhos - inclusive removeram os testes da build pois estava atrapalhando, não serviam para nada, pois alguns nem compilavam. Acho que esse problema de não replicar a alteração em todos os artefatos não é resolvido transformando requisito em teste.

Isso acontece em equipes que não tem compromisso com o software que estão produzindo. O infeliz que subiu código sem passar pela suíte de testes e os demais membros da equipe que não cobraram dele o fato. Contra cultura ruim e burrice não tem muito para ser feito, nem o JCDD tem alguma chance. Ou a equipe tem compromisso e atitude no sentido de produzir resultado de boa qualidade ou automação de testes só vai ser mais um passo inútil no processo.

Pela minha experiência, a equipe é encorajada a chamar a atenção daqueles que quebrarem o build. Isso é saudável e normalmente acaba aumentando o comprometimento do time. Por isso que posse coletiva de código é fundamental, pois o outro não fez besteira no código dele, mas cagou o seu.

microfilo wrote:

cv wrote:
Se um programador olhar pras assinaturas dos metodos e souber o que os testes estao tentando provar, ele tb entende os requisitos daquela unidade que esta sendo testada.

Certo, eu tenho a visão dos requisitos daquela unidade sendo testada, e da visão do todo? Dos requisitos como um todo?

Para isso existem os outros testes, que não são de unidade.

pcalcado wrote:
[...]Mas atualmente eu estou referindo o StoryRunner:

Scenario "file is already in registro's format" do Given "A file in Registro's format" And "A parser for log files in DSL" When "Parser parses file" And "The resulting DSL lines are interpreted" Then "A timeline should be created with all entries in the file" end

rodrigoy wrote:
Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.

Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham!
Acho que a questão é: se o cara te contratou, você tem que trabalhar nos termos dele, fazendo o máximo para entregar o software com qualidade. Não é por que o cara te obriga a usar Use Case e use case tem a tendência de ficar desatualizado que eu vou deixar ser descuidado e efetivamente deixar o use case ficar desatualizado! Não da para querer mudar a cultura do cliente. O cara quer ser atendido de uma determinada maneira, se der para mostrar para ele como funciona o agile e ele gostar, ok, ótimo, se ele quiser usar waterfall da vida, eu prefiro atender ele nos termos dele.

rodrigoy wrote:
Lembra que falei aqui a minha frustração com ambiente EJB3 com relação a TDD? Dá para rodar no Microcontainer, mas é lento. Cada rodada de teste demora de 10-20 segundos. Ninguém para muito pra pensar nisso, mas é simplesmente ridículo que o EntityManager demore 10 segundos para subir com um mapeamento de umas 100 entidades.

Não rola só rodar os testes unitários "leves" em quanto desenvolve e deixar os testes mais pesados para rodarem uma vez por madrugada?

rodrigoy wrote:
Colocaria isso num requisito? Como assim? Num texto? Num dicionário de dados? XP, DDD, MDA, DSLs, no fundo, tudo isso tenta fazer com que tenhamos menos "layers" nos nossos artefatos, aproximando o software do negócio. Se a tecnologia permite hoje que a visão lógica e a visão fisica seja a mesma, porque não juntar a necessidade à solução? Você não sonha um dia ter uma ubiquitous language implementada numa DSL ou PIM que resolva o negócio de maneira executável?

Dependendo do caso, colocaria num texto da documentação do requisito - não ficaria detalhando informações sobre a minha estrutura de tabelas num documento de requisitos.

rodrigoy wrote:
Acho que o CV já respondeu isso da melhor maneira possível... dá margem a criar o VDD (Vodka-Driven Development). TDD não resolve tudo. XP não resolve tudo. Nem mesmo a computação resolve tudo. Não procure a bala de prata.

Eu acho que uma equipe deisleixada o suficiente para deixar a documentação de requisitos desatualizada também poderia deixar os testes desatualizados. O problema não é ser um documento word em si, o problema é o desleixo mesmo. É lógico que der 300 mil tipos de documentação não ajuda.

rodrigoy wrote:
Cara, na boa, deve ser meio caro desenvolver software na tua visão... como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.

Eu não disse nada sobre matriz de rastreabilidade de requisitos CMMI-like. Disse sobre rastreabilidade entre "artefatos".

Notícias, artigos e o maior fórum brasileiro sobre Java