Behavior Driven Development

Transcrição

1 Paulo Henrique Lerbach Rodrigues Behavior Driven Development Brasília - DF 2014

2 Paulo Henrique Lerbach Rodrigues Behavior Driven Development Artigo apresentado ao curso de pós-graduação da Fundação Universa, como requisito parcial para a obtenção do título de Especialista em Engenharia e Desenvolvimento de Software. UNIVERSIDADE CATÓLICA DE BRASÍLIA PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA LATO SENSU ENGENHARIA E DESENVOLVIMENTO DE SOFTWARE Orientador: Prof. Esp. Flávio Roberto Cruz Silva Brasília - DF 2014

3 Paulo Henrique Lerbach Rodrigues Behavior Driven Development/ Paulo Henrique Lerbach Rodrigues. Brasília - DF, p. : il. ; 30 cm. Orientador: Prof. Esp. Flávio Roberto Cruz Silva Artigo (Especialização) UNIVERSIDADE CATÓLICA DE BRASÍLIA PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA LATO SENSU ENGENHARIA E DESENVOLVIMENTO DE SOFTWARE, Behavior Driven Development. 2. Acceptance Test-Driven Development. I. Prof. Esp. Flávio Roberto Cruz Silva. II. Universidade Católica de Brasília. III. Pró-Reitoria de Pós-Graduação e Pesquisa LATO SENSU em Engenharia e Desenvolvimento de Software. IV. Behavior Driven Development CDU 004

4 Paulo Henrique Lerbach Rodrigues Behavior Driven Development Artigo apresentado ao curso de pós-graduação da Fundação Universa, como requisito parcial para a obtenção do título de Especialista em Engenharia e Desenvolvimento de Software. Trabalho aprovado. Brasília - DF, 31 de julho de 2014: Prof. Esp. Flávio Roberto Cruz Silva Orientador Engenharia e Desenvolvimento de Software Fundação Universa Prof. Esp. Michel Anderson Coordenador de Trabalho de Conclusão de Curso Brasília - DF 2014

5 Este trabalho é dedicado aos artistas desenvolvedores de software que desenvolvem seus sistemas como obras de arte com dedicação e preocupação com os detalhes.

6 Agradecimentos Agradeço primeiramente a Deus porque ele não deixou de ouvir a minha oração e nunca me negou o seu amor. À minha esposa Tatá e minhas filhas Amanda e Paula pelo amor, apoio e compreensão incondicionais, sempre me incentivando a seguir em frente e ultrapassar as dificuldades encontradas. Ao Prof. Flávio Roberto por sua dedicação e atenção durante toda a execução deste trabalho. Finalmente não poderia deixar de agradecer a meus pais pelos infindáveis amor e suporte.

7 Seja bendito o nome de Deus, de eternidade a eternidade, porque dele é a sabedoria e o poder; é ele quem muda o tempo e as estações, remove reis e estabelece reis; ele dá sabedoria aos sábios e entendimento aos inteligentes. (Bíblia Sagrada, Daniel 2, 20 e 21)

8 Resumo Este trabalho apresenta o Behavior Driven Development e demonstra como utilizá-lo no desenvolvimento de software. Além disso descreve como utilizar algumas ferramentas, apontando quais as vantagens e desvantagens de cada uma. Ao final é feita uma análise para verificar qual o impacto de sua utilização no desenvolvimento de software. Palavras-chaves: BDD. ATDD. Behavior Driven Development. acceptance test-driven development.

9 Abstract This study presents the Behavior Driven Development and demonstrates how to use it in software development. Besides it describes how to use some tools, pointing out the advantages and disadvantages of each. It concludes making an analysis to see how are the impact of their use in software development. Key-words: BDD. ATDD. Behavior Driven Development. acceptance test-driven development.

10 Lista de ilustrações Figura 1 Relatório gerado pelo Thucydides Figura 2 Classe com os Steps Figura 3 Desenvolvendo 28 Figura 4 Desenvolvendo 28 Figura 5 Relacionamento do BDD com o TDD Figura 6 Desenvolvendo o Service da Aplicação Figura 7 Relatório gerado pelo Thucydides com os testes passando Figura 8 Dependências no pom.xml para utilizar o Concordion Figura 9 Configuração de Build no arquivo pom.xml para utilizar o Concordion - Build - Recursos de Testes Figura 10 Configuração de Build no arquivo pom.xml para utilizar o Concordion - Plugins - Surefire Figura 11 Namespace do Concordion para o HTML Figura 12 Descrevendo os Requisitos utilizando HTML Figura 13 Instrumentando o HTML Figura 14 Adicionando a folha de estilo Figura 15 Classe elo entre o HTML e a aplicação no teste que falha Figura 16 Teste reprovado no Concordion Figura 17 Classe elo entre o HTML e a aplicação no teste que passa Figura 18 Teste aprovado no Concordion Figura 19 Dependências necessárias para utilizar o Cucumber-JVM Figura 20 Feature descrita para o Cucumber-JVM Figura 21 Relatório gerado pelo Cucumber com os testes pendentes Figura 22 Relatório gerado pelo Cucumber com os testes falhando Figura 23 Classe de Instrumentação para o Cucumber-JVM Figura 24 Relatório gerado pelo Cucumber com os testes passando

11 Lista de tabelas Tabela 1 Especificação por Exemplos

12 Sumário Introdução COMO UTILIZAR O BDD? Definindo a Visão de Valor do Produto Descrevendo os Objetivos de Negócio do Software Segmentando os Objetivos de Negócio em Features Transformando as Features em Histórias Enriquecendo as Histórias com Exemplos Convertendo os Exemplos em Critérios de Aceitação AUTOMATIZANDO OS CRITÉRIOS DE ACEITAÇÃO Palavras Chaves Dado - Given Quando - When Então - Then Thucydides e JBehave Concordion Cucumber Comparação entre as ferramentas JBehave e Thucydides Concordion Cucumber VANTAGENS DA UTILIZAÇÃO DO BDD Conclusão Referências

13 12 Introdução Porque será que os projetos de software falham? A resposta para essa pergunta depende de uma série de fatores porém grande parte dos motivos de falha de projetos de software estão agrupados em duas categorias: 1 construir o software certo; e 2 construí-lo da maneira correta! Construir o software certo tem relação com o alinhamento das necessidades de negócio com as funcionalidades do software. Para saber se o software certo está sendo construído tem que estar claro que as funcionalidades desse software estão sendo criadas e vão resolver problemas do negócio! O outro grande motivo é construir o software da maneira correta! Será que a solução que está sendo construída é performática o suficiente? Será que alguém conseguirá fazer manutenção desse código? É possível modificá-lo e adaptá-lo com facilidade? Percebam que não adianta conceber uma excelente solução e não construí-la de forma adequada! Além do software atender às necessidades de negócio ele deve ser construído da melhor forma possível! Os projetos falham então quando se constrói soluções que não atendem às necessidades dos usuários e/ou quando essas soluções não são bem construídas. Essas duas características do software estão diretamente ligadas ao conceito de qualidade de software. Não existe qualidade num software bem construído que não atende às necessidades de seu usuário bem como não existe qualidade num software que atende às necessidades de seu usuário sem eficácia, inviabilizando a solução. É para atender a esses dois conceitos construir o software correto da maneira correta que nasce o desenvolvimento guiado por comportamento ou BDD / Behavior Driven Development -. Esse artigo explica o que é o BDD e como utilizá-lo para construir software de qualidade.

