Já participei de várias equipes que tentam praticar metodologias ágeis e, muitas vezes, essas equipes são centradas nos testes. O teste é uma parte necessária da prática da metodologia Agile ou é apenas uma prática de XP que foi travada ao longo dos anos?

O teste é absolutamente essencial para o ágil, principalmente porque o ágil se baseia em melhorias incrementais: a dificuldade é que às vezes pode ser difícil ver como as mudanças atuais afetarão seu código antigo. A melhor maneira de ter certeza de que você não quebrou algo é testá-lo e saber COMO testá-lo. Dessa forma, você encontra o bug imediatamente, não no caminho quando se esquece exatamente o que fez quando estava escrevendo o código que quebrava algum recurso antigo.

A razão pela qual isso é diferente da programação do tipo de projeto de cima para baixo mais tradicional é que, nesse ambiente, é a) muito difícil de testar até que você tenha o produto final b) em teoria, você está considerando todos os critérios de design ao mesmo tempo, e portanto, é menos provável que você tome uma decisão de design que quebre as anteriores.

Você provavelmente está falando sobre testes automatizados, testes de unidade, testes de integração etc. Estes são mais importantes para o ágil que o manual (com testadores e outros) porque são muito lentos, portanto, não é possível testar todas as pequenas alterações que você faz. Como o agile trata de pequenas iterações rápidas, é muito útil ter testes que verifiquem a correção em segundos ou minutos, em vez de horas ou dias.

Se você não possui testes, como você sabe que seu código funciona?

Edit: a afirmação de que os testes não podem provar que o código funciona falha ao definir um termo crucial, ou seja, funciona . O que significa para um programa funcionar? Se você mantiver esse termo vago, não há como provar ou garantir que algum programa funcione. Sempre.

Por outro lado, você pode definir trabalhos como "se comporta de acordo com uma especificação". Agora você pode não apenas usar testes para mostrar que o código funciona, mas os próprios testes podem servir como uma especificação executável do comportamento do seu código. Em outras palavras, um conjunto de testes bem escrito define o que funciona significa.

Essa maneira de pensar também obriga a reexaminar o significado de um bug . Se o seu código passar em todos os testes, não haverá bugs no código. Se, apesar disso, o sistema não se comportar como deveria, então seu comportamento não será especificado corretamente. I. e. o bug está na especificação, definida por testes.

Essa abordagem ao desenvolvimento de software dissocia a especificação funcional de um sistema de sua implementação, o que, de acordo com todos os livros de engenharia de software do mundo, é uma coisa muito boa. Ao mesmo tempo, essa abordagem garante que sua implementação sempre corresponda à especificação funcional.

Não, não é necessário"

Os princípios do Agile não dizem nada diretamente sobre o teste.

Mas é altamente recomendável

Dado o compromisso da Agile com um processo sustentável, entrega contínua / incremental e qualidade de software, o teste automatizado é a melhor solução atualmente disponível para a maioria dos projetos.

Exceções (como observado por Jörg W Mittag) incluem ferramentas de desenvolvimento comprovadamente corretas, sistemas de metaprogramação que geram código, et al. Mas esses tipos de sistemas são raros.

O Agile e o XP tentam evitar o Big Design Up Front . Em BDUF, requisitos estão reunidos, uma especificação formal é criado, em seguida, a codificação é feito, em seguida, o teste é feito. Isso faz sentido para sistemas bem definidos, críticos para a missão e a vida, como equipamentos médicos, sondas espaciais, etc.

O Agile evita esse fluxo porque não funciona bem para problemas que não estão bem definidos, por exemplo "o que quer que as mudanças que o cliente solicite nesta semana". Ainda precisamos de uma especificação formal, para sabermos o que fazer e quando terminarmos, mas, em vez de algum tipo de documento escrito, usamos o código na forma de testes automatizados.

Testes de unidade automatizados são rápidos de escrever, rápidos de executar e muito modulares / desacoplados. Isso os torna uma maneira rápida de especificar e verificar formalmente os requisitos.