Sim, sim, sim, um milhão de vezes sim.

Agile é uma filosofia, TDD é uma metodologia específica.

Se eu quisesse ser realmente exigente, eu poderia simplesmente apontar que há algumas variações de xDD - que seus defensores explicarão em profundidade não TDD - mas esses ainda estão substancialmente ligados ao primeiro teste, então isso seria trapaça.

Então, vamos dizer isso - você pode ser ágil sem fazer o "primeiro teste" (veja como funciona o scrum - em nenhum lugar existem detalhes sobre como você escreve o código). Olhe para um quadro kanban, veja todos os tipos de metodologias ágeis.

Você quer testes de unidade? É claro que sim, por todos os tipos de razões - e você pode argumentar que não pode ser ágil sem testes de unidade (embora eu suspeite que você possa ser) - mas você não precisa escrevê-los primeiro para ser ágil.

E, finalmente, é igualmente verdade que você poderia fazer Test First sem ser argumentos ágeis e strongs para fazer o teste primeiro, independentemente de sua filosofia geral de desenvolvimento.

Parece que outros (com um representante mais sólido) têm uma opinião semelhante ...

link

@unclebobmartin: http://t.co/huxAP5cS Though it's not impossible to do Agile without TDD and OOD, it is difficult. Without TDD the iteration rate of...

(O link no tweet é a resposta completa no LinkedIn)

"Ser ágil" significa simplesmente aderir aos valores e princípios do manifesto ágil . Nada nesse documento menciona TDD, ou mesmo testes unitários para esse assunto.

Então, sim, você pode ser ágil sem fazer TDD ou teste de unidade.

Eu não recomendaria isso ...

Sim ,

Veja um dos valores ágeis:

Individuals and interactions over processes and tools

Isso deve respondê-lo já. TDD é uma certa metodologia, um processo. Na verdade, um processo que poderia ser usado em processos de desenvolvimento ágil, mas nada mais. Eu acho que talvez o TDD seja o estado da arte agora quando está sendo ágil. Mas eu acho que o conceito de ágil ainda será capaz de durar, mesmo que talvez o TDD tenha sido substituído por outras práticas.

Eu resumiria como:

• Hoje, o TDD é um padrão de fato para ser ágil

• Pode haver maneiras de ser ágil sem TDD

eu digo

Não [tipo de]

Se você voltar para a fonte original link , o TDD é fundamental para o processo; os testes substituem as especificações de requisitos e casos de uso de cascata, servem como documentação viva e exemplos funcionais, etc. Eles são indispensáveis.

No entanto, há tantos sabores diferentes de 'ágil' flutuando agora que é inteiramente possível que um deles evite o TDD

EDIT: @ interpretação de Murph da questão parece ser o preferido. Poxa até inventei, é uma boa resposta. No entanto , eu mantenho minha posição de que o Manifesto Ágil é um conjunto de princípios, não uma metodologia de desenvolvimento. Não vejo utilidade em dizer "ah, sim, sou ágil" sem realmente implementar as práticas que trazem os benefícios. Em particular:

Working software is the primary measure of progress.

e

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Para mim, estes dois princípios implicam se não exigir TDD - pelo menos eu não conheço outra maneira de alcançá-los sem isso!

EDIT 2: sim, tecnicamente você pode escrever os testes depois; mas eu ainda considero test-first / TDD como fundamental. Não porque você não pode "ser ágil" sem ele, mas porque você será mais ágil com ele. Test-first / test-driven é uma abordagem muito mais eficiente do que test-later / test-afterthought. As descrições de teste são os requisitos . Não os deixe até mais tarde; -)

EDIT 3: Eu finalmente descobri o que me incomoda muito com a resposta muito bem escrita de Murph. É essa noção de que alguém poderia "ser ágil" sem realmente fazer isso . E "fazer isso" (como mostrado acima) praticamente requer TDD.

Estritamente, você é ágil ao aderir ao manifesto ágil . Na prática, uma base de código não é ágil, a menos que tenha uma boa cobertura de teste. Você pode fazer TDD e escrever os testes antes / durante o desenvolvimento da funcionalidade ou escrever testes para a funcionalidade depois que ela for desenvolvida. Normalmente, é mais fácil e mais eficiente fazer o caminho do TDD.

Você pode ser ágil, mas provavelmente há espaço para melhorias.

Um dos princípios da agilidade é que você deve ser capaz de responder às mudanças. Isso significa que não se sabe com antecedência o que você deve construir. Se você estivesse seguindo um processo em cascata, saberia com x meses de antecedência exatamente o que precisava construir, e poderia projetar componentes de software individuais para que cada um participasse de um esquema maior, chegando ao produto final (pelo menos você pensaria que foi assim). Mas como o ágil determina que você não sabe qual é o produto final, você nunca sabe para que será usado e, mais importante, quando ele será alterado.