14 13 1 Como utilizar o BDD? O BDD está intimamente ligado ao desenvolvimento ágil, por isso pode-se dizer que ele também nasce como uma forma de evoluir o desenvolvimento de software, reduzindo o desperdício e aumentando o retorno do investimento! Dan North, seu criador, enquanto ministrava cursos de desenvolvimento guiado por testes TDD / Test Driven Development percebeu que uma série de dúvidas frequentes de seus alunos poderiam ser facilmente respondidas desde que ele - o TDD - fosse apresentado de maneira direta e evitando algumas armadilhas. Para apresentar o TDD da melhor forma possível ele concebeu então o BDD, uma evolução das práticas ágeis estabelecidas, tornando-as mais acessíveis e eficazes. Com o tempo a ideia foi amadurecendo e hoje abrange também a análise ágil de requisitos e automatização de testes de aceitação. Mas como utilizar essas práticas para construir software de qualidade? Nas próximas seções desse artigo será descrito passo a passo como utilizar o BDD. Para facilitar o entendimento e possibilitar que o leitor acompanhe a evolução dos requisitos desde o problema do usuário até a automatização dos testes de aceitação. 1.1 Definindo a Visão de Valor do Produto A visão de produto expressa aquilo que satisfará o cliente! Ela descreve um objetivo ou necessidade do mais alto nível e deve fornecer contexto, orientação, motivação e inspiração para o desenvolvimento do software! Toda a equipe deve focar em alcançar esse objetivo. Uma forma bastante interessante de se descrever essa visão é utilizando o modelo chamado Teste do Elevador apresentado por Geoffrey Moore. Esse método é citado tanto em Sabbagh (2013) quanto em Smart (2013) como um template para facilitar a descrição da visão. Esse template define o seguinte formato: Para (cliente-alvo), que (problema ou oportunidade), o (nome do produto) é um (categoria do produto) que (benefício chave, razão convincente para utilizar). Ao contrário de (Alternativa primária competidora), nosso produto (diferenciação primária). Os exemplos utilizados em Sabbagh (2013) são esses: Para usuários de Internet solteiros em busca de um relacionamento sério, que estão insatisfeitos com encontros mal sucedidos e a oferta de numerosas opções pouco

15 Capítulo 1. Como utilizar o BDD? 14 criteriosas, o LoveFinder é um site de relacionamentos amorosos que os ajuda a encontrar sua alma gêmea. Ao contrário de sites de encontros populares, nosso produto oferece pretendentes compatíveis com as preferências do usuário, apresentando detalhes suficientes que incluem fotos. E esse: Para turistas usuários de smartphone, que desejam aproveitar melhor seus destinos, o MyTrip é um aplicativo móvel de viagens que sugere roteiros diários flexíveis de acordo com seu perfil. Ao contrário de guias de viagens com roteiros predefinidos, nosso produto elabora trajetos personalizados e adaptáveis. Já Smart (2013) deixa esse exemplo: Para viajantes, que desejam ser recompensados por viajar com as Linhas Aéreas Voando Alto, o Programa Voando Alto de Benefícios para Viajantes Frequentes é um programa de fidelidade que permite que os clientes de forma fácil e conveniente visualizem e gerenciem seus pontos acumulados, em tempo real, e gastem seus pontos em compras reais com facilidade sem igual. Ao contrário de outros programas de Viajantes Frequentes, nosso programa permite que o membro use seus pontos facilmente para qualquer tipo de compra online ou compras nas lojas físicas. 1.2 Descrevendo os Objetivos de Negócio do Software Um dos pontos chave do BDD é facilitar a assimilação dos objetivos para que todos tenham um entendimento claro sobre o que o projeto pretende entregar, como ele vai beneficiar o negócio. (SMART, 2013) Para tanto trabalhamos junto aos usuários e os stakeholders para definir e clarificar um conjunto de objetivos estratégicos que o software deve atender. São esses objetivos que vão prover uma visão concisa sobre o que temos de construir. Como os objetivos de negócio do software são sobre entregar valor para o cliente é comum vê-los expressos tanto em termos de aumentar e proteger o lucro quanto diminuir custos. (SMART, 2013) Smart deixa o seguinte exemplo de um objetivo de negócio que determinado software deve atingir: trem. Aumentar o lucro na venda de tickets tornando mais fácil e produtivo viajar de Para Sabbagh Esses objetivos significam passos que devem ser dados para se alcançar a visão do produto! É claro que devem ser enumerados diversos objetivos para que a visão do produto seja satisfeita. Nesse ponto é desejável que cada objetivo esteja com um detalhamento

16 Capítulo 1. Como utilizar o BDD? 15 e granularidade tal que seja possível o seu desenvolvimento em apenas uma iteração da equipe de desenvolvimento. Caso contrário o objetivo deve ser segmentado para gerar objetivos possíveis em apenas uma iteração. Se o objetivo Aumentar a satisfação do usuário tornando menor o tempo de espera em pontos de ônibus não estiver detalhado o suficiente é possível fatiá-lo em outros objetivos menores, entregáveis em apenas uma iteração. Então é possível fatiar esse objetivo nos seguintes objetivos menores: a) Aumentar a satisfação do usuário informando quais as linhas que ligam uma origem a um destino; b) Aumentar a satisfação do usuário informando qual a posição de cada ônibus; c) Aumentar a satisfação do usuário informando qual o tempo estimado para o próximo ônibus chegar ao ponto em que ele está; Essas três fatias contribuirão para se atingir aquele objetivo maior, entregam valor ao usuário e, por serem menores, podem ser concretizados em uma única iteração da equipe. 1.3 Segmentando os Objetivos de Negócio em Features Já que existe um entendimento e uma visão dos objetivos de negócio do software, é possível trabalhar com os stakeholders no sentido de definir exatamente como eles desejam que esses objetivos sejam atendidos! Essa etapa gera um conjunto de features que o software deve ter para entregar o valor que se deseja. Smart (2013) elenca para um sistema que deve atender os usuários de metrô em Sydney as seguintes features essenciais: a) Prover aos viajantes itinerários otimizados; b) Prover em tempo real o posicionamento dos trens para os viajantes saberem sobre atrasos; c) Permitir aos passageiros escolherem suas viagens favoritas; d) Notificar o passageiro que o trem dele está atrasado; Uma vez que já existem algumas features de alto-nível definidas é possível descrever essas features. Existem diversas formas de se descrever essas features mas é comum em projetos Agile a utilização no formato como <stakeholder>, desejo <alguma coisa>, então <entregue algum valor de negócio>. (SMART, 2013)

17 Capítulo 1. Como utilizar o BDD? 16 Essa estrutura ajuda os desenvolvedores a entenderem o contexto dos requisitos como se fossem o usuário do software, percebendo de forma bastante clara o que o usuário espera quando estiver utilizando essa feature. Como exemplo Smart (2013) estabelece: como um usuário do metrô desejo saber o melhor caminho entre duas estações então chegarei ao meu destino rapidamente. por exemplo: O mesmo autor ainda reforça que existem outras variações desse formato como, para <entregue algum valor de negócio> como <stakeholder> desejo <alguma coisa>. Apesar da diferença nessa variação ser pequena é bastante significativa. Quando se planeja features e histórias o alvo é entregar valor ao negócio. Mais importante que propor uma feature para um usuário e depois procurar qual valor de negócio a justifica, começa-se pelo valor de negócio que se pretende entregar, passando por quem precisa dessa feature e finalmente qual feature que suportará essa necessidade de negócio. (SMART, 2013) Usando esse formato a feature acima poderia ser reescrita da seguinte forma: para planejar minhas viagens mais eficientemente como usuário do metrô desejo saber o melhor itinerário entre duas estações. 1.4 Transformando as Features em Histórias Geralmente é necessário quebrar as features em pedaços menores que caibam dentro de cada ciclo de desenvolvimento. As features podem ser quebradas em histórias de usuário e cada história explorará uma faceta diferente do problema e deve ser pequena o bastante para ser totalmente desenvolvida em uma iteração. (SMART, 2013) Smart considera, por exemplo, que o time de desenvolvimento pode entender que a feature Prover aos usuários itinerários otimizados precise de mais de uma iteração para ser completada. Considera ainda que a equipe deseja ter feedback dos usuários antes de

