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

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?

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

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?

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.

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.

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

mochuara:

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?

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.

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

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

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

mochuara:

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

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

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.

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

carol_programadora:

Oie a todos.

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

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

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.

peerless:

mochuara:

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

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

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.

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.

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.

mochuara:

peerless:

mochuara:

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

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

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.

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.

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é?

Não seria vermelho-verde-refactor ?

Não seria vermelho-verde-refactor ?

;)

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

de alguns ruins, também!

Não seria vermelho-verde-refactor ?

;)

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

mesmo assim sua ordem ainda está errada…

Não seria vermelho-verde-refactor ?

;)

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

mesmo assim sua ordem ainda está errada…

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.

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

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

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.

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.

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.

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.

joseguilherme:

TDD para praticantes de XP não é opcional.

http://www.extremeprogramming.org/rules/testfirst.html

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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. "

Dito isto, na minha opinião, o ciclo verde-vermelho-corrige é obrigatório.Ter testes unitários de integração, etc… é obrigatório.

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.

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.

marcosalex:

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.

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).

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.