Opinião de quem utiliza TDD

Assuntos Gerais Agile
#1

Boa tarde gente,

gostaria da opinião de pessoas que utilizam TDD no desenvolvimento de software, relatando o que acha desta metodologia. O que melhorou no processo de desenvolvimento. Como fica a questão dos prazos. E se vale mesmo a pena mesmo utilizar esta metodologia. Não é para pesquisa nem nada. É apenas curiosidade mesmo. Aqui na empresa utilizamos TDD e ATDD. O prazo de desenvolvimento é maior, mas o que perdemos em tempo ganhamos em qualidade. O que é mais importante para vocês, tempo ou qualidade?

#2

O que é importante pra gente costuma não ter voz, e sim para a gerência.

Se ela abraçar a idéia não haverá problema com o 20% de tempo a mais gasto (em média).

#3

Tem outra coisa, tempo de entrega é uma coisa, tempo de manutenção/correção é outra

Você pode até entregar um produto bem mais rápido sem qualidade, mas a manutenção disso com o passar do tempo fica inviável, já passei por várias situações onde era melhor fazer do zero do que manter um sistema mal feito e sem qualidade…

abs

#4

[quote=novato25]Boa tarde gente,

gostaria da opinião de pessoas que utilizam TDD no desenvolvimento de software, relatando o que acha desta metodologia. O que melhorou no processo de desenvolvimento. Como fica a questão dos prazos. E se vale mesmo a pena mesmo utilizar esta metodologia. Não é para pesquisa nem nada. É apenas curiosidade mesmo. Aqui na empresa utilizamos TDD e ATDD. O prazo de desenvolvimento é maior, mas o que perdemos em tempo ganhamos em qualidade. O que é mais importante para vocês, tempo ou qualidade? [/quote]

Se o tempo de desenvolvimento aumenta, tem algo errado. TDD deveria diminuir o tempo de desenvolvimento porque reduz muito o tempo de debug, o tempo de subir uma instancia do servidor, esperar, esperar, acessar a tela, esperar, preencher os dados, na tela, carregar, esperar, testar pra ver se funciona. Em não funcionando, debugar pra ver o problema, então corrigir e repetir o processo.

Se a qualidade aumenta voces estao no caminho certo, mas se o tempo gasto eh maior da pra melhorar.

Além de que, como já foi dito aí, o tempo de desenvolvimento não é o tempo que se leva entre implementar e mandar para os testes de aceitaçao, o tempo de desenvolvimento é o tempo que se leva entre implementar e por em produção. Então se voce faz em 10 minutos, depois de 2 horas volta, em mais 10 minutos voce arruma, mais duas horas volta com outro erro, voce nao levou 20 minutos pra desenvolver a funcionalidade, levou 4 horas e 20 minutos.

Então se com os testes voce liberar em 24 minutos (supostos 20% a mais), voce esta ganhando 3 horas, não perdendo 4 minutos.

#5

[quote=YvGa][quote=novato25]Boa tarde gente,

gostaria da opinião de pessoas que utilizam TDD no desenvolvimento de software, relatando o que acha desta metodologia. O que melhorou no processo de desenvolvimento. Como fica a questão dos prazos. E se vale mesmo a pena mesmo utilizar esta metodologia. Não é para pesquisa nem nada. É apenas curiosidade mesmo. Aqui na empresa utilizamos TDD e ATDD. O prazo de desenvolvimento é maior, mas o que perdemos em tempo ganhamos em qualidade. O que é mais importante para vocês, tempo ou qualidade? [/quote]

Se o tempo de desenvolvimento aumenta, tem algo errado. TDD deveria diminuir o tempo de desenvolvimento porque reduz muito o tempo de debug, o tempo de subir uma instancia do servidor, esperar, esperar, acessar a tela, esperar, preencher os dados, na tela, carregar, esperar, testar pra ver se funciona. Em não funcionando, debugar pra ver o problema, então corrigir e repetir o processo.

Se a qualidade aumenta voces estao no caminho certo, mas se o tempo gasto eh maior da pra melhorar.

Além de que, como já foi dito aí, o tempo de desenvolvimento não é o tempo que se leva entre implementar e mandar para os testes de aceitaçao, o tempo de desenvolvimento é o tempo que se leva entre implementar e por em produção. Então se voce faz em 10 minutos, depois de 2 horas volta, em mais 10 minutos voce arruma, mais duas horas volta com outro erro, voce nao levou 20 minutos pra desenvolver a funcionalidade, levou 4 horas e 20 minutos.