18 Capítulo 1. Como utilizar o BDD? 17 desenvolver toda a feature. Portanto a feature pode ser fragmentada em pequenas histórias como a seguir: a) Encontrar qual o horário que o próximo trem para o meu destino sai; b) Encontrar o itinerário ótimo entre estações na mesma linha; c) Encontrar o itinerário ótimo entre estações em linhas diferentes; Para detalhar ainda mais as histórias, segundo Smart, podem ser descritas da mesma forma que as features, como a seguir: História - Encontrar qual o horário que o próximo trem para o meu destino sai: para planejar minhas viagens mais eficientemente como usuário do metrô desejo saber quais os próximos trens indo para o meu destino. História - Encontrar o itinerário ótimo entre estações na mesma linha: para chegar ao meu destino no horário como usuário do metrô desejo saber qual o trem devo tomar. História - Encontrar o itinerário ótimo entre estações em linhas diferentes: para chegar ao meu destino no horário como usuário do metrô desejo saber qual o trem devo tomar e saber detalhes de qualquer conexão que eu precise fazer. Concluindo essa etapa Smart reforça que essas histórias não servem para criar uma obrigação entre usuários e desenvolvedores. A definição de histórias deve ser um processo dinâmico e iterativo para facilitar a comunicação e o entendimento compartilhado sobre o problema. A cada história implementada deve-se buscar o feedback dos stakeholders e isso permitirá refinar as histórias subsequentes, adicionar novas histórias ou até mesmo eliminar as que se tornarem desnecessárias, sempre com foco nos objetivos de negócio. Descobrir features e histórias faz parte do processo de aprendizado. (SMART, 2013) 1.5 Enriquecendo as Histórias com Exemplos Depois de descrever features e histórias é possível explorá-las em maiores detalhes. Uma maneira bastante eficiente de fazer isso é perguntando para os usuários e stakeholders sobre exemplos concretos. Para Smart é natural que quando os desenvolvedores ouvem o usuário pedindo por uma feature, eles imediatamente começam a construir uma solução mental e uma implementação incorreta que pode se manifestar mais tarde. Em contrapartida, ainda segundo Smart, quando se pergunta para os stakeholders por exemplos

19 Capítulo 1. Como utilizar o BDD? 18 concretos sobre o que eles desejam tem se uma grande oportunidade de se validar e confirmar o entendimento do problema.(smart, 2013) Em Gärtner (2012) e Smart (2013) são descritos alguns exemplos de conversas com usuários e stakeholders e o quanto elas podem ser proveitosas. Gärtner cita como exemplo o caso de um sistema que pré-calculava o preço de estacionamento em diversas possibilidades e planos. Na primeira tentativa as mudanças foram tão significativas que eles não conseguiram entregar o que o cliente necessitava. Então foi marcada uma reunião com o gerente do aeroporto e no decorrer da conversa eles foram construindo uma tabela com uma coluna para a duração da permanência no estacionamento e outra para o custo para cada um dos planos. Outra etapa bastante interessante descrita por Gärtner é o filtro nos exemplos para se selecionar os exemplos essenciais, retirando daquela tabela gerada todos os exemplos que fossem repetitivos de forma que cada exemplo estivesse associado a um objetivo de negócio específico. Esses exemplos são muito importantes pois servirão de parâmetro para validar se a lógica do nosso software está se comportando como deveria! Na descrição feita por Gärtner é impressionante como diversas regras sobre a variação do preço de estacionamento em um aeroporto são simplificadas e validadas com uma simples tabela, veja: Tabela 1: Especificação por Exemplos. Tempo de Estacionamento Custo 30 minutos $ 12,00 3 horas $ 12,00 5 horas $ 12,00 5 horas e 1 minuto $ 18,00 12 horas $ 18,00 24 horas $ 18,00 1 dia e 1 minuto $ 36,00 3 dias $ 54,00 1 semana $ 126,00 Fonte: Gärtner (2012) Essa simples tabela com exemplos concretos de como a aplicação deve funcionar abrange muito das regras de negócio e são insumos práticos para validar o funcionamento da aplicação. O exemplo que Smart traz é a seguinte conversa entre o leitor e Jill, um especialista no metrô de Sidney: você: Você poderia me dar um exemplo de usuário viajando entre duas estações?

20 Capítulo 1. Como utilizar o BDD? 19 Jill: Claro, que tal ir de Parramatta para Town Hall? você: E como seria? Jill: Bem, ele teria que pegar a linha ocidental. Esta linha é muito utilizada, e existem entre 8 e 16 trens por hora, dependendo do horário do dia. Nós só precisamos mostrar ao usuário os próximos trens agendados nessa linha você: Você poderia me dar um exemplo de uma viagem onde um usuário teria a possibilidade de escolha de mais de uma linha? Jill: Sim, um viajante que vai de Epping para a Central poderia tomar tanto a linha Epping, a linha Norte, ou ainda a linha Newcastle. O tempo de viagem vai variar de 27 a 43 minutos e os trens de qualquer dessas linhas geralmente chegam a cada 2 minutos de modo que seria necessário dar aos passageiros informação suficiente sobre as partidas e chegadas dos trens nas duas linhas Uma simples conversa com um especialista no negócio torna os detalhes visíveis, o que nem sempre é possível apenas pela descrição das histórias e as features. Esses exemplos vão tornar claras as minúcias do sistema e vão fundamentar os critérios de aceitação. 1.6 Convertendo os Exemplos em Critérios de Aceitação Os exemplos são utilizados como base para os critérios de aceitação. De forma bem simples os critérios de aceitação são a garantia para os stakeholders de que a aplicação efetivamente faz o que deveria fazer. (SMART, 2013) Em Behavior Driven Development é necessário lançar mão de uma notação bem estruturada para se descrever os critérios de aceitação pois o objetivo é que esses critérios sejam automatizados. Por isso a seguinte notação é geralmente utilizada: Dado <contexto> Quando <alguma coisa acontece> Então <espera-se algum resultado>. As palavras Dado(Given), quando(when) e então(then) tem significado especial em algumas ferramentas de automação de testes, por isso a descrição dos critérios de aceitação é um pouco menos flexível. Apesar de ser menos flexível ela ainda assim é muito

21 Capítulo 1. Como utilizar o BDD? 20 interessante pois permite perceber como o usuário interagirá com o sistema e quais os resultados esperados. Utilizando essa notação nos exemplos descritos por Smart, de acordo com a conversa descrita acima, tem-se: Dado que os trens da linha ocidental chegam a Parramatta às 7:58, 8:02, 8:08, 8:11, 8:14, 8:21 Quando eu quiser viajar de Parramatta para a Toen Hall às 8:00 Então eu devo ser avisado sobre o trem das 8:02, 8:11, 8:14.

