TDD - vocês acham que deve ser adotada em outras metodologias?

Assuntos Gerais Agile
#1

Oie a todos.

Galera queria saber a opinião de vocês:

TDD é uma das práticas mais importantes da XP.

RUP por exemplo não prevê algo semelhante, vocês acham que TDD pode e deveria ser adotado em qualquer metodologia de desenvolvimento?

Pergunto somente essa disciplina da XP, digamos em ambientes que não são adequados para implantar XP, mesmo assim, vale a pena acrescentar TDD na metodologia em que está em uso ou acham que ela funciona somente num ambiente XP onde o cliente está constantemente presente etc etc?

Que acham?

#2

[quote=carol_programadora]Oie a todos.

Galera queria saber a opinião de vocês:

TDD é uma das práticas mais importantes da XP.

RUP por exemplo não prevê algo semelhante, vocês acham que TDD pode e deveria ser adotado em qualquer metodologia de desenvolvimento?

Pergunto somente essa disciplina da XP, digamos em ambientes que não são adequados para implantar XP, mesmo assim, vale a pena acrescentar TDD na metodologia em que está em uso ou acham que ela funciona somente num ambiente XP onde o cliente está constantemente presente etc etc?

Que acham?[/quote]

Se você usa uma boa prática já é melhor do que não usar nenhuma!

#3

[quote=carol_programadora]Oie a todos.

Galera queria saber a opinião de vocês:

TDD é uma das práticas mais importantes da XP.

RUP por exemplo não prevê algo semelhante, vocês acham que TDD pode e deveria ser adotado em qualquer metodologia de desenvolvimento?

Pergunto somente essa disciplina da XP, digamos em ambientes que não são adequados para implantar XP, mesmo assim, vale a pena acrescentar TDD na metodologia em que está em uso ou acham que ela funciona somente num ambiente XP onde o cliente está constantemente presente etc etc?

Que acham?[/quote]

Voce precisa de um processo que seja iterativo ao extremo, baseado em comunicação e na mentalidade de que o código é o artefato principal para modelagem, e não diagramas UML e documentação excessiva que apesar de lindinhos vão acabar numa gaveta empoeirada porque, convenhamos, ninguém tem tempo a perder lendo especificações que ja se encontram desatualizadas antes mesmo do projeto começar. Ou seja, se quer os benefícios de uma metodologia ágil primeira coisa a fazer é não usar uma metodologia waterfall como RUP.

#4

Eu acho que TDD ja esta andando independentemente do XP.

Mas se sua equipe entende que TDD eh importante no desenvolvimento de software, por osmose as demais praticas ageis vao sendo agregadas a equipe. Uma coisa leva outra.

#5

TDD é só uma boa prática de engenharia e, portanto, pode (e deve) ser usada em qualquer projeto de software que preze qualidade.

abraços

#6

[quote=mochuara][quote=carol_programadora]Oie a todos.

Galera queria saber a opinião de vocês:

TDD é uma das práticas mais importantes da XP.

RUP por exemplo não prevê algo semelhante, vocês acham que TDD pode e deveria ser adotado em qualquer metodologia de desenvolvimento?

Pergunto somente essa disciplina da XP, digamos em ambientes que não são adequados para implantar XP, mesmo assim, vale a pena acrescentar TDD na metodologia em que está em uso ou acham que ela funciona somente num ambiente XP onde o cliente está constantemente presente etc etc?

Que acham?[/quote]

Voce precisa de um processo que seja iterativo ao extremo, baseado em comunicação e na mentalidade de que o código é o artefato principal para modelagem, e não diagramas UML e documentação excessiva que apesar de lindinhos vão acabar numa gaveta empoeirada porque, convenhamos, ninguém tem tempo a perder lendo especificações que ja se encontram desatualizadas antes mesmo do projeto começar. Ou seja, se quer os benefícios de uma metodologia ágil primeira coisa a fazer é não usar uma metodologia waterfall como RUP.[/quote]

Quem disse que o RUP é waterfall (além de quem não entendeu o RUP) ?

#7

[quote=Alexandre Gazola]TDD é só uma boa prática de engenharia e, portanto, pode (e deve) ser usada em qualquer projeto de software que preze qualidade.

abraços [/quote]

