Behavior Driven Development

Behavior Driven Development (BDD) ou ainda uma tradução livre Desenvolvimento Guiado por Comportamento é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não técnicas ou de negócios num projeto de software. Foi originalmente concebido em 2003, por Dan North [1]como uma resposta à TDD, e tem se expandido bastante nos últimos anos (Behavior Driven Development, 2012). No BDD, os testes de aceitação são descritos em linguagens naturais próximas do domínio do negócio usando DSL. Para estes testes de aceitação são usadas DSTL e se estes possuírem formalidade suficiente podem ser interpretados e executados por uma ferramenta especializada (CAETANO, 2012). Os testes descritos em linguagem natural são interpretados por ferramentas especializadas que, por sua vez, exercitam o código/API do sistema para demonstrar se o comportamento foi atendido.

O BDD pode ser visto como uma evolução da técnica de programação TDD [ (AL., 2009), e compartilha com essa técnica a característica principal de se escrever testes antes de escrever a implementação do que está sendo testado, para então desenvolvê-la até que o teste passe. (RIMMER, 2010) mostra que outra forma de se ver o BDD é como uma nova compreensão sobre o processo de TDD que estabelece que o teste não é o ponto central real da técnica, mas sim a descoberta e compreensão, através da definição dos testes, do comportamento que está se querendo obter com um código. O processo de BDD incrementa o TDD de forma a resolver algumas questões em aberto com as seguintes práticas: cada funcionalidade deve ser claramente compreendida por ambas partes (desenvolvedores e clientes), para isso se deve usar uma linguagem para os casos de teste compreensível a ambas partes, uma vez que os casos de teste são na realidade especificações de comportamento; cada funcionalidade deve possuir um valor claro e verificável para o negócio, de modo a priorizar o mais importante e evitar o que pode não vir a ser necessário; deve-se planejar a frente o mínimo possível, escrevendo testes para o menor e mais prioritário subconjunto de funcionalidades possível e o desenvolvendo antes de adicionar mais funcionalidades (AL., 2009).

O foco em BDD é a linguagem e interações usadas no processo de desenvolvimento de software. O BDD propicia o uso da língua nativa, a linguagem natural, em combinação com a linguagem ubíqua (usada no processo de desenvolvimento de software) permitindo que os desenvolvedores foquem em por que o código deve ser criado, ao invés de detalhes técnicos minimizando assim, traduções entre linguagem técnica na qual o código é escrito e outras linguagens de domínio, usuários, clientes, gerência do projeto, etc. (NORTH, 2006).

As práticas de BDD incluem:

●       Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora pra Dentro)

●       Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código

●       Automatizar os exemplos para prover um feedback rápido e testes de regressão

●   Usar deve (should em inglês) na hora de descrever o comportamento de software para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas

