se você ler todas as respostas, elas meio que concordam. você pode afirmar ser ágil sem fazer TDD, porque "ágil" é um manifesto difuso, não uma metodologia específica. Mas eu não vi nenhuma resposta abaixo que disse: "oh sim, teste anterior não é necessária" ;-)
Steven A. Lowe
Alguém poderia passar sem o TDD, mas por que se aleijar e andar 11 quilômetros na neve?
Job
3
@ Job - Isto é precisamente o que estou me referindo. Embora "ágil" não especifique explicitamente a realização de TDD, é geralmente aceito, no mundo real , que "ser ágil" inclui "fazer TDD" (ou pelo menos testes de unidade)?
CraigTP
2
Por que você se importa tanto com "ser ágil" ??? Você não tem nada mais importante com que se preocupar, como escrever software que encanta seus clientes?
Xpmatteo
1
@ShadowChaser Entendi o que você está dizendo, mas, por um momento, como advogado do diabo em relação ao Ponto Agile # 1, se eu estivesse em uma equipe que fez um desenvolvimento no estilo cascata, mas tivemos uma ótima comunicação e colaboração entre os membros desse equipe, isso nos tornaria ágeis?
CraigTP
Respostas:
50
Sim, sim, sim, um milhão de vezes sim.
Agile é uma filosofia, TDD é uma metodologia específica.
Se eu quisesse ser realmente exigente, poderia simplesmente apontar que existem algumas variações do xDD - que seus advogados explicarão em profundidade não são TDD - mas essas ainda estão substancialmente ligadas ao teste primeiro, o que seria trapaça.
Então vamos dizer o seguinte - você pode ser ágil sem fazer o desenvolvimento "test first" (veja como o scrum funciona - em nenhum lugar há detalhes sobre como você escreve código). Veja 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 seja) - mas você não precisa escrevê-los primeiro para ágil.
E, finalmente, é igualmente verdade que você poderia fazer o Teste Primeiro sem ser argumentos ágeis e fortes para fazer o teste primeiro, independentemente da sua filosofia geral de desenvolvimento.
Parece que outros (com um representante mais SOLID) têm uma opinião semelhante ...
Com +1, você é ágil da maneira geral como age, não porque usa essa ou aquela metodologia.
10
É necessário que os testes de unidade sejam ágeis. É só que você não precisa escrevê-los primeiro.
Macneil
6
@ Mcneil: Você não precisa escrever testes de unidade para "ser ágil". TDD e UT são ótimas práticas por si só, mas não são necessárias ou mesmo mencionadas no manifesto ágil.
Martin Wickman
4
@Marin: no desenvolvimento de métodos em tudo são mencionadas no manifesto
Steven A. Lowe
4
Acabei de começar a trabalhar em uma grande empresa usando o SCRUM para executar projetos. O projeto no qual estou trabalhando é SCRUM (corretamente!), Mas o código não possui testes de unidade. Não ter testes de unidade não afeta a capacidade de usar o SCRUM ou ser ágil, mas afeta minha capacidade de confiar na qualidade do código e de fazer alterações rapidamente (com confiança). Dada a falta de documentação produzida no Agile, acho que escrever testes primeiro, último ou no meio é um grande benefício para o Agile restante (para mudar).
Rob Gray
19
"Ser ágil" significa simplesmente aderir aos valores e princípios do manifesto ágil . Nada nesse documento menciona TDD, ou mesmo testes de unidade para esse assunto.
Então, sim, você pode ser ágil sem fazer testes de TDD ou de unidade.
@ Martin: bem dito - não há práticas de desenvolvimento especificadas no manifesto. É uma declaração de missão, não uma metodologia.
Steven A. Lowe
4
@ Martin: Há uma diferença entre um processo ágil e os princípios ágeis. Se você pode nomear um processo ágil que não possui testes, faça isso.
Macneil
@ Macneil: Scrum não tem testes.
Martin Wickman
2
@ Martin: novamente, Scrum é um método de gerenciamento de projetos , não uma metodologia de desenvolvimento de software. Scrum é normalmente usado com uma metodologia de desenvolvimento ágil como XP, mas não é um substituto para ele
Steven A. Lowe
@ Steven: Obrigado por esclarecer minha resposta de que o Scrum não contém práticas de desenvolvimento, como testes. Eu acho que o ponto é bem martelado em até agora :-)
Martin Wickman
11
Sim ,
Veja um dos valores ágeis:
Indivíduos e interações sobre processos e ferramentas
Isso já deve responder. 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 ao ser ágil. Mas acho que o conceito de ágil ainda poderá durar, mesmo que o TDD tenha sido substituído por outras práticas.
Se você voltar à fonte original, o http://en.wikipedia.org/wiki/Extreme_Programming TDD é fundamental para o processo; os testes substituem as especificações de requisitos e os casos de uso da cascata, servem como documentação viva e exemplos de funcionamento, etc. Eles são indispensáveis.
No entanto, existem tantos sabores diferentes de 'ágil' flutuando agora que é perfeitamente possível que um deles evite o TDD
EDIT: @ A interpretação de Murph da pergunta parece ser a preferida. Caramba, eu até votei, é uma boa resposta. No entanto , 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 "sim, sou ágil" sem realmente implementar as práticas que trazem os benefícios. Em particular:
O software de trabalho é a principal medida de progresso.
e
Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.
Para mim, esses dois princípios implicam se não exigem TDD - pelo menos não conheço outra maneira de alcançá-los sem ele!
EDIT 2: sim, tecnicamente você pode escrever os testes depois; mas ainda considero o teste primeiro / TDD fundamental. Não porque você não pode "ser ágil" sem ele, mas porque você será mais ágil com ele. Testar primeiro / orientado a testes é uma abordagem muito mais eficiente do que testar mais tarde / testar depois. As descrições de teste são os requisitos . Não os adie até mais tarde ;-)
EDIÇÃO 3: Eu finalmente descobri o que me incomoda tanto na resposta muito bem escrita de Murph. É essa noção de que alguém pode "ser ágil" sem realmente fazê-lo . E "fazê-lo" (como mostrado acima) requer praticamente TDD.
Em nenhuma parte da página é mencionado o TDD ou o Test First, exceto como um link para uma página relacionada.
Murph
2
Trabalhei como programador extremo em 2000-2001. Sim, escrevemos testes de unidade, mas quase sempre escrevemos o código primeiro e depois testamos o código posteriormente.
Michael Shaw
1
Escolha errada de palavras. Vamos reformular: o Agile não é apenas Extreme Programming; Scrum e Kanban também pode ser visto como metodologias ágeis e nenhum deles impor o uso de TDD como o XP faz
t3mujin
2
@ Murph: a primeira frase era tudo o que importava. @Ptolomeu: então você fez errado ;-) @ t3mujin você deve estar brincando!
Steven A. Lowe
4
+1: Estou atrasado para a festa, mas esta é a única resposta útil . Dizer que podemos fazer TDD sem testes é como dizer que podemos passar em um exame de motorista sem saber dirigir. Sim, é possível, mas dificilmente. Como Michael Feathers disse, "Código legado é código sem testes". E código que, por definição, é difícil de manter, também é extremamente difícil de trabalhar quando você usa um processo ágil e iterativo.
rsenna
2
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. Geralmente é mais fácil e mais eficaz fazê-lo da maneira TDD.
Você pode ser ágil, mas provavelmente há espaço para melhorias.
Um dos princípios do Agile é que você deve ser capaz de responder à mudança. Isso significa que você não sabe antecipadamente o que precisa construir. Se você estivesse seguindo um processo em cascata, saberia x meses com antecedência exatamente o que precisa construir e poderia projetar componentes de software individuais para que cada um participasse de um esquema maior, atingindo o produto final (pelo menos você pensaria que foi assim). Porém, como o ágil determina que você não sabe qual é o produto final, nunca sabe para que seu código será usado e, mais importante, quando será alterado.
Portanto, você precisa de um conjunto de testes completo para garantir que os recursos que você já construiu continuem funcionando conforme 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 será TDD. Mas o TDD ajuda com outro aspecto, evita a superprodução.
Na minha própria equipe ágil, tenho lutado com os desenvolvedores que escrevem códigos que eles acreditam que seriam úteis mais tarde no projeto. Se tivesse sido o desenvolvimento em cascata que provavelmente seria bom, porque eles estavam adicionando suporte para algo no plano do projeto para os próximos x meses.
Mas se você estiver seguindo os princípios ágeis, não deverá escrever esse código, porque não tem idéia se isso será necessário. O recurso planejado para a próxima semana pode subitamente ser adiado indefinidamente.
Se você seguir corretamente o princípio TDD, uma única linha de código não poderá existir antes que um teste dite essa linha de código (pessoalmente, eu posso escrever um código trivial sem testar) e, se você começar escrevendo o teste de aceitação, implementará apenas exatamente o que é necessário para fornecer os recursos necessários.
Portanto, o TDD ajuda a evitar a superprodução, permitindo que a equipe seja o mais eficaz possível, o que também é um princípio ágil.
O software de trabalho é a principal medida de progresso
Você pode ser ágil sem fazer TDD (desenvolvimento orientado a teste)?
Resposta curta: Sim.
Resposta mais longa: já existem muitas respostas realmente boas para esta pergunta e muito boas referências. Não tentarei debater esses pontos.
Na minha experiência, o 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 o incluo nesta resposta?
O Lean não significa cortar todo o possível do seu método. Como observou um de nossos colegas, você não precisa incluir TDD ou teste de unidade 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 sem nome localizado em AK. Existe o consumidor. Eles vão para a loja. A loja recebe vários produtos via caminhão. Os caminhões, presumivelmente, obtêm esses produtos de um armazém. O armazém é preenchido por remessas de vários fabricantes. Os fabricantes, por sua vez, possuem cadeias inteiras de suprimento.
O que acontece quando o gerente geral de remessa da cadeia de suprimentos acima é informado de que ele receberá um bônus anual de US $ 1 milhão por ano por ter menos de 10 caminhões na frota? Ele cortará imediatamente a frota para 9 caminhões. Nesse cenário "terrível", isso aumentará a quantidade de mercadorias armazenadas no armazém (aumentando o custo nesse nó). E vai "morrer de fome" nas fachadas das lojas.
Portanto, a cadeia de suprimentos geral sofre se a otimização local for 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 Use Case Drive Development ou o comportamento dos requisitos do User Story Driven Development. Ele 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 geral 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)?
Certamente você pode. Uma pergunta diferente, e talvez melhor, é: - Se eu aplicar o TDD a este projeto, isso resultará em uma entrega global mais eficiente de software ou menos eficiente?
Para citar um autor favorito ... JRR Tolkien
Senhor dos Anéis. Irmandade dos Anéis. Pág. 94 'E também é dito', respondeu Frodo: 'Não peça conselho aos elfos, pois ambos não e sim'.
Então, no final, ... depende. Você deve responder a pergunta. Qual caminho o levará com mais eficiência aos seus objetivos desejados.
Para TDD ou não para TDD. Essa permanece a questão. :-)
Se você fosse projetar um castelo usando o Agile. Você escreveria partes com funções específicas e incentivaria o usuário a usar as partes funcionais, ajustando o design futuro às reações do usuário. Então, você constrói a masmorra e se comunica com o guardião da masmorra, testando a base fornecida pela terra e pela masmorra. Você construía os parapeitos e perguntava aos vigias noturnos se é bom. Você construiria os muros e os soldados testariam o valor defensivo. Você construía a cozinha e os cozinheiros examinavam. E durante esse processo, todas as partes até o momento funcionariam além da estrutura atual. Então, quando você terminasse a masmorra, poderia mover os prisioneiros. E assim por diante. Mas quando você finalmente termina o castelo, descobre que os prisioneiros escaparam.
Castelo TDD
Com o TDD, você aparece com os prisioneiros e vê se eles escapam. Então você escreve as celas da prisão até que elas não possam escapar. Em seguida, refatoraria o código removendo células desnecessárias de maneira limpa e removendo barras que estão no local errado e testando novamente. Os prisioneiros não escaparam. Você não precisa se comunicar com o carcereiro. E você pode entregar o castelo inteiro assim que terminar tudo. Nesse ponto, o carcereiro diz que a masmorra precisa de mais células, e agora você precisa desenterrar mais da fundação.
Castelo TDD ágil
Se você combinar Agile e TDD. Você veria se os prisioneiros escapavam e perguntaria ao carcereiro o que era necessário. Ele diz que você precisa de mais células. Você pegaria algumas pessoas aleatórias para fingir ser prisioneiro e ver se elas escapavam. Se não, então você mostra ao carcereiro, e ele fica feliz com isso. Então você começa a construir os parapeitos.
Conclusão
Então, ambos resolvem problemas diferentes. O Agile ajuda na mudança de requisitos, com base na descoberta das necessidades dos usuários, à medida que eles veem o produto se desenvolver no ponto do processo em que é mais fácil se adaptar. Envolve liberar adições estáveis, separadas do design geral.
TDD resolve o problema de antecipar falha. Descobrir e corrigir falhas, como ocorre em um ponto do processo em que é mais fácil de corrigir. Isso envolve o teste de unidades de código dissociadas estáveis, separadas do design geral.
É fácil ver o TDD como uma extensão do Agile, porque ambos seguem o mesmo padrão, progresso e revisão orientados pela unidade. A diferença é que as unidades no Agile funcionam externamente até o momento como um todo, enquanto as unidades no TDD funcionam como parte e podem não produzir um produto funcional para revisão externa. E ambos os processos governam diferentes necessidades (usabilidade versus correção). Como ambos funcionam sobre um processo de desenvolvimento em unidades, os dois processos de revisão podem ocorrer em pontos semelhantes, com o TDD sendo dividido de maneira mais precisa.
Notas
Só ter testes de unidade não significa que você use TDD. TDD significa fazer o teste antes da unidade produzida e usá-lo à medida que você desenvolve para confirmar a unidade. O teste de unidade sem 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 as 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 de unidade controlarão unidades não entregues e, portanto, o TDD fará um ciclo mais rápido que o Agile. E se você empregar ambos, seus ciclos ágeis conterão um ou mais ciclos TDD (se todas as unidades forem testadas).
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 a isso.
Você falha no TDD ao falhar no teste de unidade. Produzindo código que não produz o recurso corretamente.
O Agile o força a lidar e reduzir os riscos de cronograma e qualidade a cada iteração. ou seja, o 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. Nesse projeto, o TDD adicionará algum risco de agendamento nas iterações iniciais, porque você também precisa escrever casos de teste. No entanto, o TDD gera enormes economias de custos em iterações posteriores, pois mitiga continuamente os riscos de qualidade. isto é, TDD é recomendado.
Respostas:
Sim, sim, sim, um milhão de vezes sim.
Agile é uma filosofia, TDD é uma metodologia específica.
Se eu quisesse ser realmente exigente, poderia simplesmente apontar que existem algumas variações do xDD - que seus advogados explicarão em profundidade não são TDD - mas essas ainda estão substancialmente ligadas ao teste primeiro, o que seria trapaça.
Então vamos dizer o seguinte - você pode ser ágil sem fazer o desenvolvimento "test first" (veja como o scrum funciona - em nenhum lugar há detalhes sobre como você escreve código). Veja 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 seja) - mas você não precisa escrevê-los primeiro para ágil.
E, finalmente, é igualmente verdade que você poderia fazer o Teste Primeiro sem ser argumentos ágeis e fortes para fazer o teste primeiro, independentemente da sua filosofia geral de desenvolvimento.
Parece que outros (com um representante mais SOLID) têm uma opinião semelhante ...
http://www.twitter.com/unclebobmartin/status/208621409663070208
(O link no tweet é para a resposta completa no LinkedIn)
fonte
"Ser ágil" significa simplesmente aderir aos valores e princípios do manifesto ágil . Nada nesse documento menciona TDD, ou mesmo testes de unidade para esse assunto.
Então, sim, você pode ser ágil sem fazer testes de TDD ou de unidade.
Eu não recomendaria embora ...
fonte
Sim ,
Veja um dos valores ágeis:
Isso já deve responder. 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 ao ser ágil. Mas acho que o conceito de ágil ainda poderá durar, mesmo que o TDD tenha sido substituído por outras práticas.
Eu resumiria como:
Hoje o TDD é um padrão padrão por ser ágil
Pode haver maneiras de ser ágil sem TDD
fonte
eu digo
Não [tipo de]
Se você voltar à fonte original, o http://en.wikipedia.org/wiki/Extreme_Programming TDD é fundamental para o processo; os testes substituem as especificações de requisitos e os casos de uso da cascata, servem como documentação viva e exemplos de funcionamento, etc. Eles são indispensáveis.
No entanto, existem tantos sabores diferentes de 'ágil' flutuando agora que é perfeitamente possível que um deles evite o TDD
EDIT: @ A interpretação de Murph da pergunta parece ser a preferida. Caramba, eu até votei, é uma boa resposta. No entanto , 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 "sim, sou ágil" sem realmente implementar as práticas que trazem os benefícios. Em particular:
e
Para mim, esses dois princípios implicam se não exigem TDD - pelo menos não conheço outra maneira de alcançá-los sem ele!
EDIT 2: sim, tecnicamente você pode escrever os testes depois; mas ainda considero o teste primeiro / TDD fundamental. Não porque você não pode "ser ágil" sem ele, mas porque você será mais ágil com ele. Testar primeiro / orientado a testes é uma abordagem muito mais eficiente do que testar mais tarde / testar depois. As descrições de teste são os requisitos . Não os adie até mais tarde ;-)
EDIÇÃO 3: Eu finalmente descobri o que me incomoda tanto na resposta muito bem escrita de Murph. É essa noção de que alguém pode "ser ágil" sem realmente fazê-lo . E "fazê-lo" (como mostrado acima) requer praticamente TDD.
fonte
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. Geralmente é mais fácil e mais eficaz fazê-lo da maneira TDD.
fonte
Você pode ser ágil, mas provavelmente há espaço para melhorias.
Um dos princípios do Agile é que você deve ser capaz de responder à mudança. Isso significa que você não sabe antecipadamente o que precisa construir. Se você estivesse seguindo um processo em cascata, saberia x meses com antecedência exatamente o que precisa construir e poderia projetar componentes de software individuais para que cada um participasse de um esquema maior, atingindo o produto final (pelo menos você pensaria que foi assim). Porém, como o ágil determina que você não sabe qual é o produto final, nunca sabe para que seu código será usado e, mais importante, quando será alterado.
Portanto, você precisa de um conjunto de testes completo para garantir que os recursos que você já construiu continuem funcionando conforme 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 será TDD. Mas o TDD ajuda com outro aspecto, evita a superprodução.
Na minha própria equipe ágil, tenho lutado com os desenvolvedores que escrevem códigos que eles acreditam que seriam úteis mais tarde no projeto. Se tivesse sido o desenvolvimento em cascata que provavelmente seria bom, porque eles estavam adicionando suporte para algo no plano do projeto para os próximos x meses.
Mas se você estiver seguindo os princípios ágeis, não deverá escrever esse código, porque não tem idéia se isso será necessário. O recurso planejado para a próxima semana pode subitamente ser adiado indefinidamente.
Se você seguir corretamente o princípio TDD, uma única linha de código não poderá existir antes que um teste dite essa linha de código (pessoalmente, eu posso escrever um código trivial sem testar) e, se você começar escrevendo o teste de aceitação, implementará apenas exatamente o que é necessário para fornecer os recursos necessários.
Portanto, o TDD ajuda a evitar a superprodução, permitindo que a equipe seja o mais eficaz possível, o que também é um princípio ágil.
fonte
Você pode ser ágil sem fazer TDD (desenvolvimento orientado a teste)?
Resposta curta: Sim.
Resposta mais longa: já existem muitas respostas realmente boas para esta pergunta e muito boas referências. Não tentarei debater esses pontos.
Na minha experiência, o 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 o incluo nesta resposta?
O Lean não significa cortar todo o possível do seu método. Como observou um de nossos colegas, você não precisa incluir TDD ou teste de unidade 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 sem nome localizado em AK. Existe o consumidor. Eles vão para a loja. A loja recebe vários produtos via caminhão. Os caminhões, presumivelmente, obtêm esses produtos de um armazém. O armazém é preenchido por remessas de vários fabricantes. Os fabricantes, por sua vez, possuem cadeias inteiras de suprimento.
O que acontece quando o gerente geral de remessa da cadeia de suprimentos acima é informado de que ele receberá um bônus anual de US $ 1 milhão por ano por ter menos de 10 caminhões na frota? Ele cortará imediatamente a frota para 9 caminhões. Nesse cenário "terrível", isso aumentará a quantidade de mercadorias armazenadas no armazém (aumentando o custo nesse nó). E vai "morrer de fome" nas fachadas das lojas.
Portanto, a cadeia de suprimentos geral sofre se a otimização local for 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 Use Case Drive Development ou o comportamento dos requisitos do User Story Driven Development. Ele 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 geral 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)?
Certamente você pode. Uma pergunta diferente, e talvez melhor, é: - Se eu aplicar o TDD a este projeto, isso resultará em uma entrega global mais eficiente de software ou menos eficiente?
Para citar um autor favorito ... JRR Tolkien
Então, no final, ... depende. Você deve responder a pergunta. Qual caminho o levará com mais eficiência aos seus objetivos desejados.
Para TDD ou não para TDD. Essa permanece a questão. :-)
PS - Também estou publicando esta resposta em outro site. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=pt
fonte
Comparando com a engenharia de um castelo.
Castelo ágil
Se você fosse projetar um castelo usando o Agile. Você escreveria partes com funções específicas e incentivaria o usuário a usar as partes funcionais, ajustando o design futuro às reações do usuário. Então, você constrói a masmorra e se comunica com o guardião da masmorra, testando a base fornecida pela terra e pela masmorra. Você construía os parapeitos e perguntava aos vigias noturnos se é bom. Você construiria os muros e os soldados testariam o valor defensivo. Você construía a cozinha e os cozinheiros examinavam. E durante esse processo, todas as partes até o momento funcionariam além da estrutura atual. Então, quando você terminasse a masmorra, poderia mover os prisioneiros. E assim por diante. Mas quando você finalmente termina o castelo, descobre que os prisioneiros escaparam.
Castelo TDD
Com o TDD, você aparece com os prisioneiros e vê se eles escapam. Então você escreve as celas da prisão até que elas não possam escapar. Em seguida, refatoraria o código removendo células desnecessárias de maneira limpa e removendo barras que estão no local errado e testando novamente. Os prisioneiros não escaparam. Você não precisa se comunicar com o carcereiro. E você pode entregar o castelo inteiro assim que terminar tudo. Nesse ponto, o carcereiro diz que a masmorra precisa de mais células, e agora você precisa desenterrar mais da fundação.
Castelo TDD ágil
Se você combinar Agile e TDD. Você veria se os prisioneiros escapavam e perguntaria ao carcereiro o que era necessário. Ele diz que você precisa de mais células. Você pegaria algumas pessoas aleatórias para fingir ser prisioneiro e ver se elas escapavam. Se não, então você mostra ao carcereiro, e ele fica feliz com isso. Então você começa a construir os parapeitos.
Conclusão
Então, ambos resolvem problemas diferentes. O Agile ajuda na mudança de requisitos, com base na descoberta das necessidades dos usuários, à medida que eles veem o produto se desenvolver no ponto do processo em que é mais fácil se adaptar. Envolve liberar adições estáveis, separadas do design geral.
TDD resolve o problema de antecipar falha. Descobrir e corrigir falhas, como ocorre em um ponto do processo em que é mais fácil de corrigir. Isso envolve o teste de unidades de código dissociadas estáveis, separadas do design geral.
É fácil ver o TDD como uma extensão do Agile, porque ambos seguem o mesmo padrão, progresso e revisão orientados pela unidade. A diferença é que as unidades no Agile funcionam externamente até o momento como um todo, enquanto as unidades no TDD funcionam como parte e podem não produzir um produto funcional para revisão externa. E ambos os processos governam diferentes necessidades (usabilidade versus correção). Como ambos funcionam sobre um processo de desenvolvimento em unidades, os dois processos de revisão podem ocorrer em pontos semelhantes, com o TDD sendo dividido de maneira mais precisa.
Notas
fonte
O Agile o força a lidar e reduzir os riscos de cronograma e qualidade a cada iteração. ou seja, o 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. Nesse projeto, o TDD adicionará algum risco de agendamento nas iterações iniciais, porque você também precisa escrever casos de teste. No entanto, o TDD gera enormes economias de custos em iterações posteriores, pois mitiga continuamente os riscos de qualidade. isto é, TDD é recomendado.
fonte