Na última reunião da AgilDF, fiquei de escrever um pouco sobre nossa experiência com testes de aceitação escritos com Selenium. O Rafa escreveu sobre os detalhes técnicos de se colocar os testes pra funcionar, mas fiquei achando que faltou descrever um outro lado, mais relacionado com as dúvidas que o pessoal trouxe na reunião:

De que forma os testes podem funcionar como documentação?

Como escrever os testes selenium antes de codificar as telas e o fluxo?

Que testes são necessários?

Como/quando/quem deve escrevê-los?

Vou tentar responder a todas as questões de uma vez, descrevendo a forma como estamos fazendo no Sigadaer. Não estou dizendo que essa é a forma correta, ou melhor forma, nem nada disso. (Tenho um outro post sobre isso, aguardem.) O que será descrito aqui trata-se apenas da forma como a coisa se desenvolveu no nosso projeto, no nosso cliente, com as nossas restrições, e da forma como a nossa criatividade mandou.

Inicialmente, vale lembrar que a terceira pergunta (quais testes) foi um dos grandes motivadores para evoluirmos nosso esquema de testes. Levantou-se em uma reunião de retrospectiva como essa que alguns bugs não haviam sido detectados pelos testes. Discutimos um pouco e chegamos à conclusão de que haviam faltado alguns cenários de teste.

Até então, havíamos combinado escrever apenas um teste selenium por cenário, exercitando o “caminho feliz” daquele caso. Isso porque a maior parte da equipe ainda estava engatinhando com a técnica de testes, com o selenium, com o sistema, e - porque não dizer - com o cliente. Achamos que é mais fácil aprender uma coisa de cada vez.

Depois de algumas iterações, a questão surgiu sozinha, de dentro da própria equipe. Precisávamos que a Valeska ou o Souto (nossos product-owners) descrevessem o cenário. Mas como pedir, por exemplo, para o Souto colocar as mãos no código e testar a aplicação? Não rola… Então decidimos que, antes de se começar cada novo cartão, a equipe deveria chamar um dos dois e levantar os cenários de teste um a um, anotando num papel de rascunho ou então escrevendo direto em comentários no código, desse jeito:

Esse código é real e foi extraído do código fonte no dia em que levantamos os cenários. Na verdade, como dá pra perceber, não tem praticamente nenhum código aí. Apenas comentários que refletem exatamente o que o usuário nos disse. Depois, com toda calma, o pessoal, enquanto programa a funcionalidade, vai preenchendo esses métodos com código de verdade, até que no final da iteração o mesmo arquivo acaba ficando assim:

E esse teste, no final da iteração executa e prova que a funcionalidade foi corretamente implementada. Melhor ainda: esse teste vai executar umas 10 vezes por dia, garantindo que isso não para de funcionar à medida em que programamos coisas novas ou reestruturamos o código todo porque não estávamos satisfeitos com o design do código.

No final, ainda conseguimos gerar o javadoc das classes e ter uma documentação detalhada de tudo o que os testes estão cobrindo. Ainda não chegamos ao ponto de um rpec ou de um fitnesse em termos de geração de documentação a partir dos testes, mas já está muito bom. O principal recado é esse: não se preocupe em acertar de primeira, faça o seu melhor hoje e faça amanhã melhor do que fez ontem (MelhoriaContinua).

Espero que tenha dado uma boa visão de como os testes têm nos ajudado nesse e em todos os outros projetos. Hoje consideramos que a disciplina de testes é o carro chefe do sucesso dos nossos projetos. Citando o GuilhermeChapiewski, “nosso lema é qualidade - nós não viramos noite e mesmo assim entregamos software no prazo, testado e funcionando muito bem, obrigado.” Por isso, aliás, é que consideramos fundamentais iniciativas como o DojoSEA!

Aproveito pra deixar o link desse artigo do DaniloSato sobre testes de aceitação com que esbarrei agora sem querer no blog do Guilherme, procurando a referência acima.