●     Usar dublês de teste [2](mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos

BDD é guiado pelos valores de negócios; que é o benefício trazido para o negócio no qual a aplicação está sendo produzida. A única maneira na qual o benefício pode ser percebido é através de interfaces de usuário para a aplicação, comumente (mas nem sempre) a interface gráfica de usuário. Da mesma maneira, cada trecho de código, começando com a interface de usuário, pode ser considerado como sendo um cliente de outros módulos de código no qual a interface é utilizada. Cada elemento de código provê algum comportamento, o qual em colaboração com outros elementos provê o comportamento da aplicação. A primeira parte de código de produção que os desenvolvedores que usam BDD implementam é a interface de usuário, pois dessa maneira os desenvolvedores podem se beneficiar com um feedback rápido para saber se a interface está adequada ou não. Através de código, e usando princípios de design e refatoração, desenvolvedores descobrem colaboradores para a interface de usuário, e posteriormente para cada unidade de código. Isso os ajuda a aderirem o princípio de YAGNI, desde que cada trecho de código de produção é requerido pelos negócios ou por outro trecho de código já escrito (Behavior Driven Development, 2012).

Devido ao impacto da aplicação de BDD no projeto como um todo ele se tornou uma metodologia ágil de segunda geração. (Primeira geração, Scrum, XP. Segunda geração BDD). Segundo (CHELIMSKY, ASTELS, et al., 2010) o desenvolvimento guiado por comportamento se baseia em três princípios básicos:

●       O bastante é o bastante: Planejamento antecipado, análise, e design são atividades que possuem um retorno decrescente. Não deve-se fazer menos do que o necessário para iniciar o projeto, porém, mais do que isso é desperdício de esforço. Isso também se aplica à automação do processo. Ter um processo de implantação do sistema e testes automatizados é importante, mas deve-se evitar automatizar tudo.

●       Entregar valor aos stakeholders: Se uma atividade não está entregando valor ou melhorando a capacidade de entregar valor, então não se deve executá-la e deve-se focar em outra atividade.

●       Tudo é comportamento: Não importa se ao nível de código, à nível de aplicação, ou além, pode-se utilizar o mesmo pensamento e construção linguística para quaisquer níveis de granularidade.

Defensores de BDD alegam que o uso de "deve" (should) e "garantirQue" (ensureThat) em exemplos de BDD incentivam os desenvolvedores a questionarem se as responsabilidade que eles estão atribuindo aos seus objetos são apropriados, ou se elas podem ser delegadas ou movidas inteiramente para outros objetos. Um objeto que é mais simples que o código de colaboração e provê a mesma interface, porém com um comportamento mais previsível, pode ser injetado no código que precisa dele, e os exemplos de comportamento do código podem ser escrito usando estes objetos ao invés da versão de produção.

A palavra-chave para este tipo de técnica é "especificação executável” baseada no comportamento da aplicação. Especificações executáveis ​​têm muito mais chance de não serem abandonas, já escrevê-las, ao contrário de escrever estática não executável e tradicional documentação, torna-se efetivamente parte de todo o processo de desenvolvimento. Executando estas especificações é possível visualizar instantaneamente o que realmente o software em questão faz, enquanto no momento em que se inspeciona o código fonte é revelado somente o que este supostamente deveria realizar. Trazendo á tona um benefício desta prática, gerando para uma equipe praticante uma maior confiança em relação ao trabalho que está sendo desenvolvido

---

[1] Ativista da causa Ágil. Mais informações em: http://dannorth.net/

[2] Mais informações em: http://martinfowler.com/articles/mocksArentStubs.html

Testes Ágeis

A maioria dos métodos ágeis tenta delimitar e reduzir o risco pelo desenvolvimento do software em curtos períodos, denominados iterações, os quais despendem menos de uma semana de tempo a um máximo de quatro semanas, sendo que cada iteração é como um projeto de software em pequena escala do projeto principal, e inclui em si todas as tarefas necessárias para implantar um mini-incremento de uma nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação (Desenvolvimento ágil de software, 2005). Enquanto em um processo convencional cada iteração não está necessariamente focando em adicionar um conjunto de funcionalidades, um projeto de software com metodologia ágil busca a capacidade de implantar uma versão nova do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.

Pressman denota a filosofia do método ágil para desenvolvimento de software da seguinte forma:

 “A engenharia de software ágil combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfação do cliente e a entrega incremental do software logo de início; equipes de projeto pequenas, altamente motivadas, métodos informais, produtos de trabalho de engenharia de software mínimos e simplicidade global de desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto (apesar dessas atividades não serem desencorajadas) e a comunicação ativa entre desenvolvedores e clientes” (PRESSMAN, 2002)

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente in loco, em vez de documentação escrita. A maioria dos stakeholders de um grupo ágil deve estar agrupada em uma sala. Isso inclui todos aqueles necessários para terminar o software: no mínimo, os programadores, gerentes e/ou analistas de negócio e seus clientes. Nesta sala devem também se encontrar os testadores e projetistas. Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos (Desenvolvimento ágil de software, 2005). É recomendada apenas a produção de documentação que realmente será útil.

Segundo (NADALETE, 2010) em se tratando de desenvolvimento ágil, alguns princípios definidos por meio do Manifesto Ágil são utilizados com o objetivo de nortear a linha de produção, como:

●       Indivíduos e interações entre eles mais que processos e ferramentas;

●       Software em funcionamento mais que documentação abrangente;

●       Colaboração com o cliente mais que negociação de contratos;

●       Capacidade de responder a mudanças mais que seguir um plano.

Os mesmos princípios usados para direcionar o desenvolvimento ágil, devem ser considerados quando for aplicado teste ágil, ou seja, testar de forma ágil exige uma forte adaptação na rotina e dinâmica da equipe de teste, em relação ao processo de desenvolvimento adotado, com o objetivo de propiciar um processo relativamente simples e que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com um nível de qualidade que seja apreciada e valorizada pelo cliente ou usuário final (NADALETE, 2010).

Afirma (LEAL, 2009) que os requisitos para metodologias de teste para processos ágeis não possuem grande diferenciação em relação processos guiados por planos. O que é diferente é o grau de importância atribuído aos testes em cada um dos processos. Nos processos guiados por planos, existe uma extensa série de artefatos documentais resultantes de uma análise profunda sobre o sistema a ser desenvolvido. Sendo assim testes são utilizados nesse caso apenas como mais um artefato produzido pelo processo visando garantir a detecção de erros antes da liberação da versão final

Segundo análise comparativa realizada por (NETO, 2004) tomando como base os documentos gerados na etapa de testes o RUP orientado para pequenos projetos gera apenas um único documento que é o Modelo de Testes, já a XP gera quatro, que são os Testes de Aceitação, Testes de Dados, Testes de Resultados e Unidades de Testes (KENT, 1999).   Esses quatro documentos gerados na programação extrema são englobados num único documento no Processo Unificado da Rational, fazendo com que este artefato se torne extenso e abrangente, porém sendo tratado como único (KRUCHTEN, 2000)

Reitera (MÁRIO, 2009) que no processo XP antes do desenvolvimento do código, recomenda o processo, que se crie uma bateria de testes unitários para que a história fique satisfeita. Então o foco dos programadores é a satisfação destes testes unitários. Para a codificação o XP, recomenda que esta seja feita em pares, isto garante outros aspectos como qualidade, e rapidez. Os testes unitários são mantidos ao longo das várias iterações e passam a fazer parte de uma bateria de testes de regressão, que não é mais do que todos os testes unitários agrupados para serem testados periodicamente de uma vez em períodos curtos. A ideia é confirmar que nada deixou de funcionar. Os clientes são considerados parte da equipe de desenvolvimento, uma vez que a todo o momento são questionados sobre prioridades e testes de versões.

Ressalta-se que muitos métodos ágeis, como Lean, Scrum e XP recomendam que todas as pessoas de um projeto (programadores, gerentes, equipes de homologação e até mesmo os clientes) trabalhem controlando a qualidade do produto todos os dias e a todo o momento, pois acreditam que prevenir defeitos é mais fácil e barato que identificá-los e corrigi-los. A Programação eXtrema, em particular, recomenda explicitamente testes automatizados para ajudar a garantir a qualidade dos sistemas de software (BERNARDO, 2008). Através da definição do processo ideal e simplificado, onde o teste ágil é suportado, um conjunto de práticas que proporcionem a diminuição do tempo entre o erro e a sua descoberta tende a ser estabelecidos em conjunto com uma sistemática de trabalho que possibilite à área de teste de software ser mais proativa do que reativa.

Analisemos algumas das práticas do processo de teste tradicional aplicados na tentativa de gerenciar o "chaos", ou ao menos evitar culpados (HENDRICKSON, 2006).

●       A área de teste de software assumindo a postura de "Último Defensor da Qualidade";

●       Restrições no gerenciamento de mudanças;

●       Preparação detalhada e planejamento acima de tudo;

●       Conjunto de documentação pesado para a terceirização dos esforços de teste;

●       Critérios de entrada e saída rigorosos e com aprovações;

●       Automatização de testes pesada e com foco nas regressões;

●       Tentativas de execução do processo.

Ao se tratar de teste ágil, essas mesmas práticas não se adaptam à dinâmica almejada. Em um ambiente ágil de controle de qualidade devem-se considerar os prazos e as atividades de teste do começo ao fim da iteração (NADALETE, 2010). Ao contrário do teste tradicional, não se espera que uma única equipe se responsabilize pela qualidade final das entregas, mas sim que todas as equipes tenham sua colaboração no controle dessa qualidade, desde o levantamento das necessidades do cliente, até a implantação do produto final gerado.

 Ainda afirma que no teste tradicional, espera-se que os defeitos sejam identificados no último nível, pela equipe de QA, enquanto que ao se aplicar teste ágil, isso é antecipado pela própria equipe de desenvolvimento por meio de práticas como desenvolvimento em pares, integração contínua, pequenas entregas, refatoração constante e padrões de codificação, de técnicas como TDD (Test Driven Development) e ATDD (Acceptance Test Driven Development), e através da automatização dos testes gerados. Ao se trabalhar com testes ágeis, (NADALETE, 2010) observa algumas mudanças de conceito em relação ao modelo tradicional, tais como:

•     Mudanças são inevitáveis, e com base nisso toda equipe, incluindo os programadores, testadores e clientes, são responsáveis pelo resultado final;
•          Todos da equipe devem estar acessíveis e se comunicando ativamente através do projeto;
•          O teste de software se torna mais preventivo, ou seja, programadores testam mais cedo, com mais frequência e agressivamente. Neste ponto a prática de TDD pode e deve ser aplicada;
•          Toda equipe solicita ativamente feedback das demais;
•        Testadores e programadores tendem a ser mais proativos (participação direta com o cliente) e técnicos (aplicação de práticas XP e técnicas como TDD e ATDD);
•          Testadores precisam saber automatizar, com o intuito de manter o ciclo de entregas dos testes sempre no prazo estabelecido e com teste de regressão atualizado. Só não se automatiza o que realmente não pode ser automatizado ou não vale a pena ser automatizado (e.g. Teste de Usabilidade);
•          Os testes tonam-se uma rotina que nasce e morre junto à iteração planejada.

Specification By Example

Terminologia e Definição

O termo Specification by Example (Especificação por Exemplos) surgiu segundo seu criador Gojko Adzik (2011) com o intuíto de unificar em um só termo as seguintes técnicas, metodologias e práticas ágeis:

• Agile acceptance testing
• Test-Driven Development
• Acceptance Test-Driven Development
• Example-Driven Development
• Story testing
• Behavior-Driven Development

Segundo Gojko o fato de as mesmas práticas possuírem tantos nomes diferentes reflete o grande número de inovações nesse campo no cenário atual da industria de software. Sobre essas diferentes nomenclaturas Gojko afirma:

Se queremos os usuários finais (stakeholders) mais envolvidos, o que é o principal objetivo dessas práticas, precisamos usar os nomes corretos para as coisas corretas e parar de confundir as pessoas.

O autor decidiu por tanto simplificar essa terminologia na comunidade de software para que as pessoas possam usufruir de seus benefícios sem entrarem em discuções improdutivas sobre terminologias. Specification by Example é o resultado de um conjunto de estudos de caso realizados por Gojko com mais de 50 projetos de desenvolvimento de software do mundo real. Projetos que variam em tecnologia (de websites a softwares para desktop) e em metodologias (Extreme Programing, Scrum, Kanban e outras metodologias normalmente agrupadas sobre os termos agile e lean). Specification by Example pode ser definido como um suplemento de práticas que podem ser incorporadas a qualquer metodologia de desenvolvimento atual.

Necessidade

Construir o produto certo e construir certo o produto são dois objetivos distindos. Porém os dois são necessários para se obter sucesso. Segundo Gojko tradicionalmente, construir o produto certo requeria enormes especificações funcionais, documentação e longos ciclos de teste, atualmente em um mundo de releases semanais isso não funciona. Ainda segundo Gjko é necessário uma solução para:

• Evitar super-especificações inúteis; Evitar gastar tempo em detalhes que mudarão antes do primeiro fragmento de trabalho ser desenvolvido.
• Ter documentos legíveis que explicam oque o sistema faz para que se posso modificá-lo facilmente.
• Checar de maneira eficiente que o sistema faz o que as especificações dizem.
• Manter a documentação relevante e confiável com o menor custo de manutenção.
• Colocar tudo isso em processos baseados em iterações, de forma que a informação do trabalho a ser feito é produzida sob demanda.

Specification by Example unificou padrões e processos que times do mundo real utilizaram para atingir esses objetivos.

Padrões de processo

Os padrões estabelecidos por Specification by Example são assim denominados no sentido em que eles são elementos recorrentes usados por diferentes times; São resultados de uma série de experimentos empíricos com projetos e times reais e não de um modelo teórico de elaboração de processos.

Figura 1. Principais padrões de processo de Specification by Example.

1. Deriving scope from goals (Derivando o escopo dos objetivos): Nessa etapa a equipe que criará o software deve derivar os escopos de desenvolvimento a partir dos objetivos estabelecidos pelos stakeholders. Segundo Gojko é um erro esperar que os usuários envolvidos digam qual o escopo de desenvolvimento pois os mesmos não são designers de software. O mais apropriado nessa etapa é elencar os objetivos que os stakeholders querem atingir com o software em questão. Em outras palavras, qual ou quais os problemas que a “solução” deve ser capaz de resolver. Começa-se com um objetivo de negócios o time de desenvolvimento colabora definindo o escopo que vai atingir este objetivo.

2. Specifying collaboratively (Especificando colaborativamente): O time nesse etapa deverá juntamente com os stakeholders especificar colaborativamente o comportamento esperado para cada funcionalidade do escopo. Desenvolvedores, testadores e analista de negócios devem participar nessa etapa pois cada um tem um contexto único e habilidades que podem ajudar a resolver questões que de outra forma poderiam passar desapercebidas gerando re-trabalho no futuro.

3. Illustrating using examples (Ilustrando utilizando exemplos): Ao invés de esperar que as especificações sejam expressadas precisamente em uma linguagem de programação durante a implementação, deve-se ilustrar o comportamento  esperado do sistema utilizando exemplos antes do desenvolvimento ser iniciado. O time de desenvolvimento trabalha com os stakeholders para identificar exemplos-chave que descrevem a funcionalidade esperada. Desenvolvedores e testadores dão exemplos adicionais que revelam áreas antes ignoradas da funcionalidade evitando assim gaps funcionais e faz com que todos tenham um conhecimento distribuído sobre aquilo que precisam entregar.

4. Refining the specification (Refinando a especificação): Nessa etapa o time de desenvolvimento deve remover informações irrelevantes dos exemplos tais como detalhes que tornam os exemplos extensos e verbosos sem adicionar informações úteis. Segundo Gjko deve-se identificar o que o software deve fazer e não detalhar o como fazer. Os resultados dessa etapa podem ser considerados critérios de aceitação, que ao mesmo tempo são especificações para o desenvolvimento e futuramente quando automatizados farão parte dos testes de regressão.

5. Automating validation without changing specifications (Automatizando as validações sem modificar as especificações): Com os exemplos especificados e refinados o time pode usá-los como meio de validar o produto. O sistema será validado diversas vezes durante o desenvolvimento para assegurar que o mesmo atinge os objetivos. Rodar essas validações manualmente introduziria um delay desnecessário e o feedback seria lento. A solução para isto é automatizar as validações, porém essa automação deve também ser acessível aos stakeholders e não deve modificar as especificações originais. O time de desenvolvimento literalmente deve escrever a automação com as mesmas palavras utilizadas para criarem os exemplos, pois scripts e código fonte não têm a capacidadade de contar expressar adequadamente o contexto de negócio em que estão inseridos e documentação puramente textual fica desatualizada rapidamente. Portanto nessa etapa a validação automática do sistema, suas especificações por exemplos e seus critérios de aceitação tornam-se um só. O resultado dessa etapa gera especificações executáveis.  

6. Validating Frequently (Validando frequentemente): Gjko afirma que a documentação tradicional de software fica desatualizada antes mesmo de o sitema ser lançado. A validação frequente é um produto das especificações executáveis ela sincroniza o que foi especificado com o que o sistema realmente está fazendo.

7. Evolving a documentation system (Evolução de um sistema de documentação): Nessa etapa o time de desenvolvimento mantém a documentação viva (especificações executáveis - testes) atualizada com as modificações requisitadas pelos stakeholders para incrementar o software. As especificações e testes estando em um mesmo lugar facilitam essa mudança pois concentram os esforços em apenas uma fonte de informações. Desenvolvedores utilizam essa documentação como especificações, testadores utilizam como testes e os analistas de negócio utilizam para avaliar o impácto que uma mudança ou especificação futura pode ter no sistema.

Os exemplos são tratados como fonte única de verdade, sendo este um aspecto chave desta metodologia. Desta forma, evita que diferentes colaboradores de uma equipe de desenvolvimento gerem e trabalhem somente em seus próprios documentos. Neste contexto, pode-se afirmar que a eficácia da entrega do software é significativamente afetada pela constante necessidade de coordenação e sincronização destas diferentes “versões da verdade”. Fazendo uso de SbE todos os membro da equipe participam da criação da única fonte de verdade, sendo assim nela encontra-se a compreensão de todos. Estes exemplos são utilizados para proporcionar precisão e clareza, para fazer uso desta informação tanto como uma especificação como um teste funcional. Qualquer informação considerada relevante durante o ciclo de desenvolvimento é adicionada a esta fonte de exemplos única, sem requerer qualquer necessidade de tradução ou interpretação.

Documentação Viva

Segundo Gojko a questão da documentação gerada pelo Specification by Example advém parte do ATTD e parte do BDD, ambas com focos diferentes que quando unidas proporcionam uma totalidade na cobertura e profundidades acerca das especificações do sistema. O ATTD detém seu foco na automação dos testes funcionais, de regressão e são alvos mais claros para o desenvolvimento. O ATDD é mais útil para a adoção inicial quando se tem muitos problemas relacionados a qualidade funcional do sistema. Já o BDD centra-se no processo de especificação de cenários por meio do comportamento do sistema, podendo servir como base para fundamentar as atividades de entrega de software, a médio e curto prazo. O BDD centra-se na construção do entendimento comum entre as partes interessadas através da colaboração e esclarecimento de especificações. É necessário saber o que um sistema faz para ser capaz de analisar os impactos das mudanças sugeridas, apoiá-lo, e solucionar problemas. Muitas vezes, a única maneira de descobrir o que o sistema faz é olhar para o código-fonte da linguagem de programação e aplicar engenharia reversa na funcionalidade do negócio. Logo uma boa documentação é útil para além do desenvolvimento de software. 
A solução ideal seria um sistema de documentação que é fácil e barato de manter, de forma que ele possa ser mantido de acordo com a funcionalidade do sistema, mesmo se o código da linguagem de programação subjacente é alterado com frequência. O problema com qualquer tipo de documentação completa é, de fato, o custo de manutenção. Quando um sistema de software é continuamente validado contra um conjunto de especificações executáveis, uma equipe pode estar certa de que o sistema irá fazer o que as especificações dizem, ou, em outras palavras, que as especificações vão continuar a descrever o que o sistema faz. Essas especificações vivem com o sistema, e elas são sempre consistentes, e pelo fato da noção das diferenças entre as especificações e a funcionalidade de fato implementada de forma imediata, esta documentação pode ser mantida consistente a um baixo custo. Estas especificações executáveis ​​criam um corpo robusto de documentação, uma fonte autorizada e não ambígua de informações sobre a funcionalidade de um sistema,fazendo uma analogia, cada uma das especificações seriam como páginas do livro que é o próprio sistema de documentação viva. 
Gojko ainda afirma que a documentação viva substitui todos os artefatos que as equipes precisam para entregar o produto certo, ela pode até mesmo apoiar a produção de manuais de usuários (embora provavelmente não substituí-los). As especificações são definidas conforme e concomitante a evolução do sistema, a documentação resultante é incremental e assim torna-se barata de escrever. Ao mesmo tempo em que os processos de negócio são derivados é possível executá-los exercitando e auxiliando o processo de desenvolvimento do software, já que se trata de algo mais leve e intrinsecamente mais ligado ao código real, é uma documentação real. Aplicar Specification by Example somente pelo fato do ganho por meio dos testes de regressão acaba por não justificar o investimento feito em longo prazo para implementá-lo já que conforme as estimativas dos custos de software, aponta que a eficiência na remoção dos defeitos por meio de testes de regressão é de 23% em média. Esta prática permite a criação de documentação viva sem necessidade de anos de prática pela sua forma mais natural de escrita, criando documentação por meio de especificações executáveis.

Figura 2 Tipo de documentação que deve ser escrita

A documentação viva é tão importante quanto o sistema que se está entregando, a ideia de que a documentação é um produto chave é o cerne deste método. Algumas vantagens em ter uma documentação viva são apontadas por Gojko: 

• Ajuda as equipes a longo prazo  evitando os problemas mais comuns com manutenção;
•  Ajuda as equipes a criarem documentação útil que irá facilitar a evolução do software ao longo do tempo;
•  Ajuda a evitar problemas de manutenção causados ​​pela falta de conhecimento compartilhado.

Como o Cucumber Funciona

O cucumber é uma ferramenta de linha de comando. Seu módo de funcionamento e suas camadas operam basicamente da seguinte forma:

Camada de negócios

1. O Cucumber lê as especificações escritas em arquivos de texto plano chamados features;
2. Examina esse tipo de arquivos a procura de scenarios;
3. Cada scenario é uma lista de steps que o Cucumber irá tentar executar;
4. Cada step é escrito em linguagem natural de domínio da aplicação. Para que sejam facilmente lidos e interpretados por pessoas sem a necessidade de qualquer conhecimento técnico;

Camada de tecnologia

1. Para realizar quaisquer ações os steps# precisam estar implementados em um arquivo separado chamado de  step definition;
2. A implementação dos steps dentro dos steps definitions é realizada através do support code ou código de suporte, que pode ser escrito em uma variada gama de linguagens¹;
3. O support code é o responsável por se encarregar das tarefas de automação, normalmente isso envolve uma automation library ou biblioteca de automação que então entrará em contato direto com o sistema alvo do teste.

Essa hierarquia de camadas pode ser melhor observada na figura 1.0.

Figura 1.0. Pilha de funcionamento do cucumber.

Gherkin

O padrão de escrita chamado Gherkin nasceu da necessidade  de expressar de forma clara o comportamento esperado das funcionalidades que os stakeholders esperam do sistema utilizando exemplos.

“O Gherkin fornece uma estrutura leve para documentar os exemplos de comportamento que os stakeholders querem.”  

Mesmo o Gherkin podendo ser similar a uma linguagem de programação o seu principal objetivo é ser legível para humanos, isto significa que, é possível escrever testes automatizados que podem ser lidos como documentação tais como no exemplo a seguir:

Funcionalidade: Retirar dinheiro do caixa eletrônico

Cenário: Retirando dinheiro de uma conta com crédito

Dado uma conta contendo R$ 100,00

Quando eu requisito $ 49,00

Então o caixa deve liberar o valor de $ 49,00

E o saldo restante deve ser R$ 51,00

Exemplo de cenário escrito com Gherkin.

O Gherkin também foi traduzido para mais de quarenta idiomas bastando para isso utilizar as palavras-chave (em negrito no exemplo anterior) equivalentes no idioma desejado.

Formato e Sintaxe

Os arquivos Gherkin usam a extensão .feature e são salvos em texto plano, isto significa que eles podem ser lidos e editados por ferramentas simples. A estrutura de um arquivo Gherkin é estabelecida pelas seguintes palavras-chave (com seus equivalentes em português):

• Feature, Funcionalidade.
• Background, Contexto.
• Scenario, Cenário.
• Given, Dado.
• When, Quando.
• Then, Então.
• And, E.
• But, Mas.
• *.
• Scenario Outline, Esquema do Cenário.
• Examples, Exemplos.

Para outro idioma basta utilizar as palavras equivalentes na linguagem desejada.

Feature (Funcionalidade)

Cada arquivo Gherkin começa com a palavra-chave Feature. Essa palavra-chave não afeta o comportamento do cucumber, ela apenas dá um lugar conveniente para escrever alguma documentação resumida a respeito do comportamento da funcionalidade que será descrita através dos testes.

Segue um exemplo da utilização dessa palavra-chave:

Funcionalidade: Esse é o título da funcionalidade

Essa é a descrição da funcionalidade que pode ocupar

diversas linhas.

É possível até mesmo colocar linhas em branco

De fato, tudo que esteja escrito até a próxima palavra-chave do Gherkin é incluído

na descrição.

Dentro de uma estrutura Gherkin válida a palavra-chave Feature deve obrigatoriamente ser seguida de uma das seguintes palavras-chave:

• Scenario
• Background
• Scenario Outline

Scenario (Cenário)

Para representar o comportamento necessário, cada feature contém vários Scenarios. Cada Scenario é um único e concreto exemplo de como a funcionalidade em questão deve se comportar em um caso específico. Todos os Scenarios de uma Feature juntos definem o comportamento dessa Feature.

Todos os Scenarios seguem o seguinte padrão:

1. Colocam o sistema em um estado específico.
2. Realizam algum tipo de ação.
3. Examinam o estado final.

Given, When, Then (Dado, Quando, Então)

No padrão Gherkin os estados, ações e asserções que ocorrem em um Scenario são representados pelas palavras-chave Given, When, Them, da seguinte forma:

Scenario:

Given <prepara o contexto>

When <executa uma ação ou evento>

Then <verifica o estado final>

Dessa  forma usa-se o  Given para preparar o contexto de onde o Scenario vai acontecer. Usa-se o When para interagir com o sistema de alguma forma e o Then para checar se o resultado dessa ação foi o esperado.

And, But (E, Mas)

Cada linha de um Scenario é conhecido como step (passo). É possível adicionar mais steps para cada Given, When ou Them utilizando-se And e But. Como no exemplo a seguir:

Cenário: Retirando dinheiro de uma conta com crédito

Dado uma conta contendo R$ 100,00

Quando eu requisito $ 49,00

Então o caixa deve liberar o valor de $ 49,00

E o saldo restante deve ser R$ 51,00

Essas palavras-chave não modificam o comportamento do Cucumber e existem simplesmente para promover a legibilidade dos Scenarios.