22 21 2 Automatizando os Critérios de aceitação Nesse ponto já é possível perceber as diversas vantagens de se trabalhar orientado aos objetivos de negócio, segmentando esses objetivos em features, descrevendo essas features em histórias e enriquecendo essas histórias com exemplos. Converter esses exemplos em critérios de aceitação, utilizando o padrão dado - quando - então contribui com a diminuição da possibilidade de mal-entendido ou ideias incoerentes com as necessidades dos usuários, com os objetivos do negócio. Uma outra grande vantagem dessa abordagem é facilitar a automatização dos requisitos na forma de testes de aceitação automatizados. (SMART, 2013) Nesse artigo será utilizado, a fim de demonstrar a utilização do BDD, um breve sistema de relacionamento com eleitores. A ideia é prover para a sociedade e para seus representantes no governo uma forma de interação, de maneira que o político tenha uma forma de contato com seus eleitores e vice-versa. O primeiro passo é conversar com os stakeholders - a sociedade e os políticos - e ter certeza que você e a equipe tem uma ideia clara dos objetivos de negócio que direcionam o projeto. Após entender e articular os objetivos de negócio é possível enumerar as features que a aplicação deve ter para atingir esses objetivos. Alguns exemplos de possíveis features desse sistema são: Possibilitar a interação entre políticos e eleitores; Cadastrar políticos e eleitores e suas intenções de voto; Essas features são bastante amplas e talvez não seja possível entregá-las de uma única vez. Como a ideia é sempre entregar alguma funcionalidade nova a cada iteração o passo agora é fracionar essas features em unidades menores que sejam possíveis de serem entregues em uma única iteração. Essas unidades menores são conhecidas pelos praticantes de agile como histórias. Por exemplo a feature Cadastrar políticos e eleitores e suas intenções de voto poderia ser fracionada em: a) Possibilitar o cadastro de usuários; b) Cadastrar eleitores; Cadastrar políticos; Dessa forma a equipe pode primeiramente desenvolver um cadastro genérico e depois, talvez em outra iteração, especializar esse cadastro para eleitores e políticos. Na hora de implementar essa história o ideal é enriquecê-la com exemplos concretos de como o sistema deve se comportar. Esses exemplos se tornarão os critérios de aceitação

23 Capítulo 2. Automatizando os Critérios de aceitação 22 da história e devem ser expressos no formato utilizado no BDD que seja possível sua automatização posteriormente: Dado que o eleitor José da Silva deseja acompanhar seu representante no governo; Quando ele preencher o formulário de cadastro e submetê-lo; Então o sistema deve exibir uma mensagem de usuário cadastrado com sucesso; É possível deixar esse exemplo ainda mais concreto: Dado que o eleitor José da Silva deseja acompanhar seu representante no governo; Quando ele preencher o formulário de cadastro com o nome de usuário jose e a senha dasilva e submetê-lo; Então o sistema deve exibir a seguinte mensagem: O usuário jose com a senha dasilva foi cadastrado com sucesso ; A partir daqui já existe um ponto inicial para o desenvolvimento então será demonstrado como automatizar esse critério de aceitação e alguns exemplos de implementação utilizando a linguagem de programação Java, o projeto será executado utilizando o Maven. 2.1 Palavras Chaves A maioria das ferramentas de automação dos testes de aceitação utilizam o padrão dado-quando-então ou give-when-then. O objetivo dessa seção é orientar e dar exemploes da utilização de cada uma dessas palavras Dado - Given De acordo com a Wiki do Cucumber 1, serve para colocar o sistema num estado conhecido antes do usuário iniciar a interação com ele. Evite descrever interações com o usuário no Dado - Given! Adicione aqui as precondições para a execução do teste Quando - When O propósito do Quando - When é descrever a ação chave que o usuário irá executar! Por exemplo descrever quando o usuário interagirá com um site ou um componente da interface. Se não existir um usuário pode ser, por exemplo, uma ação numa biblioteca que dispare algumas outras em outros lugares Então - Then O propósito do Então - Then é observar as saídas. Esses resultados esperados devem ter relação com os valores de negócio que se pretende entregar conforme a descrição da feature. Esses resultados esperados são as saídas do sistema, por exemplo relatórios, 1 <

24 Capítulo 2. Automatizando os Critérios de aceitação 23 mudanças na interface, mensagens. Não deve ser algo interno no código! Deve ser algo que traga valor ao negócio! Aqui é o local apropriado para verificar se algo relacionado com o Dado - Given e Quando - When está ou não na saída do sistema ou então verificar se o sistema interagiu com outros sistemas, por exemplo enviando uma mensagem (Será que o conteúdo da mensagem estava adequado?). Parece tentador colocar aqui verificações se algo foi ou não escrito no banco de dados porém o ideal é verificar apenas aquilo que é pode ser observado pelo usuário - ou sistema externo - e os banco de dados não são acessíveis dessa forma ao usuário! 2.2 Thucydides e JBehave Existem diversas ferramentas que possibilitam a automatização dos critérios de aceitação, dentre as mais populares estão: JBehave, Cucumber, SpecFlow, Behat, Concordion, Fitnesse. Elas não são indispensáveis mas facilitam demais expressar os testes automatizados de forma estruturada no padrão given... when... then ou de forma livre (caso do Concordion). Para gerar um relatório da execução dos testes útil para que os envolvidos possam acompanhar a evolução do desenvolvimento, bem como a geração da documentação viva será utilizado a ferramenta Thucydides, uma biblioteca open source que facilita e organiza o resultado dos testes BDD. Esses exemplos foram desenvolvidos utilizando uma JDK Java 1.8 e o Maven 3.0.x. Comece baixando o projeto inicial nesse endereço: Após baixar o projeto execute o comando mvn verify e espere o resultado BUILD SUCCESS indicando que está tudo ok com o projeto. É necessário seguir as convenções do Maven para a organização do projeto, por isso o código da aplicação será armazenado em src/main/java e o código de testes deve estar em src/test/java. As histórias do JBehave estarão em src/test/resources/stories. Crie esses diretórios na raiz do projeto. Agora crie uma classe que será responsável pela execução de todas as histórias do JBehave que estiverem em src/test/resources. Essa classe nada mais é que um test runner do JUnit que deve estender a classe net.thucydides.jbehave.thucydidesjunitstories e pode se chamar, por exemplo AcceptanceTestSuite.java. Coloque essa classe no pacote raiz da sua aplicação que deve estar no source folder de teste (src/test/java). No exemplo do artigo o nome da aplicação é contacta e o pacote raiz é sitedo.ph,

25 Capítulo 2. Automatizando os Critérios de aceitação 24 por isso a classe ficou em src/test/java/sitedo/ph/contacta. Você também pode criar nesse momento o pacote raiz no source folder do código da aplicação: src/main/java/sitedo/ph/contacta. O ideal seria que as especificações estivessem em português, com o objetivo de facilitar o entendimento de todos os envolvidos, desde os desenvolvedores até os stakeholders! O JBehave até fornece suporte ao idioma mas o Thucydides não se comporta perfeitamente quando o projeto está configurado para reconhecer as palavras-chaves em português. Portanto substituiremos essas palavras para o default, em inglês. Nesse momento é possível automatizar aquele critério de aceitação que foi criado, para isso crie a história, no JBehave ela ficará assim: Possibilitar o cadastro de usuários Narrative: In order to acesso ao sistema As a um Usuário I want to preencher um formulário com os dados necessários Scenario: Cadastrar o usuário no sistema com sucesso Given o eleitor José da Silva deseja acompanhar seu representante no governo When ele preencher o formulário de cadastro com o nome de usuário jose e a senha dasilva e submetê-lo Then o sistema deve exibir a seguinte mensagem: O usuário jose com a senha dasilva foi cadastrado com sucesso No JBehave os cenários estão agrupados por histórias e são armazenados em arquivos com o sufixo.story, portanto crie o arquivo cadastrar_usuarios.story no diretório src/test/resources/stories/usuarios do projeto. Utiliza-se a pasta usuários para poder agrupar as histórias por grupos funcionais de alto nível. O conteúdo do arquivo deve ser exatamente a história descrita acima, nela temos: 1. Título da história: Possibilitar o cadastro de usuários 2. Descrição da história:

26 Capítulo 2. Automatizando os Critérios de aceitação 25 Narrative: In order to acesso ao sistema As a um Usuário I want to preencher um formulário com os dados necessários 3. Cenário: Scenario: Cadastrar o usuário no sistema com sucesso 4. Pré-condição: Given o eleitor José da Silva deseja acompanhar seu representante no governo 5. Ação sob teste: When ele preencher o formulário de cadastro com o nome de usuário jose e a senha dasilva e submetê-lo 6. Resultado esperado: Then o sistema deve exibir a seguinte mensagem: O usuário jose com a senha dasilva foi cadastrado com sucesso Perceba que as palavras acima em negrito são palavras chave utilizadas pelo JBehave! É usual criar diretórios para representar grupos de funcionalidade. Nesse exemplo foi criado o diretório usuarios que conterá todas as especificações relacionadas com as funcionalidades de usuários, ou seja agrupamos em diretórios os grupos funcionais. Opcionalmente o diretório com a história pode contar com um arquivo narrative.txt com um título e uma breve descrição sobre o grupo funcional daquele diretório. Nesse momento se o comando mvn verify for executado e o resultado for BUILD SUCCESS o Thucydides terá gerado um relatório com o resultado da execução dos testes. Esse relatório pode ser acessado na pasta target/site/thucydides no arquivo index.html, vejam na Figura 1. Nesse momento o cenário deixou de ser um arquivo simples de texto e se tornou uma especificação executável! É possível, a partir desse cenário em formato texto simples, acompanhar a evolução e implementação da especificação. É necessário agora implementar o código que atenderá essa especificação para trocar

27 Capítulo 2. Automatizando os Critérios de aceitação 26 Figura 1: Relatório gerado pelo Thucydides o status de pendente - pending - para passou - passed -. Note que é possível acompanhar o status atual de todos os requisitos bastando acessar o menu Requirements no Thucydides. A próxima etapa é criar o código que realmente testara a aplicação, dando vida à especificação! Na saída da execução do comando mvn verify já é possível ver alguma dica sobre esse código. Crie então no source folder de teste - src/test/java - o pacote sitedo.ph.contacta.steps

28 Capítulo 2. Automatizando os Critérios de aceitação 27 e dentro dele a classe CadastroDeUsuarioSteps. Adicione dentro dessa classe exatamente o código gerado na saída do comando de verificação do maven. Ela deve estar parecida com a Figura 2. Figura 2: Classe com os Steps 1 package s i t e d o. ph. contacta. s t e p s ; 2 3 import org. jbehave. core. annotations. Given ; 4 import org. jbehave. core. annotations. Pending ; 5 import org. jbehave. core. annotations. Then ; 6 import org. jbehave. core. annotations.when; 7 8 p u b l i c c l a s s CadastroDeUsuarioSteps { 9 ( " o e l e i t o r Jos é da S i l v a d e s e j a acompanhar 11 seu r e p r e s e n t a n t e no governo " ) 13 p u b l i c void givenoeleitordesejaacompanharogoverno ( ) { 14 } 15 " e l e preencher o formul á r i o de cadastro com 17 o nome de usuá r i o $usuario e a senha $senha e submet ê l o " ) 19 p u b l i c void whenelepreencheroformulario ( S t r i n g usr, S t r i n g pwd) { 20 } 21 ( " o sistema deve e x i b i r a s e g u i n t e mensagem : $mensagem " ) 24 p u b l i c void thenosistemadeveexibir ( S t r i n g mensagem ) { 25 } 26 } Note que a indica que esse cenário ainda será implementado. É configurado dessa forma para garantir que no relatório o status continue pendente! Além disso perceba a associação de $usuario, $senha e $mensagem com os parâmetros que são utilizados na assinatura dos métodos! O JBehave fara a conversão do texto na especificação para seu respectivo parâmetro no código de teste! Faz parte da prática do BDD começar especificando o resultado desejado para, a partir dele, desenvolver a aplicação. Portanto inicie desenvolvendo o conforme Figura 3. A estrutura para a realização do teste já está codificada, já existe um local apro-