Portanto, você precisa de um conjunto de testes completo para garantir que os recursos já construídos continuem funcionando, pois a base de código é modificada.

Mas isso em si não é TDD. Se você escrever os testes depois de escrever o código, não é TDD. Mas o TDD ajuda com outro aspecto, evita a superprodução.

Em minha própria equipe ágil, tenho lutado com desenvolvedores que escrevem códigos que acreditam que se tornariam úteis mais tarde no projeto. Teria sido um desenvolvimento em cascata que provavelmente seria OK, porque eles estavam adicionando suporte para algo no plano do projeto para os próximos x meses.

Mas se você está seguindo os princípios ágeis você não deve escrever este código, porque você não tem idéia se isso será necessário. O recurso que foi planejado para a próxima semana pode de repente ser adiado indefinidamente.

Se você seguir corretamente o princípio do TDD, uma única linha de código não poderá existir antes de um teste ditar essa linha de código (pessoalmente, posso escrever algum código trivial sem testar), e se começar escrevendo o teste de aceitação, você só implementa exatamente o que é necessário para fornecer os recursos necessários.

Assim, o TDD ajuda a evitar a superprodução, permitindo que a equipe seja o mais eficiente possível, o que também é um princípio ágil essencial.

Working software is the primary measure of progress

Você pode ser ágil sem fazer TDD (desenvolvimento orientado a testes)?

Resposta curta: Sim.

Resposta mais longa: Existem muitas respostas realmente boas para esta pergunta e referências muito boas. Eu não vou tentar debater esses pontos.

Na minha experiência, Agile é sobre escolher o nível certo de Lean-ness para o projeto em questão. O que quero dizer com Lean-ness? E por que eu trago isso para essa resposta?

Lean não significa cortar todo o possível do seu método. Como um de nossos colegas observou, você não precisa incluir o TDD ou o Teste Unitário em seus comportamentos. No entanto, no contexto do projeto você se encontra, pode ou não ser benéfico.

Vamos pensar na cadeia de suprimentos de um grande varejista não identificado localizado em AK. Existe o consumidor. Eles entram na loja. A loja recebe vários produtos via caminhão. Os caminhões, presumivelmente, pegam esses produtos em um depósito. O armazém é preenchido por remessas de vários fabricantes. Os fabricantes, por sua vez, têm cadeias completas de suprimentos.

O que acontece quando o gerente geral de transporte da cadeia de suprimentos acima é informado de que receberá um bônus anual de US $ 1 milhão por ano para ter menos de 10 caminhões na frota? Ele imediatamente cortará a frota para 9 caminhões. Nesse cenário "terrível", isso aumentará a quantidade de mercadorias armazenadas no depósito (aumentando o custo nesse nó). E vai "passar fome" nas fachadas das lojas.

Assim, a cadeia de suprimentos em geral sofre se a otimização local é permitida sem considerar o todo.

Voltar para TDD e UT. TDD é um mecanismo de expressão de requisitos. O sistema deve executar essas restrições. Justo. O TDD pode substituir o comportamento dos requisitos do Desenvolvimento do Drive de Casos de Uso ou o comportamento dos requisitos do Desenvolvimento Orientado pelo Usuário. Tem o benefício "inclinado" de combinar as cargas de trabalho de Teste de Unidade e Requisitos. É um benefício se a carga de trabalho geral for reduzida. Não é, se a carga de trabalho da cadeia de suprimentos for aumentada (vamos corrigir a qualidade).

E então, você perguntou: Você pode ser ágil sem fazer TDD (desenvolvimento orientado a testes)?

Claro que você pode. Uma pergunta diferente e talvez melhor é: - Se eu aplicar o TDD a este projeto, isso resultará em uma entrega de software mais eficiente ou menos eficiente?

Para citar um autor favorito ... J.R.R. Tolkien

Lord of the Rings. Fellowship of the Rings. Pg 94 'And it is also said', answered Frodo, 'Go not to the elves for counsel, for they will both no and yes.'

Então, no final, ... depende. Você deve responder a pergunta. Qual caminho o conduzirá mais eficientemente ao (s) objetivo (s) desejado (s).

Para TDD ou não para TDD. Essa continua sendo a questão. : -)

PS - Estou repostando esta resposta em outro site também. link

Comparando com a engenharia de um castelo.

Castelo Ágil