TDD não é prática de engenharia aqui, nem na China. TDD é sobre design.

#8

[quote=mochuara][quote=Alexandre Gazola]TDD é só uma boa prática de engenharia e, portanto, pode (e deve) ser usada em qualquer projeto de software que preze qualidade.

abraços [/quote]

TDD não é prática de engenharia aqui, nem na China. TDD é sobre design.[/quote]

mochuara: Colega, eu discordo de você. Engenharia é tão voltada a design como também tem fortes ligações com métodos de desenvolver software, XP por exemplo.

#9

TDD é uma prática dos bons profissionais, não tem nada a ver com metodologia usada, profissionais ruins existem seja onde for.

#10

[quote=carol_programadora]Oie a todos.

Galera queria saber a opinião de vocês:

TDD é uma das práticas mais importantes da XP.
[/quote]

Primeiro é preciso deixar bem claro que TDD não é uma das práticas do XP. A prática do XP é criar testes antes do codigo e sempre criar testes. Isto não é a mesma coisa que TDD. TDD é Test Driven Design, é uma metodologia de design e não de teste.

Se vc quer criar um codigo e vc já sabe como será a classe vc não precisa de TDD , o design já está pronto. Mas precisa do teste que garante que a classe funciona. Do outro lado se vc usou TDD para desenhar a classe os testes que usou para isso podem não garantir que funciona, vc ainda precisará de adicionar testes unitários.

TDD e Cobertura de Testes não são a mesma coisa. XP pede que o teste exista e esteja pronto antes das classes a testar. É o ciclo verde-vermelho-corrige. Vc altera apenas erros na implementação,não o modelo.
TDD usa testes, não necessáriamente com cobertura, para evoluir o design. É o ciclo verde-vermelho-desenha-altera.Vc altera o modelo e por conseqüência a implementação. São coisas diferentes.

Dito isto, na minha opinião, o ciclo verde-vermelho-corrige é obrigatório.Ter testes unitários de integração, etc… é obrigatorio.
Utilizar TDD é opcional. Usar TDD para design pode ser perigoso porque é um processo de tentativa-erro demorado. É interessante quando vc está explorando algo que nunca ninguém fez, mas se vc está fazendo sistemas comuns é provável que outras *DD o ajudem mais como DDD ou FDD. Ou mesmo a pura e simples OO junto com boas práticas.

Teste unitário é mandatorio em todas as metadologias. TDD é opcional em todas. Todos os Driven são opcionais porque são caminhos para guiar o processo, não são o processo em si.

Todas as metodologias, RUP inclusive, têm um passo de teste. Embora na RUP isso seja uma “fase” depois do desenvolvimento e na XP seja um desenvolvimento igual a criar o codigo o fato é que testes têm que existir. Como vc os coloca lá depende do estilo da metodologia, mas têm que estar lá. A diferença entre XP e RUP é que os testes são feitos antes e independentemente do codigo a testar. Isso é um nivel de garantia. Contudo na prática os proprios testes podem ter bugs e dar falso positivos e falsos negativos.
No fim, o codigo do teste é uma extenção do codigo da aplicação e ao mudar este vc precisa mudar o outro.

#11

[quote=peerless][quote=mochuara][quote=Alexandre Gazola]TDD é só uma boa prática de engenharia e, portanto, pode (e deve) ser usada em qualquer projeto de software que preze qualidade.

abraços [/quote]

TDD não é prática de engenharia aqui, nem na China. TDD é sobre design.[/quote]

mochuara: Colega, eu discordo de você. Engenharia é tão voltada a design como também tem fortes ligações com métodos de desenvolver software, XP por exemplo.[/quote]

Engenharia e TDD são formas diferentes de se chegar a um design, qual parte não entendeu?

Sugiro que procure um dicionário para estudar melhor a diferença entre os conceitos.

#12

Isso deixou de ser verdade no momento que agile entrou para o mainstream. Hoje em dia TDD tb é prática daqueles que querem parecer antenados com a ultima moda, mesmo que pra isso continue usando metodologias tradicionais como RUP.

#13

[quote=mochuara][quote=peerless][quote=mochuara][quote=Alexandre Gazola]TDD é só uma boa prática de engenharia e, portanto, pode (e deve) ser usada em qualquer projeto de software que preze qualidade.

