Desenvolvimento Orientado a Testes de Aceitação
José Inácio Ferreira Filho, Olissea Artiaga da Silva
1Pontifícia Universidade Católica de Goiás (PUC - Goiás)
Av. Universitária, nº 1.069, Setor Leste Universitário (Área 4, Blc A, Campus I) – Goiânia – GO – Brasil
joseinacio@msn.com, olissea@gmail.com
Abstract. In an increasingly competitive market, organizations are seeking
means to improve the quality of its products, reducing cost, time spent on rework and production thereof, and to achieve this goal are adopting methods of developing a vision code high quality, sustainable and above all customers want reliable software that will help them be more productive, thus make more money, a software that maintain or improve the operational capacity, to undertake a market, and so on. The Driven Development Acceptance Testing (TDD acceptance) helps developers create a high quality software that meets business needs in a reliable way TDD helps ensure the technical quality of software being developed.
Resumo. Em um mercado cada vez mais competitivo, as organizações estão
buscando meios que permitam aumentar a qualidade dos seus produtos, reduzindo o custo, o tempo e o retrabalho na produção dos mesmos. Para atingir este objetivo, as empresas estão adotando métodos de desenvolvimento que visam um código de alta qualidade, sustentável e acima de tudo confiável. Os clientes querem softwares que os ajudem a ser mais produtivos, conseqüentemente, que sejam mais rentáveis e mantenham ou melhorem a capacidade operacional. O Desenvolvimento Orientado a Testes de Aceitação (TDD aceitação) ajuda os desenvolvedores a criar um software de alta qualidade que atenda às necessidades do negócio de uma forma confiável. O TDD ajuda a garantir a qualidade técnica do software a ser desenvolvido.
1. Informações Gerais
A qualidade do software está diretamente ligada à existência de defeitos. O teste de software consiste na busca desses defeitos que podem ser inseridos por diversos motivos como, por exemplo, a especificação incompleta ou incorreta dos requisitos, ou requisitos não passíveis de implementação, ou durante a manutenção de um sistema já existente.
Segundo Myers, autor do livro The Art of Software Testing, o principal objetivo do teste é revelar a presença de erros no produto. Existem duas abordagens de testes, testes caixa branca, no qual através do código fonte avalia-se o comportamento interno do software (parte estrutural) e os testes caixa preta, que avaliam o comportamento externo do software (parte funcional), ou seja, os testes podem ser feitos através da verificação do código ou através da utilização do produto para a busca dos ―bugs‖.
Este artigo tem como objetivo abordar os testes caixa branca, demonstrando a técnica de desenvolvimento orientado a testes de aceitação (ATDD). A técnica direciona o comportamento interno do sistema com a criação de testes em linguagem comum que, interpretados por um framework, colaboram para o desenvolvimento bem estruturado.
O ATDD assim como o Desenvolvimento Orientado a Testes (TDD) baseia-se na criação de testes antes do código, sendo que no ATDD os testes representam as expectativas acerca do comportamento desejado para o sistema. São criados um ou mais testes de aceitação para a funcionalidade a ser desenvolvida, estes testes são discutidos e levantados juntamente com os responsáveis pelo negócio, ou seja, aqueles que são responsáveis por definir e especificar os requisitos desejados no sistema.
Considerando que o backlog é uma lista de itens que formam uma história, e que existe uma priorização desses itens a serem desenvolvidos para um sistema, o responsável pelo negócio é aquele capaz de definir o backlog, termo também utilizado em Extreme Programming (XP), metodologia ágil de desenvolvimento.
Na aplicação dessas técnicas consideradas análogas, inicia-se escrevendo um teste que deverá falhar. Isso demonstra que a base do código escrito ainda não possui um recurso totalmente implementado. Após o teste de unidade falhar, o código de produção é então escrito para fazer com que o teste passe.
A parte do código que passa no teste é refatorada, eliminando duplicações para deixar o código-fonte mais limpo, legível e com melhor design. O Test Driven Development (TDD), ou Desenvolvimento Orientado a Teste, tem fases curtas, é executado um teste por vez para cada unidade implementada. O TDD não é uma técnica de teste e sim uma prática de programação. Esta prática leva à automação dos testes unitários. Este tipo de desenvolvimento está ligado à definição das expectativas quanto à funcionalidade, fazendo que estas expectativas em relação ao comportamento do código guiem a implementação que está sob teste.
Definindo os testes em formato suportado por um framework de automação de testes funcionais, como, por exemplo, o SpeckFlow, é possível que os desenvolvedores escrevam o código de suporte (―fixtures‖) da forma em que será implementada a funcionalidade.
O artigo irá explicar o ciclo de ATDD com mais detalhes, mostrando exemplos de testes utilizando ATDD e TDD durante o processo de desenvolvimento de software.
2. Entendendo o ATDD
Para o entendimento do Desenvolvimento Orientado a Testes de Aceitação será utilizado um exemplo básico de um sistema login em que a aplicação realiza três ações básicas, verifica se existe o cadastro do usuário e senha informados, permite criar um usuário com nome e senha válidos e efetua login com nome de usuário e senha válidos. Iniciamos definindo as ações e as respostas esperadas do sistema.
A tentativa de efetuar login com uma conta de usuário ou senha inexistente irá resultar na mensagem de erro:
Ao criar uma conta de usuário com nome de usuário e senha valida é exibida a mensagem:
Conta Criada com Sucesso
E quando for efetuando o login com uma ―Conta Criada com Sucesso‖ obteremos a mensagem:
Bem-vindo!
Definido o esboço inicial das ações e respostas do sistema a ser desenvolvido, temos um ponto de partida para entendermos a utilização do ATDD.
Figura 1. Ações e Respostas do Sistema.
Inicialmente temos um sistema que realiza ações básicas para login de usuário e no próximo item priorizado no backlog aplicaremos o Desenvolvimento Orientado a Testes de Aceitação.
Para um sistema se login mais seguro criamos o nosso próximo item a ser priorizado no backlog:
Figura 2. Próximo Item de priorização no Backlog. 3. O Ciclo do Desenvolvimento Orientado a Testes de Aceitação
Todas as funcionalidades e melhorias do código iniciam-se com um teste. Adicionamos um teste e compilamos observado-o falhar intencionalmente para que ele aponte exatamente o que não está funcionando, logo será desenvolvido o código da forma mais simples para que o teste passe. Ao passar a primeira vez a parte do código que passou e verificada e refatorada. Após refatorado, o trecho do código é executado novamente e ao passar seguimos com a implementação de um novo teste para a realização de uma nova parte de código e assim por diante.
O desenvolvedor deve conhecer cada item e cada história discutida nos requisitos e entender também as exceções do sistema. Essa técnica força o desenvolvedor a escrever testes focados nos requisitos discutidos.
Cada teste elaborado deve cobrir uma funcionalidade ou melhoria que ainda não foi implementada, então esse teste deverá falhar na primeira execução, garantindo que não passará sem a necessidade de alteração do código. A falha no teste faz com que o desenvolvedor aplique o código necessário e suficiente para passar no novo teste, sem se preocupar com a elegância do código que depois será refatorado. Veremos com mais detalhes cada parte deste ciclo.
Figura 3. Ciclos TDD por Kent Beck e ATDD por James Shore
4. Discutir os Requisitos
Na Reunião de Planejamento (Planning Meeting) acontece a discussão da história acerca do tratamento para utilização de senhas seguras. Nesta reunião os
responsáveis pelo negócio são indagados para que sejam levantados os critérios de aceitação para implementação desse sistema.
Considerando o item priorizado no backlog veja exemplos de questionamentos que podem ser feitos no momento da reunião:
”Caso o usuário informe uma senha insegura como o sistema deve reagir?”
“Que estrutura de senha você considera segura? Os símbolos seriam aceitos no cadastro da senha?”
“Quantos caracteres serão permitidos no cadastro da senha?”
“Deve ser sugerido um dicionário de substituições óbvias que atendam aos critérios e que ainda possam ser segura, como 's3nh@s'?”
“Como o sistema irá se comportar com as contas já existentes?”
“O que será necessário para considerar que a funcionalidade está 'funcionando' adequadamente?”
A discussão mostra que por mais simples que pareça, existem muitos detalhes importantes para a implementação de um sistema e que essa discussão faz o responsável pelo negócio pensar melhor sobre suas expectativas e consiga definir critérios de aceitação para este sistema.
Novas necessidades podem surgir na Reunião de Planejamento como, por exemplo, forçar os usuários com contas existentes a atualizarem sua senha. A definição dos critérios de aceitação colabora para que fique bem definido que a atualização da senha para contas já existentes será uma nova história que será consolidada em outro momento.
A compreensão do que os interessados no negócio esperam que o sistema deva ou não fazer fica mais clara. Assim fica definido um esboço dos testes de aceitação juntamente com os interessados no negócio.
Os testes são escritos em linguagem comum, veja:
Figura 4. Senhas válidas que resultam em CONTA CRIADA COM SUCESSO
Figura 5. Senhas inválidas que resultam em ERRO
Figura 6. Mensagem de erro caso informado Senha inválida 5. Elaborar os Testes no Formato Interpretado pelo Framework
Elaborado o esboço dos testes é necessário reescrevê-los no formato interpretado pelo framework de automação de testes. Atualmente existem vários frameworks que suportam especificação de testes a priori. Será utilizado o formato do Specflow nos exemplos a seguir.
Os testes no Framework SpeckFlow podem ser escritos num arquivo TXT da seguinte forma:
Caso de Teste Ação Argumento
Verificar senhas válidas e inválidas Senha deve ser válida s3nh@s Senha deve ser válida @0101ab Senha deve ser válida p@wss w0rd Senha deve ser válida 53nh*s Senha deve ser válida !$&ab123 Senha deve ser válida *1234cd Senha deve ser inválida senhas Senha deve ser inválida 123456 Senha deve ser inválida &*$@ Senha deve ser inválida _-/abcd Senha deve ser inválida Senha Senha deve ser inválida @c3ss0 Senha deve ser inválida s3nhas Senha deve ser inválida @@@101
Tabela 1. Padrão de Escrita dos Casos de Teste no SpeckFlow
No momento da especificação dos testes o foco deve ser os testes para validação do que é desejado pelo cliente e não os detalhes da implementação. Na próxima parte do ciclo serão associados os testes ao código.
6. Desenvolver o Código e Associar aos Testes
Utilizando a abordagem de desenvolvimento orientado a testes, aqueles de aceitação são executados e irão falhar. Utilizando o Speckflow os testes irão falhar com mensagens de erro apresentada pelo Framework. Veja:
Figura 7. Mensagem de Erro apresentada pelo Framework
A falha é perfeitamente normal, ainda não existe implementação para a palavra-chave no framework. Os testes inicialmente foram escritos sem a pretensão de automação e agora é necessário pensar na automação desses testes criando e escrevendo palavras-chaves que conectem os testes ao código. Semelhante em todos os Frameworks, adicionamos o código a um Fixture, elemento o qual associa os testes ao código.
Caso de Teste Ação Argumento Argumento
Verificar senhas válidas e Criar login Jose s3nh@s
Inválidas
Mensagem deve ser
CONTA CRIADA
COM SUCESSO
Tentativa de efetuar login Jose s3nh@s com os dados
Mensagem deve ser Bem-vindo
Criar login Jose @@@101d
Mensagem deve ser
CONTA CRIADA
COM SUCESSO
Tentativa de efetuar login Jose @@@101d com os dados
Mensagem deve ser Bem-vindo
Tabela 2. Reescrita dos Casos no SpeckFlow
O SpeckFlow permite criar palavras-chaves a partir de outras palavras-chaves já existentes, veja:
Caso de Teste Ação Argumento Argumento
Senhas devem ser válidas [Arguments] ${senha}
Criar login Jose ${senha]
Mensagem deve ser
CONTA CRIADA COM SUCESSO
Tentativa de efetuar login Jose ${senha} com os dados
Mensagem deve ser Bem-vindo Senhas devem ser inválidas [Arguments] ${senha}
Criar login Jose ${senha}
Mensagem deve ser A senha deve ter pelo menos 6 caracteres e conter pelo menos uma letra, um número e um símbolo.
Tentativa de efetuar login Jose ${senha} com os dados
Mensagem deve ser Acesso negado
Tabela 3. Criando palavras-chaves a partis de outras existentes
Não existe um sintaxe específica para o Framework SpeckFlow, mas é necessário uma associação das palavras-chaves usadas no testes ao código executável.
Implementadas as palavras-chaves, os testes são executados novamente para a obtenção de resultados mais significativos. Esses novos resultados não trarão somente mensagem de erro dizendo que as palavras-chaves não foram implementadas, o resultado neste momento são mensagens como:
Figura 8. Mensagem para Palavras-Chaves não Implementadas
O teste falha agora, pois a funcionalidade ainda não está implementada no sistema. As senhas ainda podem ser inseguras. Sabendo que os testes falhariam, pois nada foi feito para que os mesmos passassem, existe a possibilidade de que tenha sido implementado este teste incorretamente. Dessa forma, é possível que ele passe mesmo que nenhum código tenha sido escrito.
Ver o teste falhar e certificar que ele está falhando pelo motivo correto é a forma de verificar o teste.
7. Implementando Código com TDD
Inicialmente são executados os testes unitários para garantir que o código corresponde às expectativas atuais.
Observando o conteúdo dos testes unitários relacionados à criação de uma nova senha encontramos testes unitários com os seguintes nomes:
Figura 9. Testes Unitários
A impressão é a de que já existe código para manipular senhas inseguras. Os testes unitários cumprem uma de suas tarefas documentando o comportamento da base de código existente.
Analisando melhor o código verifica-se a existência de código escrito para determinar se a senha é valida ou não, porém este não está sendo usado no momento. O método que certifica se a senha é valida ou não é chamado por nenhum componente do código, um trecho de código morto.
Analisando os demais testes unitários identificamos os relacionados à criação de novas contas de usuários com senha, observe:
Figura 10. Teste Unitário para Verificar Criação de Novas Contas
O teste cria uma nova conta com nome de usuário ―novaconta‖ e senha ―s3cr3t!@‖ verificando então se o método retorna ―success‖.
Quando criado um assert para criação de conta com senha inválida esse teste irá falhar, veja:
Figura 11. Teste Unitário para Verificar Criação de Contas com senha inválida
No design do projeto assumi-se que o método ―create‖ será retornado quando solicitada a criação de uma conta com senha inválida. Essa implementação ocorreu enquanto eram escritos os testes unitários. Percebemos que a técnica de Desenvolvimento Orientado a Testes está mais ligada à arquitetura do que ao teste de software em si.
Quando os testes unitários forem chamados com os parâmetros ―novaconta‖ e ―a‖ o método ―create‖ retornará ―sucess‖. Quando todos os testes unitários são executados com Conta Criada com SUCESSO as alterações são salvas no repositório.
8. Demonstrando os Testes Exploratórios
Ao tentarmos criar uma nova conta com a senha que possui o caractere ―&‖ ―&>_/ab0123‖ vejamos o que acontece:
Figura 12. Teste Cria Nova Conta com senha “&>_/ab0123”
A resposta do sistema é a seguinte:
Figura 13. Resposta ao tentar usar a senha &>_/ab0123
O Shell tenta interpretar alguns caracteres especiais como, por exemplo, ―&‖. Isto ocorre sempre, não somente para a aplicação em questão. Temos esta reação porque o caractere tem significado para o Shell. O tratamento para este problema tem de ser feito por meio da aplicação. O sistema cuida para que o usuário não possa usar tais caracteres.
Repetindo a ação, mas inserindo aspas simples, vejamos o que acontece:
Figura 14. Resposta ao tentar a senha entre aspas simples
O sistema retorna:
Figura 15. Resposta do sistema ao inserir senha com aspas simples
Ao se inserir aspas simples, o Shell não tenta interpretar o caractere ―&‖.
Com isto, é observado que os testes de aceitação permitem identificar brechas que não foram pensadas inicialmente. Assim que a equipe concorde que o sistema corresponde às expectativas, ele é apresentado aos interessados no negócio.
Os riscos em potencial, identificados ao longo da implementação e exploração do sistema são apresentados como, por exemplo, a questão do caractere ―&‖.
10. Conclusão
A discussão do requisito no ciclo ATDD proporciona melhor entendimento das necessidades do cliente, além de uma antecipação em relação às suas expectativas, evitando assim que ao final do projeto seja entregue um software que fuja do que foi solicitado pelo cliente. O TDD e o ATDD são formas de conhecer melhor essas necessidades e de se antecipar a essas expectativas, com a diferença de que o TDD antecipa o comportamento do código (parte interna do código) e o ATDD se antecipa ao comportamento do software (verifica se aquilo que é desenvolvido atende a uma particularidade do software).
O Desenvolvimento Orientado por Testes de Aceitação envolve a escrita de testes a partir das indagações feitas aos interessados no negócio. Os testes são escritos em uma linguagem comum, podendo ser facilmente interpretados sem a necessidade de conhecimento avançado, esses testes também podem ser utilizados como documentação, garantindo que o solicitado foi implementado. A especificação de testes de aceitação dá mais segurança no requisito que se espera do sistema a ser desenvolvido e também cria um escopo de desenvolvimento bem definido.
Este tipo de desenvolvimento faz com que seja desenvolvido o código fonte da forma mais simples possível. O design é evolutivo, o desenvolvimento é feito em partes, para cada problema novo são adicionadas novas características ao design. O código desenvolvido fica limpo e conciso. Dificilmente existirão quebras pois os testes mostram caso uma falha seja inserida. O tempo de implementação pode aumentar, mas em contrapartida a manutenção ou evolução do sistema é facilitada.
11. Referências
Beck, Kent (2003). Test-Driven Development: By Example. Addison-Wesley. Carmen Zannier , Hakan Erdogmus, Lowell Lindstrom(2004). Extreme
Glenford J. Myers(2008), The Art of Software Testing.
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series) by Ken Pugh (Jan 1, 2011)
Watt, Richard J. and Leigh-Fellows, David. ―Acceptance Test Driven Planning‖ http://testing.thoughtworks.com (Jan 2012)
Paul Gerrard, Neil Thompson (2008). Risk-Based E-Business Testing.
PRESSMAN, Roger S(2002). Engenharia de Software. Makron Booksdo Brasil Editora Ltda.
SOMMERVILLE, Ian(2007). Engenharia de Software, 8ª edição / Ian Sommerville São Paulo: PearsonAddison ± Wesley.
Test-Driven Development in Microsoft .NET (Microsoft Professional) by James W. Newkirk and Alexei A. Vorontsov (Abr 14, 2004)
Test-Driven Development no Rails Unit Tests — Simples Ideias. Por Nando Vieira. http://simplesideias.com.br/tdd-no-rails-unit-tests/ (Jan. 2012)