29 Capítulo 2. Automatizando os Critérios de aceitação 28 Figura 3: Desenvolvendo 1 package s i t e d o. ph. contacta. s t e p s ; 2 3 import s t a t i c org. f e s t. a s s e r t i o n s. A s s e r t i o n s. assertthat ; 4 5 import org. jbehave. core. annotations. Given ; 6 import org. jbehave. core. annotations. Pending ; 7 import org. jbehave. core. annotations. Then ; 8 import org. jbehave. core. annotations.when; 9 10 p u b l i c c l a s s CadastroDeUsuarioSteps { p r i v a t e S t r i n g mensagemexibida ; // Trechos suprimidos ( " o sistema deve e x i b i r a s e g u i n t e mensagem : $mensagem " ) 17 p u b l i c void thenosistemadeveexibir ( S t r i n g mensagem ) { assertthat ( mensagemexibida ). isequalto ( mensagem ) ; 20 } 21 } priado para a saída esperada e a realizada. Agora é necessário definir como a aplicação responderá, perceba que você pode projetar a sua aplicação da melhor forma possível e o teste facilita isso. Suponha que a aplicação terá serviços para a realização de suas tarefas! Você pode criar um UsuarioService e colocar nele os métodos necessários para o cadastro de usuários! Codifique então o método anotado Abaixo está uma possível solução na Figura 4. Figura 4: Desenvolvendo " e l e preencher o formul á r i o de cadastro com 2 o nome de usuá r i o $usuario e a senha $senha e submet ê l o " ) 3 p u b l i c void whenelepreencheroform ( S t r i n g usr, S t r i n g pwd) { 4 U s u a r i o S e r v i c e u s u a r i o S e r v i c e = new U s u a r i o S e r v i c e ( ) ; 5 mensagemexibida = u s u a r i o S e r v i c e. c a d a s t r a r ( usuario, senha ) ; 6 } Não se preocupe nesse momento em fazer tudo compilar e funcionar! O primeiro

30 Capítulo 2. Automatizando os Critérios de aceitação 29 passo é fazer um teste que falhe! Depois será feito com que ele passe e funcione atendendo à especificação! Você acabou de projetar a classe UsuarioService e é preciso codificá-la internamente! Para tanto é necessário passar de teste de aceitação para teste unitário, aumentando a granularidade daquilo que vai ser testado! Geralmente são escritos vários testes unitários para fazer um teste de aceitação passar! O objetivo do exemplo desse artigo é demonstrar de forma sucinta a construção de uma funcionalidade bastante simples utilizando o BDD passo a passo. Para simplificar não será abordado o teste unitário mas o recomendável é mesmo desenvolver vários testes unitários automatizados para cada funcionalidade da aplicação, veja a Figura 5. Figura 5: Relacionamento do BDD com o TDD Refatorar Vermelho BDD Verde O código mais simples que atende à especificação pode ser visto na Figura 6. Após implementar esse Service e reexecutar o comando mvn verify o Thucydides é atualizado e é possível ver que o teste agora passou, indicando que ele foi implementado e está funcionando! Veja a Figura 7. Agora que a primeira história está resolvida você pode especificar novas histórias, fazer algumas falharem e outras ficarem pendentes e ver como o relatório vai ficar.

31 Capítulo 2. Automatizando os Critérios de aceitação 30 Figura 6: Desenvolvendo o Service da Aplicação 1 package s i t e d o. ph. contacta. s e r v i c e s ; 2 3 p u b l i c c l a s s U s u a r i o S e r v i c e { 4 5 p u b l i c S t r i n g c a d a s t r a r ( S t r i n g usuario, S t r i n g senha ) { 6 7 // Ló g i c a para p e r s i s t i r o usuá r i o no banco de dados! 8 9 return "O usuá r i o " + u suario + " com a senha " + senha 10 + " f o i cadastrado com s u c e s s o " ; 11 } } Figura 7: Relatório gerado pelo Thucydides com os testes passando

32 Capítulo 2. Automatizando os Critérios de aceitação Concordion Existe uma outra ferramenta chamada Concordion! Ele não te amarra a uma sintaxe específica e permite que os requisitos sejam descrito de forma livre, no entanto exige que a pessoa que for escrever os requisitos saiba um pouco de html. O primeiro passo é preparar o projeto para utilizar o Concordion, editando o arquivo pom.xml adicionando a dependência do concordion e configurando o build para executar o teste e adicionar o html ao classpath. O arquivo pom.xml para isso está descrito na Figura 8 - dependências -, Figura 9 - definição de recursos utilizados para testes! Decreve onde os arquivos HTML estarão - e Figura 10 - configurações do plugin Surefire explicitando o o Concordion gerará seus relatórios -. Figura 8: Dependências no pom.xml para utilizar o Concordion 1 <dependencies > 2 <dependency> 3 <groupid>org. concordion </groupid> 4 <a r t i f a c t I d >concordion </ a r t i f a c t I d > 5 <version >1.4.4 </ version > 6 </dependency> 7 </dependencies > Figura 9: Configuração de Build no arquivo pom.xml para utilizar o Concordion - Build - Recursos de Testes 1 <testresources > 2 <testresource > 3 <d i r e c t o r y >s r c / t e s t / java </d i r e c t o r y > 4 <excludes > 5 <exclude > /. java </exclude> 6 </excludes > 7 </testresource > 8 <testresource > 9 <d i r e c t o r y >s r c / t e s t / r e s o u r c e s </d i r e c t o r y > 10 <excludes > 11 <exclude > /. java </exclude> 12 </excludes > 13 </testresource > 14 </testresources >

33 Capítulo 2. Automatizando os Critérios de aceitação 32 Figura 10: Configuração de Build no arquivo pom.xml para utilizar o Concordion - Plugins - Surefire 1 <plugin > 2 <groupid>org. apache. maven. plugins </groupid> 3 <a r t i f a c t I d >maven s u r e f i r e plugin </ a r t i f a c t I d > 4 <version > </ version > 5 <c o n f i g u r a t i o n > 6 <systemproperties > 7 <property> 8 <name>concordion. output. dir </name> 9 <value>t a r g e t / concordion </value> 10 </property> 11 </systemproperties > 12 <i n c l u d e s > 13 <include > /. java </include > 14 </i n c l u d e s > 15 <forkmode>once </forkmode> 16 </c o n f i g u r a t i o n > 17 </plugin > Para automatizar os requisitos do mesmo sistema que o artigo trata comece criando um arquivo html que é onde a especificação estará contida! Chame esse arquivo de CadastroDeUsuarioSpec.html e o coloque na pasta src/test/java/spec. Adicione no topo desse arquivo o cabeçalho padrão para arquivos html e o namespace do concordion como na Figura 11. Figura 11: Namespace do Concordion para o HTML 1 <?xml v e r s i o n ="1.0" encoding="utf 8"?> 2 <html xmlns : concordion ="http : / /www. concordion. org /2007/ concordion " lang ="pt BR"> Agora descreva o requisito, da forma como preferir - não precisa utilizar palavras chaves aqui! - veja a Figura 12. Agora é necessário instrumentar o arquivo html para que ele se torne um teste, como na Figura 13. Perceba que o atributo concordion:set vai definir uma variável em nossa classe de teste e o atributo concordion:assertequals vai verificar se o resultado da invocação do método insereusuario passando os parâmetros usuario e senha é igual ao esperado!

34 Capítulo 2. Automatizando os Critérios de aceitação 33 Figura 12: Descrevendo os Requisitos utilizando HTML 1 <?xml v e r s i o n ="1.0" encoding="utf 8"?> 2 <html xmlns : concordion ="http : / /www. concordion. org /2007/ concordion " 3 lang ="pt BR"> 4 5 <head> 6 <t i t l e >BDD com Concordion </ t i t l e > 7 </head> 8 9 <body> 10 <h1>cadastrar o usuá r i o no sistema com sucesso </h1> 11 <div c l a s s ="example"> 12 <h2>exemplo</h2> 13 <p>dado que o e l e i t o r Jos é da S i l v a d e s e j a acompanhar seu 14 r e p r e s e n t a n t e no governo i g u a l.</p> 15 <p> 16 Quando e l e preencher o formul á r i o de cadastro com o nome de usuá r i o 17 j o s e 18 e a senha 19 d a s i l v a 20 e submet ê l o. 21 </p> 22 <p> 23 Então o sistema deve e x i b i r a s e g u i n t e mensagem : 24 O usuá r i o j o s e com a senha d a s i l v a f o i 25 cadastrado com s u c e s s o. 26 </p> 27 </div> 28 </body> 29 </html> Para deixar o resultado com o visual mais agradável adicione no head do arquivo html um link para a folha de estilo, como está descrito na Figura 14. Baixe o arquivo em e nele você encontrará o arquivo concordion.css com a folha de estilo. Extraia o arquivo CSS em src/test/java. Agora é necessário criar a classe que será o elo entre a especificação feita em html e a aplicação. Para tanto crie na mesma pasta onde você criou o html (src/test/java/spec) a classe CadastroDeUsuarioSpecTest.java. Essa classe será esse elo. É bastante simples codificá-la! Especifique que ela é um runner do Junit e do

35 Capítulo 2. Automatizando os Critérios de aceitação 34 Figura 13: Instrumentando o HTML 1 <p> 2 Quando e l e preencher o formul á r i o de cadastro 3 com o nome de usuá r i o 4 <b concordion : s e t="#u s u a rio "> jose </b> 5 e a senha 6 <b concordion : s e t="#senha"> d a s i l v a </b> 7 e submet ê l o. 8 </p> 9 <p> 10 Então o sistema deve e x i b i r a s e g u i n t e mensagem : 11 <span concordion : a s s e r t E q u a l s =" i n s e r e U s u a r i o (#usuario, #senha )">O 12 usuá r i o j o s e com a senha d a s i l v a 13 f o i cadastrado com sucesso </span> 14 </p> Figura 14: Adicionando a folha de estilo 1 <head> 2 <t i t l e >ATDD com Concordion </ t i t l e > 3 <l i n k r e l =" s t y l e s h e e t " type=" t e x t / c s s " h r e f = ".. / concordion. c s s " /> 4 </head> Concordion com a e crie nela o método insereusuario que recebe como parâmetros um nome de usuário e senha, como descrito na Figura 15. Por enquanto retorne null. Nesse momento fizemos o passo do BDD criar um teste que falhe. Veja o teste falhar executando o comando mvn test. Observe na saída do comando o seguinte: Running spec.cadastrodeusuariospectest target/concordion/spec/cadastrodeusuariospec.html Successes: 0, Failures: 1 Acesse o arquivo html gerado e veja o resultado! Perceba que o Concordion deixa o teste que falhou vermelho e o deixa tachado! Observe a Figura 16. Agora faça o teste passar! Como o Service da aplicação já está desenvolvido e instanciado basta executar o método cadastrar passando o nome de usuário e a senha, e

36 Capítulo 2. Automatizando os Critérios de aceitação 35 Figura 15: Classe elo entre o HTML e a aplicação no teste que falha 1 package spec ; 2 3 import org. concordion. i n t e g r a t i o n. j u n i t 4. ConcordionRunner ; 4 import org. j u n i t. runner. RunWith ; 5 6 import s i t e d o. ph. contacta. s e r v i c e s. U s u a r i o S e r v i c e ; 7 ConcordionRunner. c l a s s ) 9 p u b l i c c l a s s CadastroDeUsuarioSpecTest { p r i v a t e U s u a r i o S e r v i c e s e r v i c e = new U s u a r i o S e r v i c e ( ) ; p u b l i c S t r i n g i n s e r e U s u a r i o ( S t r i n g usuario, S t r i n g senha ) { 14 return n u l l ; 15 } 16 } Figura 16: Teste reprovado no Concordion retornar o resultado da execução do método, como descrito na Figura 17. Pronto! Agora você consegue executar o teste utilizando o JUnit com o Eclipse ou o comando mvn test. Veja o resultado final com o teste passando e o html gerado pelo Concordion, como na Figura 18.

37 Capítulo 2. Automatizando os Critérios de aceitação 36 Figura 17: Classe elo entre o HTML e a aplicação no teste que passa 1 package spec ; 2 3 import org. concordion. i n t e g r a t i o n. j u n i t 4. ConcordionRunner ; 4 import org. j u n i t. runner. RunWith ; 5 6 import s i t e d o. ph. contacta. s e r v i c e s. U s u a r i o S e r v i c e ; 7 ConcordionRunner. c l a s s ) 9 p u b l i c c l a s s CadastroDeUsuarioSpecTest { p r i v a t e U s u a r i o S e r v i c e s e r v i c e = new U s u a r i o S e r v i c e ( ) ; p u b l i c S t r i n g i n s e r e U s u a r i o ( S t r i n g usuario, S t r i n g senha ) { 14 return s e r v i c e. c a d a s t r a r ( usuario, senha ) ; 15 } 16 } Figura 18: Teste aprovado no Concordion 2.4 Cucumber A última ferramenta que será analisada é o Cucumber, especificamente a versão para a linguagem Java, o Cucumber-JVM. Comece preparando o projeto para utilizá-lo, adicione algumas dependências ao pom.xml, como demonstrado na Figura 19.

38 Capítulo 2. Automatizando os Critérios de aceitação 37 Figura 19: Dependências necessárias para utilizar o Cucumber-JVM 1 <dependencies > 2 <dependency> 3 <groupid>i n f o. cukes </groupid> 4 <a r t i f a c t I d >cucumber java </ a r t i f a c t I d > 5 <version >1.1.8 </ version > 6 <scope>t e s t </scope> 7 </dependency> 8 9 <dependency> 10 <groupid>i n f o. cukes </groupid> 11 <a r t i f a c t I d >cucumber j u n i t </ a r t i f a c t I d > 12 <version >1.1.8 </ version > 13 <scope>t e s t </scope> 14 </dependency> <dependency> 17 <groupid>j u n i t </groupid> 18 <a r t i f a c t I d >j u n i t </ a r t i f a c t I d > 19 <version >4.11</ version > 20 <scope>t e s t </scope> 21 </dependency> <dependency> 24 <groupid>i n f o. cukes </groupid> 25 <a r t i f a c t I d >cucumber pro</ a r t i f a c t I d > 26 <version > </ version > 27 <scope>t e s t </scope> 28 </dependency> 29 </dependencies > 30 No Cucumber as features são reunidas em arquivos texto puro com a extensão.feature e essas features podem abrigar diversos cenários. Crie então um arquivo chamado cadastrar_usuarios.feature no source folder de recursos de teste (src/test/resources) dentro do pacote principal da sua aplicação, por exemplo: /sitedo/ph/contacta/. O conteúdo do arquivo está descrito na Figura 20. Semelhante ao JBehave as palavras given..when..then..scenario..feature aqui são importantes! Elas fazem parte da sintaxe e servirão para ligar a especificação à classe de teste. Observe o relatório gerado pela ferramenta para requisitos pendentes - Figura 21 - e requisitos que estão falhando - Figura Agora que o requisito já está especificado no arquivo de feature crie a classe que

39 Capítulo 2. Automatizando os Critérios de aceitação 38 Figura 20: Feature descrita para o Cucumber-JVM 1 Feature : P o s s i b i l i t a r o cadastro de usuá r i o s 2 3 Para obter a c e s s o ao sistema 4 Como um Usuá r i o 5 Desejo preencher um formul á r i o com os dados n e c e s s á r i o s 6 7 Scenario : Cadastrar o usuá r i o no sistema com s u c e s s o 8 Given que o e l e i t o r Jos é da S i l v a d e s e j a acompanhar seu r e p r e s e n t a n t e no governo 9 When e l e preencher o formul á r i o de cadastro com o nome de usuá r i o jose e a senha d a s i l v a e submet ê l o 10 Then o sistema deve e x i b i r a s e g u i n t e mensagem : "O usuá r i o j o s e com a senha d a s i l v a f o i cadastrado com s u c e s s o " 11 Figura 21: Relatório gerado pelo Cucumber com os testes pendentes Figura 22: Relatório gerado pelo Cucumber com os testes falhando vai executar essas especificações, sendo a cola entre o arquivo texto puro e a aplicação. A Figura 23 descreve como implementar essa classe. Perceba que o próprio Cucumber pegará o texto na especificação de requisito e

40 Capítulo 2. Automatizando os Critérios de aceitação 39 Figura 23: Classe de Instrumentação para o Cucumber-JVM 1 package s i t e d o. ph. contacta ; 2 3 import s t a t i c org. f e s t. a s s e r t i o n s. A s s e r t i o n s. assertthat ; 4 import s i t e d o. ph. contacta. s e r v i c e s. U s u a r i o S e r v i c e ; 5 import cucumber. api. java. pt. Dado ; 6 import cucumber. api. java. pt. Então ; 7 import cucumber. api. java. pt. Quando ; 8 9 p u b l i c c l a s s CadastrarUsuariosStep { p r i v a t e S t r i n g mensagemexibida ; 12 que o e l e i t o r Jos é da S i l v a d e s e j a acompanhar seu r e p r e s e n t a n t e no governo$ " ) 14 p u b l i c void que_o_eleitor_jos é _da_silva_deseja_acomp_seu_representante ( ) 15 throws Throwable { 16 } 17 e l e preencher o formul á r i o de cadastro com o nome de usuá r i o (.+) e a senha (.+) e submet ê l o $ " ) 19 p u b l i c void ele_preencher_o_formul ário_e_submet ê _lo ( S t r i n g usuario, S t r i n g senha ) 20 throws Throwable { U s u a r i o S e r v i c e u s u a r i o S e r v i c e = new U s u a r i o S e r v i c e ( ) ; 23 mensagemexibida = u s u a r i o S e r v i c e. c a d a s t r a r ( usuario, 24 senha ) ; 25 } 26 ("^ o sistema deve e x i b i r a s e g u i n t e mensagem : " (. + ) " $ " ) 28 p u b l i c void o_sistema_deve_exibir_a_seguinte_mensagem ( S t r i n g mensagem ) 29 throws Throwable { assertthat ( mensagem ). isequalto ( mensagemexibida ) ; 32 } 33 } converterá nos argumentos para a execução dos métodos. Agora o requisito já foi implementado corretamente e já é possível ver o teste

