TDD para praticantes de XP não é opcional.
http://www.extremeprogramming.org/rules/testfirst.html
Eu faço TDD e digo que pode sim ser aplicado com qualquer metodologia.
[quote=joseguilherme]TDD para praticantes de XP não é opcional.
http://www.extremeprogramming.org/rules/testfirst.html
Eu faço TDD e digo que pode sim ser aplicado com qualquer metodologia.[/quote]
Acho que vc não leu o topico. TestFirst e TDD são coisas diferentes!
O objetivo do TestFirst é assegurar que os requisitos estão bem implementados.
O Objetivo do TDD é chegar num modelo que permita que os requisitos possam ser suportados.
[quote=joseguilherme]TDD para praticantes de XP não é opcional.
http://www.extremeprogramming.org/rules/testfirst.html[/quote]
O link que vc passou oferece otimas razões para usar TDD, mas não consegui achar o trecho que diz que é obrigatório por isso vou assumir que ele não é opcional PRA VC.
Sera que pair-programming tb é obrigatório pra vc?
http://www.extremeprogramming.org/rules/pair.html
Legal. Então porque não conta pra gente sua experiência com TDD numa metodologia waterfall? Como fez pra quebrar use-cases em estorias menores? Como fez pra lidar com ausencia do cliente on-site? E a falta de releases frequentes?
Esses, acredito, são alguns dos questionamentos que pode ajudar a sanar algumas da dúvidas do autor do topico.
Sérgio, TDD também pode se referir a Test Driven Development, e aí, fica alinhado com a prática do XP.
Daí a confusão.
[quote=ViniGodoy]Sérgio, TDD também pode se referir a Test Driven Development, e aí, fica alinhado com a prática do XP.
Daí a confusão.[/quote]
Pra mim sempre foi Test-Driven Development, mas só agora que tu comentou que me liguei que o Sérgio estava se referindo a -Design. Anyway, o TDD (development!) tem como fundamento primário, o design.
[quote=lasse koskela]In other words, write the test first, and only then write the code that makes it pass.
This rule is controversial to many of us who have been schooled to first produce a
thorough design, then implement the design, and finally test our software in
order to find all those bugs we?ve injected during implementation. TDD turns this
cycle around, as illustrated in figure 1.3.
Test first, then code, and design afterward. Does the thought of ?designing
afterward? feels awkward? That?s only natural. It?s not the same kind of design
we?re used to in the traditional design-code-test process. In fact, it?s such a different
beast that we?ve given it a different name, too. We call it refactoring to better
communicate that the last step is about transforming the current design toward a
better design. With this little renaming operation, our TDD cycle really looks like
that in figure 1.4: test-code-refactor.[/quote]
[quote=mochuara]Legal. Então porque não conta pra gente sua experiência com TDD numa metodologia waterfall? Como fez pra quebrar use-cases em estorias menores? Como fez pra lidar com ausencia do cliente on-site? E a falta de releases frequentes?
Esses, acredito, são alguns dos questionamentos que pode ajudar a sanar algumas da dúvidas do autor do topico.[/quote]
Bem, eu já fiz TDD em metodologia waterfall. Ao implementar um test-case você fatidicamente diagrama tudo e quebra em classes menores, e nelas você aplica os testes. Os use cases ainda fornecem uma documentação das entradas e saídas esperadas no sistema, seus agentes, etc… e tudo isso pode ser testado. É possível integrar módulos do sistema ao excel, e fazer formulários para testes para o usuário.
A ausência do cliente on-site é mesmo um problema. Mas não impede a prática. Você pode eleger alguém capaz para testar, como um colega desenvolvedor. Mesmo num ciclo waterfall, existem milestones de avaliação do produto, e as classes passam por revisões. Mas ter um cliente ausente não é parte do desenvolvimento de metodologia nenhuma, até onde eu sei. Mesmo o RUP, prega que o cliente deve estar próximo do desenvolvimento, e ele verificará o que foi feito cedo ou tarde. O contrário de “always available” não é necessariamente “never available”, haverá reuniões com ele, e momentos em que ele terá interesse em conhecer o sistema. Não é à toa que prototipação e projetos piloto são etapas comuns de metodologias waterfall.
As outras práticas tornam o TDD mais efetivo? Certamente. Mas a ausência delas não impede TDD, de forma alguma.
[quote=ViniGodoy]
Bem, eu já fiz TDD em metodologia waterfall. Ao implementar um test-case você fatidicamente diagrama tudo e quebra em classes menores, e nelas você aplica os testes. Os use cases ainda fornecem uma documentação das entradas e saídas esperadas no sistema, seus agentes, etc… e tudo isso pode ser testado. É possível integrar módulos do sistema ao excel, e fazer formulários para testes para o usuário.[/quote]
Ou seja vc implementou um micro-processo e resolveu adotar algumas praticas ageis dentro de um macro-processo que é waterfall. Acontece que pra funcionar dessa maneira voce tera que dispensar energia extra pra que práticas do processo maior não venham anular os benefícios que se obtem sendo agil. A pergunta que fica é: Existe um motivo pra não fazer a mudança de vez pra agil? Só porque TDD ta na moda não é começar a fazer TDD num processo quebrado que vai consertar alguma coisa, porque não vai acontecer nada, e pode ser até mais estressante.
[quote=ViniGodoy]
A ausência do cliente on-site é mesmo um problema. Mas não impede a prática. Você pode eleger alguém capaz para testar, como um colega desenvolvedor. Mesmo num ciclo waterfall, existem milestones de avaliação do produto, e as classes passam por revisões. Mas ter um cliente ausente não é parte do desenvolvimento de metodologia nenhuma, até onde eu sei. Mesmo o RUP, prega que o cliente deve estar próximo do desenvolvimento, e ele verificará o que foi feito cedo ou tarde. O contrário de “always available” não é necessariamente “never available”, haverá reuniões com ele, e momentos em que ele terá interesse em conhecer o sistema. Não é à toa que prototipação e projetos piloto são etapas comuns de metodologias waterfall.
As outras práticas tornam o TDD mais efetivo? Certamente. Mas a ausência delas não impede TDD, de forma alguma.[/quote]
Bom, então sua solução para o problema da ausência do cliente é fazer de conta que ele e o developer são o mesmo?
Eu vou fazer de conta que isso da certo.
Olá
Só para colocar na roda: So you write unit tests, but do you really TDD?
Segundo o autor (anônimo mas acho que é um norueguês ligado a .NET):
Particularmente acho excelente este modo de desenvolver e para mim deveria ser ensinado nas escolas. Mas não precisa ser exatamente assim em 100% das atividades para que o projeto seja considerado como usando TDD.
[]s
Luca
Não conheco nenhum praticamente de XP que trabalhe assim (e sim, conheco muitos) e jamais contrataria uma pessoa que trabalhe dessa maneira para uma “equipe minha”…[/quote]
…e nem uma que pense assim.
[]s
Não conheco nenhum praticamente de XP que trabalhe assim (e sim, conheco muitos) e jamais contrataria uma pessoa que trabalhe dessa maneira para uma “equipe minha”…
[]s[/quote]
Voce deve ser onipresente então. Como vc vai saber se determinado programador escreveu o teste antes ou depois. Voce fica no cangote do seus programadores o dia inteiro?
Primeiro de tudo, quando trabalhei com isso, mal se falava em TDD, ou em projetos ágeis. Muitas práticas “inovadoras e ágeis” já eram aplicadas há muito tempo, antes do ágil, com outros nomes. Aliás, a informática está começando a herdar a mania da administração, de reescrever as mesmas coisas com outros nomes, só para soar mais moderno (como no caso de “cloud computing”). Veja o exemplo do Luca, sobre as práticas de testes que eles adotavam.
Segundo, não houve adaptações do processo. No processo waterfall, também se divide o sistema em módulos e classes. Não existe um único grande bloco de software. E essas classes são tão testáveis como uma não-waterfall. Aliás, tem método e atributos do mesmo jeito. Como eu falei, no modelo waterfall, existem milestones, bem definidos, onde o cliente verifica e avalia o produto. E existem fases de piloto, onde o produto é efetivamente usado e comentado pelo usuário final.
Você as vezes se refere ao waterfall puro. Bem, acho que isso foi abandonado desde a época do mainframe, mais ou menos. Talvez, mesmo antes.
[quote=ViniGodoy]Bom, então sua solução para o problema da ausência do cliente é fazer de conta que ele e o developer são o mesmo?
Eu vou fazer de conta que isso da certo.[/quote]
Não foi isso que falei. Deixei claro que isso é um quebra-galho, pois a ausência do cliente constitui um problema. Mas o XP também fala em “proxy clients”, para esses casos, o que é um quebra-galho do mesmo jeito. Mas você desconsiderou o resto. As reuniões de avaliação, o piloto, práticas que eu já havia comentado. Você também desconsiderou que boa parte do TDD é feita tão somente pela equipe de software, como é o caso dos testes unitários, testes de regressão, testes de carga, etc…
É óbvio que a cobertura de testes de um colega desenvolvedor será muitíssimo menor que a do cliente. E é lógico também que seria melhor um cliente identificar um erro mais cedo, testanto ele mesmo o sistema.
[quote=ViniGodoy]Sérgio, TDD também pode se referir a Test Driven Development, e aí, fica alinhado com a prática do XP.
Daí a confusão.[/quote]
Não ha confusão nenhuma. Só existe um TDD. chamar de design ou development é questão de estilo e enfase. Afinal design e development é a mesma coisa nesse contexto. Por exemplo, siga este link http://www.agiledata.org/essays/tdd.html e veja o titulo. Leia o texto e veja que a referencia ao livro do kent (que se chama development) é feita do design.
Além disso se vc ler com atenção essa página da wiki verá que fala de um ciclo. no centro desse ciclo está o passo de alterar o codigo.
Quando vc usa XP o ponto é apenas ter o teste pronto. O teste não evolui junto com o código da funcionalidade. São duas fases Primeiro o teste ,Segundo o codigo (por isso se chama teste first). Só que o teste é verdadeiro, ou seja, ele já testa realmente a funcionalidade (especialmente se for um test funcional) e todos os vermelhos são culpa do codigo. Em TDD nem todos os vermelhos são culpa do código.
TDD usa testes de codigo. XP usa qualquer teste que garanta que a funcionalidade está implementada corretamente.
TDD usa testes de integração principalmente enquanto XP pode usar unitários, integração e de funcionalidade.
TDD não é usado para implementar um funcionaldiade, mas para descobrir como será o modelo da funcionalidade.
Primeiro.
Não conheço nenhum praticante de XP de verdade que acha realmente isso. Se você estiver com dúvida sobre o assunto recomendo a leitura do livro de XP do Kent Back.
Vou colocar 2 trechos do livro que fala sobre isso.
E também acho que é possível usar TDD em ambientes waterfall. Já fiz muito isso.
TDD é sobre design evolucionário, sobre como faço e evoluo o design do meu software usando a prática de test-first. Portanto, é sim uma prática de engenharia. Como o peerless colocou, “Engenharia é composta por diversas disciplinas, entre elas o Design” e ainda o artigo citado pelo Luca: "TDD is not about testing, it is about how you develop software. "
[quote]Dito isto, na minha opinião, o ciclo verde-vermelho-corrige é obrigatório.Ter testes unitários de integração, etc… é obrigatório.
[/quote]
O ciclo red-green-refactor, test-code-refactor ou ainda test-code-design estão todos relacionados ao TDD, que pode ser Test-driven development ou test-driven design (como fala o Lasse Koskela em seu ótimo livro “Test-Driven”). Se esse ciclo é obrigatório, então TDD é obrigatório. Eu, particularmente, não acho que TDD seja obrigatório, desde que os testes sejam feitos paralelamente ao código sendo desenvolvido.
O ciclo red-green-refactor, test-code-refactor ou ainda test-code-design estão todos relacionados ao TDD, que pode ser Test-driven development ou test-driven design (como fala o Lasse Koskela em seu ótimo livro “Test-Driven”). Se esse ciclo é obrigatório, então TDD é obrigatório. Eu, particularmente, não acho que TDD seja obrigatório, desde que os testes sejam feitos paralelamente ao código sendo desenvolvido.
[/quote]
Não é verdade.
Quando vc usa test first vc já tem o teste e vc vai alterando o sut (system under test: classe ou classes) até que fique verde.
Este “até” implica num ciclo de vermelhos e alterações até chegar no verde. Vc tem um ciclo, mas não tem evolução do design, logo tem um ciclo, mas não tem TDD.
[quote=marcosalex][quote=ViniGodoy]
Muitas práticas "inovadoras e ágeis" já eram aplicadas há muito tempo, antes do ágil, com outros nomes. Aliás, a informática está começando a herdar a mania da administração, de reescrever as mesmas coisas com outros nomes, só para soar mais moderno (como no caso de "cloud computing"). Veja o exemplo do Luca, sobre as práticas de testes que eles adotavam.
[/quote]
Concordo plenamente e uma vez quase apanhei quando disse isso. heheh
Mas não sei se ela utiliza TDD em outra metodologia se pode ser chamado de TDD ou se teria outro nome. Acho que cai na mesma do tópico sobre usar Scrum parcialmente e se pode chamar ou não de Scrum (houveram opiniões divergentes e não chegaram em consenso).[/quote]
Usemos a seguinte analogia :"Loiça Chinesa made in Espanha"
"Loiça Chinesa" significa : loiça feita na china => neste caso a frase não faz sentido e é uma antitese. Se é chinesa não é feita na espanha e vice-versa.
"Loiça Chinesa" significa um tipo especifico de loiça. É um termo próprio em si mesmo que designa uma categoria de loiça. Neste caso faz todo o sentido.
Scrum é um termo especifico que designa um conjunto de diretrizes seguidas simultaneamente. Não designa um conjunto de práticas normalmente usadas para seguir essas diretrizes. TDD é a mesma coisa. È um termo especifico que designa um conjunto de diretrizes seguidas simultaneamente. Os ciclos do scrum e do TDD , a filosofia que leva a esses ciclos isso é que é a metodologia em si. O resto são práticas associadas. As práticas foram refinadas para se ajustarem à metodologia, mas outras poderiam ser usadas se fossem igualmente ajustadas.
Práticas ad doc usadas à 40 anos atrás dificilmente são basedas na mesma filosofia.
Existe até uma diferenciação entre Teste e Experiencia. A experiencia é muito comum. É o tipo põe a rodar e vê o que acontece. Se acontece o que esperamos está ok. Teste é mais que isso. É saber de antemão quais experiencias garantem que está como queremos e executá-los. Com dada experiência errada sabemos exatamente o que temos que mudar.
Experiencia leva a um processo empirico de tentativa e erro.
Teste é um processo cientifico de falsear hipoteses.