Se você fosse projetar um castelo usando o Agile. Você escreve porções que têm funções específicas e encoraja o usuário a usar as partes funcionais, ajustando o design futuro às reações do usuário. Então, você constrói o calabouço e se comunica com o dungeon keeper, você testaria a fundação fornecida pela terra e pelo calabouço. Você construiria os parapeitos e perguntaria aos vigias noturnos se isso é bom. Você construiria as paredes e mandaria os soldados testarem o valor defensivo. Você construía a cozinha e mandava os cozinheiros dar uma olhada. E durante esse processo, todas as partes até hoje funcionariam além da estrutura atual. Então, quando você terminasse a masmorra, você poderia mover os prisioneiros para dentro. E assim por diante. Mas quando você finalmente terminou o castelo, você descobre que os prisioneiros escaparam. Agora você precisa voltar para o calabouço e descobrir que precisa de barras mais grossas, mas as portas não são profundas o suficiente para segurar as barras, e as dobradiças não suportam portas maiores.

Castelo TDD

Com o TDD, você aparece com os prisioneiros e vê se eles escapam. Então você escreve as celas até que elas não possam escapar. Então você refataria o código removendo de forma limpa as células desnecessárias, removendo barras que estão no local errado e testando novamente. Prisioneiros não escaparam. Você não precisa se comunicar com o carcereiro. E você poderia entregar o castelo inteiro assim que terminasse tudo. Nesse ponto, o carcereiro diz que a masmorra precisa de mais células, e agora você tem que desenterrar mais da fundação.

Ágil Castelo TDD

Se você combinar o Agile e o TDD. Você veria se os prisioneiros escapassem e perguntaria ao carcereiro o que é necessário. Ele diz que você precisa de mais células. Você iria pegar algumas pessoas aleatórias para fingir ser prisioneiras e ver se elas escapam. Se não, você mostra para o carcereiro, e ele está feliz com isso. Então você começa a construir os parapeitos.

Conclusão

Portanto, ambos resolvem problemas diferentes. O Agile ajuda a alterar os requisitos com base na descoberta das necessidades dos usuários, pois eles vêem o produto se desenvolver no ponto em que é mais fácil se adaptar. Envolve a liberação de adições estáveis desmembradas do design geral.

O TDD resolve o problema de antecipar falhas. Descobrindo e corrigindo falhas como ocorre em um ponto no processo em que é mais fácil consertar. Envolve testar unidades de código desacopladas estáveis e quebradas do design geral.

É fácil ver o TDD como uma extensão do Agile, porque ambos seguem o mesmo padrão, o progresso e a revisão orientados à unidade. A diferença é que as unidades no Agile funcionam externamente até o momento como um todo, enquanto as unidades no TDD funcionam como uma parte e podem não produzir um produto funcional para revisão externa. E ambos os processos governam diferentes necessidades (usabilidade vs. correção). Como ambos funcionam em um processo de desenvolvimento em unidades, ambos os processos de revisão podem ocorrer em pontos semelhantes, com o TDD sendo dividido de maneira mais fina.

Notas

• Ter apenas testes de unidade não significa que você use o TDD. TDD significa ter o teste antes da unidade produzida e usar o teste conforme você desenvolve para confirmar a unidade. O teste de unidade sem o TDD pode ser usado para garantir que você não invalide a funcionalidade criada anteriormente.
• Ter sprints e outras reuniões não o torna ágil. Os objetivos do manifesto tornam você ágil. Você pode dividir metas em cascata em sprints com unidades de trabalho, sem cumprir o compromisso de favorecer as pessoas sobre os processos.
• Por definição de TDD e Agile. Seus testes unitários governarão as unidades não entregues e, portanto, o TDD será executado mais rapidamente que o Agile. E se você empregar ambos, seus ciclos ágeis conterão um ou mais ciclos de TDD (se cada unidade for testada).
• Pelo que entendi: você falha no Agile ao não desenvolver uma unidade de entrega / significativa para o usuário. A unidade pode ser significativa, mesmo que acelere o produto. Mas como o Agile explica a refatoração para facilitar a manutenção? Eu não cobri o suficiente para responder isso.
• Você falha no TDD ao falhar no teste da unidade. Produzindo código que não produz o recurso corretamente.

O Agile obriga você a abordar e atenuar os riscos do cronograma e da qualidade em todas as iterações. ou seja, TDD não é necessário para ser considerado Ágil .

No entanto, o TDD é uma tremenda técnica para mitigar riscos de qualidade, especialmente para um projeto com um grande número de iterações ou pessoas. Em tal projeto, o TDD adicionará algum risco de cronograma nas iterações iniciais, porque você também deve escrever casos de teste. No entanto, o TDD produz grandes economias de custos em iterações posteriores, pois mitiga continuamente os riscos de qualidade. ou seja, recomenda-se TDD.