41 Capítulo 2. Automatizando os Critérios de aceitação 40 passando! Para tanto execute o comando mvn clean install e abra no browser o arquivo index.html que foi criado no diretório target/cucumber/ que deve ser semelhante à Figura 24. Figura 24: Relatório gerado pelo Cucumber com os testes passando 2.5 Comparação entre as ferramentas Nesse capítulo serão enumerados os pontos positivos e negativos de cada uma das ferramentas analisadas JBehave e Thucydides Pontos Positivos a) Os requisitos são descritos em texto puro e o analista não precisa conhecer HTML; b) O programador não precisa alterar nada nos requisitos para poder implementálo; c) A instrumentação é feita direta no código Java; d) O relatório gerado pelo Thucydides é bem completo e gerá gráficos interessantes para o acompanhamento do desenvolvimento; Pontos Negativos a) O analista de negócio terá que se adequar ao formato pré-definido dos requisitos; b) Das três abordagens essa é a mais complicada de configurar para utilização; c) Apesar do JBehave permitir utilizar palavras chaves em outros idiomas o Thucydides ainda não interpreta corretamente essas palavras-chaves em outros idiomas;

42 Capítulo 2. Automatizando os Critérios de aceitação Concordion Pontos Positivos a) Não é necessário seguir uma sintaxe, os requisitos podem ser descritos de forma livre; b) O relatório final demonstra exatamente o que está falhando; c) Como não existe uma sintaxe própria os requisitos podem ser escritos em qualquer idioma; Pontos Negativos a) O analista de requisito precisa conhecer HTML; b) O refactor automático feito pela IDE não irá funcionar no HTML; c) Às vezes o programador precisará alterar os requisitos para instrumentá-lo para o teste automatizado; Cucumber Pontos Positivos a) Os requisitos são descritos em texto puro e o analista não precisa conhecer HTML; b) O programador não precisa alterar nada nos requisitos para poder implementálo; c) A instrumentação é feita direta no código Java; d) Suporta palavras-chaves em diversos idiomas; e) Existe um plugin para a integração com o servidor de integração contínua Jenkins; Pontos Negativos a) O analista de negócio terá que se adequar ao formato pré-definido dos requisitos; b) Não é simples personalizar o relatório. Até existe um plugin do maven com um relatório melhorado mas ele só funciona para palavras-chaves em inglês;

