Você que está começando nesse novo mundo ágil. Devora seus primeiros livros, os clássicos é claro, lê blogs conhecidos, e talvez até busque alguns conselhos aqui na InfoQ. E a orientação é, entre outras coisas, automatizar seus testes - particularmente seus "testes de aceitação", para assegurar que os requisitos foram entendidos e, de fato, atendidos. Bem, adivinhe só, alguns dos mesmos especialistas por trás dessa regra estão agora propondo o oposto: não automatize esses testes.
A frente dessa recente discussão acerca dessa reviravolta está James Shore, respeitado líder intelectual do movimento ágil e, ironicamente (ou não), coordenador de projeto do Fit (framework de Ward Cunningham que faz testes de aceitação automatizados e que iniciou isso tudo).
Em uma conversa com Gojko Adzic, Shore mostrou suas idéias sobre os "problemas com testes de aceitação (automatizados)", resumidos nos seguintes pontos:
- O benefício de uma ferramenta de automação de testes de aceitação, como o Fit, imaginado originalmente era que os próprios especialistas do negócio (clientes) escreveriam exemplos executáveis. A história mostrou que isso ocorre muito raramente. Os testes são escritos em alguns casos pelos testadores, mas na maioria das vezes, pelos desenvolvedores.
- Esses testes frequentemente se tornam um fardo na manutenção, pois são lentos, frágeis e normalmente difĩceis de refatorar. JB Rainsberger possui uma grande série de artigos explicando racionalmente a sua opinião sobre por que o custo desses "testes de integração" de ponta a ponta é maior do que o seu valor.
Em poucas palavras, Shore (e Rainsberger indiretamente) afirma que como o valor pretendido (clientes escrevendo os testes) não está presente, o alto custo (de manutenção) não se justifica.
Então não devemos escrever testes automatizados? Parece uma mudança radical no modo de pensar. Não surpreendentemente, Brian Marick também tem dito coisas parecidas há algum tempo. O que é, novamente, ironico (ou não), pois um artigo de Marick de 1998 falando sobre os possíveis méritos da automatização de testes de aceitação foi um trabalho pioneiro no movimento dos testes de aceitação automatizados. Entretanto dez anos depois (há dois anos) Marick dizia:
Uma aplicação construída utilizando TDD com testes feitos pelo programador, um design whiteboard-style e com muitos exemplos de negócio, testes exploratórios das funcionalidades visuais, e um pequeno conjunto de testes automatizados para todo o sistema terá um desenvolvimento mais barato e não será pior em qualidade do que um com o mínimo de testes exploratórios, feitos através da GUI, mais um conjunto completo de testes de aceitação derivados do design com muitos exemplos de negócio.
Adzic, o destinatário original da mensagem de Shore, concorda com o primeiro ponto, mas não está completamente convencido sobre toda a mensagem de "não os automatize":
Eu nunca esperei que os clientes escrevessem nada por eles mesmos, mas fui relativamente bem sucedido em persuadí-los a participar em workshops de especificação que levavam a exemplos que eram então convertidos posteriormente a testes de aceitação... Exemplos claros e melhora da comunicação são os maiores benefícios do processo, mas utilizar uma ferramenta também traz alguns benefícios adicionais. Uma ferramenta nos dá uma medida imparcial do progresso. Ian Cooper disse durante a entrevista para meu novo livro que "a ferramenta mantém os desenvolvedores honestos", e eu posso certamente concordar com isso. Com testes que são avaliados por uma ferramenta imparcial, "feito" é realmente "o que todos concordaram", não "quase feito, somente com algumas coisas pra completar amanhã". Não estou certo se uma revisão local [como sugerido pelo artigo de Shore] é suficiente para se proteger disso completamente.
George Dinwiddie também concorda que tem havido pouco sucesso com especialistas do negócio escrevendo esses testes, incluindo a maioria dos testadores nessa categoria, mas insiste que a automatização ainda vale a pena para prevenir falhas de regressão:
Como Elisabeth Hendrickson diz, "Se o cliente tem uma expectativa e expressou essa expectativa, ele tem todos os motivos pra acreditar que você já a realizou e não quer ter que re-verificar manualmente que você realmente fez aquilo que disse que já havia feito."
É pedir muito?
...
Dado que estou convencido que as coisas devem ser retestadas, e que quanto menor a iteração mais frequentemente elas precisam ser testadas, eu não quero abrir mão dos testes automatizados. ...
Se realizamos o desenvolvimento dos exemplos com o cliente e de acordo com as condições do cliente, então completamos a parte mais difĩcil. Vale a pena realizar um esforço extra para fazer esses exemplos funcionarem (automatizando-os) para prevenir defeitos ao invés de descobri-los depois de ocorrerem.
Shore continuou seu comentário examinando as coisas que fez sua equipe realizar para "eliminar defeitos" sem testes de aceitação automatizados. Com isso, Shore deixa claro que não está sugerindo que simplesmente joguemos fora os testes de aceitação automatizados, mas que devem ser substituídos por algo, e segue descrevendo a sua visão sobre esse "algo". Essencialmente a abordagem que Shore apresenta equivale a uma boa e rigorosa aplicação das práticas modernas de XP (entretanto, o post é digno de uma leitura rigorosa e de registro).
Como resposta aos dois posts de Jim, Ron Jeffries entrou na discussão com seu longo artigo. Entre muitos outros pontos, Jeffries, assim como Adzic e Dinwiddie, ainda não está convencido de que a automatização deva ser abandonada:
Jim diz que não se incomoda se os testes não estão automatizados e se não são compreensíveis para o cliente. Eu não me incomodo que não sejam compreensíveis para o cliente - entretanto eu preferiria que fossem, caso isso fosse quase de graça. Fico menos confortável com a idéia de não serem automatizados. Minha preocupação é que se não são automatizados, portas estão abertas para regressões.
Seria interessante saber quando esses testes são automatizados, e quando não são, e que outros testes são normalmente colocados em seu lugar nesse caso. Certamente não é necessário rodar todos os exemplos para ter certeza de que o código funciona. Mas provavelmente é necessário rodar alguns.
...
Minha conclusão é que certamente o que a equipe de Jim está fazendo está funcionando, e que estão cumprindo muito bem todas as práticas de XP. Se outras equipes cumprirem as práticas tão bem quanto eles, provavelmente obterão resultados semelhantes.
E acredito que testes de história automatizados são o modo mais simples e garantido de evitar o surgimento de defeitos nas histórias posteriormente.
Então todos re-enfatizam que juntar os especialistas de negócio com os desenvolvedores para discutir exemplos ainda é algo que devemos fazer, ufa. Mas quanto a automatizar esses exemplos, Shore, Rainsberger, e Marick dizem que talvez não. Outros argumentam que sim.
De fato um debate interessante. O que você acha?