Desenvolvimento Orientado a Testes de Aceitação José Inácio Ferreira Filho, Olissea Artiaga da Silva 1 Pontifí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: Acesso Negado
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 Senha deve ser válida Senha deve ser válida Senha deve ser válida Senha deve ser válida @0101ab p@wss w0rd 53nh*s!$&ab123 *1234cd senhas 123456 &*$@ _-/abcd Senha @c3ss0 s3nhas @@@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 palavrachave 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. Os testes deverão ser reescritos no padrão do framework:
Caso de Teste Ação Argumento Argumento Verificar senhas válidas e Criar login Jose s3nh@s Inválidas Tentativa de efetuar login Jose com os dados CONTA CRIADA COM SUCESSO Bem-vindo s3nh@s Criar login Jose @@@101d Tentativa de efetuar login Jose com os dados CONTA CRIADA COM SUCESSO Bem-vindo Tabela 2. Reescrita dos Casos no SpeckFlow @@@101d 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] Tentativa de efetuar login Jose com os dados CONTA CRIADA COM SUCESSO Bem-vindo ${senha} Senhas devem ser inválidas [Arguments] ${senha} Criar login Jose ${senha} 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 com os dados Acesso negado Tabela 3. Criando palavras-chaves a partis de outras existentes ${senha} 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 Programming and Agile Methods - XP/Agile
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)