abraços [/quote]

TDD não é prática de engenharia aqui, nem na China. TDD é sobre design.[/quote]

mochuara: Colega, eu discordo de você. Engenharia é tão voltada a design como também tem fortes ligações com métodos de desenvolver software, XP por exemplo.[/quote]

Engenharia e TDD são formas diferentes de se chegar a um design, qual parte não entendeu?

Sugiro que procure um dicionário para estudar melhor a diferença entre os conceitos.[/quote]

Calminha aí pequeno gafanhoto e desculpe se te sentiu ofendido. Não foi a intenção. :lol:

Engenharia é composta por diversas disciplinas, entre elas o Design. A forma que tu faz, pouco importa se vai usar TDD, UML, MDA, WTF…

E dai? que bom então, né?

#14

Não seria vermelho-verde-refactor ?

:wink:

#15

Não seria vermelho-verde-refactor ?

;)[/quote]

Não. É corrige mesmo. Refacto é muito genérico e não mostra a distinção entre corrigir e remodelar.

#16

de alguns ruins, também!

#17

Não seria vermelho-verde-refactor ?

;)[/quote]

Não. É corrige mesmo. Refacto é muito genérico e não mostra a distinção entre corrigir e remodelar.[/quote]

mesmo assim sua ordem ainda está errada…

#18

Não seria vermelho-verde-refactor ?

;)[/quote]

Não. É corrige mesmo. Refacto é muito genérico e não mostra a distinção entre corrigir e remodelar.[/quote]

mesmo assim sua ordem ainda está errada…[/quote]

veja com cuidado - ambas colocações estão corretas. Talvez vocês estejam apenas confundindo o ponto inicial, ou seja, ponto inicial tudo funfando para criar os testes que quebram e entao concertá-los, enquanto no outro caso você tem o teste quebrado, concerta e refatora para deixar tudo mais “bonitinho”. Em uma das abordagens é dado um alto valor ao refactoring, enquanto na outra não.

#19

Olá

Concordo com o dreamspeaker, TDD pode e deve ser usado independente de XP.

Tanto é verdade, que TDD é o modo como se desenvolvia programas quando comecei a programar efetivamente em 1969. Não era só eu que fazia assim. Todo mundo programava já escrevendo pequenos testes e imprimindo resultados intermediários que na prática é o mesmo que programar na base de testes.

Quando fiz a COPPE em 1971/1972, esta prática era tão arraigada, que muitos dos meus colegas desenvolviam sistemas completos sem entrada formal de dados e sem saída organizada. O sistema era na verdade um monte de testes embutidos. Só depois de tudo funcionando e testado, é que partiam para fazer os módulos de entrada de dados e apresentação dos resultados. Como tinha um monte de saídas intermediárias provisórias, as entradas e saídas eram logo testadas.

Isto é um fato, acreditem ou não.

[]s
Luca

#20

[quote=Luca]Olá

Concordo com o dreamspeaker, TDD pode e deve ser usado independente de XP.

Tanto é verdade, que TDD é o modo como se desenvolvia programas quando comecei a programar efetivamente em 1969. Não era só eu que fazia assim. Todo mundo programava já escrevendo pequenos testes e imprimindo resultados intermediários que na prática é o mesmo que programar na base de testes.

Quando fiz a COPPE em 1971/1972, esta prática era tão arraigada, que muitos dos meus colegas desenvolviam sistemas completos sem entrada formal de dados e sem saída organizada. O sistema era na verdade um monte de testes embutidos. Só depois de tudo funcionando e testado, é que partiam para fazer os módulos de entrada de dados e apresentação dos resultados. Como tinha um monte de saídas intermediárias provisórias, as entradas e saídas eram logo testadas.

Isto é um fato, acreditem ou não.

[]s
Luca[/quote]

TDD é opcional até mesmo entre praticantes do XP porque muitos preferem escrever teste depois, o que não é TDD mas não vejo problema nisso desde que o software no final funcione e tenha cobertura de testes. Dizer que alguem DEVE fazer TDD sem conhecer a realidade da pessoas envolvidas no projeto (sem falar na metodologia utilizada) é o tipo de conselho que esta matando o agile.

Lembrem-se, pessoas vem antes das ferramentas e práticas.