Então se com os testes voce liberar em 24 minutos (supostos 20% a mais), voce esta ganhando 3 horas, não perdendo 4 minutos.[/quote]

Exatamente… É ilusão achar que aplicar TDD leva mais tempo pra terminar o projeto! No máximo o msm tempo!

me diga como vc faz pra testar uma query? sobe a aplicação e testa, se os dados não estiverem corretos? Derruba, altera,sobe e testa novamente?

será que realmente leva mais tempo?

:wink:

abrass

#6

Uma curiosidade… como vocês implementam os testes de repositório e os testes de aceitação? tipo, você precisa testar uma consulta e para a montagem do contexto existem alguns relacionamentos. Resumindo a história você precisa inserir em 4, 5 ou mais tabelas para testar a funcionalidade e depois remover os dados destas tabelas (ou dar rollback)… Então, no fim das contas, para se implementar uma consulta, não é necessário um tempo extra considerável para montagem dos contextos? Sem falar que teste também é programação. Sendo assim você também pode falhar na implemetação deles. Recentemente um cliente pediu para implementar um sistema e não fez questão de testes. Como o prazo era curto resolvi arriscar e implementar sem testes. O sistema tinha de tudo (relatórios, consumo de web services, gravação e leitura de arquivos, geração de boleto, etc). Consegui entregar no prazo e acredito que o código ficou muito bom. Houveram bugs, é claro. Mas foram muito poucos e fáceis de resolver. E houveram algumas mudanças também durante o desenvolvimento, mas não foi um sacrifício fazê-las (no caso de se fazer testes, além de fazer a mudança no código, teria que mudar os testes e até refazê-los, conforme o caso). Bom, eu sei que se ganha tempo com debug, mas você gasta tempo implementando os testes e acho que o tempo que se leva implementando testes é maior. Porém, no fim das contas eu ainda acho que vale a pena sim fazer testes e claro, utilizar TDD, porque se produz um código com qualidade e mais fácil de fazer manutenção. (mas isso só é verdade se a equipe for experiente em TDD). E quando você utliza TDD por algum tempo é difícil fazer um projeto sem ele. Você vai sentir que algo está faltando. Pelo menos para mim foi assim. :slight_smile:

#7

vc pode usar DBUnit, ou desabilitar as FOREIGN KEY

msm assim ainda acho que testar antes, não leva muito tempo a mais como vc diz.

mas ainda bem que segui os conselhos de um colega e resolvi criar testes, só praticando msm pra perceber a melhora que ele nos traz, e com o tempo vc vai percebendo as vantagens…

mas pra quem está iniciando assim como eu… realmente ainda leva um pouco mais de tempo…

obs: vc não testa um repositório e sim o DAO :wink:

#8

Voce esta confundindo testes de integracao com testes unitarios. Voce nao precisa de um registro na tabela para testar uma regra. Voce nao precisa de uma tabela, sequer de um banco de dados. Voce precisa de classes simples, valores colocados em memoria, e executar a regra sobre eles.

Voce desenha o seu modelo de classes atraves dos testes e depois cuida do que esta alem das fronteiras dele. Se for o caso existem algumas ferramentas para testes de aceitacao e testes de integracao, mas elas não substituem e não se relacionam com testes unitarios.

#9

entendi… mas então como se faz teste de unidade de um DAO?

#10

Voce esta confundindo testes de integracao com testes unitarios. Voce nao precisa de um registro na tabela para testar uma regra. Voce nao precisa de uma tabela, sequer de um banco de dados. Voce precisa de classes simples, valores colocados em memoria, e executar a regra sobre eles.

Voce desenha o seu modelo de classes atraves dos testes e depois cuida do que esta alem das fronteiras dele. Se for o caso existem algumas ferramentas para testes de aceitacao e testes de integracao, mas elas não substituem e não se relacionam com testes unitarios.[/quote]

depende do que ele for testar… como vc testaria uma query sem dados no banco?

#11

Voce esta confundindo testes de integracao com testes unitarios. Voce nao precisa de um registro na tabela para testar uma regra. Voce nao precisa de uma tabela, sequer de um banco de dados. Voce precisa de classes simples, valores colocados em memoria, e executar a regra sobre eles.

Voce desenha o seu modelo de classes atraves dos testes e depois cuida do que esta alem das fronteiras dele. Se for o caso existem algumas ferramentas para testes de aceitacao e testes de integracao, mas elas não substituem e não se relacionam com testes unitarios.[/quote]