43 42 3 Vantagens da utilização do BDD Não existem muitos estudos analisando a utilização do BDD e o impacto disso na qualidade do software. O que se encontra são estudos a respeito da utilização do TDD - Test-Driven Development -, como o BDD é uma evolução do TDD então esse artigo vai expor o que alguns estudos tem apontado em relação aos impactos do TDD na qualidade do software. Um artigo recente - Munir et al. (2014) - já reúne os estudos mais relevantes sobre o assunto. Ele estatui que existem diversos motivos para a adoção do TDD no desenvolvimento ágil. Primeiro ele permite que o desenvolvedor pense além da funcionalidade antes de escrever o código. Segundo ele garante que o desenvolvedor já terá testes para validar o seu trabalho. Terceiro o TDD permite que o código seja refatorado antecipadamente e mantém a maior qualidade possível do código. Além disso ele previne a introdução de novos bugs e ajuda facilitando a manutenção contínua do software por executar constantemente casos de teste automatizados. Ainda segundo Munir et al. (2014) a maioria das evidências relatadas a respeito do TDD pertencem aos seguintes aspectos da engenharia de software: 1 - Qualidade interna do código, 2 - Qualidade externa do código, e 3 - Produtividade. Pontos importantes nos resultados agrupados por Munir et al. (2014) são: a) O TDD ou o TLD - Test-Last Development - não aceleram o processo de implementação; b) O TDD demonstra evidências de códigos fontes mais legíveis e manuteníveis quando comparado com o TLD; c) O TDD não impacta negativamente a produtividade da equipe! d) Segundo um estudo feito na IBM (MAXIMILIEN; WILLIAMS, 2003) a taxa de defeitos foi reduzida a 50% quando comparada com sistemas similares utilizando metodologia de teste tradicional; e) A suíte de teste desenvolvida durante o TDD é reutilizável e um recurso extensível que ajuda a aumentar a qualidade do código durante todo o ciclo de vida do software; Ainda segundo Munir et al. (2014) existem diversos artigos que apresentam vantagens na utilização do TDD mas que não apresentam estatísticas que validem as vantagens apresentadas. Apenas um dos artigos pesquisado por ele está bem embasado do ponto de

44 Capítulo 3. Vantagens da utilização do BDD 43 vista da estatística. Munir conclui que apesar de ter encontrado dados positivos em favor do TDD ele não conseguiu poder estatístico suficiente para comprovar as hipóteses elencadas.

45 44 Conclusão O BDD nasceu da necessidade de simplificar o desenvolvimento de software guiado por testes e posteriormente foi acrescido com técnicas para o levantamento de requisitos e automatização de testes de aceitação. No decorrer do artigo foi explicitado passo a passo como utilizar o BDD desde o levantamento dos requisitos até a automatização dos critérios de aceitação em diversas ferramentas. Dentre as ferramentas o melhor relatório é o gerado pelo Thucydides mas sua configuração é cheia de detalhes e bastante complicada quando comparada com as outras ferramentas, além disso, para que o relatório seja gerado, o Thucydides exige que as palavras-chaves estejam em inglês. O Concordion é simples de configurar e cada requisito gera uma página simples, muito agradável e explicita sobre a execução dos testes, ele não gera um overview do projeto mas permite a descrição dos requisitos de forma livre e em qualquer idioma, o que é excelente, porém exige que o analista de requisitos entenda um pouco de HTML para escrever o requisito. Por fim o Cucumber possui a configuração ainda mais simples que o Concordion, suporta a utilização das palavras chaves em diversos idiomas, gera um overview do projeto e os requisitos são escritos em formato texto puro, sem exigir que o analista entenda sobre o HTML. Foi feita uma pesquisa bibliográfica para verificar o impacto do uso do BDD e TDD na qualidade de software em comparação com outras metodologias. Não foi encontrado muitos estudos sobre o BDD. Foram encontrados alguns que analisavam o TDD e resolveuse utilizá-los por conta do BDD ser uma evolução do TDD com utilização das mesmas técnicas. Em relação ao resultado encontrado pelos referênciais bibliográficos pesquisados ainda não existe nenhum deles com poder estatístico suficiente para comprovar o impacto positivo da utilização do TDD na qualidade do software ou na performance da equipe. O que existe de excelente na utilização do BDD/TDD do ponto de vista do material pesquisado é que não existe um impacto negativo na performance da equipe que utiliza TDD. O que foi observado é que independente da metodologia as equipes tem alcançado a mesma performance, derrubando por terra o mito de que equipes que primeiro desenvolvem testes são menos performáticas. Outras vantagens são apontadas: a suíte de testes automatizados quando se utiliza TDD; o código fonte em diversos artigos teve mais qualidade e apresentou menos defeitos; a equipe entende mais dos requisitos; o código fica mais legível e manutenível; Não existe motivo que contra-indique a utilização do desenvolvimento guiado por

46 Conclusão 45 comportamento ou por testes (BDD/TDD) - equipes que utilizam essas metodologias não são menos performáticas que as que não utilizam e o tempo gasto desenvolvendo testes é reaproveitado por conta da suíte de testes gerada - por isso acredita-se que essa seja uma excelente metodologia para a utilização no processo de engenharia e desenvolvimento de software.

47 46 Referências GÄRTNER, M. ATDD by Example: A Practical Guide to Acceptance Test-Driven Development. Pearson Education, (Addison-Wesley Signature Series (Beck)). ISBN Disponível em: < Citado na página 18. MAXIMILIEN, E. M.; WILLIAMS, L. Assessing test-driven development at ibm. In: Proceedings of the 25th International Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, (ICSE 03), p ISBN X. Disponível em: < Citado na página 42. MUNIR, H. et al. An experimental evaluation of test driven development vs. test-last development with industry professionals. In: Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering. New York, NY, USA: ACM, (EASE 14), p. 50:1 50:10. ISBN Disponível em: < Citado na página 42. SABBAGH, R. Scrum: Gestão Ágil para Projetos de Sucesso. 1a edição. ed. [S.l.]: Casa do Código, ISBN 978* Citado na página 13. SMART, J. F. BDD in Action: Behavior-driven development for the whole software lifecycle. [S.l.]: Manning Publications, Citado 8 vezes nas páginas 13, 14, 15, 16, 17, 18, 19 e 21.