depende do que ele for testar… como vc testaria uma query sem dados no banco?[/quote]

Aí não é um teste unitário, é um teste de integração.

#12

bom, eu teste o resultado da consulta. No caso de não haver nada no banco eu verifico se a consulta retornou alguma coisa… no caso deveria retornar uma lista vazia ou um objeto nulo, dependendo da query. Algo diferente disso faria o teste falhar.

#13

certo… então não se faz teste unitário de DAO?

#14

Voce esta confundindo testes de integracao com testes unitarios. Voce nao precisa de um registro na tabela para testar uma regra. Voce nao precisa de uma tabela, sequer de um banco de dados. Voce precisa de classes simples, valores colocados em memoria, e executar a regra sobre eles.

Voce desenha o seu modelo de classes atraves dos testes e depois cuida do que esta alem das fronteiras dele. Se for o caso existem algumas ferramentas para testes de aceitacao e testes de integracao, mas elas não substituem e não se relacionam com testes unitarios.[/quote]

depende do que ele for testar… como vc testaria uma query sem dados no banco?[/quote]

Aí não é um teste unitário, é um teste de integração.[/quote]

Mas quem disse que é um teste unitário? estamos falando de TDD

msm sendo um teste de integração ele deve aplicar TDD ou estou errado?(como eu disse anteriormente, estou aprendendo tb!) xD

#15

O ponto é que quando você escreve um teste que usa o banco, ele se torna um teste de integração. Você está testando a integração entre seu código e a base. :smiley:

Mas lembre-se que o DAO não deve conter lógica de negócios…

#16

Entendi… mas a questão é que sendo de unidade ou de integração, testar o DAO é custoso. E quando se usa TDD, testar o DAO é necessário. Ou não?

#17

Voce esta confundindo testes de integracao com testes unitarios. Voce nao precisa de um registro na tabela para testar uma regra. Voce nao precisa de uma tabela, sequer de um banco de dados. Voce precisa de classes simples, valores colocados em memoria, e executar a regra sobre eles.

Voce desenha o seu modelo de classes atraves dos testes e depois cuida do que esta alem das fronteiras dele. Se for o caso existem algumas ferramentas para testes de aceitacao e testes de integracao, mas elas não substituem e não se relacionam com testes unitarios.[/quote]

depende do que ele for testar… como vc testaria uma query sem dados no banco?[/quote]

Aí não é um teste unitário, é um teste de integração.[/quote]

Mas quem disse que é um teste unitário? estamos falando de TDD

msm sendo um teste de integração ele deve aplicar TDD ou estou errado?(como eu disse anteriormente, estou aprendendo tb!) xD[/quote]

Ora, você citou o YvGA e ele estava explicando sobre testes de integração.

Quanto a testes de integração com banco no tdd, não sei se há uma regra. Particularmente eu escrevo poucos testes deste tipo, só para algumas consultas mais complexas. E normalmente rodo eles com menos frequência, pq tendem a ser mais lentos. Mas acho que se usar um banco como hsqldb pode melhorar o desempenho neste caso.

#18

[quote=Maracuja]Como ja foi dito, teste unitario quer dizer testar uma unidade, ou seja, uma unica classe. Qualquer teste que envolva mais de uma classe na poderia ser considerado como “teste unitario”. Como tambem ja foi dito, testes que envolvem bancos de dados, seria mesmo teste de integracao.

DbUnit

Para os demais testes unitarios geralmente usa-se algo como EasyMock, Mockito ou JMock por exemplo.

[]'s
[/quote]E também pode usar um banco de dados em memória: http://uaihebert.com/?p=58

#19

wagnerfrancisco

eu que me expressei mal msm! xD

#20

[quote=Maracuja]Como ja foi dito, teste unitario quer dizer testar uma unidade, ou seja, uma unica classe.
[/quote]

Gostava de saber como vc infere que “unidade” == “classe”.

O teste unitário é sobre uma unidade do sistema. Correto.
Mas a unidade não tem que ser a classe. Pode ser o pacote, pode ser o modulo, o component, etc… alguma coisa que seja autocontida, mas não necessária uma única classe.

Quando vc começa a depender de coisas externas à JVM então temos testes de integração. Assim como quando começa a depender de outros sistemas ou componentes.
Quando testa um fluxo, também é um teste de integração.

Teste de integração = Teste da “integração” das unidades previamente testadas sozinhas.

Se uma unidade fosse só uma classe, testar o builder do EsasyCriteria seria um teste de integração. Integração do quê ? Dele mesmo com ele próprio ? :lol: